Package management on Unix-like systems has improved out of all recognition in the last decade. However, improvements are being suggested all the time, ranging from improved utilities for existing package tools like apt and yum to Autopackage and Zero Install, both of which allow non-users to install software, to Conary, which combines package management with version control to permit multiple versions of the same software to co-exist. The most recent experiment is Nix, which takes its own approach to multiple package versions in order to reduce the risks of upgrading.

Nix is an academic project that began as a project for Eelco Dolstra's doctorate at Utrecht University in the Netherlands. More recently, Dolstra has continued development as he does post-doctorate work at Delft University of Technology. According to Delft, the project has "a small but growing community" of 10-15 developers who submit regular commits, and an active mailing list.

"We are interested in improving the state of the art of software deployment," Dolstra said in a recent interview. "Tools like rpm and apt have all sorts of problems, and we wanted to look at that in a fresh way."

Specifically, Dolstra and his fellow developers are interested in securely permitting multiple package versions to exist on the same system. With existing package systems, Dolstra explains, any upgrade comes with the danger that any new dependencies could break other packages.

This danger can be mitigated by strict package standards such as the one used by Debian, in which most dependencies list a minimal version number of a package and will generally run on later versions. However, Dolstra says, "Ideally, you would not want to rely on these sorts of standards. You would just want it to work."

An Overview of Nix

Nix sidesteps such problems with the Nix expression language, which is specifically designed to define and build packages. The language draws its inspiration from the configuration management system Vesta, and from the Haskell programming language to produce what Dolstra describes as a "purely functional language. If you want to build multiple versions of a package, you just make a function that builds the package, and you call it multiple times with different arguments, and the system builds don't overwrite each other."

Using the Nix expression language, Nix gives each package a unique cryptographic hash derived from all dependencies and other inputs that went into the package. All these packages are stored in /nix/store, instead of the more customary /usr. Softlinks with human-readable names spare users from dealing directly with the hashes.

The advantages of this basic arrangement, Dolstra notes is that "You can upgrade the entire system, and you don't override the previous system. And you can always rollback to the original." In addition, if the upgrade is interrupted, the system remains bootable, making recovery easier.

Another feature of Nix is that, like Gentoo, it is a source-based package system. However, Nix is also designed so that it can use binary versions of packages if they exist within the repositories.

"The model is source-based," Dolstra says, "But you get binaries as a sort of automatic optimization. If there is no pre-built binary for a hash, then Nix will fall back to source. We like to say we have the best of both worlds: You get the flexibility of a source-based system, but in general, you also get binaries."

Another feature of Nix is that all users can install software, not just root. The Nix system cancels any duplications, and avoids any potential security problems with its strictly defined package format. Also, packages are built and installed as a unique user--and not as the one that started the process--so that a would-be cracker cannot interfere.

You can install Nix on an existing Unix-like system, but, more recently, Nix's developers have extended the project by creating NixOS, a GNU/Linux distribution. This step was necessary because Dolstra and his team wanted "to experiment without having to convince an existing distribution" to adopt Nix.

"It's not realistic to think that a company like Red Hat would switch," Dolstra observes.

NixOS takes things one step further by maintaining multiple configuration files. This extra step is designed to eliminate another problem of upgrades: The overwriting of configuration files. "So far, [Nix] scales well," Dolstra observes.

Problems and Nix's Future

Package management systems are a specialized area of development. However, according to Dolstra, Nix and NixOS have been well received by those who are interested in it.

In particular, "People in the Haskell world tend to be very enthusiastic about it," he says. "They understand the paradigm, so you don't have the problem of explaining that."

All the same, Nix faces some significant concerns in the future. Although NixOS includes a tool to locate duplicate files and hard-link them to each other, it has yet to address the problem of administering multiple file versions. "We don't really have tools for that," Dolstra admits. "The idea as always that disk space is cheap, so you trade disk space for correctness. We would rather have a few more copies of a library lying around than haven anything potentially not working."

Similarly, the Nix model does not address security upgrades. "Sometimes you really want to force an upgrade--for instance, if there was a security bug in a library," Dolstra says. "You don't want applications continuing to use the old version. You really want to get rid of the old thing. And that doesn't fit in nicely with our approach, so we have to find a good way to deal with that kind of destructive upgrade. We don't have a good way to do that yet."

A third problem is that, because of the way that Nix stores multiple versions, it does not comply with the Linux Standards Base--and therefore runs contrary to an increasing trend among major distributions. Unfortunately, there may be no way around this problem, because Nix's entire solution is based squarely on this non-compliance.

However, an academic project like Nix does not stand or fall on how many distributions adopt it. What matters with projects like Nix is that they call attention to problems and suggest possible solutions to them.

In the end, Nix itself may be only a footnote in the history of Unix-like systems. But, if it encourages the mainstream to address the problems it highlights, then it will have served its purpose.