With most computer systems, you manage them step-by-step. To install a web browser, you run a command like apt install firefox. To get a text editor, you run another command. This is the imperative approach: you give a series of one-off instructions to change the system's state.

Think of it like giving a friend directions by telling them each turn to make: "Turn left, then drive two blocks, then turn right." After many turns, it's hard to be certain of their exact location or how they got there. Over time, your system can become a tangled web of updates, installations, and manual changes, making it fragile and difficult to reproduce.

NixOS uses a declarative approach. Instead of giving step-by-step instructions, you describe the final state you want in a single configuration file. You list the software you want, the user accounts that should exist, and the services that should be running. NixOS then takes that file and builds the system to match your description.

The magic behind this declarative model is the Nix Store. It's a special directory located at /nix/store. In a traditional system, software files are scattered across directories like /bin, /lib, and /usr. In NixOS, every package—from a large application to the tiniest helper library—gets its own unique, isolated folder inside the Nix Store.

The name of each folder isn't simple, like firefox-121.0. Instead, it's a long, unique string of characters generated by a cryptographic hash function. This hash is calculated based on everything used to build the package: the source code, its dependencies, the compiler settings, and even the build script. If even a single bit of input changes, the hash changes, and Nix creates a brand new folder in the store.

This structure is what makes NixOS so robust. Since each application directly references the exact version of the dependencies it was built with, it's impossible for another installation or update to break it. This completely solves the problem known as dependency hell because different programs can safely use conflicting versions of the same software, as they each live in their own isolated world within the store.

The combination of a declarative configuration and the Nix Store leads to the ultimate benefit: reproducibility. Because your single configuration.nix file describes the entire desired state of your system, you can take that file to any other machine running NixOS, run a single command, and build an identical environment. Every package, every setting, and every dependency will be exactly the same.

Furthermore, the system is largely immutable. The contents of /nix/store are read-only and never change. When you update your system, Nix builds the new configuration and its dependencies in the store. It then switches a single pointer to make the new configuration active. This makes updates safe and atomic. If something goes wrong, you can instantly roll back to the previous, perfectly working generation of your system.