Nix an OS or a package manager
Nix has a lot of features and can be used to solve some common problems:
1. Replacing language version managers such as nvm, rvm, and virtualenv.
2. Separate development dependencies from user dependencies.
3. Create a simple CI process.
The goal of the Nix language is not to become a general-purpose programming language like Haskell or Scala but to make it easier to write a declarative definition of a package (called derivative in the Nix community) for any programming language and any other application or tool.
At the same time, the enormous power of a Nix functional programming language is used. This syntax may seem strange, but it is similar to other programming languages like Haskell. Do not worry if you have not programmed in such a language before.
A Nix package definition is a set of attributes with consistent attribute names. These attributes define all dependencies and the necessary steps (builds) to compile this package and use it as a library or application.
Many popular programming languages have a version manager that installs multiple language versions side by side. After using rvm for Ruby version control and nvm for Node.js, people ran into some issues with them and started looking for alternatives. We have found that the Nix shell functionality discussed earlier provides a more isolated and maintainable solution than language version managers
Nix provides tools for specifying an archived version of the desired dependency to be extracted and compiled from the source. Even if Nix doesn’t have the latest version yet, you can still get the source code and build it with Nix.
Two main advantages
Let’s look at two advantages closer.
This is the most obvious advantage since it is the main motivation of Nix. Two people assembling the same package will always get the same result if you are careful enough with pinning versions of the input data. And even if some of the input data is different, it will be clear because the path to the storage will change.
Another advantage we get from Nix is binary caching. Since the path to the repository is known before the package is built, we are sure that the same path to the repository will contain the same output, we can replace this path to the repository from another location if there is this path in that location and we trust whoever creates it.
These advantages are good, but Nix can be extended. We have only described how to perform reproducible builds and have not said anything about runtime consistency.
How can we be sure that the application will have the same configuration files that the Linux kernel version has every time we deploy it on the server?
NixOS is a Linux distribution that uses Nix as a package and configuration manager. Each configuration file is described as a derivative, and your system is a derivative that depends on all the applications and configuration files you have specified. This way, you get all the benefits of Nix applied to our runtime environment. If two people install an OS system with the same storage path, they will always get the same system on their computers.