Keystone SystemsKS Systems
HardwareSoftwareManaged

The History of NixOS

NixOS represents one of the most ambitious attempts to rethink how operating systems manage software and configuration. Its origins trace back to academic research, but it has grown into a practical solution for reproducible infrastructure.

Origins: The PhD Thesis

In 2006, Eelco Dolstra published his PhD thesis at Utrecht University: "The Purely Functional Software Deployment Model." The core insight was radical: what if we treated software deployment the way functional programming treats computation?

In functional programming:

  • Functions don't have side effects
  • The same inputs always produce the same outputs
  • Data is immutable

Applied to package management:

  • Packages don't modify global state
  • The same build inputs always produce the same output
  • Installed software is immutable

The Problem It Solves

Traditional package managers share common problems:

Dependency Hell: Package A needs libfoo 1.2, Package B needs libfoo 1.3. You can't have both.

Non-Reproducible Builds: Build on Monday, get one result. Build on Friday, get something different because a dependency updated.

Stateful Upgrades: Upgrades mutate the system in place. If something breaks mid-upgrade, you're in an undefined state.

"It Worked Yesterday": The system evolves through accumulated changes. Reconstructing why something broke requires archaeology.

Key Innovations

The Nix Store

Everything lives in /nix/store, addressed by cryptographic hash:

/nix/store/abc123...-git-2.42.0
/nix/store/def456...-git-2.43.0

Multiple versions coexist. Nothing conflicts. Old versions remain until garbage collected.

Derivations

A derivation is a build recipe: inputs, build script, and expected outputs. The hash of a derivation determines where its output lives in the store.

Same inputs → same hash → same output path. If the path exists, the build is skipped. This enables binary caches and guarantees reproducibility.

Atomic Upgrades

Upgrading doesn't modify existing packages. It builds new versions and atomically switches a symlink. The old version remains available.

Generations

Each system configuration is a "generation." You can boot into any previous generation from the bootloader. Rollback is instant and safe.

Evolution of the Ecosystem

Nix (2003-2006)

The package manager itself, capable of managing software in any environment.

NixOS (2007+)

The logical extension: an entire Linux distribution configured through Nix expressions. Your whole OS is a derivation.

Nixpkgs

The package repository, now one of the largest in the open source world with over 80,000 packages. Monorepo style, community maintained.

Flakes (2020+)

A modern layer adding:

  • Standardized project structure
  • Lock files for reproducible inputs
  • Better composability between projects

Home Manager

User-level configuration in the Nix style. Manage dotfiles, user packages, and services declaratively.

Community and Adoption

The NixOS Foundation oversees development. An RFC process guides major changes.

Commercial adoption has grown: Determinate Systems, Flox, and others build products on Nix. Companies use NixOS in production for its reproducibility guarantees.

The learning curve remains steep, but the payoff is infrastructure you can reason about mathematically.