← Back to articles
News· 4 min read

The History of NixOS: The Reproducible Operating System

Concept of reproducible configuration and declarative code that inspires NixOS
Foto: Pixabay · Pexels

Few Linux distributions break as many conventions as NixOS. Most systems carry the same philosophy inherited from the 1990s: install packages into /usr, mutate the system on the fly, and hope nothing breaks. NixOS started from scratch with a bolder idea, treating the operating system’s configuration as if it were pure, mathematical, reproducible code. The result is a Linux that looks like nothing else, and knowing where it came from explains why it is having such a moment today.

Academic origins: Eelco Dolstra’s thesis

This started in academia. In 2003 Eelco Dolstra began a project at Utrecht University in the Netherlands, supervised by Eelco Visser, to rethink how software is deployed. It came together in his 2006 doctoral thesis, The Purely Functional Software Deployment Model.

What the thesis proposed felt counterintuitive at the time: applying the principles of purely functional programming languages to software installation. A mathematical function always returns the same result for the same input, and a package should be built the same way, fully deterministically from its declared dependencies. That idea produced Nix, the package manager that would become the heart of everything that came after.

From package manager to full operating system

NixOS logo, the distribution based on the Nix package manager
The NixOS logo, the distribution derived from the Nix manager created by Eelco Dolstra. · Imagen: Tim Cuthbertson / CC BY 4.0 · Wikimedia Commons

Nix proved you could manage software reproducibly. The next question almost asked itself: what if the entire operating system worked this way? Armijn Hemel put it into practice in 2006, also as part of his master’s work, with a prototype titled NixOS: The Nix Based Operating System.

The distribution matured over several years until its first stable release, version 13.10, shipped in 2013. In 2015 the NixOS Foundation was established, a Dutch non-profit that sustains the project’s development and community infrastructure. That academic experiment had become a real, usable distribution.

The technical core: /nix/store and declarative configuration

Default GNOME desktop of NixOS 21.11 running
Default GNOME desktop of NixOS 21.11, where the whole system is materialized from the declarative configuration. · Imagen: NixOS contributors (NixOS Foundation) / GPL · Wikimedia Commons

What sets NixOS apart from Debian, Ubuntu or Arch is how it places files. Every package, library, kernel and configuration file lives in a special directory called /nix/store. Each item is named by a cryptographic hash that summarizes all of its dependencies and build options. Two different versions of the same library coexist without stepping on each other, because they occupy separate, immutable paths.

On top of that foundation sits its most striking feature, declarative configuration. Instead of installing packages one by one with imperative commands, you define the system’s entire state in a single file (/etc/nixos/configuration.nix): which packages you want, which services should start, which users exist. You run a rebuild, and NixOS materializes exactly that state.

Isolated builds and atomic rollbacks

Each Nix derivation deterministically references all of its dependencies and is built in an isolated environment, a sandbox. That makes builds reproducible: if a package works on one machine, it will work the same on another, with no hidden dependencies. It also makes Nix an excellent starting point for the celebrated Reproducible Builds, a goal the Linux kernel ecosystem and many distributions pursue for security reasons.

The other gem is atomic rollbacks. Every time you rebuild the system, NixOS creates a new “generation” without touching the previous one. If an update breaks something, you reboot and pick the earlier generation from the boot menu. No inconsistent intermediate states, no half-applied upgrades: the change is atomic, like a transaction.

Flakes and the recent surge driven by reproducibility

For years you could pin dependency versions in Nix, but it was a fairly artisanal affair. That changed with flakes, which arrived in Nix 2.4 on November 1, 2021. Flakes give projects a uniform structure and, above all, a lock file that pins every dependency precisely. Sharing a reproducible environment became as simple as sharing a repository.

The timing could not have been better. Worry over software supply-chain security, the need for identical development environments across teams, and the pull of machine learning and cloud infrastructure have all pushed interest sharply upward. The Nix ecosystem added 50% more packages in 2024 compared to 2023, with particularly strong growth in cloud-native and AI tooling.

An oddity gaining ground

NixOS is still a demanding distribution. Its learning curve intimidates anyone coming from Linux Mint or Pop!_OS, and the Nix language has its own quirks. But what it offers —total reproducibility, configuration as code, and the ability to undo any change— answers real problems that other distributions, from Fedora to openSUSE, tackle in more conventional ways.

From a 2006 doctoral thesis to the fashionable answer for reproducible infrastructure in 2026. The history of NixOS shows that radical ideas, when they solve genuine problems, eventually find their moment.