Jump to content

NixOS

From Wikipedia, the free encyclopedia

This is an old revision of this page, as edited by 94.51.120.209 (talk) at 14:34, 3 February 2021. The present address (URL) is a permanent link to this revision, which may differ significantly from the current revision.

NixOS
NixOS snowflake with text
Written inNix expression language
OS familyLinux (Unix-like)
Working stateIn development
Source modelOpen source
Initial release2003; 21 years ago (2003)
Latest release20.09 / October 27, 2020; 4 years ago (2020-10-27)[1]
Repository
Marketing targetGeneral purpose
Package managerNix
Platformsi686, x86-64, ARMv7, AArch64
Kernel typeMonolithic (Linux kernel)
LicenseMIT[2]
Official websitenixos.org

NixOS is a Linux distribution 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.[citation needed] NixOS has tools dedicated to DevOps and deployment tasks.[5][6]

History

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

The Stichting NixOS was founded in 2015 and aims to support projects like NixOS that implement the purely functional deployment model.[8]

Versions

NixOS follows a cadenced releasing, twice a year.[9] This used to happen around March and September but, starting with 21.05, NixOS targets May and November instead.[10] Each version number has the following format: "YY.MM".

For example: "20.03" is the version released around March 2020.

Besides that, each version is named, such as “Markhor” for the release 20.03.

Versions History
List of NixOS versions[11]
Date Version Name Notes
2013-10-31 13.10 Aardvark First stable release
2014-04-30 14.04 Baboon Linux kernel 3.12
2014-12-30 14.12 Caterpillar Linux kernel 3.14
2015-09-30 15.09 Dingo Linux kernel 3.18
2016-03-31 16.03 Emu Linux kernel 4.4
2016-09-30 16.09 Flounder Linux kernel 4.4
2017-03-31 17.03 Gorilla Linux kernel 4.9
2017-09-29 17.09 Hummingbird Linux kernel 4.9
2018-04-04 18.03 Impala Linux kernel 4.14
2018-10-05 18.09 Jellyfish Linux kernel 4.14
2019-04-11 19.03 Koi Linux kernel 4.19
2019-10-09 19.09 Loris Linux kernel 4.19
2020-04-20 20.03 Markhor Linux kernel 5.4
2020-10-27 20.09 Nightingale Linux kernel 5.4

Features

Declarative system configuration model

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. This means that building a new configuration cannot overwrite previous configurations.[12]

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

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

After changing the configuration file, the system can be updated using the nixos-rebuild switch command. This command does everything necessary to apply the new configuration, including downloading and compiling packages and generating configuration files.

Reliable upgrades

Since Nix files are pure and declarative, evaluating them 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

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.[14]

Rollbacks

If after a system update the new configuration is undesirable, it can be rolled back using a special command (nixos-rebuild switch --rollback). Every system configuration version automatically shows up at the system boot menu. If the new configuration crashes or does not boot properly, an older version can be selected. Rollbacks are lightweight operations that do not involve files being restored from copies.

Reproducible system configurations

NixOS's 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 generates the same system configuration (kernel, applications, system services, and so on) except for parts of the system not managed by the package manager such as user data.

Source-based model, with binaries

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.[15]

Consistency

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 then the package manager will ensure that external kernel modules will be rebuilt. Similarly, 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

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

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 and 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 doesn't follow the Filesystem Hierarchy Standard. The only exceptions are a symlink /bin/sh to the version of bash in the Nix store (like this: /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 /nix/store such as /nix/store/s2sjbl85xnrc18rl4fhn56irkxqxyk4p-sshd_config. Not using global directories such as /bin is part of what allows multiple versions of a package to coexist.

Reception

Jesse Smith reviewed NixOS 15.09 for DistroWatch Weekly.[16] Smith wrote:

I very much like the way NixOS takes the worry out of upgrading packages by placing each change in its own "generation" and I found, from the end user's point of view, NixOS worked just the same as any other Linux distribution. Setting up NixOS is not for beginners, and I do not think NixOS is intended to be used as a general purpose desktop operating system. But what NixOS does do is give us a useful playground in which to examine the Nix package manager and I think this is very interesting technology which deserves further exploration and adoption by additional distributions.

DistroWatch Weekly also has a review of NixOS 17.03, written by Ivan Sanders.[17]

See also

References

  1. ^ "Release 20.09 ("Nightingale", 2020-10-27)". 2020-10-27. Retrieved 2020-10-28.
  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. Archived from the original (PDF) on 2019-04-21.
  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.). Archived from the original (PDF) on 2019-06-09.
  8. ^ "Stichting NixOS Foundation". Nixos.org. Retrieved 2015-09-19.
  9. ^ "Governance". Nixos.org. Retrieved 2020-08-28.
  10. ^ https://github.com/NixOS/rfcs/blob/master/rfcs/0080-nixos-release-schedule.md
  11. ^ "Appendix B. Release Notes". Nixos.org. Retrieved 2020-08-28.
  12. ^ Dolstra, Eelco; Hemel, Armijn (2007). "Purely Functional System Configuration Management" (PDF). Archived from the original (PDF) on 2019-07-06. {{cite journal}}: Cite journal requires |journal= (help)
  13. ^ "About NixOS". Nixos.org. Retrieved 2015-09-19.
  14. ^ van der Burg, Sander; Dolstra, Eelco; de Jonge, Merijn (2008). "Atomic Upgrading of Distributed Systems" (PDF). Archived from the original (PDF) on 2019-01-15. {{cite journal}}: Cite journal requires |journal= (help)
  15. ^ Dolstra, Eelco (2005). "Secure Sharing Between Untrusted Users in a Transparent Source/Binary Deployment Model" (PDF). Archived from the original (PDF) on 2019-09-26. {{cite journal}}: Cite journal requires |journal= (help)
  16. ^ DistroWatch Weekly, Issue 637, 23 November 2015
  17. ^ DistroWatch Weekly, Issue 712, 15 May 2017
  18. ^ "About — GuixSD". www.gnu.org. Retrieved 2018-05-03.