NixOS: A Distro Focused on Next-Generation Package Management

NixOS is not about to challenge Ubuntu or Fedora as a desktop distribution any time soon. But, then, user-friendliness is not its point. Originally developed by Eelco Dolstra as a doctoral project at Utrecht University, and now developed by a small team at Delft University of Technology in the Netherlands, NixOS is designed as a test of Nix, a new package manager designed to overcome key problems with existing package managers. As a result, what you think of NixOS is likely to depend largely on your interest in package management.

The installation routine alone is enough to put off many desktop users. I say “routine” because it is not an application, but a series of steps that, if you’re a long-time GNU/Linux user, could make you think you’ve slipped twelve years into the past. Not only is installation completely command-line based, but you create and format partitions using such time-honored tools as fdisk, mke2fs, and mkswap, and mount the install partition in the /mnt folder.

You then have to create a configuration description file by running the nixos-hardware-scan script, and adding information about the target device for the GRUB bootloader and the root and swap partitions using either nano or vim. You can always press Alt+F7 for instructions, but don’t be surprised if you have a false start or two before you manage to run the install script. Fortunately, any errors in your configuration description become obvious in the first couple of minutes, so you don’t have to sit through the entire installation before you try again.

Exploring NixOS

Once you successfully run NixOS, chances are that you won’t want to linger over the programs, except to complete the installation by adding a root password and everyday account. NixOS has a standard assortment of software, including a 2.6.26 kernel, KDE 3.5., Compiz, OpenOffice.org, and WINE, but, in this case, the desktop software is beside the point.

Instead, take the time to see how NixOS is structured, and to consider why. To start with, notice that the configuration file whose creation was the main feature of the installation is actually a flexible tool for administration. By running the nixos-rebuild script with various options, you can quickly create and test multiple configurations without making your system usable. Should you choose, you can maintain multiple system descriptions that appear as options in GRUB, creating different configurations for different purposes or users. Similarly, if you accidentally create an unusable configuration, you can still boot into your system using another one, or use the installation CD to create another one. No configuration is deleted unless you specifically choose to remove it.

The same principle of redundancy applies even more strongly to packages. Within NixOS, each installed package and its configuration file is placed in a separate folder under /nix/store, rather than such usual locations such as /us, /bin or /sbin, where later versions of software generally overwrite earlier ones. Even /etc consists largely of symbolic links to /nix/store, with the exception of a few core files like passwd.

Using such a structure, NixOS has no trouble allowing multiple versions of the same software to co-exist, any more than the rival Conary package manager does — or, like Autopackage, another software installation system, of having non-root users install software only for themselves. Any danger from non-root installs is reduced by scripts that run only programs and other scripts that are specifically declared in the package definition.

With this arrangement, users no longer have to rely on package maintainers remembering to specify a specific version of a library or later — instead, the needed version is installed as required. Just as importantly, NixOS avoids the problem of having the installation of the latest version of a key file added as a dependency for one application disabling another application that requires an earlier version. If a problem emerges anyway, then you can easily rollback the change by deleting the last installed program without danger of collateral damage to the rest of the system.

NixOS is an ingenious construct, and, despite the fact it is less than a year old, it includes enough packages and versions that you can easily put it through its paces.

However, the solutions to long-standing problems that NixOS provides seem questionable in a couple of ways. To start with, abandoning the long-established file hierarchy standards of Unix seems a drastic step. Perhaps Conary’s solution of adding version control and specific package names for separate versions of the same application is more economical than such an extreme alterationl? If nothing else, a system that is so obviously non-compliant with the Linux Standards Base is unlikely to be adopted by any major distribution, regardless of how useful it may be.

In addition, on a practical level, NixOS depends on unlimited hard drive space. Unlike with other package management systems — as imperfect as they sometimes are with cleaning up after themselves — nothing gets removed unless you specifically make the effort to remove it. In the short term, this arrangement is not a problem, but over a three or four year lifespan of a machine, it could create a serious shortage of hard drive space. On a network, administrators would almost surely want to run it with set limits on the storage allowed for each account to prevent a handful of users from gobbling up all available space. Long-time users, too, accustomed to jealously preserving hard drive space, might find the idea of keeping everything an extremely inelegant solution.

Still, the point of an academic distribution like NixOS is not necessarily to gain widespread popularity. Rather, the purpose is to experiment and offer alternatives in areas that developers and users often take for granted. From that perspective, NixOS is an intriguing success, and well worth investigating.

This article was first published on LinuxPlanet.com.