5396304c73
more common than the latter (which exists only on Linux and FreeBSD). We don't really care about dropping the saved IDs since there apparently is no way to quiry them in any case, so it can't influence the build (unlike the effective IDs which are checked by Perl for instance).
147 lines
6 KiB
XML
147 lines
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 the deployment of software. Software
|
|
deployment is concerned with the creation, distribution, and
|
|
management of software components (<quote>packages</quote>). There
|
|
are many tools for this, but they tend to ignore some important
|
|
requirements for deployment:
|
|
|
|
<itemizedlist>
|
|
|
|
<listitem><para><emphasis>Correctness</emphasis>. The basic goal of
|
|
software deployment is to transfer software from one machine (e.g.,
|
|
the developer's, where it presumably works) to another machine (e.g.,
|
|
the end user's). The software should work exactly the same on the
|
|
target machine as on the source machine. But this in practice turns
|
|
out to be rather difficult due to <emphasis>dependencies between
|
|
components</emphasis> and <emphasis>interference between
|
|
components</emphasis>. If we deploy a component that depends on other
|
|
components, then we should deploy those dependencies as well. If they
|
|
are missing on the target system, the component probably won't work.
|
|
If they <emphasis>are</emphasis> present but are not the right
|
|
version, the component might not work. And if even if they are the
|
|
right version, they may have been built with different flags or
|
|
options, which can cause incompatibilities. Interference occurs when
|
|
components <quote>collide</quote> with each other in the file system.
|
|
For instance, different versions of the same package tend to overwrite
|
|
each other, so they cannot be installed at the same time. But always
|
|
picking the latest version might break components that only work with
|
|
some older version.</para></listitem>
|
|
|
|
<listitem><para><emphasis>Variability</emphasis>. Many package
|
|
management tools have difficulty supporting the installation of
|
|
multiple versions or variants of the same component. This is bad
|
|
because as ...</para></listitem>
|
|
|
|
</itemizedlist>
|
|
|
|
</para>
|
|
|
|
<para>Here are some of Nix's main features:
|
|
|
|
<itemizedlist>
|
|
|
|
<listitem><para>Nix can quite reliably figure out the dependencies
|
|
between components.</para></listitem>
|
|
|
|
</itemizedlist>
|
|
|
|
</para>
|
|
|
|
<warning><para>This manual is a work in progress. It's quite likely
|
|
to be incomplete, inconsistent with the current implementation, or
|
|
simply wrong.</para></warning>
|
|
|
|
<note><para>Some background information on Nix can be found in two
|
|
papers. The ICSE 2004 paper <ulink
|
|
url='http://www.cs.uu.nl/~eelco/pubs/immdsd-icse2004-final.pdf'><citetitle>Imposing
|
|
a Memory Management Discipline on Software
|
|
Deployment</citetitle></ulink> discusses the hashing mechanism used to
|
|
ensure reliable dependency identification and non-interference between
|
|
different versions and variants of packages. The LISA 2004 paper
|
|
<citetitle>Nix: A Safe and Policy-Free System for Software
|
|
Deployment</citetitle> gives a more general discussion of Nix from a
|
|
system-administration perspective.</para></note>
|
|
|
|
<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>
|