2004-09-09 17:55:31 +02:00
|
|
|
<chapter><title>Introduction</title>
|
2003-08-13 11:13:52 +02:00
|
|
|
|
2004-09-09 17:55:31 +02:00
|
|
|
<epigraph><para><quote>The number of Nix installations in the world
|
|
|
|
has grown to 5, with more expected.</quote></para></epigraph>
|
2003-12-02 17:29:41 +01:00
|
|
|
|
2004-09-09 17:55:31 +02:00
|
|
|
<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>
|
2003-11-26 13:30:16 +01:00
|
|
|
|
|
|
|
<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>
|
2003-08-13 11:13:52 +02:00
|
|
|
|
2003-11-26 13:30:16 +01:00
|
|
|
</chapter>
|