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

[AdamW]

You say that, but why? It's not a completely unfamiliar OS - it's just the latest upgrade to the one I've been running for years, and which I expect to work *more or less* the same way as the previous version.

...that happens to contain completely new installer and upgrader code, a fact which is specifically listed in the release notes, which you *really ought to read*. That's what I'm talking about here, as it's mostly what the thread has been about. The rest of F18 is a pretty normal release and should be pretty solid, but the installer and upgrader code is entirely new, and this is hardly something we've hidden.

My complaints are with the way you're presenting this as a big deal, that people shouldn't be upgrading casually. I'm sure it's not your intention, but your messages are coming across with a strong subtext of "don't trust this release".

It is a big deal, because any time you do a ground-up rewrite of code as sensitive as the installer and the upgrade system, there's going to be borkage. My personal advice is to ensure you back up any sensitive data before installing or upgrading to F18. This is actually the sensible thing to do before you upgrade or install *any* OS, yes even 'just the next version of the one you were using before'. Upgrading in particular is an inherently sensitive operation and subject to the same 'problem space' problem I mentioned earlier: we (distributors) can test upgrade _mechanisms_ reasonably well, but it's very hard to test that upgrade goes off without a hitch in all of the billions or trillions of possible machine configurations (storage configuration, bootloader configuration and package set, mostly). My experience across distros (at least MDV, Fedora and Ubuntu) and operating systems (Windows - Microsoft's official advice is that you do not rely on upgrades between Windows releases working without problems, and in several Windows releases, they didn't offer a real 'upgrade' mechanism) is that even with releases which *aren't* major rewrites, you shouldn't trust the upgrade function unreservedly.

[energyman]

Maybe it's finally the time to actually address devastating Linux issues instead of constantly whining.

It's you, Linux developers, Alan Cox and Linus Torvalds included, who chose this f*cked up, absolutely broken, rolling development model. It's you, Linux developers, who get mad at it (even Linus has complained several times that userspace applications got broken due to incompatible changes in APIs).

Maybe it's the time to change?

But no, we'll have similar threads, complaints and pieces of news over and over again. And no one will do anything. No wonder people avoid Linux like a plague. In a world where no one is responsible for anything, where QA and testing are unheard of, nothing will ever be usable.

P. S. I for one chose CentOS 6.3 - but I'm a happy guy, 'cause I can run vanilla kernel - LTS distros are unusable as well, because the kernel development model is outright broken.

well birdie, maybe it is time for you to stop posting bullshit?
LINUX has stable APIs AND ABIs for more 20 years.

Internal constructs are neither APIs nor ABIs.

Please stop posting until you started to think. People like you with their 'give me. NOW' attitude and no clue at all make me sick.

[V!NCENT]

I found this on the fscking Fedora homepage:

After many years of maintaining and developing the pre-Fedora 18 installer, the installer development team determined that a rewrite of the installer was necessary for a myriad of reasons, including the following:

The previous installer had an aging (around 13 years old) infrastructure that was difficult and time-consuming to maintain and improve, constraining new feature development. One current install team developer refers to the old infrastructure as "an incredible mess."
The performance of the old installer left a lot to be desired. Long-term tasks could not be performed in the background. This required long wait times and pauses throughout the installation experience. For example, as CPU and time-intensive tasks were processed, the UI would freeze for several moments until a given processing task completed.
The previous UI was not very responsive. This manifested in various ways, including a failure of the UI screens to redraw when the display was changed between a TTY and back to the UI.
The text-only version of the installer interface was a completely separate codebase, which increased the maintenance burden of the installer. This also increased the amount of work needed to implement new features as they would need to be written twice, once for each codebase.
The previous codebase was not written in a modular fashion. This caused issues where similar functionality in different modes (for example, GUI vs kickstart) used different logic and resulted in inconsistencies for users.
The automated kickstart mode of the installer was separate and incompatible with the UI modes of the installer. A separate utility, system-config-kickstart, was created solely to provide a UI for creating kickstarts since the existing UI could not be used for this purpose without a completed install.
The live media method of installation used a different codepath than the installer than the DVD method, causing maintenance and development difficulties and resulting in an inconsistent and at times buggy user experience.
The old installer's interface had a 'point of no return' past which any changes you'd made to your storage configuration could destroy data on your disk(s) and you couldn't go back to change it. Since the UI followed a linear path, this exact inflection point occurred close to the middle of the screen flow and required a rather discouraging pop-up dialog to explain the impact.
In previous versions of Fedora, the installer's interface followed a wizard design pattern , consisting of multiple linear screens with occasional nested modal pop-up dialogs. (See diagram below) While nothing is inherently problematic with wizards as a design pattern, the sheer number of screens required by the installer made it unwieldy. You could end up several screens into the process and need to go back and change something on an earlier screen, requiring a lot of clicking and screen flipping to go back and return to where you left off. Multiple modal nested dialog windows also made it confusing at times to interact with certain screens, in particular the partitioning-related screens.

Good enough points to do a rewrite, huh? Guess the previous installer did suck...

[V!NCENT]

OK, this one example was not correct, I admit that. What about the other things mentioned in this thread where logout on a single user machine makes sense?

1. Leaving system on without logged users
How is that useful?

2. Switching DEs
Right. One can select spins for other DEs. In the case you want to mess with, say, Gnome3 and install E17, then why not also take the time to install Entrance (E17's Display Manager)? Problem solved and it looks a lot nicer too.

[eliac]

OK, this one example was not correct, I admit that. What about the other things mentioned in this thread where logout on a single user machine makes sense?

Remember: logout by default is not shown if there's a single user and only the Gnome shell session is available.
That covers the remarks I have read about Gnome developers not considering other desktops, and the remaining use cases seem to just fall in the remote access / headless background process category.

Now I very much hope that the same person who set up NFS or Samba or VNC server, who configured X for remote access or really needed to move users from group to group for some further reason won't have much trouble setting once and for all a gsetting by ticking a checkbox in a GUI or adding a one-liner to a setup script.

Really, that's what this silly fuss is about: a default that makes sense for the less techincal user and that whoever needs differently can override in about 30 seconds. The computer version of "first world problems", I'd say

[squirrl]

Meanwhile,

Back at the Hall of Slack. Their 'setup` still uses the old ncurses package to provide stable installations one after another.

Fedora is for testing. RedHat had no interest in the desktop.

[GreatEmerald]

I found this on the fscking Fedora homepage:


Good enough points to do a rewrite, huh? Guess the previous installer did suck...

Hmm, good points indeed. The multiple processes issue is also in YaST, and can get quite annoying (as is its inability to asynchronously download and install packages).

That raises another question, though - why did the UI have to change? Why not leave it as it was before, just on a new codebase?

[lsatenstein]

Too bad Cinnamon is not available in the Ubuntu repository.

Too bad OpenSCAD does not have syntax highlighting.

Some guys are spoiled. Some guys always write perfect code. Some guys were born as perfect coders and programmers.

Fedora 18 applications are just fine. UEFI delayed Fedora development to where delivery was late. Is the installer a bad design. I definitely say no. The concept is very good. Do the updates according to your preferences, -- keyboard, language, and so forth.

Is it a beta implementation -- a first effort to make it work, I say yes. It needs some extra quality control.

My fault with Gnome is that has the design that is trying to please desktop users and tablet users. And it does neither very well. So, if the argument about Fedora 18 is negative, you must blame the DE. (Presentation design).

I use Gnome rarely with Fedora 18. Cinnamon is a fantastic DE for Fedora 18. Cinnamon replaced Nautalus, uses the Gnome GUI libraries and is superb. It makes Fedora 18 much better than Ubuntu. If Gnome continues with one more bad release, you can rest assured that it will not be number one for Fedora 20.

One nice undocumented feature of Fedora18, is the ability to log into the system in GUI mode as root. Moving files, deleting files, copying files, renaming files, in fact directory and file manipulation with a GUI interface is so much faster and safer than with command line.

Fedora18 recognizes that system maintainers are not dumbells, who have to be prevented from using a graphical user interface from a root logon.

Cinnamon and Fedora 18, a great combination.

[BO$$]

Sheesh, it's weird how a perfectly simple comment goes over people's heads: someone said I was dismissing 'customers'. I was not, since Fedora by definition has no customers. You don't pay anything for it. Simple enough. I'm not saying anyone's cheap, I'm just saying that it is an inescapable fact that Fedora has no customers.

Your post is still borderline incoherent, but let me see if I can extract any sense from it:

"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?"

Define 'broken'.

Anaconda is an operating system installer. In fact it's one of the most capable operating system installers out there. It can install several million possible combinations of software packages to several million hardware configurations using several million storage configuration possibilities expressed via two completely different methods (interactive install vs. kickstart) and all kinds of other configuration possibilities. So our problem space is at least millions multiplied by millions multiplied by millions multiplied by two, and I'm simplifying.

When you're dealing with a problem space that large, a binary "it's broken" / "it works" distinction is entirely ludicrous. F18 installer has bugs. So did F17 installer. So did F16 installer. So did every installer anyone's ever shipped. F18 installer has more bugs than F17 and F16 (I think this is uncontroversial). Well, so did F15, and we shipped that. It's very difficult to make every release your best release ever. It's basically impossible to make a release which contains a ground-up rewrite of something as complex as an operating system your best release ever.

You had problems with F18's installer, and I'm sorry. Other people did too, indeed. Lots of people had problems with F17's installer, and F16's, and F15's, and so on. Go to the forums for any distribution around the time of a release and you will find people having problems with that release. You cannot possibly release a PC operating system which has no problems. It's just impossible. The problem space is too large.

So again: what does 'broken' mean? Usefully? Believe me, I'm a QA person. This is something I've thought about. Extensively.

As far as big overhaul goes - this is the big overhaul. The whole point is that you can't do a big overhaul and nail it on the first try. It does not need a big overhaul any more, it needs refinement.

"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."

Ah, "common sense: usually neither". One of my favourite aphorisms. You cannot predicate software development on some vague notion of 'common sense'. What common sense, exactly, allows one to roadmap the development of an extremely complex piece of software? You are the master of common sense: explain to me how you would have made the decision when to jump to newUI by default, given the constraints explained in the above posts?

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

Oh good, I'm glad you're here to tell me I'm insane. I wouldn't have noticed otherwise.

So look at our situation two weeks ago: we're sitting on a build of Fedora which has some issues but basically meets our release criteria. We're already several weeks late. There is lots of good stuff in F18 taken as a whole which people have worked hard on, and which users are expecting to get to play with. Why is it so blindingly obvious that the only sane path is to say 'we're not going to release this for another few months or at all'? Because that's what you're saying. The significant issues left in F18 are not ones that are quick patch-ups. The issue with re-using existing LVM containers, for instance, involves re-working how manual partitioning handles free space calculation, since right now it doesn't really consider the possibility of 'unallocated space inside a VG'. This isn't a one-line fix that can be safely tested in two days. Making changes of that significance effectively throws us back to the Beta phase of development: we would have thrown in some similarly impactful changes and basically restarted the Final validation process. I certainly would've expected that to put back release another month or so.

Sorry, but I disagree: neither of the things you suggested are the only possible choices for "a sane person".

"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."

That's still completely unhelpfully vague as a bug report. What were you doing in Firefox exactly? What does 'kill the system' mean? How much memory does the instance in question have? What error messages do you see? Etc. Fedora validation testing explicitly includes running Firefox in a virtual machine, I did it hundreds of times during release testing, never saw anything like what you're describing, and I haven't seen anyone else report it. I'm not saying you're not seeing a bug. What I'm saying is to bear in mind, as I explained above, that a computer operating system is a ridiculously complex thing and it can be deployed in literally billions of billions of configurations. There is absolutely no way we can guarantee weird bugs won't happen in some cases. On the contrary, they always have and always will. Check the history of absolutely any Linux-related discussion forum for this. You hit one in F18 you didn't hit in F17. That doesn't mean F18 is a crime against nature.

"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)."

This story never appears to finish in your post, but are you saying you did an 'automatic' install into empty space and it worked? If so, er, yay?

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

I have no idea what you're talking about. Uh. Yes, a typical F18 install would include a 500MB mount point, I guess? That's the standard size of the /boot partition. What is your problem here?

"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."

Er, but you've just talked about the partitioning process, so it sounds like you got there. What? Are you talking about a different machine here? What the hell is going on? I'm going to guess you got a kernel slowpath warn from abrt during live install (which happens sometimes) and then after install the installed system wouldn't boot. Okay, that's unfortunate, but I really can't begin to guess what the problem might be given that you don't say what your hardware is or really provide any other useful details...did you try any of the standard troubleshooting steps?

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

if this is what I'm thinking of, it's nothing Fedora-specific, it's just changes within ext4. I recall reading about something similar affecting Ubuntu users upgrading from 12.04 to 12.10. But again, you provide absolutely no useful details.

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

That's funny, it looks like you had a problem with Lightworks crashing in Ubuntu 13.04:

http://phoronix.com/forums/showthrea...000#post306000

and a problem running various distros - at least Ubuntu and MorphOS - on PowerPC:

http://phoronix.com/forums/showthrea...271#post305271

These are not problems with distros?

I just fucking love the justification level this guy reaches: look! Others have problems too! Look at Ubuntu! They have bugs too! We have bugs in previous releases so why shouldn't we have bugs in this one? Bugs are perfectly normal! I mean what is so wrong with having bugs? You should learn to cherish your bugs! Learn to live with them, learn from them, accept them! They are OK! You are OK! See? You are both OK! Marry your bugs! Love them! Learn to be patient and solve your bugs instead of doing your work! Everybody has bugs! Why should we be below them and have less?

There are billions of combinations of hardware! Why do you think it should work? It shouldn't! If the last past 3 releases it didn't work it's because you weren't lucky! Not our fault at all! Why should we be expected to actually test code on different machines? It's insane, think of the billions of combinations!


And in a different note: You rewrote the installer? Bwhahahaha! RULE NUMBER 0: NEVER REWRITE APPLICATIONS FROM GROUND UP! I thought you knew this stuff! They teach this shit early when you learn coding for christ sake. Everytime there is a new idiot thinking that he is better and starts to rewrite an application thinking this time it will be better, and in the end, after trillions of bugs and frustrated users that leave his product, he ends up where he was before he begun!

AGAIN: NEVER REWRITE APPLICATIONS FROM GROUND UP!

That maintenance thing is just bullshit. Learn to use interfaces so that when implementations change you can still have your old functionality. I wonder how incompetent can you be. Then I realize this is Red Hat we're talking about....

[GreatEmerald]

One nice undocumented feature of Fedora18, is the ability to log into the system in GUI mode as root. Moving files, deleting files, copying files, renaming files, in fact directory and file manipulation with a GUI interface is so much faster and safer than with command line.

That's horrible. You are supposed to do this, or an equivalent thereof:

kdesu dolphin .