NixOS

Nix as a package manager originated in 2003 as a research project by Eelco Dolstra at Utrecht University under the supervision of Eelco Visser. Dolstra’s 2006 doctoral thesis, The Purely Functional Software Deployment Model, describes a declarative and functional approach to software deployment and lays out the design of the Nix package manager. The first NixOS prototype was created by Armijn Hemel in 2006 as part of his Master's thesis NixOS: The Nix Based Operating System, which explored applying Nix and its principles to a Linux distribution. Hemel demonstrated the application of package management, system services, kernel management, and other principles that defined NixOS. After continued development, NixOS issued its first stable release, version 13.10, in 2013. The NixOS Foundation, a Dutch non-profit established in 2015, supports the development and community infrastructure of NixOS and related Nix projects. == Release version history ==

Since 2021, NixOS publishes stable releases twice per year, near the ends of May and November. Prior to the first stable release in 2013, major versions were numbered semantically, up to release 0.2. == Features ==

) Declarative configuration model In NixOS, the entire operating system—including the kernel, applications, system packages, and configuration files—is built by the Nix Package manager from a definition in the Nix language. Building a new version will not overwrite previous versions. A NixOS system is configured by specifying the desired state in a Nix expression file, typically /etc/nixos/configuration.nix. The following example configures the bootloader and enables the OpenSSH daemon: { boot.loader.grub.device = "/dev/sda"; fileSystems."/".device = "/dev/sda1"; services.openssh.enable = true; } Changes may be built and activated with the nixos-rebuild command, which evaluates the configuration, builds the necessary derivations, and produces a new system generation. Upgrades and configuration changes to NixOS systems are applied transactionally. New system generations are activated atomically, so that previous generations are retained and may be rolled back. If an upgrade is interrupted (for example, by power failure), the system remains consistent and will boot either the old or the new configuration. If, after a system update, the new configuration is undesirable, it may be rolled back by switching to a previous generation (nixos-rebuild switch --rollback). New generations are automatically added to the system bootloader and may be selected prior to boot. Rollbacks are lightweight operations that switch system references to different store paths. Reproducible system configurations NixOS uses a declarative configuration model that allows system configurations to be reproduced on different machines. By sharing a configuration file with a target machine, users can generate an equivalent system, including the kernel, applications, and system services. Components not managed by the package manager, such as user data, are not affected by this process. Multi-user package management In addition to the system-wide profile, every normal user in a NixOS system has a profile in which they can install packages without special privileges. In the Nix store, multiple versions of a package may coexist, allowing different users to have alternate versions of the same package installed in their respective profiles, or share an identical version. Nix’s security model restricts what unprivileged users can influence. Prebuilt binaries may be fetched from binary caches that are explicitly trusted by the system configuration, otherwise packages are built locally in a sandbox. Without special privileges, users cannot pass options that would introduce impurities into builds or use untrusted caches. Nix-shell The nix-shell command starts an interactive shell based on a Nix expression. It allows developers to work with isolated sets of dependencies without affecting the system globally. Experimental features Nix command The nix command provides a redesigned command-line interface for the Nix package manager, intended to replace the traditional nix-env, nix-build, and related commands. It introduces a more consistent syntax and improved user experience with commands such as nix build, nix develop, and nix run. The goal was to simplify common operations and provide better functionality through a unified command structure. Flakes Flakes provide a standard structure for Nix expressions that explicitly declare dependencies and outputs. Each flake contains a flake.nix file that specifies its inputs (dependencies, external flakes, repositories) and outputs (packages, NixOS configurations, and development environments). Flakes use a lock file to keep exact versions of dependencies to ensure that evaluations remain reproducible over time. The feature provides a standardized way to define, manage, and share Nix expressions, while making it easier to create and maintain reproducible systems. == Implementation ==

The Nix store Installed packages are stored in a read-only directory known as the Nix store, commonly located at /nix/store. Packages in the store are identified by a cryptographic hash of all input used for their build. This system is also used to manage configuration files, ensuring that newer configurations do not overwrite older ones. An implication of these principles is that NixOS does not follow the Filesystem Hierarchy Standard. The only exceptions are that a /bin/sh symlink is created to the version of bash in the Nix store (e.g. /nix/store/s/5rnfzla9kcx4mj5zdc7nlnv8na1najvg-bash-4.3.43/), and while NixOS does have an /etc directory to keep system-wide configuration files, most files in that directory are symlinks to generated files in the Nix store, such as /nix/store/s2sjbl85xnrc18rl4fhn56irkxqxyk4p-sshd_config. By not using global directories such as /bin, Nix allows multiple versions of a package to coexist, avoiding package conflicts sometimes known as "dependency hell". This also means that AppImage executables cannot be run directly as they expect certain libraries to exist on certain paths. This can be worked around by running them through an interpreter. == Reception ==

Jesse Smith, reviewing NixOS 15.09 for DistroWatch Weekly in 2015, wrote: A 2022 review of NixOS 21.11 "Porcupine" in Full Circle concluded: NixOS 22.11 "Raccoon" reviewed by Liam Proven at The Register: NixOS 23.11 "Tapir" reviewed by Jesse Smith at DistroWatch: == Community ==

Wiki An official NixOS wiki was launched in 2011, but was shut down in 2016 due to spam. An unofficial wiki at nixos.wiki was later started by the community to fill in the documentation gap. On 1 April 2024, the official wiki was revived at wiki.nixos.org, using contents migrated from the unofficial nixos.wiki. == See also ==