Explaining Nix
Earlier I have written two recipes explaining the Nix package manager, each having its pros and cons. The first recipe is basically explaining Nix from a system administrator's perspective -- it starts by explaining what the disadvantages of conventional approaches are and then what Nix does differently: namely storing packages in isolation in separate directories in the Nix store using hash codes as prefixes. Usually when I show this to people, there is always a justification process involved, because these hash codes look weird and counter-intuitive. Sometimes it still works out despite the confusion, sometimes it does not.
The other recipe explains Nix from a programming language perspective, since Nix borrows its underlying concepts from purely functional programming languages. In this explanation recipe, I first explain in what way purely functional programming languages are different compared to conventional programming languages. Then I draw an analogy to package managers. I find this the better explanation recipe, because the means used to make Nix purely functional (e.g. using hash codes) make sense in this context. The only drawback is that a large subset of the people using package managers are often not programmers and typically do not understand nor appreciate the programming language aspect.
To summarize: advertising the Nix concepts is tough. While I was at the NixOS stand, I had to convince people passing by in just a few minutes that it is worth to give NixOS (or any of its sub projects) a try. In the following section, I will transcribe my "sales pitch explanation" of NixOS.
The pitch
NixOS is a Linux distribution built around the Nix package manager solving package and configuration management problems in its own unique way. When installing systems running Linux distributions by conventional means, it is common to do activities, such as installing the distribution itself, then installing additional custom packages, modifying configuration files and so on, which is often a tedious, time consuming and error prone process.
In NixOS the deployment of an entire system is fully automated. Deployment is driven by a declarative configuration file capturing the desired properties of a system, such as the harddrive partitions, services to run (such as OpenSSH, the Apache webserver), the desktop (e.g. KDE, GNOME or Xfce) and end-user packages (e.g. Emacs and Mozilla Firefox). With just one single command-line instruction, an entire system configuration can be deployed. By adapting the declarative configuration file and running the same command-line instruction again, an existing configuration can be upgraded.
NixOS has a couple of other nice properties as well. Upgrading is always safe, so there is no reason to be worried that an interruption will break a system. Moreover, older system configurations are retained by default, and if an upgrade, for example, makes a system unbootable, you can always switch back to any available older configuration. Also configurations can be reproduced on any system by simply providing the declarative configuration file to someone else.
Several tools in the Nix project extend this deployment approach to other areas: NixOps can be used to deploy a network of NixOS machines in the cloud, Hydra is the Nix-based continuous integration server, Disnix deploys services into a network of a machines. Furthermore, the Nix package manager -- that serves as the basis for all of these tools -- can also be used on any Linux distribution and a few other operating systems as well, such as Mac OS X.
Concluding remarks
The above pitch does not reveal much about its technical aspects, but simply focuses itself on its key aspect -- fully automated deployment and some powerful quality properties. This often leads to more questions from people passing by, but I consider that a good thing.
This year's FOSDEM was a very nice experience. I'd like to thank all the fellow Nixers who did all the organisation work for the stand. As a matter of fact, apart from doing some promotion work at the stand I was not involved in any of its organizational aspects. Besides having a stand to promote our project, Nicolas Pierron gave a talk about NixOS in the distributions devroom. I also enjoyed Larry Wall's talk about Perl 6 very much:
I'm looking forward to see what next year's FOSDEM will bring us!