mirror of
https://github.com/privatevoid-net/nix-super.git
synced 2024-11-10 16:26:18 +02:00
93 lines
3.6 KiB
XML
93 lines
3.6 KiB
XML
<chapter>
|
|
<title>Introduction</title>
|
|
|
|
<epigraph>
|
|
<para><quote>The number of Nix installations in the world has grown to 5,
|
|
with more expected.</quote></para>
|
|
</epigraph>
|
|
|
|
<para>
|
|
Nix is a system for software deployment. It supports the
|
|
creation and distribution of software packages, as well as the installation
|
|
and subsequent management of these on target machines (i.e., it is also a
|
|
package manager).
|
|
</para>
|
|
|
|
<para>
|
|
Nix solves some large problems that exist in most current deployment and
|
|
package management systems. <emphasis>Dependency determination</emphasis>
|
|
is a big one: the correct installation of a software component requires
|
|
that all dependencies of that component (i.e., other components used by it)
|
|
are also installed. Most systems have no way to verify that the specified
|
|
dependencies of a component are actually sufficient.
|
|
</para>
|
|
|
|
<para>
|
|
Another big problem is the lack of support for concurrent availability of
|
|
multiple <emphasis>variants</emphasis> of a component. It must be possible
|
|
to have several versions of a component installed at the same time, or
|
|
several instances of the same version built with different parameters.
|
|
Unfortunately, components are in general not properly isolated from each
|
|
other. For instance, upgrading a component that is a dependency for some
|
|
other component might break the latter.
|
|
</para>
|
|
|
|
<para>
|
|
Nix solves these problems by building and storing packages in paths that
|
|
are infeasible to predict in advance. For example, the artifacts of a
|
|
package <literal>X</literal> might be stored in
|
|
<filename>/nix/store/d58a0606ed616820de291d594602665d-X</filename>, rather
|
|
than in, say, <filename>/usr/lib</filename>. The path component
|
|
<filename>d58a...</filename> is actually a cryptographic hash of all the
|
|
inputs (i.e., sources, requisites, and build flags) used in building
|
|
<literal>X</literal>, and as such is very fragile: any change to the inputs
|
|
will change the hash. Therefore it is not sensible to
|
|
<emphasis>hard-code</emphasis> such a path into the build scripts of a
|
|
package <literal>Y</literal> that uses <literal>X</literal> (as does happen
|
|
with <quote>fixed</quote> paths such as <filename>/usr/lib</filename>).
|
|
Rather, the build script of package <literal>Y</literal> is parameterised
|
|
with the actual location of <literal>X</literal>, which is supplied by the
|
|
Nix system.
|
|
</para>
|
|
|
|
<para>
|
|
As stated above, the path name of a file system object contain a
|
|
cryptographic hash of all inputs involved in building it. A change to any
|
|
of the inputs will cause the hash to change--and by extension, the path
|
|
name. These inputs include both sources (variation in time) and
|
|
configuration options (variation in space). Therefore variants of the same
|
|
package don't clash---they can co-exist peacefully within the same file
|
|
system.
|
|
</para>
|
|
|
|
<para>
|
|
Other features:
|
|
</para>
|
|
|
|
<para>
|
|
<emphasis>Transparent source/binary deployment.</emphasis>
|
|
</para>
|
|
|
|
<para>
|
|
<emphasis>Unambiguous identification of configuration.</emphasis>
|
|
</para>
|
|
|
|
<para>
|
|
<emphasis>Automatic storage management.</emphasis>
|
|
</para>
|
|
|
|
<para>
|
|
<emphasis>Atomic upgrades and rollbacks.</emphasis>
|
|
</para>
|
|
|
|
<para>
|
|
<emphasis>Support for many simultaneous configurations.</emphasis>
|
|
</para>
|
|
|
|
<para>
|
|
<emphasis>Portability.</emphasis> Nix is quite portable. Contrary to
|
|
build systems like those in, e.g., Vesta and ClearCase, it does not rely on
|
|
operating system extensions.
|
|
</para>
|
|
|
|
</chapter>
|