It’s no secret that the new Anaconda installer for Fedora 18 has caused a stir. As part of a major internal re-write, the user interface has been completely re-designed which has caused some confusion and there are bugs and missing features. This is why we included an install video in Korora 18, to help walk you through the process.

However, like all good free and open source software, while this might be the case now it will just keep getting better (especially if users report their problems and post ideas on Bugzilla). Fedora 18 was so delayed that the community didn’t have a chance to address all issues in the interface, unfortunately. Some of the badness has already been fixed for the next release however, with more improvements to come.

So, yes, it might be hard to use for this release but it’s getting better. And thankfully it’s just the installer and not the rest of the interface, so it’s a one-off pain, not an every day one. If it’s really a drama, one could install version 17 and use FedUp to upgrade without using the new installer.

Finally, Anaconda developer Will Woods an excellent blog post on the re-write, which really opens your eyes to the need for it (it’s much, much more than just the user interface).

Here’s some of the content:

Why rewrite, anyway?
Back in August 2009 we were trying to redesign the storage UI to handle modern storage needs. This turned out to require rewriting a lot of the storage back-end code (again) because the existing anaconda code was basically all duct tape and bubble gum, creaking under the strain of modern demands.

You might think I’m exaggerating, but keep in mind that anaconda was originally written in 1999, for Red Hat Linux 6.1, It was designed to run off a 1.44MB floppy, using the still-newish Linux 2.2.x kernel.

In 2009 it still had its own custom initrd init system – called “loader” – written entirely in C. (Statically-linked, too, until 2007.) So anaconda had its own copy of stuff like mount(), and losetup, and mknod.. but no bash before the GUI started. (Good luck trying to debug anything!)

The design pre-dated udev and /sys – and devfs, HAL, and NetworkManager, and dbus – and had its own builtin module loading stuff instead of depmod and modprobe. So anaconda was doing all the hardware setup (probing, module loading and unloading, network setup, disk setup, RAID setup, etc., etc.) by itself… and not always doing it well. And every time there was a new device driver for anything we had to manually add support for it to the installer.

And specifically on the user interface:

And then there’s the GUI. It was single-threaded, so (for example) while we waited for lvm or yum to do something the UI would just.. stop drawing. If you dragged a window around you just ended up with big empty gray blotches until lvm finished and let us start refreshing the UI again.

It was also designed for much smaller screens – 640×480, or 800×600 if you were lucky. You can’t fit much on a screen that size (smaller than your average smartphone!), so it made sense to break the process into a series of steps. Except by 2009 you ended up with screens that looked like this [when setting the root password]:

Great use of space there!

The logic for moving between steps had also gotten really hairy and fragile. Like, as soon as you finished partitioning the disk (but before you picked software to install!) we formatted the disks, because we used to need swap space to even think about running yum. But then what happens if it turns out you need more hard drive space to install the stuff you want? TOO BAD, YOU CAN’T GO BACK NOW!

So on behalf of Korora Project please forgive us for causing you frustration, but we’re here to help and believe us when we say it is already improving!