Fedora 18 Is Now One Month Behind Schedule

[Pallidus]

"the website of fedora looks very corperative, very company-biased"

maybe because it is? and who gives a fuck... I tell you what I much rather have a company like red hat be open about their agenda "we are giving you fedora so you will use it and test it so then we can port shit over to our money maker: rhel" than a company like canonical trying to monetize their system by making it phone home to amazon and shit like that.


I'm no expert in linux but in the last couple months I tested every distro under the sun, from mint to arch. I have settled with fedora because it's plain to see it's the superior one.

Now I don't hate gnome but I also don't like it that much, kde and xfce look like they were made by kids with crayons, lxde is fast and functional but looks like ass... I do wish in fedora 18 they would steal lubuntu's 12.10 theme because they managed to make lxde look pro, that and a software center would also bring monkeys like me to the dozens to fedora.

[AdamW]

https://bugzilla.redhat.com/show_bug.cgi?id=798844

thats my bug.

1. fedoras bug is a bit older ok not much but at least there were 2 stable releases since this time so it matters.
2. 1. month later a response form a paid ubuntu dev (after the conformation of the 2nd bugreport)
3. 2 months later he posted a solution that made the card work again, shurly no distro-bug but at least anybody who search this bug, is able to fix the sound
4. the bug is basicly fixed and the dev waits for the inclusion in upstream of this bug.

5. it seems that its fixed upstream but that its not on fixed stand is because the alsa devs did not answer his last question to make sure it works:
http://mailman.alsa-project.org/pipe...ly/053749.html

so its basicly fixed 1month later you had a workaround and 6 months later its fixed in ubuntu next it should work.

So way way extremely better support than what I got here:

https://bugs.launchpad.net/ubuntu/+s...er/+bug/960124

so your example in fact does prove how much better ubuntu support is.

Er. What? You can't compare two completely different bugs. That just doesn't work at all. My example was 'the Vaio Z bug in Ubuntu vs. the Vaio Z bug in Fedora'. Not 'The Vaio Z bug in Ubuntu vs. your bug in Fedora'. That'd be a silly comparison.

Frankly, for sound issues, my advice is, regardless of what distro you're running, report them upstream to the alsa-dev mailing list. That's the best chance you have to get a fix. As far as I know, no distro has more than one full-time audio maintainer (Fedora has Jaroslav Kysela, SUSE has Takashi Iwai, Ubuntu has...dunno?), but _everyone_ who works on Linux audio - including the distro developers - subscribes to alsa-dev and does all their work upstream then filters it down into the distros. So you have a far, far better chance of getting an issue fixed at the upstream ALSA level than you do of getting it fixed in any distro.

Not to blame you, since there's no way you could know, but a problem with your Fedora report is that you filed it against alsa-lib not kernel, so it got assigned to Jaroslav personally - no-one else is on the bug. He isn't great at handling bug reports, to be honest, since he's too busy being the audio guy for the whole of Red Hat. If you filed it against the kernel, all the kernel maintainers would see it, and there's a decent chance they'd at least catch the fix going upstream and backport it to the Fedora kernel if nothing else. I'll re-assign to the kernel and see if the kernel team can do anything about it.

To the preupgrade thing I tried that, it wasnt painless,

Again, this is just anecdata. We already know there are cases where upgrade doesn't work, regardless of distribution. Kano and I explained why this is pretty much always going to be the case. So one report of a case which didn't work doesn't _tell_ us very much in general.

but if you dont recommend it its poor.

Sorry, I may have been confusing there: preupgrade is a supported upgrade method for Fedora. It's *yum* that isn't, officially speaking. (Though in practice, lots of people use yum and it usually works fine; it's not supported because there are some things a package manager-based upgrade just can't handle, like say the /usr move or a bootloader change. When those things happen we have to provide instructions for people to do those changes manually when upgrading via yum.)

And to upgrade from a usb-stick or something like that, is not very userfriendly.
why can debian do that since 10 years without a usbstick boot and fedora not? or is it since 20 years? ^^

Again, this isn't true. Fedora can online upgrade the same way Debian does, using its package manager. I believe Debian goes to greater lengths to try and make sure this is usually possible without manual workarounds, but in practice it works a lot of the time in Fedora. The fact that it's 'supported' for Debian and 'not supported' for Fedora is mostly a policy issue. 'Support' for upgrade methods is something of a fiction when it comes to Linux distributions, to be quite honest. It's not like anyone gives you your money back (well...) or comes over and fixes your system for you if it goes wrong, after all. And it's not plausible, as I already explained, for any distro to just flat out say "it will always work and you will never have problems". So what we 'support' is more down to appearances than anything else. This is why I've lately been trying to use 'recommend' rather than 'support' when it comes to upgrade methods...

And if you say in 18 there is a new one, thats basicly then because the old way did suck, or why would you fix something thats not broken.

Basically it boiled down to deciding there was no reason to keep the upgrade code in the installer any more. The Old Way was that we had two recommended upgrade methods - preupgrade, and upgrading from the installer directly. These were quite similar (preupgrade in the end just fires the installer) but did have significant differences (preupgrade writes out a kickstart and boots the installer via a kernel pair, both things that can break independently of a regular installer-based upgrade breaking). So we had to test and fix up both, which was a pain for no readily apparent benefit. There was also no intrinsic reason the upgrade-your-system code had to be tied to the install-a-system code, so why not split them out when we were re-writing the installer anyway? It grew naturally out of the installer rewrite - someone said 'hey, while we're rewriting the installer, why not get the upgrade code out of it'.

So the new system works more or less like preupgrade but does the actual upgrade-your-system step via dracut (the initramfs environment). It mostly just updates the system packages using yum, and then custom dracut scripts can handle any operations that need to be done outside the package manager - like the /usr move thing, or a bootloader re-install, or anything like that. It's a cleaner design in general, and it will be our sole recommended upgrade method, which reduces the testing and maintenance burden. And it can be maintained and updated separately from the installer. It's certainly better than the old way, but that doesn't mean the old way was _broken_ exactly.

[AdamW]

Yes, that's what I was talking about. Right now I'm on F16 and nobody tells me there's a new release out there. But in this case, it's for the better because I ouldn't upgrade if I wanted to (businees requirements). Regardless, I think such an option make a distro way friendlier in the eyes of newcomers.

Ah, right, we don't have an upgrade applet that actively notifies you that a new release is out, no. It wouldn't be a very difficult thing to write, I think just no-one thought it was super important yet. But maybe I should ask Will if he wants to do it as a feature for F19 or something.

@Kano: Yes, I also use the separate /home partition "trick". That way I can break anything and not give a rat's behind.

Yeah, it's a pretty good option to have available on any distro.

[blackiwid]

Er. What? You can't compare two completely different bugs. That just doesn't work at all. My example was 'the Vaio Z bug in Ubuntu vs. the Vaio Z bug in Fedora'. Not 'The Vaio Z bug in Ubuntu vs. your bug in Fedora'. That'd be a silly comparison.

You tried to make a point in comparsion of your audio bug and mine, so its the best bug we can have, and they handeld it much better than my bug, sorry. you can say its my fault because I dont konw which people are more active in whatnot subsystem but you cant think that all your users know that. I am no kernel dev with knowledge of 500 kernel devs and what they are doing.

so ok I guess you have to compile your own kernels and stuff and find the right developers without any support to be able to use fedora? ok.

As far as I know, no distro has more than one full-time audio maintainer (Fedora has Jaroslav Kysela, SUSE has Takashi Iwai, Ubuntu has...dunno?)

you dont need a kernel dev to give support, its enough that someone is there who gives you some advise or something. Like that guy at ubuntu, that was also no alsa-dev just a guy who has some technical and processable knowledge. Even the automatic janitor process that changes the status on this bug is some feedback...

Not to blame you, since there's no way you could know, but a problem with your Fedora report is that you filed it against alsa-lib not kernel, so it got assigned to Jaroslav personally - no-one else is on the bug.

you can´t blame me for searching first if someone else did post the same bug, and I found someone that postet it, so I added my "I have the same Problem" to maybe get more attention because more people are affected.

He isn't great at handling bug reports, to be honest, since he's too busy being the audio guy for the whole of Red Hat. If you filed it against the kernel...

to fill a bugreport is what most users just dont do, they go away if maybe using windows or so. ok you can say if someone than says something against linux, he should have done that. instead of posting to forums, but if someone do that, you cant blame them for assigning the bug to the wrong group, when its not obvious, and this is not obvious. So close his bug-responsibility merge the alsa-group to kernel and the problem is fixed, I have no second sight.

Again, this is just anecdata. We already know there are cases where upgrade doesn't work, regardless of distribution. Kano and I explained why this is pretty much always going to be the case. So one report of a case which didn't work doesn't _tell_ us very much in general.

thats not the point, each distro cant guarantee that for all users upgrade dont work, but the preinstall tools are not userfriendly, I dont have aproblem with console tools but why is there no yum --dist-upgrade; done no 5-6 tools and stuff very amateurish and to read that its not recommand and that did stand in the wiki, thats also not good, just because you cant guarantee anything, you shoudl not tell people that its not recommand because most people use tools that the developers who created it are not recommand it to use it.

Sorry, I may have been confusing there: preupgrade is a supported upgrade method for Fedora. It's *yum* that isn't, officially speaking. (Though in practice, lots of people use yum and it usually works fine; it's not supported because there are some things a package manager-based upgrade just can't handle, like say the /usr move or a bootloader change. When those things happen we have to provide instructions for people to do those changes manually when upgrading via yum.)

so there is a yum way to upgrade like apt-get dist-upgrade? so why the hell would you not recommand to use that?

Again, this isn't true. Fedora can online upgrade the same way Debian does, using its package manager. I believe Debian goes to greater lengths to try and make sure this is usually possible without manual workarounds

I dont await that you are having such quality than debian have, its impossible because debian freezes stuff for like centuries so they make it pretty stable at some point, you cant compete with that wiht a bleeding edge distro, but then say yes allways something can break everywhere, but you should update with yum or something and its ok. then I use it and 99% of the times I am happy...


btw I am very disapointed about systemd, thought that would be a great thing, maybe it is, but not in the most important point a desktop user cares, in boot time, fedora 17 did boot way slower than ubuntu 12.04 or so.




BUT I apriciate, and that you did move this bug to a better place, when there somebody gives a workaround or something or a statement of upstream/fedora bug state in fedora 18 thats mostly all I want, the other stuff is more a userfeedback from a knew user and what he sees there and how it looks for a new user when he tries your distribution. Flaming is not my "main" point, its kind of a feadback + a bit frustration of no reaction from your devs. so hope that changes now

[AdamW]

You tried to make a point in comparsion of your audio bug and mine, so its the best bug we can have, and they handeld it much better than my bug, sorry. you can say its my fault because I dont konw which people are more active in whatnot subsystem but you cant think that all your users know that. I am no kernel dev with knowledge of 500 kernel devs and what they are doing.

I didn't mean to imply you did anything wrong. I was simply pointing out a different bug which showed a different result from the one you pointed out: the bug I pointed out showed a better result on Fedora than Ubuntu. Which was just in support of my point that things are more complex than 'distro XX is better than distro YY', when it comes to hardware support stuff. Distro XX might give you a better experience, Distro YY might give me a better experience, Distro ZZ might give that guy over there with different hardware a better experience. It's just such a huge problem space that the results are never going to be completely clearcut.

so ok I guess you have to compile your own kernels and stuff and find the right developers without any support to be able to use fedora? ok.

No, that's not what I said at all. I only mentioned compiling anything once, and that was in relation to the Vaio bug *on Ubuntu* - right now, to get working sound on that machine in Ubuntu, you have to compile the ALSA drivers (using a DKMS package, though, not doing it manually). I didn't say anything about compiling your own kernels for Fedora. Again, for sound issues, the best chance of getting a sound issue fixed *whatever distro you're using* is to report it upstream to ALSA, simply because everyone who works on sound for Linux works at the upstream ALSA level first. You will always reach the greatest possible number of audio developers by posting to alsa-devel.

you dont need a kernel dev to give support, its enough that someone is there who gives you some advise or something. Like that guy at ubuntu, that was also no alsa-dev just a guy who has some technical and processable knowledge. Even the automatic janitor process that changes the status on this bug is some feedback...

Sure, that kind of feedback (we usually call it triaging) can help and it's probably true that Ubuntu has more people doing that than Fedora does at present.

to fill a bugreport is what most users just dont do, they go away if maybe using windows or so. ok you can say if someone than says something against linux, he should have done that. instead of posting to forums, but if someone do that, you cant blame them for assigning the bug to the wrong group, when its not obvious, and this is not obvious. So close his bug-responsibility merge the alsa-group to kernel and the problem is fixed, I have no second sight.

I already specifically said I wasn't blaming you. I'm not arguing with you, I'm just trying to provide you with useful information on the specific reason you had a bad experience with that report.

thats not the point, each distro cant guarantee that for all users upgrade dont work, but the preinstall tools are not userfriendly, I dont have aproblem with console tools but why is there no yum --dist-upgrade; done no 5-6 tools and stuff very amateurish and to read that its not recommand and that did stand in the wiki, thats also not good, just because you cant guarantee anything, you shoudl not tell people that its not recommand because most people use tools that the developers who created it are not recommand it to use it.

preupgrade doesn't really have much UI to it, that I remember, you pretty much pick a release to upgrade to, hit 'Go', and that's it. It asks you to reboot half way through.

As far as yum goes, the step 'yum --releasever=XX distro-sync' is the equivalent to apt-get dist-upgrade. Most of the other steps on the instruction page aren't strictly *required*: 'yum update yum' is just to make sure you have the latest version of yum which will give you the best chance of the upgrade working, but if you've been keeping the system up to date you'd have it anyway. 'yum clean all' cleans the yum caches, and is really just a precautionary step...I don't usually do it and it shouldn't usually be necessary, it's just included because in some odd case it could potentially cause a problem, so the instructions are playing it safe. 'yum groupupdate Base' will add any packages we added to the default install package set since the previous release, which you might want, but again it's not usually actually _needed_ (it's another step I don't usually do). And reinstalling the bootloader isn't usually necessary either, again, it's just included in the instructions to be safe. Honestly, I pretty much just do 'yum --releasever=XX distro-sync' and that's enough (plus anything in the specific instructions for the upgrade I'm doing).

so there is a yum way to upgrade like apt-get dist-upgrade? so why the hell would you not recommand to use that?

Yes, see above. And I already explained why it's not recommended. https://fedoraproject.org/wiki/Upgra...-.3E_Fedora_17 is a classic example. In Fedora 17 we did a feature called '/usr move' - we moved everything from /bin into /usr/bin, everything from /sbin into /usr/sbin, everything from /lib into /usr/lib. This is a major change and it can't be implemented entirely through a package manager (any package manager) for detailed technical reasons I won't bother going into, just take it on trust - yum couldn't do it, apt couldn't do it, no live package manager could safely achieve such a move, it _has_ to be done while the system is offline. So if you're upgrading from F16 to F17 using yum you have to do some fancy footwork to achieve the /usr move first, *then* do the yum upgrade. If you don't do that it'll go very wrong. Another example would be that we switched from grub to grub2 between F15 and F16 - again, that's not something you can safely have the package manager do automatically. So because version upgrades sometimes need changes like that, which the package manager can't handle, we don't feel like it's a good idea to make yum upgrades a 'recommended' upgrade mechanism, because you can easily get into trouble doing them if you don't check the instructions and do the manual steps properly.

For other releases, though, there aren't any such changes and the process is pretty smooth. F17 to F18 is a pretty smooth yum upgrade. F14 to F15 was too.

I dont await that you are having such quality than debian have, its impossible because debian freezes stuff for like centuries so they make it pretty stable at some point, you cant compete with that wiht a bleeding edge distro, but then say yes allways something can break everywhere, but you should update with yum or something and its ok. then I use it and 99% of the times I am happy...

Based on my experience, as long as you always check the info on the 'upgrading with yum' page, then yeah, upgrading with yum actually works perfectly well. I have my desktop, laptop, VM host machine and four VMs (personal servers) running Fedora and I upgrade them all from release to release with yum, and since I follow the instructions properly, they've all survived all the upgrades fine so far.

btw I am very disapointed about systemd, thought that would be a great thing, maybe it is, but not in the most important point a desktop user cares, in boot time, fedora 17 did boot way slower than ubuntu 12.04 or so.

I think a lot of the news stories concentrated way too much on boot time when it comes to systemd, and that isn't really the main benefit of systemd at all. systemd can _theoretically_ improve boot time somewhat, but in practice, boot time is usually much more dependent on bottlenecks in what actually gets run on boot - no matter what the init system is. So yes, it's perfectly possible for a SysV or upstart-based distro to boot faster than a systemd one out of the box. It's certainly not going to be the case that all systemd systems smoke everything else for boot time or whatever. I think some journalists didn't really realize that upstart can do parallelization, so can pinit (which Mandriva used for a long time), and parallelization doesn't have a _huge_ impact on boot times anyway (it's usually only like 15%). So they expected systemd to be some kind of elixir for boot times or something, which it just isn't. You're certainly right about that.

The interesting benefits of systemd are much more to do with _functional_ stuff. The classic one is socket activation - say you have the httpd service 'enabled' in systemd, that doesn't mean httpd necessarily runs when the system starts up, instead, it runs the first time someone actually tries to connect to port 80 (that's a simplified example, but you get the idea). A service can be set to fire when something tries to connect to its port or to a dbus service it provides or some other types of socket.

But really there's a huuuuge range of stuff that systemd does that's really cool, way too much to mention in one forum post. Some of the conditionals it allows are really neat - a service can fire only if you're booting from a live image, for instance. Or only if a certain kernel parameter was passed (or not passed). Or only if the system is being booted within a virtual machine. It's really damn clever.

systemd can give you all kinds of information on services too, systemctl is very powerful. You can show all running services, or all active services, or all services on the system, or just all failed services, or something like that. You can get the logs that are associated with a specific service (if you have the journal enabled). You can see the service's cgroup (basically all the processes associated with that specific service). There's lots of stuff on Lennart's blog and on the systemd site if you want to dig into it, but it really does have all sorts of cool capabilities that sysv just didn't. It's worth noting if you're an Ubuntu user that upstart is also pretty cool and powerful and has some similar advanced capabilities to systemd, there are significant differences between the two but both upstart and systemd are really pretty neat compared to sysv. I think a lot of Ubuntu users just treat upstart as a sysv-replacement init service but it's really better than that.

BUT I apriciate, and that you did move this bug to a better place, when there somebody gives a workaround or something or a statement of upstream/fedora bug state in fedora 18 thats mostly all I want, the other stuff is more a userfeedback from a knew user and what he sees there and how it looks for a new user when he tries your distribution. Flaming is not my "main" point, its kind of a feadback + a bit frustration of no reaction from your devs. so hope that changes now

[/QUOTE]

Sure, like I said, I'm not trying to argue with you mostly, just have a conversation Thanks for the feedback!