If this is your first visit, be sure to
check out the FAQ by clicking the
link above. You may have to register
before you can post: click the register link above to proceed. To start viewing messages,
select the forum that you want to visit from the selection below.

NM was just an example, in practice, it's usually stuff like dracut, systemd and libparted that require changes. There's other bits too - these are all just _some_ of the things anaconda builds on. And you have to remember the 'problem space' calculation I just did for Pallidus: we are not working with a simple bit of software that does a couple of things, here. One set of changes to dracut can break initialization of the installer in both BIOS mode and UEFI mode, reading existing disk partitioning in all kinds of ways (we've got to consider LUKS encryption, MD and DM RAID arrays, LVM and btrfs containers, exotic storage stuff like iSCSI and multipath, and that's just a sampling), and umpteen other things - fixes to any of which can then expose other issues elsewhere. The easiest way to understand this stuff is just to get involved: go work on installer development or testing for your favourite distro. You'll pick it up in no time, believe me.

Hah, well, my favourite distro is openSUSE and its installer is YaST, which also happens to be the control panel and thus pretty much the central part of the distribution. So I can see how things can go wrong in that sense, but then again, YaST never had any rewrites (well, actually, there was that time when it was rewritten from YaST1 to YaST2, but it was 13 years ago). And I haven't seen many complaints about how difficult it was to maintain it - but then I haven't specifically looked for it, either.

Speaking of which, what makes the new Anaconda better in this regard, compared to the old one? Why is it now easier to maintain, aside from no longer needing to develop both in parallel?

Comment

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.

Perhaps a more appropriate word is "Consumer." Clearly the Fedora team has consumers, otherwise, why would they produce anything?

Ubuntu 13.04 is at alpha 1, kernel 3.8 and sna for intel... it should be unstable as all hell... I had it installed for a couple of weeks and run live sessions a couple of times a week, how many times has it become unresponsive? 1

compare that to fedora 18... I can't count the number of times it just simply killed X and crashed.

I didn't say I was comparing it. You said you had zero problems with other distributions. I showed that statement was false. You're the one who went around inadvisedly making definitive statements.

I already said, several times, that the problem with shipping a PC operating system is you're shipping a combination of several thousand moving parts and telling several billion people with several billion hardware configurations 'here is something that will probably work on your computer'.

Every Linux distribution ever released will fail to run X on some computer somewhere. You will never find one which didn't. The 'problem space' is so huge that individual changes in it are probably more subject to chaos theory than any simplistic notion of QA: you simply cannot conclude anything definitive about the 'quality' of one distribution compared to another, or one release compared to another, based on anecdotal evidence of 'well, my computer worked with X but didn't work with Y'. It's just not plausible. There are billions and of Xs and Ys. You have to go up to the scale of thousands of reports, or something like a solidly-triaged bug of the kind 'All graphics card of generation foo completely fail to work in X', before you can draw meaningful comparisons. And even *then*, it's tricky.

Comment

I understand that but I do have a bunch of intel centrino laptops that HAVE to be 100% linux compliant.

Everything from the gfx to wi fi has to function out of the box in every distro

Fedora 17 worked like a dream.

Fedora 18 my first experience I booted into the live_ram or live_session no longer remember the command and I went to firefox 16.02 (months ago) open youtube and watch a 50 minute html5 video = firefox dies, doesn't start again, entire graphical desktop environment dies, system dies.

and to be honest my experiences with it didn't become better

it was a punch in the stomach for someone who really liked f17, so yeah I understand that's probably working well for a lot of people but I my perception is my realiy and for me it failed.

So I think what may be going on there is that Firefox now caches HTML5 video live so you can jump around in it, and old Firefox didn't do that. I wonder if we could disable that on the live session, or set a limit. But yeah, stuff like that happens; it's pretty hard to catch it all.

Comment

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.

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.

And for the record, it *is* mostly working for me, once I worked out that I needed to manually install gstreamer1-libav to replace the older gst-ffmpeg - not strictly a Fedora problem since it's a third-party repo, but it did mean that none of my videos worked anymore. 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".

Comment

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.

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.

Comment

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

Comment

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.