New Anaconda – a retrospective

During FUDCon, I got to wondering: with all the rewriting and refactoring and fixing we’ve done on anaconda in the past couple years, is there any of the old code left anymore?

So: git blame --line-porcelain and a little python later:


There’s two things to point out here:

  1. About 90% of the code in current anaconda HEAD was committed (note: not necessarily written) in the year-plus-a-bit since Fedora 16.
  2. Nearly half of the new code was added in Fedora 17.

But this just shows when the code was committed – not when it was designed or written. Or, for that matter, why.

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 backend 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 predated 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 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:


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!

Even code that worked OK was still crusty and weird. There were still places in anaconda where it did things like:

  if f[0:5] == "/dev/":
      count = count + 1

because Python 1.x didn’t have “+=” or “.startswith()“.

The long-overdue redesign

By January 2011 we’d started serious planning to redesign the UI and rework a lot of the backend pieces. That FUDCon is the one where I did the first whiteboard sketch of the current hub-and-spoke design:hub-and-spoke whiteboard sketch

We started laying the groundwork immediately. We changed the way the installer images were built, so all of anaconda was crammed into initrd.img. This landed in Fedora 15 (May 2011), paving the way for us to gradually remove loader from the installer.

We also spent a full year doing lots of prototyping and design work, all in public view, reaching out for feedback in any way we could think of – at one point, Máirín printed out the mockups and taped them to the wall of the office so passers-by could comment on it.

After a year of development, an early NewUI prototype was first made public in November 2011, just before Fedora 16 was released and Fedora 17 development started.

As time went on, it became clear that handling upgrades and installation in the same tool made everything a lot more complicated. Every discussion seemed to get stuck in this loop:

“Yeah, that seems like it would work… oh, but what about upgrades?”
“…oh. Right. Damn, that makes this much harder.”
“Oh, maybe we could do it like this?”
“Yeah, that seems like it would work…”

By January 2012 we decided that it would make a lot more sense to handle upgrades with a separate tool, to be written later – like as soon as we finished Fedora 17.

The longest year

Working feverishly through the Fedora 17 development cycle, we continued design and development on NewUI while also replacing all 18,000 lines (or so) of loader with a normal initramfs.. you know, with udev and modprobe (and bash so you can actually debug things). Fedora 17 was released at the end of May 2012.

Two weeks before we even finished Fedora 17, the new Anaconda UI was proposed for Fedora 18. We wanted to do this as early as possible, to make sure everyone was aware of the scope of the changes and the risks involved. FESCo approved it unanimously, as-is (without any text UI planned).

We started merging NewUI into the main development branch a few days after the Fedora 17 release. Meanwhile, I went straight from rewriting loader to writing fedup.

The Fedora 18 release cycle was grueling, but progress continued. As the Fedora 18 Alpha release approached, someone proposed delaying NewUI until Fedora 19. FESCo considered the idea, but decided to go forward with NewUI. We worked later and later nights. There was spirited and occasionally unkind feedback. The text UI suddenly became a requirement, so that had to be added. We worked through vacations and holidays. The release dragged on and on.

After two months of !!RELEASE PANIC!!, NewUI and fedup were declared finished enough to satisfy the release criteria, and shortly thereafter Fedora 18 was actually released.


And how was it received? Well, some people really like it. Some don’t:

[…] fills the needs of novice users admirably by clarifying the most problematic features […], it fails almost everyone else, particularly experienced and/or advanced users with sophisticated needs.

[…] a total failure in that it not only fails to improve upon any aspect of [previous versions’] equivalent GUI features, it actually makes every single one of them substantially worse.

I continue to enjoy the technical aspects […] and I hold out hope that they will listen to users and reconsider some of the UI decisions

Oh, my mistake – these are actually from early reviews of Mac OS X. Whoops!

Dumb jokes aside, the bottom line is this:

The redesign/rewrite was sorely needed. It’s not perfect – what 1.0 release is? – but it still does what it’s supposed to: get the bits onto your disk. It does everything most folks need it to do, and does it quicker and easier than any previous version.

And it still has the most advanced storage management of anything I’ve ever seen (let me know when gparted can set up iSCSI, for example). And it still has full backwards compatibility for Kickstart-scripted installs.

Most importantly: unlike the old anaconda, we can actually work on this code. It’s vastly more flexible, and sane, and modular – the storage library has been split into its own separate package, for example.

So sure, there’s room to improve. But now we’re in a place where we can actually make improvements, which is far, far more important. And we’ve got plenty of improvements planned for the next release already.

But if you’re dead-set on keeping the old installer, or you think we’re a bunch of idiots who got the UI all wrong, well, that’s the beauty of Open Source: the code’s right here. Feel free to show us how it should be done! Enjoy! I look forward to seeing what you come up with!

(This discussion continues in Package handling in anaconda – another retrospective)


45 thoughts on “New Anaconda – a retrospective

  1. Pingback: » Anaconda didn’t just shed its skin Ryan Lerch

  2. This was a nice reading. Although for me the major problem with F18’s NewUI was those annoying bugs in the non-english translations, the amount of screens and text to just resize/format an partition was not exactly nice. Indeed, now that I think, the single thing I’d change in the NewUi would be replacing the “Continue” button with an “Auto partition” and a “Manual Partition” buttons.

    The fact that it looks somewhat weird in non-Gnome3 environments also annoys me, but, well, let’s hope for a future better integration. I, for one, would love an QML Anaconda.

    • Yeah, translations were definitely a problem – but rewriting nearly all the code means that nearly all the strings changed too, which means the translations all need to be redone.

      Luckily this is a simple matter of time – the translations will probably be much, much better in Fedora 19.

      Try to remember that the old anaconda had nearly fifteen years to get all its translations in order. I hope everyone will give us a few more months to sort things out!

  3. I read through the to-do work on the page you linked. I didn’t see anything about fine grain package selection. Is that something that is planned? It really needs to be. I should be able to weed out unwanted packages from groups or add misc. packages from the installer.

    • In short: no. And this is intentional.

      If you really do need this, look into writing a kickstart file. All you need is a %packages section that specifies the exact packages that you want. You have complete control – add and remove packages or entire groups, plus you can create users, automatically partition the system to your liking, configure services, set up the network devices.. the sky’s the limit with kickstart.

      But if this is just a personal preference – something you’re used to doing and really miss – in the end it’s far easier and safer to add and remove packages after the install is finished, using the normal system tools. You could even write a “” script that does this for you – including setting up .bashrc and other configuration files – and just download and run that after the install finishes.

      But no, we’re not going to be writing yet another package management frontend. There’s more than enough of those already.

      • So true. Especially since after the installation, you have a much more useful setup ( like you can browse the web, listen to music, discuss with others on what you want to install ). Anaconda is the wrong place to do that, because you spend more time on something that is offering a rather too simple UI when compared to what you could do on a real system.
        And pushing the customisation to the after installation step do not let some people think they need to reinstall to customize, or that this is a crucial step.

      • First, I should note that I really appreciate the work that has gone into Anaconda, and I was waiting for new UI for releases!
        But, there are a few things that I’ve also noted in my recent blog posts:
        1. I liked the theme in the mockups much more. Their blue theme makes Anaconda a really refreshing look, and I really liked it. It is much more beautiful than the current standard GTK colored UI IMHO.
        2. While I (and probably many others) would really appreciate find-grained package selection in the UI like before, but there are more serious problems with the current package selection (some of they were also in previous Anaconda UI but the ability to customize package selection made it less annoying) is the left columnt, in which you can only select one category. There are two problems with it: 1. Why someone should not be able to select multiple categories? What if I want both a web server and set of development tools (e.g. I might be a web developer). What if I want to install two desktop environments? 2. The categories are too inflexible. Why I can’t select my desktop environment if I want to select a development workstation (I don’t remember the exact names)? I want to have a KDE based development system, but I can’t select that in the current UI. At least, I think selecting the target desktop environment (can be: Gnome, KDE, other graphical DEs, and Shell environment (No X)), should be separate from selecting the purpose of using the system (e.g. development or web browsing). I know that it won’t fit with the current way groups are organized (we don’t have groups for text mode development tools, but we have some kind of KDE development tools and Gnome development tools IIRC), but I think this is how it really should be.

        And about this: “…in the end it’s far easier and safer to add and remove packages after the install is finished, using the normal system tools…”. Well, not true. Consider someone who do not have access to a fast (and cheap) internet connection who have acquired Fedora DVD and want to make best use of its packages. The current installer isn’t flexible enough, and you can select a very limited set of packages. Now, consider you are going to install missing packages after the installation. Is it easy? A normal user will have no Idea how it can install remaining packages from DVD. AFAIK, Fedora currently doesn’t have any user friendly method to recognize DVD as a repository and install packages from it. The user should create a repository file manually, probably disable fedora and updates repositories (so that package manager doesn’t try to use internet), and then try to install packages it wants. This is certainly broken. I agree that it should be fixed in PackageKit and Yum, but it hasn’t for years (broken since Fedora 4, (almost) worked in a few releases in between but broken again). I used to suggest people to select most of what they want in the installer so that they won’t need to struggle with such issues, but now… .

      • The package selection was a big plus for me at the old installer. I was looking for a bare minimum installation, since my old laptop has really, really small disk. As an amateur Linux user with no desire to became a specialist I removed a lot. Too much, so I get an unusable system. When I tried again I was more cautious and remove only the stuff I know I do not need and left unknown libraries, applications alone. But after several days of use the system updated itself and since there were some dependencies missing I got almost all of the removed stuff back.
        What I would really love is to be able to get a bare minimum installation (no office tools, no mail client, no picture editor software, no multimedia players), since I (and probably many more) spend a good amount of time replacing them with our tools of choice. You have mentioned kickstart script and post installation scripts. But I prefer not to use them and install everything using the provided package management solution.
        I generally like the new installer. It is easy to use even for a non expert. It has some rough edges but for people like me, that would like to install OS without googling how to do it, it is an improvement. And I am looking forward to see the improvements during the next few releases. And I would be really happy if you would reconsider the minimal vs all-included install 🙂

      • You make some good points. However, in my experience, it was far easier to pick the packages I wanted at installation and only install them than to install all the fluff that came in the groups that I didn’t want, uninstall it all, and then install the packages I actually wanted. It isn’t convenient to have to rely on preconfiguring a kickstart file for every install I want to do. Its also really inconvenient for those on limited bandwidth who are trying to do a netinstall.

        I assume that the new anaconda will end up in RHEL eventually. I don’t know about most people, but anaconda is the closest thing my servers will ever get to a gui interface. Having to pick out packages to remove or add from a command line stinks, although there is a greater chance that I will use a kickstart file for a server. Unfortunately the system-config-kickstart app appears to be broken at the moment. (I will try to remember to file a bug in the morning).

        From a UI perspective, you are trying to make things easier for the user, but the new groupings contain no information about what is actually in them. You pretty much have to blindly guess what a group is going to give you, how much space the group is going to require, or if a certain package even is included in the install media. And what about other repos? They may not have any groups set up.

        Just some thoughts….

      • This is really ridiculous. In the old Anaconda, the developers had already tried 2 or 3 times to remove individual package selection. Each time, user uproar forced them to put it back in the next release. It’s incredible that you still haven’t learned the lesson!

        At this point, I really have to wonder why we even support the installer DVD at all, especially now that upgrades are no longer handled by it. Package selection was the only advantage left over installing from a live image, so if you don’t want to put that back, why are we even bothering with the installer DVD at all?

      • Kevin: you’ve asked that question several times, and people have given you perfectly sensible replies, and you’ve then ignored them and continued to ask the question as if it hadn’t been answered. It’s rather tiring, I wish you’d quit with that tactic.

        To briefly recap one of the perfectly sensible use cases for the DVD image: the most obvious is that it can handily be written to a physical disc and given to someone who can then choose what package loadout they need. A single DVD will not necessarily be used only by one person, one time; it may be used by many people, used many times, or both, with a different loadout each time. There are several others. Please drop the stick and move away from the dead horse.

  4. I like the idea of the re-write for the reasons listed but PLEASE reconsider not giving us the ability to select packages in the installer!

      • A few reasons come to mind.

        i) Net installs – the bandwidth concious might not want to install a whole heap of packages only to remove them later.
        ii) Disk space limitations for those using older hardware.
        iii) Doing a minimal and building it up can be problematic and wastes time.
        iv) GUI package managers are not as easy to use to add / remove additional packages as the previous installer was when you are talking about setting up a whole new install. I could make sure I had what I wanted + dependencies and nothing more.

        I liked doing it that way – it worked well for me and allowed me to set up the system how I wanted. I have no desire to write scripts to replace functionality that should never have been removed.

        I can deal with it not being there for a release or two whilst Anaconda is being perfected as its not strictly necessary to get a system working but it is a step backwards. I should not have to prune the unneeded components from my system and add required ones post install. I should be able to have the system install and boot with what I want.

        I hope this stance about it not being needed will change as there is certainly enough community support for the functionality.

      • i) Net installs – the bandwidth concious might not want to install a whole heap of packages only to remove them later.

        So do a minimal install and add stuff afterward? Or install something more lightweight than the standard desktop?

        ii) Disk space limitations for those using older hardware.

        Again: then maybe you need a minimal install? Or something more lightweight than the standard desktop?

        iii) Doing a minimal and building it up can be problematic and wastes time.

        Ah, saving time! That’s exactly why we wrote kickstart – so you can automate installation!

        iv) GUI package managers are not as easy to use to add / remove additional packages as the previous installer was when you are talking about setting up a whole new install.

        Yes, new tools take some getting used to.

        I could make sure I had what I wanted + dependencies and nothing more.

        Which you can still do, with either a) yum, or b) a kickstart.

        I liked doing it that way – it worked well for me and allowed me to set up the system how I wanted. I have no desire to write scripts to replace functionality that should never have been removed.

        Here is the heart of the matter: “I liked doing it that way”

        Look, I really do understand. It is frustrating and annoying when things change away from the way you are used to using them.

        What you don’t understand, though, is exactly how much effort it was to maintain the godawful package selection screen that was in the old installer, and how few people actually used it, and how much better and easier the other solutions are. (There will be a longer post about this shortly.) [edit Feb 7: see Package handling in anaconda – another retrospective]

        I hope this stance about it not being needed will change as there is certainly enough community support for the functionality.

        Well then, if there’s community support, I’m sure the community will help support this feature they love so much. I look forward to seeing the mockups and getting patches and/or pull requests!

      • Kickstarts don’t save any time whatsoever if you are installing only one machine (the common case), they actually take you MORE time because of the extra step, and they also basically require you to have an already working Fedora environment to run system-config-kickstart on (unless you’re really good at hand-editing text files), which is not the common case either (especially if we’re in the single-machine setup).

        So no, “use Kickstart” is not an acceptable answer to complaints about missing UI functionality.

      • Hi Kevin! Thanks as always for showing up to say that everything we’re doing is wrong and never offering any help fixing it!

        See you again next release!

      • I am interested to know just how cumbersome the old package selection code was to maintain and why? Also if there is maybe another way it could be implemented to make it easier to maintain in the future?

        I am also keen to know if actual stats were gathered on what modifications people tended to make and how the Anaconda team determined that there was not a great deal of need for package selection due to minimal usage?

        Also, Kickstart is not a solution. It is used to deploy the same install to multiple machines not to get your single install the way you want it.

        Unfortunately we are not all developers – some of us are just lowly users who have an interest in the open source environment so we can’t all come up with solutions or even fully understand the technical implementations of some solutions. I guess what I am getting at is why something that has been around for many releases (package selection) which has worked well for me and many others now all of a sudden so hard to maintain?

        Whilst I disagree with the direction you have taken with the new installer – I appreciate the efforts the anaconda team have gone to assisting users to understand it. Fedora in my opinion often suffers from a disconnect between developers and users so actually having developers respond to blog / forum posts means a lot to users like me!

  5. Hi Luka,

    “What I would really love is to be able to get a bare minimum installation”

    There *should* have been a ‘minimal’ install option on the left-hand pane of the ‘Software Selection’ spoke… that’s a particular package group I think you can select from. You definitely shouldn’t have to manually pick through a long list of packages to get to a minimal install that might not even work – we do that for you in the minimal package group. If it wasn’t listed there, that’s a bug – did you not see it? It should have been listed alongside the various desktop options.

    • 🙂 I am sorry for my previous comment. I really did not remember seeing that screen. But after I saw the picture I remembered I have seen that screen during install. I just did not read the whole installation screen after I found the GNOME option 🙂 I will try it as soon as I had a chance. Thank you for your reply!
      Oh and I have to correct one sentence in my previous comment: “The package selection was a big plus for me at the old installer.” should be “The package selection seemed a big plus for me at the old installer but …”

  6. Pingback: Fedora 18 (Spherical Cow) review |

  7. What I see is that over the years, you Anaconda developers managed to increase the memory requirement for installing Fedora by a factor of 12 (!), due to “improvements” (which you’re advertising as such in this blog post) such as replacing that small statically-linked C loader by a huge subset of the installed system, throwing the whole stage2 into the stage1 initrd and delaying swap space creation. I think these are all steps in the wrong direction.

    • Darn it, maybe you’re right! Maybe what the Linux community needs is someone who will make steps in the right direction, back toward statically-linked C code that runs off floppy disks!

      I look forward to seeing your fork of anaconda! You’ll probably want to start from f14-branch, since F15 is where stage2 got put into initrd.

      PS. we actually split stage2 back out of initrd in F17, and memory use for CD/DVD/USB installs is around 200MB. But don’t let that stop you! Have fun!

    • You’re right, our time was better spent maintaining our own implementation of mount, our own DNS resolver, our own dependency solver, our own window manager, and our own module loading tools.

      • HA HA OH MAN that’s right! I can’t believe I forgot about mini-wm!

        Remember how we also had our own completely separate network configuration stack? So we had to write our own UI and config file handling for, like, IPv6 and bridging and proxies and routing VLANs and everything else?

        And when we tried to replace all that with nm-connection-manager, it didn’t work because mini-wm didn’t know how to switch between windows?

  8. I’d like to thank you for the great work you’ve done. Whilst the new installer looks much better I have a few suggestions I’d like to forward to the team. What is the best way to do this, feature requests with bugzilla? or is there a better place to put suggestions?

      • Moving ‘done’ to the lower right would violate adherence to how GNOME does this. You cited how GNOME does wizards and single window dialogs. We’re following the hub and spoke model, which in GNOME corresponds to the gnome-control-center. There is no done button in the lower right of the control center – it is in the upper right. The difference here:

        – Wizard is back and forward, a left-to-right motion, so buttons along the button make sense
        – Hub and spoke is moving up and down…. so having a button in the upper left makes more sense to go back up to the hub from a spoke which is lower down.

        I like the idea you have here of moving the notification area to the top, although the idea needs a bit more visual design work to look ‘right’ than you have in the mockups you did.

        The keyboard layout preview on the keyboard screen you did doesn’t make sense to me – which keyboard is it a preview for if you have multiple keyboards in the box?

        I like the idea you had in the mockups of having a green checkmark to show which screens you’ve visited, I think we should definitely investigate using that.

        Thanks for taking the time to do the mockups, a lot of good ideas there! We’ll definitely take a look!

    • Thanks for the feedback.

      Based on the fact your using the hub and spoke model, I think that it would be better to change the ‘Done’ button on each screen to the same icon used in the gnome control centre. If following the gnome control centre model it would nice to have the section header as the window title, this would add a sense of consistency from install through to day-to-day usage (assuming the end user is running Gnome).

      I’m glad you like the idea of notifications at the top – it definitely needs work (I’m certainly not a graphic designer I just cut and pasted screenshots! Hence the poor quality and mis-matched fonts…)

      In response to the keyboard screens, the idea would be that on entering that spoke the default keyboard is highlighted and the keyboard preview shows the layout for the selected keyboard. I’m not sure why you would ever have multiple keyboards highlighted in that section?

      The same for adding multiple keyboards, it might be a quick way to add lots of keyboards, but how many keyboard layouts add in general? If multiple keyboards where highlighted maybe the preview dims in response. It’s probably not clear from the mock up, but I was expecting the keyboard keys to be blank and as a keyboard was selected the keys would fill with the correct characters for the key map.

      Thanks again for all the hard work the anaconda team put in. My tinkering has given me an new appreciation of the complexities of good design.

      • Ah, okay – I think maybe in your mockup there was no keyboard in the list highlighted so I got a bit confused about the mechanics. I get it now – if no keyboard in the list is selected the keys in the preview go blank; as soon as you select a keyboard in the list its keys get loaded into the keyboard graphic. I like this, and it might eliminate an additional dialog which is always good. We do have a pending redesign to that screen though, I have to dig it up, but I think some things shifted around – hopefully we still have that space on the bottom to do the keyboard preview with the rearrangement of the screen.

        We did actually try to add the GNOME icon to the button before F18, but ran into some odd GTK issues and had to punt it (higher priority items were still on the queue and we were running out of time), I will add putting the icon in to the list of work items to try to get into F19.

        And on that note, I will say that there is sadly a significant amount of design in the anaconda new ui dictated not by how we wanted to it look and feel, but because of issues we ran into using GTK. The GTK and Glade folks were *extremely* helpful and supportive and really helped us get to where we are, but a lot of times we’d get stuck on something that should have been simple and ended up eating hours and we’d have to punt because stuff like not eating someone’s hard drive for dinner is always higher priority than UI layout. One of the biggest issues we ran into was with the GTK cell renderers not rendering properly and causing usability issues. (For example, try putting a dropdown in a GTK Tree View… it doesn’t look clickable at all until you click it. :-/ )

        Anyway thanks again for your mockups – can you set a license for them so we can use them? CC-BY would be ideal. I could then copy them into our mockup repo for reference (giving you full credit, of course.)

  9. It is easy to explain how one thing should have been done: If the innards were old and creaky and absolutely needed a rewrite, then that is *all* you should have done. Totally changing the back end and the UI at the same time was a horribly bad idea that drained resources from both sides and in all likely-hood wound up with both still needing fixes.

    • It is easy to explain how one thing should have been done: If the innards were old and creaky and absolutely needed a rewrite, then that is *all* you should have done.

      That’s exactly what we did. Over the past 8 releases we rewrote everything that needed rewriting, piece by piece. Some examples:

      • F10: Replaced network backend, rewrote build system
      • F11: Rewrote storage backend
      • F12: Improved storage backend
      • F13: More storage backend improvements
      • F14: Rewrote logging, replaced crash handler
      • F15: Rewrote media handling, replaced image build tools
      • F16: Replaced init system, rewrote GUI backend logic
      • F17: Rewrote initrd and boot option parser

      The only backend piece we rewrote in F18 was packaging. And that was because it was so entwined with the GUI that it made more sense to do them both at once.

      I think this is what confused you: the reason the code in anaconda HEAD is 90% new is that all the previous rewrites moved code out of anaconda. We replaced crusty old code with more reliable upstream tools (NetworkManager, report, systemd, dracut…) and polished the good parts into standalone tools and libraries (blivet, pykickstart, lorax…)

      If you were really trying to offer useful criticism, you should probably do some research into how we actually develop software before you give further advice. I’ll be happy to answer any questions if you have any!

    • “It is easy to explain how one thing should have been done: If the innards were old and creaky and absolutely needed a rewrite, then that is *all* you should have done. Totally changing the back end and the UI at the same time was a horribly bad idea that drained resources from both sides and in all likely-hood wound up with both still needing fixes.”

      I think Will has pointed out several reasons why the old UI was just as problematic. If you didn’t see them, I suggest a re-reading. Also check out

  10. Pingback: The new Anaconda installer « the blog of Chris

Leave a Reply

Fill in your details below or click an icon to log in: Logo

You are commenting using your account. Log Out /  Change )

Google+ photo

You are commenting using your Google+ account. Log Out /  Change )

Twitter picture

You are commenting using your Twitter account. Log Out /  Change )

Facebook photo

You are commenting using your Facebook account. Log Out /  Change )

Connecting to %s