NixOS

From Wikipedia, the free encyclopedia
Jump to: navigation, search
NixOS
Written in Nix expression language
OS family Unix-like
Working state In development
Source model Open source
Latest release nixos-15.09[1] / September 30, 2015; 4 months ago (2015-09-30)
Marketing target General purpose
Package manager Nix
Platforms x86-64
Kernel type Monolithic (Linux kernel)
License MIT[2]
Official website nixos.org

NixOS is an independently developed Linux distribution that aims to improve the state of the art in system configuration management. Built on top of the Nix package manager, it uses declarative configuration and allows reliable system upgrades.[3] Two main branches are offered: current Stable release and Unstable following latest development.

Although NixOS started as a research project,[4] it is a fully functional and usable operating system.

NixOS is DevOps friendly and has tools[5][6] dedicated to deployment tasks.

History[edit]

NixOS started as a research project by Eelco Dolstra in 2003.[4][7]

In 2015 the NixOS foundation was started to help projects supporting the purely functional deployment model like NixOS.[8]

Features[edit]

Declarative system configuration model[edit]

In NixOS, the entire operating system — the kernel, applications, system packages, configuration files, and so on — is built by the Nix package manager from a description in a functional build language. It means that building a new configuration cannot overwrite previous configurations.[9]

NixOS system is configured by writing a specification of the functionality that a user wants on their machine in a global configuration file. For instance, here is a minimal configuration of a machine running an SSH daemon:[10]

{
  boot.loader.grub.device = "/dev/sda";
  fileSystems."/".device = "/dev/sda1";
  services.sshd.enable = true;
}

After changing configuration file, the system can be updated using the nixos-rebuild switch command.

This command does everything necessary to apply the new configuration, including packages download, package compilation and configuration files generation.

Reliable upgrades[edit]

System updating will always produce the same result, regardless of what packages or configuration files are on the system. Thus, upgrading a system is as reliable as reinstalling from scratch.

Atomic upgrades[edit]

NixOS has a transactional approach to configuration management making configuration changes such as upgrades atomic. This means that if the upgrade to a new configuration is interrupted — say, the power fails half-way through — the system will still be in a consistent state: it will either boot in the old or the new configuration. In other systems, a machine might end up in an inconsistent state, and may not even boot anymore.[11]

Rollbacks[edit]

If after a system update the new configuration is undesirable, it can be rolled back using a special command (nixos-rebuild switch --rollback).

In fact, every system configuration versions automatically show up at the system boot menu. If the new configuration crashes or doesn’t boot properly, an older version can be selected. Also, rollbacks are a lightweight operation that do not involve files to be restored from copies.

Reproducible system configurations[edit]

NixOS declarative configuration model makes it easy to reproduce a system configuration on another machine. Copying the configuration file to the target machine and running the system update command generate the same system configuration (kernel, applications, system services, and so on) except for parts of the system not managed by the package manager as user data.

Source-based model, with binaries[edit]

The Nix build language used by NixOS specifies how to build packages from source. This makes it easy to adapt the system to user needs. However, building from source being a slow process, the package manager automatically downloads pre-built binaries from a cache server when they are available. This gives the flexibility of a source-based package management model with the efficiency of a binary model.[12]

Consistency[edit]

The Nix package manager ensures that the running system is ‘consistent’ with the logical specification of the system, meaning that it will rebuild all packages that need to be rebuilt. For instance, if the kernel is changed, the package manager will ensure that external kernel modules will be rebuilt as well. And when a library is updated, it ensures that all the system packages use the new version, even packages statically linked to it.

Multi-user package management[edit]

There is no need for special privileges to install software in NixOS. In addition to the system-wide profile, every user has a dedicated profile in which they can install packages. Nix also allows multiple versions of a package to coexist, so different users can have different versions of the same package installed in their respective profiles. If two users install the same version of a package, only one copy will be built or downloaded, and Nix’s security model ensures that this is secure.

Implementation[edit]

NixOS is based on the Nix package manager that stores all packages in isolation from each other in the package store.

Installed packages are identified by a cryptographic hash of all input used for their build. Changing the build instructions of a package modifies its hash that will result in a different package installed in the package store. This system is also used to manage configuration files ensuring that newer configurations are not overwriting older ones.

An implication of this is that NixOS is not using the filesystem hierarchy standard. The only exceptions are that there is a symlink /bin/sh to bash in the Nix store like

/nix/store/5rnfzla9kcx4mj5zdc7nlnv8na1najvg-bash-4.3.43/

and NixOS does have an /etc directory to keep system-wide configuration files, but most files in that directory are symlinks to generated files in /nix/store such as

/nix/store/s2sjbl85xnrc18rl4fhn56irkxqxyk4p-sshd_config

Not using global directories such as /bin is what allows multiple versions of a package to coexist.

References[edit]

  1. ^ "Release 15.09 ("Dingo", 2015/09/30)". 
  2. ^ "nixpkgs/COPYING at master · NixOS/nixpkgs · GitHub". Github.com. Retrieved 2015-09-19. 
  3. ^ "DistroWatch.com: NixOS". Distrowatch.com. Retrieved 2015-09-19. 
  4. ^ a b Dolstra, Eelco. "Integrating Software Construction and Software Deployment" (PDF). Lecture Notes in Computer Science 2649: 102–117. 
  5. ^ "NixOps - The NixOS Cloud Deployment Tool". Nixos.org. Retrieved 2015-09-19. 
  6. ^ "Disnix". Nixos.org. Retrieved 2015-09-19. 
  7. ^ Dolstra, Eelco (2006). The Purely Functional Software Deployment Model (PDF) (Ph.D.). 
  8. ^ "Stichting NixOS Foundation". Nixos.org. Retrieved 2015-09-19. 
  9. ^ Dolstra, Eelco; Hemel, Armijn (2007). "Purely Functional System Configuration Management" (PDF). 
  10. ^ "About NixOS". Nixos.org. Retrieved 2015-09-19. 
  11. ^ van der Burg, Sander; Dolstra, Eelco; de Jonge, Merijn (2008). "Atomic Upgrading of Distributed Systems" (PDF). 
  12. ^ Dolstra, Eelco (2005). "Secure Sharing Between Untrusted Users in a Transparent Source/Binary Deployment Model" (PDF). 

External links[edit]