A look at Nix and Guix

Nix and Guix are a pair of unusual package managers based on the idea of declarative configurations. Their associated Linux distributions — NixOS and the Guix System — take the idea further by allowing users to define a single centralized configuration describing the state of the entire system. Both have been previously mentioned on LWN, but not covered extensively. They offer different takes on the central idea of treating packages like immutable values.

In a normal Linux distribution, the set of packages, services, and configuration files installed on a system is built up over time using tools that do not inherently require knowledge of programming. This approach can be convenient, making it possible to simply install a missing package and then have access to it going forward. The downside of this approach is how difficult it makes reconstructing a new system with the same set of tools, services, and tweaks when it comes time to migrate to a new host. The majority of Linux distributions lack any kind of centralized record of why each package was installed or each configuration option was changed.

NixOS and Guix offer an alternative: specify your setup with a programmable configuration file, and then let the package manager arrange for the software available on the system to reflect that. These configurations can include comments, version control, and the ability to factor out common parts for different machines, making it much easier to keep track of why something was configured or installed.

The key idea

Nix is a "purely functional package manager". Unlike other package managers, Nix uses a general programming language of the same name for configuration, albeit one optimized for the task of describing packages. The Nix language takes inspiration from the ML family of languages, Haskell in particular. Like Haskell, Nix programs work with and produce immutable values through composing functions (the "functional" part) that don't have side-effects (the "pure" part). Evaluating a Nix program produces a set of build actions for the runtime of the package manager to take, but does not itself build or install anything. Nix is also lazy, calculating only the information about the produced values that actually ends up being required. This lets Nix programs skip performing computations for optional dependencies that don't end up being used.

Each Nix program describes a "derivation" — "a specification for running an executable on precisely defined input files to repeatably produce output files at uniquely determined file system paths." Derivations describe a specific build task to perform, including all of the necessary inputs to the build task in the form of required dependencies, build tools, source code, etc. Nix doesn't permit implicit dependencies between build tasks, requiring all prerequisites to be specified explicitly.

The benefit of using this model is that the full state of the system is specified in the same place, using the same language. The configuration not only includes the installed packages, but also the configuration files destined for /etc, the systemd service files, the filesystem mounts, users, kernel configuration options, drivers, etc. For example, here is a configuration module for running nginx, which builds nginx, sets up its configuration files, sets up a systemd service for nginx itself, and creates systemd timers for renewing HTTPS certificates with LetsEncrypt:

    # This whole file evaluates to a single function from a set of
    # arguments (config, lib, and pkgs are normally used, but there
    # can be more which are ignored, thus "...") to a set of configuration
    # values that themselves are used in calculating the build action for
    # the overall system.
    { config, lib, pkgs, ... }:

    {
      # ACME is the protocol that LetsEncrypt uses to give out certificates
      security.acme.acceptTerms = true;
      security.acme.defaults.email = "example@example.com";

      services.nginx = {
        enable = true;

        # Options can enable a bundle of related, more detailed settings
        recommendedTlsSettings = true;
        recommendedOptimisation = true;
        recommendedGzipSettings = true;
        recommendedProxySettings = true;
      };

      # nginx can serve multiple virtual hosts with their own configurations
      services.nginx.virtualHosts."www.example.com" = {
        http2 = true;
        enableACME = true;
        forceSSL = true;

        locations."/" = { root = "/var/www/example.com"; };
      };
    }

The code that actually implements these options is defined in nixpkgs, NixOS's package repository, in the same language as the rest of the configuration. Becoming truly proficient in Nix can take some time, but most configurations are relatively straightforward, and the NixOS manual provides examples of common setups. The options search or nix search command-line tool also let users search for configuration options and available packages.

Derivations are nearly all reproducible, with the same inputs generating the same outputs. Some packages still include randomness or information about the timing of the build, which foil reproducibility. Work is ongoing to patch these packages to reach the project's goal of fully reproducible builds. Combined with the fact that derivations record all of the inputs to the build process, this reproducibility allows the result of derivations to be cached. Nix keeps the cache of previously evaluated derivations under /nix/store/, indexed by the hash of the derivation's inputs.

Nixpkgs contains definitions for more than 80,000 packages. These packages are built, cached, and shared by Hydra, NixOS's build farm. So, despite the fact that a NixOS configuration describes how to obtain and build all of the selected software from scratch, if a user depends on the package definitions in nixpkgs, they are likely to be able to download a cached output for the derivation from Hydra. NixOS refers to itself as a mixed source/binary distribution because of this — users can build software from scratch (including tuning the build flags for their system, as can be done by Gentoo users), but most users just download binary versions of most of their packages, and know that they're getting the same result as having built from scratch.

Multiple versions

Another benefit of arranging for the system to be built in this way is the ability to depend on multiple versions of the same package. Because each derivation references its build inputs explicitly, there is no requirement that a single global version of a compiler or shared library exist that satisfies every dependent package's needs simultaneously. This makes it easier to keep older software with specific needs running, decreases the burden of updating every package in the ecosystem at once when there's a major update to a common dependency, and means that maintainers don't need to solve version conflicts. It is a bit of a double-edged sword, however, because it does mean that it is easy to depend on several versions of a package without meaning to, which can bloat the size of a NixOS installation.

Being able to keep multiple versions of packages actually extends to being able to keep multiple versions of the system's entire configuration. When re-building a system using Nix, the derivation of the previous configuration remains available, and can be switched to using the bootloader. Users can therefore upgrade fearlessly, because any problems introduced by trying a new configuration can be resolved by rebooting. By the same token, software that is only needed for a short time, such as to try out a new program or grab a seldom-used command-line tool, can be installed into a temporary environment without interfering with the overall system configuration.

It is difficult to overstate how useful this ability is in practice. It is often possible to put a Linux system into an unworkable state by doing something unusual. While a lot can be learned from troubleshooting these issues, it is inconvenient when what is needed is a functional system.

Referring to dependencies directly, the way NixOS does, causes problems with software not packaged for use on the distribution. Unlike a typical distribution, NixOS only uses /usr/bin for env, to permit running shell scripts that start with #!/usr/bin/env. Shell scripts or other programs that assume that system binaries will be available in /usr/bin or other standard locations usually need to be adapted to run on NixOS. There are some tools available to make a chroot environment that puts binaries in the expected places, however, so this is usually not much of a hassle.

Guix

The Nix approach to package management has its benefits, but the Nix language also has its quirks. Learning to use a new programming language on top of a new package-management philosophy may seem like a tall order. The Guix project is working to create a distribution that uses Nix-style package management, but using a more widely used, general, and consistent programming language: Scheme. Guix is a GNU project, and so it only packages free software (in contrast to Nix, which packages non-free software behind a configuration option). It also has many fewer contributors than Nix, and is somewhat younger as a project — Guix received its first commit in 2012, whereas Nix dates to 2003 — so the number of packages available in Guix is somewhat lower.

Despite this, Guix has made several interesting advances of its own, including fully bootstrappable builds. Guix is now capable of building itself almost entirely from source on x86_64, a major milestone for the project. Ekaitz Zárraga gave a talk at FOSDEM 2024 about extending that support to RISC-V. Guix also has some features that NixOS lacks, such as the ability to "graft" security updates onto a package. This lets a more up-to-date version of a runtime dependency of a package be substituted in (presumably to fix some security problem) without recompiling the dependent package. This permits rolling out security updates to fundamental libraries without waiting for the build farm to rebuild all of Guix's packages.

A section of a Guix configuration comparable to the Nix configuration given above would look like:

    ; Guix defines types and helper functions in their own Scheme modules
    (require (gnu services web)
             (gnu services certbot))

    ; This hook sends a signal to nginx to make it re-load its configuration,
    ; including the updated HTTPS certificates
    (define %nginx-deploy-hook
      (program-file
       "nginx-deploy-hook"
       #~(let ((pid (call-with-input-file "/var/run/nginx/pid" read)))
           (kill pid SIGHUP))))

    (define %my-nginx-service
      (service nginx-service-type
         (nginx-configuration
           (server-blocks
             (list (nginx-server-configuration
                     (server-name '("www.example.com"))
                     (root "/srv/http/www.example.com")
                     (ssl-certificate
                       "/etc/letsencrypt/live/www.example.com/fullchain.pem")
                     (ssl-certificate-key
                       "/etc/letsencrypt/live/www.example.com/privkey.pem")))))))

    (define %my-certbot-service
      (service certbot-service-type
               (certbot-configuration
                (email "example@example.com")
                (certificates
                 (list
                  (certificate-configuration
                   (domains '("www.example.com"))
                   (deploy-hook %nginx-deploy-hook)))))))

This configuration has a few differences. For one thing, Guix uses GNU Shepherd as an init system, instead of systemd. For another, the code shown here is not a standalone file that is imported by the main configuration file. Instead, the user would need to import this file and then add %my-nginx-service and %my-certbot-service to the services list for their system configuration by hand.

Experimenting

Nix and Guix (the package managers) both work on other distributions. Some distributions, such as Ubuntu and Debian, provide packages for them. For users of other distributions, Nix provides installation instructions and uninstallation instructions. Guix only provides installation instructions, but maintainer Tobias Geerinckx-Rice helpfully notes that one can read the installer script to see what ought to be removed.

In either case, using the package managers on another distribution can be useful for creating temporary environments, even if they cannot provide whole-system configuration. Individual programming languages often provide a solution for temporary development environments (for example, Python's virtual environments). Many projects are now shipping a shell.nix file as a language-agnostic alternative, which can install dependencies not packaged by the language's package manager. Somewhat fewer ship a guix.scm file serving the same purpose, but several GNU projects do.

NixOS and Guix offer a compelling alternatives to traditional distributions by rethinking how package management can be done. Their design permits incredible flexibility, simplifying package management for distribution maintainers and giving users additional control over how their computers are configured, without sacrificing binary packaging. Despite this, it seems unlikely that either will replace traditional package managers, especially when other distributions are receiving some of the same benefits of reproducibility using other techniques.