Imagine a Linux where you can test and roll back configuration changes, where multiple versions of the same library or application can live in harmony, and where the full state of the system is recorded declaratively. As any promotional paragraph beginning with “imagine” implies, this thing exists: NixOS

Ian-Woo Kim explains the terminology and internals of the Nix package manager powering NixOS. He has worked extensively with Nix, using it to manage high-energy physics software and to package the GHC Android cross-compiler.

Download Video: (HD / SD).

Summary

Ian-Woo’s interest in better package management began in his days as a high-energy physics researcher Research institutions often use old software for scientific computing because it is considered safe and secure Researchers circumvent these policies and install newer tools in their home directories The “diamond problem” pops up in manual software installation Additionally Ian-Woo started using Haskell in his physics work in 2009. Back then Cabal Hell was rampant

Nix is a purely-functional package manager Given the same inputs (source, dependencies, config) it always ends up with the same output (installed packages) This makes Nix installations reproducible and debuggable across systems Nix packages are not sensitive to the order of their installation

How does Nix provide these good things? Hashing, the solution to everything! Packages are stored in directories with a hash which captures its dependencies, version, and configuration Thus the same package can coexist on the system with multiple configurations An example with GNU Hello

A subset of the Nix store closed under the dependency relation is called a “closure” and can be distributed as a working package to other machines with Nix

User profiles are a set of symlinks into Nix store No /usr or /usr/local or opt/local , we escaped!

What stops the Nix store from continually growing with versions and configurations? The Nix garbage collector, that’s what. It uses reference counting

Although the system uses hashes internally, there is a higher level expression language to describe package sources, dependencies and build/install steps An example Dependency parameters The final goal in a Nix expression is not a package, it is a “derivation” It’s an intermediate representation for building a package The derivation is a string in key-value format which will ultimately be hashed and which can refer to objects in the Nix store

More about the Nix expression language It’s pure functional, with lazy evaluation Its DSL is tightly integrated with the shell and path manipulation It has a repl: nix-repl

Nixpkgs, open source Nix packages collection About 11,000 so far Lots of libraries, tools, and apps Basis of NixOS, a Linux distro on top of Nix and Nixpkgs It piggybacks on top of language-level package managers to allow loading libraries in many popular languages

Example Haskell environment for a numerical study

NixOS is a Linux distro where the whole system is built on Nix Even the hardware is described in Nix expressions Transaction based. Integrates with Grub for handling rollbacks NixOS gives maximal freedom to users, they can install whatever they want on the system. It won’t interfere with other users

NixOps deploys NixOS Linux on the cloud Create and connect servers, target different backends like ec2 or virtualbox

Nix Channel Packages built with a given hash can be distributed and run anywhere with the supporting dependencies A channel allows clients to stay up to date for a package by downloading pre-built binaries

Topics for future talks Porting Nixpkgs to other platforms Licenses and proprietary software Disnix: distributed service deployment Guix: Linux distro based on Nix and Guile



Related Posts