Putting functional database theory into practice: NixOS

NixOS is a Linux distribution based on Nix, a purely functional package management system. NixOS is an experiment to see if we can build an operating system in which software packages, configuration files, boot scripts and the like are all managaed in a purely functional way, that is, they are all built by deterministic functions and they never change after they have been built. Such an operating system should have all the nice characteristics that the Nix package manager has.

An excellent example of how useful functional databases can be when applied to problems which require persistence.

Comment viewing options

Select your preferred way to display the comments and click "Save settings" to activate your changes.

NixOS and Nix links

There don't seem to be any links in the start post, so here a few pointers to this work:

Besides the HotOS paper just mentioned, there is a PhD thesis available "The Purely Functional Software Deployment Model" by Eelco Dolstra, the main developer of Nix and NixOS. If you are mostly interested in the relationship between software deployment and functional languages, then the ICSE paper "Imposing a Memory Management Discipline on Software Deployment" is a good read.

Oops

Thanks for correcting this omission.

Interesting

What would be interesting is to see of the system administrators find it practical to use..

A minor nitpick is that packages look like this:
/nix/store/r8vvq9kq18pz08v249h8my6r9vs7s0n3-firefox-2.0.0.1/

A better way for readability, ordering and auto-completion would be:
/nix/store/firefox-2.0.0.1-r8vvq9kq18pz08v249h8my6r9vs7s0n3
in the end, it is still humans who runs the system, so names should be designed to be readable.

Keep in Mind...

...that no single name can be all three of distributed, secure, and human-memorable; see An Introduction to Petname Systems for more details.

Indeed, but he said

Indeed, but he said *readable* not *memorable*, and I agree: it seems more readable placing the package name before the GUID, since if you're looking through the directory at a glance, you can see what packages you've downloaded. Perhaps Nix has some reason for naming it that way though?

afaik, there is no particular reason

(sorry, reply to naasking)

The human-readable package name is only used to make the path somewhat recognizable, which is for example useful when a package maintainer is adding support for new packages to the Nix package collection.

The human-readable part of the name is not relevant to make the path unique, and the position of the human-readable part is not relevant either. The thought just never crossed our mind to switch the hash and the human-readable name, since Nix users never use the long and unique Nix store paths. Nix packages are installed in profiles, and the user only uses packages through this profile. A profile is a path that the user knows and it is usually automatically added to the PATH environment variable of the user.

But, the suggestion to switch the hash and human-readable name is useful. If it is somewhere, then why not at the beginning :)

functional database theory?

I guess I missed something, does "functional database theory" refer to "comprehending queries" (Grust) or LambdaDB type of functional databases or is it something else? The list papers don't seem to talk about functional databases.

Functional Database

The system is a functional database since updates (installing of packages etc.) does not overwrite but instead augments the existing database by pointing back to the preexisting database structure.

It is the exploitation of referential transparency that saves this system from the terrible woes that I'm dealing with right now trying to work out a funny package issue in Ubuntu where the tester happened to have a different cocktail of installed packages than I have.