Back to article
NixOS: A Distro Focused on Next-Generation Package Management
More User Control, Rollbacks, Redundancy
January 30, 2009
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.
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 unusable. 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.