Alan Cox Calls Fedora 18 "The Worst Red Hat Distro"

[AdamW]

this is coming from someone that used and liked fedora 17:


fedora 18 is not only the worse fedora release to date, it's also a broken distro that should have never been released.



The writing was on the wall and when, month after month after month, they noticed how broke everything was THEY SHOULD HAVE SIMPLY DELAYED OR CANCELLED fedora 18


jump straight to 19 or release 18 in 19's date....



Alan Cox wasn't the only one jumping to ubuntu


hell even the alpha right now is 238912833 times more stable than fedora 18

You realize, as a Fedora dev, this message just goes right to my junk filter, right? I mean, it's meaningless. It contains no useful data. You don't say what problem you had, you don't construct any kind of coherent argument. You basically just say 'it sucks'. This is not useful feedback for anyone.

We have a defined set of release criteria for Fedora and a process that ensures it reaches those criteria. The F18 release was delayed because we were going through that process: once we hit the criteria, it got released. The criteria do not say 'it must be perfect', and it's entirely the case that some releases exceed the criteria while some may only hit them. This is a thing that happens in software development. Given the nature of Fedora and the development cycle we're working on, we are never going to hit a perfect release every time, especially when that release involves rewriting the entire installer.

[AdamW]

Strawman. Of course Red Hat is not a charity which develops Fedora for the benefit of mankind.

The person I was responding to explicitly invoked the word 'customer'. It's hardly a strawman.

I agree that the criticism that some people have voiced on Fedora 18 is too harsh, and that lots of people worked very hard to improve the release in many areas. That makes it even more sad to see their work overshadowed by that turd of an installer. I have very little insight into the development process, but it appears to me that there was no proper backup plan in place so the only choice was to push out the release:

• Fedora 17 had an installer that worked just fine. So you could have continued to use that, and optionally provide your new installer to those who want to test it.
• You could have recommended users to ditch the installer altogether and link to a document instead which describes manual partitioning + febootstrap as the preferred install method (Gentoo does it like this, and Arch has recently adopted this way too).
• You could have labeled Fedora 18 as "Forever Beta" and not make it an official release, just something for the interested.

Any of these steps would possibly have led to a lot fewer disappointed users than what we are seeing now.

Perhaps you could consider *gaining* some insight into a development process before criticising it? This is not a snark, it's a genuine suggestion. All the points you raised have been raised repeatedly, and explain repeatedly, in all sorts of venues - the Fedora mailing list, the forums, here on Phoronix - over the last few months. I'm getting pretty tired of explaining it _again_.

"Fedora 17 had an installer that worked just fine. So you could have continued to use that, and optionally provide your new installer to those who want to test it."

That's not how things work in practice at all. You are by all means free to confirm this for yourself: take the Fedora 17 installer, plop it down in the Fedora 18 package set, and try to build an installer image. Ten to one it won't even compose, but on the offchance that it does, the composed image will _certainly_ be entirely busted. It won't work at all and will probably eat babies.

This is actually one of the major reasons we're doing newUI in the first place: a significant part of the work involved in maintaining any OS installer is simply in keeping it up to date with the rest of the system. You can't just take the installer from one release, shove it in the next, and call it good. It has to be maintained to account for changes in the rest of the system. oldUI in particular was getting to the point where maintaining it from release to release just so that it worked _the same_ - not noticeably better - was taking up a significant proportion of all the resources we had for installer development. That meant we couldn't really do a lot of work on making the installer better.

One of the major advantages of newUI is that it should require rather less running-to-stay-in-place maintenance work than oldUI did. However, as long as we do something like your plan - variations on which were suggested umpteen times by people who are not aware of the details - we were making the resource problem worse, not better: because we have to _both_ maintain oldUI _and_ work on newUI. newUI work did not start in the F18 cycle, it started back around the F15 cycle; so for three releases the anaconda team has been trying to work on newUI while simultaneously maintaining oldUI. This causes significant stress on them, slows the pace of newUI development, and probably means oldUI wasn't getting quite all the love it needed.

So any scenario in which we're continuing to work on both installers - let alone one where we actually offer and to some extent support both installers, which is pretty much the nightmare scenario - is a vary bad and unsustainable one.

This whole setup gives us a very strong reason to get newUI in as default as early as practical: now we have hit the point where newUI is in as default, we're in a much better place. We can kick oldUI to the curb, no-one has to work on it any more. Everyone is dedicated to making newUI better, and now we have a release out where newUI is the only option, we are getting lots of feedback on what bits of newUI need improving. The pace of newUI development will be far more rapid than it would have been had we tried some kind of do-both-at-once approach.

"You could have recommended users to ditch the installer altogether and link to a document instead which describes manual partitioning + febootstrap as the preferred install method (Gentoo does it like this, and Arch has recently adopted this way too)"

That's...interesting, but really not in line with how Fedora rolls, I don't think. It would have been just too drastic for a single release. newUI really isn't that terrible, you know; quite a few people have been saying 'it worked fine for me, I don't get the fuss'. It's at its most awkward when you're using custom partitioning with existing complex layouts, and I think that describes quite a few Phoronix users as this is one of the places for distro tweakers, but it doesn't describe everyone. If you're just doing a fresh install to a VM, for instance, it rolls fine. Even custom install to an empty disk works pretty nicely.

"You could have labeled Fedora 18 as "Forever Beta" and not make it an official release, just something for the interested."

That again would have been a valid approach, but I'm not sure it buys us a lot. At this point we have the same product and it's just about massaging the messaging. That's something we already tried to do with the release announcement and other release documentation, and see how much slack that's bought us.

[AdamW]

Why was shipping F18 with the old installer not an option?

See above post. It _was_ an option, we did not go into the F18 cycle committed to newUI. But we had to make a call at some point - and it had to be a substantial amount of time ahead of a release - as to when we were going to jump to newUI by default. And we had powerful motivation to do it as soon as possible, because things are much better for the future once we've jumped. Back in the mists of six months ago, we decided F18 was the right time to jump. We nearly did it for F17 before, BTW.

With hindsight there's a reasonable case to be made that it might have been better to wait for F19, but that's a very difficult call to make six months ahead of time. The practicalities described in the previous post mean it's not really viable to jump then jump back two months later, because then you have to retool and try to fix up oldUI for the new release, which is just as bad as trying to hack newUI into usable shape. It's pretty much a one-time call.

[AdamW]

Now Alan Cox has left the Linux developer community:

http://linux.slashdot.org/story/13/0...ux-development

See what you did Fedora? You drove him to Ubuntu, and he couldn't take it for very long! Now he's gone.

Our secret is that we're terrible people.

[GreatEmerald]

Something so invisible needs to be killed. Gnome needs to stop hiding UI elements, it kills everyday usability. OS X has a few things absolutely right, like the app menu bar locked at the top of the screen (I can find the File menu of the current app with my eyes closed)

Huh, so that was an idea from Mac OS X? I thought it was just Unity developers trying to be different for no good reason...

I agree that Fedora goes too far with the minimalization concept, but that's because the design goal seems to be the corporate desktop. Just look at all the fiddling one must do to enable the extra repos and make the installation consumer friendly. It reminds me of tweaking a Windows 98 install.

Actually, I think you're confused here. Maybe it reminds you of tweaking a Windows 8 install? Because Windows 98 never needed any tweaking to make it usable. Actually, it barely had any options that could be tweaked in the first place. It's only later that they added more options and made them default, and thus now you need to spend a few hours to configure Windows to act as it did in Windows 98 times. And it gets worse with each Windows release.

http://i826.photobucket.com/albums/zz188/kaczu_bucket/logout_zps55487f73.jpg

This really isn't THAT hard. You would think for those of us (not speaking to you directly) who compile programs, configure wine, or hell give me something (install RAID?). I don't know but this...

Hah, that's pretty funny, before reading the post I thought that the image there was from Android or so. But then I realised that this is actually GNOME 3...

Perhaps you could consider *gaining* some insight into a development process before criticising it? This is not a snark, it's a genuine suggestion. All the points you raised have been raised repeatedly, and explain repeatedly, in all sorts of venues - the Fedora mailing list, the forums, here on Phoronix - over the last few months. I'm getting pretty tired of explaining it _again_.

It was never answered in this topic before, and those are genuine questions. No need to be so harsh about that.

This is actually one of the major reasons we're doing newUI in the first place: a significant part of the work involved in maintaining any OS installer is simply in keeping it up to date with the rest of the system. You can't just take the installer from one release, shove it in the next, and call it good. It has to be maintained to account for changes in the rest of the system. oldUI in particular was getting to the point where maintaining it from release to release just so that it worked _the same_ - not noticeably better - was taking up a significant proportion of all the resources we had for installer development. That meant we couldn't really do a lot of work on making the installer better.

That's... interesting. I don't know that much in this field, but it doesn't feel right. What changes does the installer need to reflect? New package versions? I don't think all the installers of all the distributions need as much maintenance. I suppose the old Anaconda could have been an exception, though.

At this point we have the same product and it's just about massaging the messaging. That's something we already tried to do with the release announcement and other release documentation, and see how much slack that's bought us.

Oh come on, it's a well known fact that nobody ever reads manuals and licenses these days

[AdamW]

That's... interesting. I don't know that much in this field, but it doesn't feel right. What changes does the installer need to reflect? New package versions? I don't think all the installers of all the distributions need as much maintenance. I suppose the old Anaconda could have been an exception, though.

So interesting trivia: the reason F18 Alpha was delayed had little to do with newUI itself and everything to do with dracut. Yup, dracut. anaconda is built on top of dracut, just like Fedora itself, and if your initramfs-handler-thingy decides to make drastic changes between releases, anything built on top of it is going to need to handle those changes. We merged newUI - which we'd tested in a side branch was working quite well - into Rawhide, and it promptly exploded all over the place because we hadn't had the new dracut in the side branch (for stability!) and the code hadn't been adjusted for it. (oldUI was never adjusted to the new dracut either; one of the major problems with rolling back to oldUI at any time would have been replicating all the work we did to make newUI work with the dracut changes).

Anyway, just an example. anaconda in general is built on top of rather a lot of other components of Fedora. It uses NetworkManager for network configuration, for instance. It uses yum's interfaces for package installation. It uses the packaged grub2 to set up the installed system's bootloader, it uses packaged libparted for a lot of partitioning stuff, etc etc. It's a part of Fedora like any other in some ways - it's not a static blob of code laid on top, it builds against or calls out to the current packaged version of all those bits. When you build a Fedora installer image, you're essentially building a small self-contained special-case Fedora environment: the build process pulls in the current packaged kernel, dracut, anaconda itself, libparted, NetworkManager, systemd (that's another one anaconda commonly has to react to changes in), etc etc etc etc etc and smooshes them together. Booting anaconda is really just booting a specific Fedora instance with a systemd config that runs anaconda.

The 'static blob of code' approach is possible, but it comes with its own problems - you're really just trading one set in for another. If you give your installer its own network config code, or just throw a static NM build in there, you solve the problem of having to potentially adjust your installer code for changes in NM, but you give yourself some other problems instead. If you write separate network code for the installer, well, now you have two piles of network code to maintain. You can leave the network code in the installer alone and it'll probably keep more or less working, but how do you support wifi installs, when wifi comes along? Well, you've got to write a bunch of wifi code into your installer at the same time you're writing a bunch of wifi code into NM. Seems stupid. If you throw a static NM build into your installer...when do you update it? Once a cycle? What if a fix for some important bug comes along and you get it in your actual distro but not in the installer? seems sub-optimal. What if your installer winds up writing out a configuration that the installed NM can't read properly because they're different versions? Again, not great. Anyhoo. Yeah. That's the issue. You _can_ write an installer that requires less maintenance than anaconda, that's true, but at the cost of not gaining the advantages of improvements in the underlying components.

Oh come on, it's a well known fact that nobody ever reads manuals and licenses these days

Sadly seems to be true, but still not excusable. I wrote it a bit flippantly, but I am _genuinely_ amazed that it seems to be quite normal these days to assume you can throw a completely unfamiliar operating system at the computer that contains lots of your precious data and just expect to be able to Work Stuff Out As You Go Along. That's just bonkers.

[Pallidus]

"You basically just say 'it sucks'. This is not useful feedback for anyone."


Anaconda is broken and it has been broken since day one and it needs a big overhaul.



At first it was just me saying that... now there are plenty of others, are we all wrong?


Common sense would dictate that the cheer ammount of changes, and the heavy nature of, you were about to make in fedora WOULD REQUIRE much more than the time you had in the development window.


so a sane person would either continue to postpone the release or simply skip 18 and deliver a functioning and stable f19.


I mentioned the problems I had in f18's live sessions as they would simply crash firefox and kill the system, someone said they could be due to memory management, strange as f17 never did that and 4gigs were always enough to test f17 beta and it never crashed once.

I was about to install the beta but since I couldn't connect to a hidden wi fi and had a bunch of other small issues I (luckily) backed out.


When the final release came I picked up a windows 7 laptop that had plenty of unpartioned space and installed by selecting 'boot device yes' (grub installed well) and I did let anaconda do everything automatically since it said it required no input (how hard could it be really, 1 partition with windows 7, 200g of unpartioned disk space).

Manually partitioning the disk is a clusterfuck, mount point 500mb ?? I even picked standard partition as I had no need for LVM.

During install I get a Kmod 04044 something error and then it boots into the fedora logo, the wi fi lights light up etc but blank screen... blank screen... blank screen.

ext4 partitions couldnt be mounted due to fs incompabilities etc etc...


I'm sorry but I had 0 problems, ZERO, with any linux distro thus far.



That comment about "getting your money back" is counterproductive, why does microsoft go around the college here giving copies of windows 8 to IT students?

The people that are using fedora today could be a rhel contract tomorrow, so you shouldn't dismiss them as cheap guinea pigs.

[Hamish Wilson]

Dear Slashdot, switching one system that run Ubuntu in a VM to Fedora into running Ubuntu does not constitute 'switching to Ubuntu'. I've been running Unbuntu for some jobs (like building Android images) for ages 8). In fact I run several distros (Fedora still included)

And for that matter my goldfish boot/stress test image is a hacked Debian fs image...

Maybe he should have mentioned Phoronix as well...

I'm leaving the Linux world and Intel for a bit for family reasons. I'm aware that "family reasons" is usually management speak for "I think the boss is an asshole" but I'd like to assure everyone that while I frequently think Linus is an asshole (and therefore very good as kernel dictator) I am departing quite genuinely for family reasons and not because I've fallen out with Linus or Intel or anyone else. Far from it I've had great fun working there.

Most of the people who should know more do, I know I've missed a few.

I may be back at some point in the future - who knows. In the mean time if you'd like my job (or indeed one of a range of others) we're hiring 8)

So, tell me, how does this equate to moving to Windows guys?

[finalzone]

Fluxbox and Blackbox.

I took the time to reproduce the issue by installating both Fluxbox and Sugar and restarting the system. On gdm login screen, the session is available containing Fluxbox and Sugar.
I do not know how you cannot access to Fluxbox while I successful got there without a fuss.

[GreatEmerald]

Anyway, just an example. anaconda in general is built on top of rather a lot of other components of Fedora. It uses NetworkManager for network configuration, for instance. It uses yum's interfaces for package installation. It uses the packaged grub2 to set up the installed system's bootloader, it uses packaged libparted for a lot of partitioning stuff, etc etc. It's a part of Fedora like any other in some ways - it's not a static blob of code laid on top, it builds against or calls out to the current packaged version of all those bits. When you build a Fedora installer image, you're essentially building a small self-contained special-case Fedora environment: the build process pulls in the current packaged kernel, dracut, anaconda itself, libparted, NetworkManager, systemd (that's another one anaconda commonly has to react to changes in), etc etc etc etc etc and smooshes them together. Booting anaconda is really just booting a specific Fedora instance with a systemd config that runs anaconda.

Ah, that makes sense. But it still doesn't look to be so difficult. Sure, all these dependencies change, but do their interfaces change that often? Why would an updated NetworkManager suddenly break things? And if it does, does it really break more than once per release cycle? And building a mini environment with the required components should also not be as difficult. Sounds like building a LiveCD, and that is not really that hard. Not sure about the whole dracut situation, though.