What is the Nix Operating System?

Overview

The NIX is a distribution that is being built on the basis of the Nix package manager. The NIX operating system provides the user with a declarative configuration and it also allows reliable system upgrades. The Nix language is a simple programming language called lazy lambda calculus that was created specifically for configuring Nix packages. Since it uses a lazy lambda calculus, it is unable to perform side effects and can only typically evaluate expressions to a value.

It does, however, provide a few built-in features for the limited side effects necessary for that purpose because it was made for setting packages. We list it first because Nix the language is present in all other instances where the word Nix is used: it is used to write package settings, to configure your NixOS system, and to run commands on the command line, particularly with NixOS and NixOps, where commands can be Nix expressions. The Nix language has a REPL available.

Some other reason to appreciate the Nix operating system is how simple provisioning a new machine can be since you can select which packages to install when your OS is built right in your configuration file. These packages can be both default ones from the nixpkgs repository and custom ones that you develop yourself. Despite the fact that we both use NixOS on our home computers, this is particularly fantastic for servers.

History

The NIX operating system was a research project which was headed by Eelco Dolstra in the year 2003. The Stichting NixOS was established in 2015 with the goal of assisting initiatives like NixOS that use the purely functional deployment model.

Versions

The NixOS operating system is released twice a year. Since NixOS 21.05, this has been targeted at May and November rather than the traditional months or releasing the versions in the month of March and September. Every version number follows the format of YY.MM with 20.03 denoting a release in March 2020. NixOS have some specific names for each release version for example, Markhor for the release version 20.03.

A package may be installed in more than one version or variation at once. This avoids DLL hell which is particularly critical when different apps depend on various versions of the same package. Different versions of a package end up in different pathways in the Nix store thanks to the hashing algorithm, which prevents them from interfering with one another.

Since these activities never "destructively" change or destroy files that are utilized by other packages, a significant result is that operations like upgrading or uninstalling one application cannot harm other apps.

Features

The following are the features of the NIX operating system:

Declarative Configuration Model

In the NIX operating system, we can not overwrite the system configuration. By saying overwriting, it means that in the NIX operating system, all the applications, kernel, system packages, and all the files related to the configuration are built using the NIX package manager in a functional language. A global configuration file is used to specify the functionality that the user needs on their machine while configuring a NixOS system. Here is an example of a machine running an SSH daemon in its most basic configuration:

A global configuration file is used to specify the functionality that the user needs on their machine while configuring a NixOS system. Here is an example of a machine running an SSH daemon in its most basic configuration.

Reliable Upgrades

The resultant output that we get after processing the Nix files will result from the same because it does not matter for the NIX operating system where the package and the configuration files are stored. They are just real and we can easily declare the files. So, it is better to completely reinstall as well as to update a system.

Rollbacks

A specific command can be used to roll back the new configuration if it is unwelcome following a system update (nixos-rebuild switch —rollback). At the system boot menu, every iteration of the system configuration is automatically visible. A previous configuration can be used if the current one crashes or doesn't boot correctly. Rollbacks are quick actions that don't need restoring files from backups.

Automatic Upgrades

The nix operating system consists of a transactional approach for configuring any management or configuration-related changes in the system, for example, if we need to upgrade the atomics of the system then the nix operating system approaches the transactional approach. But it may be possible in some systems, a system can be inconsistent and there may be the possibility of system failure.

Reproducible System Configurations

The declarative configuration of the NIX operating makes it the operating system possible to reproduce the configuration of the system to another system very easily and smoothly. When we copy the configuration file to the specified machine and run the system update command, this will produce the same configuration of the system configurations of (applications, the kernel, system services, etc) that can be produced using the system update command. But this feature works only on the parts of the system that is not being managed by the package manager. For example, the parts of the system related to the user data.

Source-based Model

NixOS's build language for Nix describes how to create packages from source code. This makes modifying the system to meet user needs simple. In the NIX operating system, the package manager can download the binaries that are pre-built from a cache server whenever the version is available because building from a source is a time-consuming procedure. This combines the flexibility of a package management system based on sources with the effectiveness of a binary system.

Consistency

In a Nix operating system, the package manages and makes sure that the system that is running contemporary is consistent in accordance with the logical features and specifications of the system. This means whatever logic and packages are needed will be rebuilt automatically. 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. It is the same for the library of a system. If the library changes then all the system libraries will also be rebuilt.

Multi-user Package Management

We can install the NIX operating system easily without any specific rights or permission from the company. Not only this, but the user has permission to install the particular package of the Nix operating system according to their need and demand in their specific profile. There are multiple users allowed in the Nix operating system. All the contents of the Nix operating system are managed and manipulated by the user independently. So, there are no security issues related to the installation of the Nix operating system. Without those arguments, pathways can only be substituted from a substituter that the system implicitly trusts or from a local sand-boxed build.

Complete Dependencies

It is required to define dependencies when creating a package for a package management system like RPM, however, it is difficult to ensure that your dependency declaration is accurate. The component may develop and function properly on your machine but malfunction on the system of the end user if a dependency that you loaded separately on your machine is forgotten. Nix makes ensuring that package dependencies are fully specified.

Only resources that have been explicitly defined as dependencies will be discovered by a build process under Nix operating system. Under Nix, a build process will only find resources that have been declared explicitly as dependencies. There's no way it can build until everything it needs has been correctly declared. If it builds, you will know you've provided a complete declaration. Once a build is complete, ongoing runtime dependencies are detected automatically.

Garbage Collection

In the NIX operating system, when we uninstall any package using the following command:

in this way, the system package does not just uninstall away from the system and is not present in the system anymore. But for the packages that is being unused for a time, we can delete them safely by using the garbage collector command which is as follows:

This removes any packages that aren't being used by a running program or any user profiles.

Transparent Source/Binary Deployment

Typically, Nix expressions explain how to create packages from source code, so an installation step like

may result in a significant amount of build activity because, if not already included in the Nix store, all of Firefox's dependencies (all the way down to the C library and the compiler) would need to be generated. This deployment model is for sources. The majority of users find a building from a source to be tedious and time-consuming. Nix, on the other hand, has the ability to automatically forego building from source and utilize a binary cache, a web server that offers pre-built binaries.

For example, suppose we need to create /nix/store/b6gvzjyb2pg0…-firefox-33.1 from the source, the NIX will first check if there is some file available http://cache.nixos.org/b6gvzjyb2pg0….narinfo. And if this file is present it tries to access the pre-built binary reference else the package will fail in building from the source.

Functional Package Language

Nix expressions, a straightforward functional language, are the foundation of packages. Everything that goes into a package construction operation (a "derivation") is described by a Nix expression, including other packages, sources, the build script, environment variables for the build script, etc. Nix makes a lot of effort to make sure Nix expressions are deterministic; two Nix expressions should provide the same outcome.

It is simple to support constructing versions of a package because it is a functional language which means we should convert the Nix expression into a function and then we can call it as many times as necessary with providing the proper inputs. Variants in the Nix store don't clash with one another because of the hashing algorithm.

Nix: How It Works?

The Nix operating system is made up of two components. The first one is the package manager and the second one is the language. Nix is a relatively straightforward, lazy (nearly) pure functional programming language with a dynamic type that focuses on creating packages. On the other side, the package manager is intriguing and fairly distinctive. One thought is where it all begins.

You come across paths like /bin/python or /lib/libudev frequently. So, there are a lot of things about the file that's there that the developer does not know. The question is like:

• what is the version of the package?
• the libraries that we have used
• about if the configure flags were enabled during the build?

The solution for this problem can alter how an application behaves when using that specific files. There are workarounds for this in FHS, such as using /bin/python3.7 in your shebang or linking directly to /lib/libudev.so.1.6.3. But there are still a lot of unanswered questions.

This concludes that the FHS does not work if we need to achieve any consistency or reproducibility because it is impossible to infer a large number of file-specific characteristics. Tools like Docker, Snap, and Flatpak, which produce distributed isolated FHS environments with stable versions of all an application's dependencies, are one approach. There are other issues with this solution, though.

What happens if we wish to alter one of the dependencies or apply different configuration options to our application? Because tools from the FHS of the host are frequently used during build-time and because the reliability that occurs from other isolated environments may change, putting all the build artifacts in an isolated container only ensures consistency, not reproducibility, so getting the build artifact from build instructions is not guaranteed.

Advantages

The following are the advantages of the NIX operating system.

Reproducibility

Given that Nix's entire purpose is to achieve this, it is the benefit that is most clear. If you're cautious enough to pin the versions of the inputs in place, two persons constructing the same package will always produce the same result (see the comment above for circumstances when the output can slightly differ). Additionally, since the store path will change, it will be highly obvious even if some input is changed.

Binary Caching

Binary caching is another benefit Nix provides. As we already know the path of the source before making it, there will be the same path for the same output, and we can update the path from one location to the other location but also we need to be confident about the path that the user is making. This makes it possible that the outputs can be signed after the path has been built and it also ensures that no one can store them in an untrusted location).

Multi-version of Any Package Can Be Installed

There are no conflicts because each package has its own prefix during installation (until a particular package depends on numerous versions of a different package, which is not an obvious occurrence and is typically manageable). Think of virtualenvs from Python, but for any language, and you can see how useful this may be during development!

Distributed Building

As long as the remote server already has all the dependencies, we can easily implement a given derivation remotely because we are aware of exactly what is required.

Non-privileged Builds

Since the build is isolated, only its output can be changed on the host system. This indicates that allowing non-privileged users to realize derivations is secure.

Less state = smaller backups

We can safely omit the dependencies from backups since the program and its dependents can now be simply rebuilt from just the derivations.

Ecosystem

Although these advantages are great, Nix's ideas can be developed further. So far, we have only discussed repeatable builds and have said nothing about runtime consistency, another quality that is crucial for the DevOps team's ability to sleep soundly at night. How can we be certain that each time we deploy the program to the server, it will have the exact same configuration files and Linux kernel version?

Nixpkgs

The Nix package descriptions can be readily modified and merged together in the vast repository known as nixpkgs. It includes a full and current mirror of Hackage plus a number of language-specific package collections. Additionally, it has strong cross-compilation tools. For instance, bash may be cross-compiled for Windows with the ease of nix build nixpkgs.pkgsCross.mingwW64.bash.

Nix becomes an extremely potent tool for application development thanks to nixpkgs, especially if you need to target many platforms and use a variety of languages.

What Does Nix Actually Do as a Package Manager?

The NIX operating system works as a package manager and the nix operating system is compatible with various operating systems. In the Nix operating system, there is no difference between the package that the user gets from the central host and the package that we had earlier described in contrast to the majority of analogous systems like apt.

Nix is a Build Tool

The architecture of the nix operating system emphasizes atomic, repeatable builds. Because the dependency of each package is listed and packed independently from each other, everything that the package requires is installed when the user installs the package manager, making builds reproducible. Therefore, if a Nix package can be built on one system, it can likewise be built on another. Because Nix does not write over the interrelationships for any other package on the system, installing or updating one package won't break other packages. This is why the builds are atomic.

Nix Comes with Many Packages

The Nix operating system has a huge selection of packages, much like other well-known package managers like apt, homebrew, etc. Nix can be used to install just about any open-source Linux program you can imagine. The GitHub repository where it is all maintained is called nixpkgs, which is also the name of the package collection.