
Nix: The Purely Functional Package Manager - peter_d_sherman
https://nixos.org/nix/
======
peter_d_sherman
Also:

[https://nixos.org/nix/about.html](https://nixos.org/nix/about.html)

"Nix is a purely functional package manager. This means that it treats
packages like values in purely functional programming languages such as
Haskell — they are built by functions that don’t have side-effects, and they
never change after they have been built. Nix stores packages in the Nix store,
usually the directory /nix/store, where each package has its own unique
subdirectory such as /nix/store/b6gvzjyb2pg0kjfwrjmg1vfhh54ad73z-firefox-33.1/
where b6gvzjyb2pg0… is a unique identifier for the package that captures all
its dependencies (it’s a cryptographic hash of the package’s build dependency
graph). This enables many powerful features.

Multiple versions

You can have multiple versions or variants of a package installed at the same
time. This is especially important when different applications have
dependencies on different versions of the same package — it prevents the “DLL
hell”. Because of the hashing scheme, different versions of a package end up
in different paths in the Nix store, so they don’t interfere with each other.

An important consequence is that operations like upgrading or uninstalling an
application cannot break other applications, since these operations never
“destructively” update or delete files that are used by other packages.

Complete dependencies

Nix helps you make sure that package dependency specifications are complete.
In general, when you’re making a package for a package management system like
RPM, you have to specify for each package what its dependencies are, but there
are no guarantees that this specification is complete. If you forget a
dependency, then the component will build and work correctly on your machine
if you have the dependency installed, but not on the end user's machine if
it's not there.

Since Nix on the other hand doesn’t install packages in “global” locations
like /usr/bin but in package-specific directories, the risk of incomplete
dependencies is greatly reduced. This is because tools such as compilers don’t
search in per-packages directories such as
/nix/store/5lbfaxb722zp…-openssl-0.9.8d/include, so if a package builds
correctly on your system, this is because you specified the dependency
explicitly.

Runtime dependencies are found by scanning binaries for the hash parts of Nix
store paths (such as r8vvq9kq…). This may sound risky, but it works extremely
well.

Multi-user support

Starting at version 0.11, Nix has multi-user support. This means that non-
privileged users can securely install software. Each user can have a different
profile, a set of packages in the Nix store that appear in the user’s PATH. If
a user installs a package that another user has already installed previously,
the package won’t be built or downloaded a second time. At the same time, it
is not possible for one user to inject a Trojan horse into a package that
might be used by another user.

Atomic upgrades and rollbacks

Since package management operations never overwrite packages in the Nix store
but just add new versions in different paths, they are atomic. So during a
package upgrade, there is no time window in which the package has some files
from the old version and some files from the new version — which would be bad
because a program might well crash if it’s started during that period.

And since packages aren’t overwritten, the old versions are still there after
an upgrade. This means that you can roll back to the old version..."

There are more features; the ones above are the key ones, in my opinion...

