NixOS

NixOS is a Linux distribution built on the Nix package manager, in which the whole system — packages, services, users, kernel parameters, firewall rules — is derived from a declarative expression rather than accumulated through imperative commands. Building that expression produces a new system generation; the bootloader keeps the previous ones, so a bad change is undone by rebooting into the generation before it.

The property I actually care about is that machine state stops being a thing that drifts. On a conventional distribution, a machine two years into its life is the sum of every apt install and hand-edited config file anyone ever ran on it, and none of that is written down. Reproducing it means reconstructing an undocumented history. Under NixOS the machine is a function of a file I can read, and rebuilding it from scratch converges to the same system.

What that buys, concretely

Rollback is the feature people mention, but the one that changed how I work is that configuration becomes reviewable. A change to a firewall rule or an SSH policy shows up as a diff in a repository, which means it can be read before it is applied and found afterwards when something breaks. My own setup is documented as a flake-based dendritic system, where the module tree itself carries the structure.

The second thing is that development environments and system configuration stop being separate problems. The same expression language pins the toolchain for a project shell and the packages on the machine, so a project can specify precisely the compiler it needs without that leaking into the system or fighting with another project’s requirements.

Where it is genuinely hard

• The language. Nix is lazily evaluated, dynamically typed, and its error messages frequently point at a location far from the mistake. This is the single biggest obstacle and it does not fully go away with experience; it just becomes a familiar kind of pain.
• Anything that expects a normal filesystem. Pre-built binaries that assume /lib64/ld-linux.so exist do not run without wrapping. Scientific software distributed as vendor binaries hits this often, which matters if your field ships tooling that way.
• Documentation. It is spread across a manual, a wiki, several blog posts of varying vintage, and the source of nixpkgs. Reading nixpkgs is not optional, and that is a real barrier.
• The flakes question. Flakes are still nominally experimental while being what most current material assumes. You end up choosing between the documented-but-dated path and the undocumented-but-current one.

I would recommend it for machines whose configuration matters and changes rarely — servers, workstations you rebuild, anything you want to be able to reconstruct. I would not recommend it as a first Linux distribution, and I would think hard before putting a team on it who had not asked for it.

See also: my flake-based system setup, configuration management tools compared, and Linux administration in datacenters for where declarative configuration sits among the alternatives.