I spent several hours yesterday getting NixOS installed on a spare laptop.  I’ve been toying with Nix for a couple of years; it is an elegant solution to a thorny problem that all operating systems face, and about which I’ve written before: dependency hell.

The problem, in a nutshell, is that all modern software is built upon other software.  These are dependencies, and often, the software being depended upon isn’t explicitly aware of the dependents.  Certainly, when the authors of the dependees update their software, they’re unable to test all of the dependents.  Consequently, and perhaps inevitably, things break when software is upgraded.

Linux – and software written for Linux – is particularly susceptible to this.  Debian’s deb packager has done an admirable job getting around software dependencies; Redhat’s RPM has not.  Still, the frustrating thing for me has been the fact that none of these deal with two very common things:

  1. Users may want to install multiple versions of the same application at the same time.  Stable, and test.  This is extremely common because distributions simply can’t keep up with the pace of software development. There is always some piece of software that I need to upgrade that the Ubuntu package maintainers simply haven’t gotten to yet, and may not get to for a while.  I want Mercurial 1.2, and Ubuntu is still on 1.0.  Or, worse, and more commonly, there’s no back-port for it; I have to upgrade my entire system just to get newer software.  Which leads to the second item:
  2. Linux is horribly unstable.  Ever since Linus made the decision to get rid of stable kernels, any kernel upgrade is as likely as not to cause something on my laptop to fail.  Linux has the worst history of regressions of any software I’ve seen, and I’ve written a fair share of regressions myself.  Quality control is almost non-existent.  The CDROM stops working, or the sound stops working, or the damned graphics card stops working, or the network… [something]{.underline} breaks, almost every time.  What this means is that upgrading between versions of Ubuntu – which always involves a major kernel upgrade – is like playing Russian Roulette with five of the six chambers full.  After it’s aged a bit, any given version stabilizes.  In the meantime, you’re stuck with using year-old software releases, which – in computer terms – means that you’re using obsolete and unsupported software most of the time.

Ubuntu is really bad about the latter point.  Every single time I’ve upgraded to a new, major, release of Ubuntu, hardware that previously worked perfectly fails.  Gentoo is, possibly, worse.  I’m running that on a server and upgrade it rarely, and it is always a chore to get software working again after an upgrade.  So, when I recently revived a laptop, I decided to try a different distribution, called NixOS.

NixOS gets around both of those issues with a clever approach which is simple in concept: build and install software in a sandbox and link to its dependencies using a view composed of specific versions.  So, for example (and this is greatly simplified), Nix will build and install glibc-1.0 in its own directory and creates a view that contains glibc-1.0 as the “official” glibc.  Software that depends on glibc version 1.0 is built in this view.  Views can be composed of different versions of different software, so you may have a view that looks like this:

  • glibc-1.0
  • ghc-6.08
  • kde-3.5

and another view that looks like this:

  • glibc-1.5
  • ghc-6.08
  • kde-3.5

Any mix of compatible software can be installed, and you can switch your environment on the fly.

This is a very powerful concept; it lets you maintain multiple versions of software on a system, and it allows you to boot into different, major versions of the composite whole – which is not possible in any other Linux distro, or any other OS that I’m aware of – without depending on virtualization (which is hideously expensive).  Ironically, this is the same approach that ClearCase – that evil, poorly designed, poorly implemented, version control system – uses.  Only, here it makes sense, because the views are designed by the packagers, who know what the software dependencies are.

The problem with NixOS is that it doesn’t work.  It may be the nature of it’s being a young distro with few adherents.  It may be some flaw in the terribly complex system that implements the rather simple concepts.  But something is wrong with it.  For one thing, half of the software packages wouldn’t install; half of the messages were “unable to download the source package”, and the other half were compile errors in the packages.  And when I did manage to finally get X installed, it wouldn’t start, because X couldn’t find the video drivers – which were also installed.

So, NixOS has some pretty serious flaws, and isn’t ready for even casual use.  I’ll never run Gentoo again, because I don’t fancy spending all of my weekends doing system maintenance.  For kicks, I tried booting the Haiku R1α1 CD; Haiku is pretty impressive for how quickly it boots, but unfortunately has no USB support, so it was a non-starter.

I’d love to run Minix, except that there’s no virtual memory support. It is all pretty sad that, after – what,  thirty? Fourty? – years of modern computing systems, operating systems still suck. The only one that didn’t was NeXTSTEP, but Steve Jobs killed that off through mis-management and incompetence.

Right now, I’m re-installing Gobo from an old CD.  Gobo is a sort of half-way attempt at what NixOS does, but stops just short of the views.  This means that you get different versions of software, but not for the important pieces like libc.  Which is pretty crucial, if you’re concerned about regressions.  But, we’ll see; maybe newer versions of Gobo fix the problems I’d had with it before.  At the moment, I’m pretty depressed about it all.