begriffs

Purely Functional Linux with NixOS

August 8, 2016

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