143 lines
7 KiB
XML
143 lines
7 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>). Its main
|
|
features are:
|
|
|
|
<itemizedlist>
|
|
|
|
<listitem><para>It helps you make sure that dependency specifications
|
|
are complete. In general in a deployment system you have to specify
|
|
for each component 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
|
|
<emphasis>your</emphasis> machine if you have the dependency
|
|
installed, but not on the end user's machine if it's not
|
|
there.</para></listitem>
|
|
|
|
<listitem><para>It is possible to have <emphasis>multiple versions or
|
|
variants</emphasis> of a component installed at the same time. In
|
|
contrast, in systems such as RPM different versions of the same
|
|
package tend to install to the same location in the file system, so
|
|
installing one version will remove the other. This is especially
|
|
important if you want to use applications that have conflicting
|
|
requirements on different versions of a component (e.g., application A
|
|
requires version 1.0 of library X, while application B requires a
|
|
non-backwards compatible version 1.1).</para></listitem>
|
|
|
|
<listitem><para>Users can have different <quote>views</quote>
|
|
(<quote>profiles</quote> in Nix parlance) on the set of installed
|
|
applications in a system. For instance, one user can have version 1.0
|
|
of some package visible, while another is using version 1.1, and a
|
|
third doesn't use it at all.</para></listitem>
|
|
|
|
<listitem><para>It is possible to atomically
|
|
<emphasis>upgrade</emphasis> software. I.e., there is no time window
|
|
during an upgrade in which part of the old version and part of the new
|
|
version are simultaneously visible (which might well cause the
|
|
component to fail).</para></listitem>
|
|
|
|
<listitem><para>Likewise, it is possible to atomically roll back after
|
|
an install, upgrade, or uninstall action. That is, in a fast (O(1))
|
|
operation the previous configuration of the system can be restored.
|
|
This is because upgrade or uninstall actions don't actually remove
|
|
components from the system.</para></listitem>
|
|
|
|
<listitem><para>Unused components can be
|
|
<emphasis>garbage-collected</emphasis> automatically and safely: when
|
|
you remove an application from a profile, its dependencies will be
|
|
deleted by the garbage collector only if there are no other active
|
|
applications using them.</para></listitem>
|
|
|
|
<listitem><para>Nix supports both source-based deployment models
|
|
(where you distribute <emphasis>Nix expressions</emphasis> that tell
|
|
Nix how to build software from source) and binary-based deployment
|
|
models. The latter is more-or-less transparent: installation of
|
|
components is always based on Nix expressions, but if the expressions
|
|
have been built before and Nix knows that the resulting binaries are
|
|
available somewhere, it will use those instead.</para></listitem>
|
|
|
|
<listitem><para>Nix is flexible in the deployment policies that it
|
|
supports. There is a clear separation between the tools that
|
|
implement basic Nix <emphasis>mechanisms</emphasis> (e.g., building
|
|
Nix expressions), and the tools that implement various deployment
|
|
<emphasis>policies</emphasis>. For instance, there is a concept of
|
|
<quote>Nix channels</quote> that can be used to keep software
|
|
installations up-to-date automatically from a network source. This is
|
|
a policy that is implemented by a fairly short Perl script, which can
|
|
be adapted easily to achieve similar policies.</para></listitem>
|
|
|
|
<listitem><para>Nix component builds aim to be <quote>pure</quote>;
|
|
that is, unaffected by anything other than the declared dependencies.
|
|
This means that if a component was built succesfully once, it can be
|
|
rebuilt again on another machine and the result will be the same. We
|
|
cannot <emphasis>guarantee</emphasis> this (e.g., if the build depends
|
|
on the time-of-day), but Nix (and the tools in the Nix Packages
|
|
collection) takes special care to help achieve this.</para></listitem>
|
|
|
|
<listitem><para>Nix expressions (the things that tell Nix how to build
|
|
components) are self-contained: they describe not just components but
|
|
complete compositions. In other words, Nix expressions also describe
|
|
how to build all the dependencies. This is in contrast to component
|
|
specification languages like RPM spec files, which might say that a
|
|
component X depends on some other component Y, but since it does not
|
|
describe <emphasis>exactly</emphasis> what Y is, the result of
|
|
building or running X might be different on different machines.
|
|
Combined with purity, self-containedness ensures that a component that
|
|
<quote>works</quote> on one machine also works on another, when
|
|
deployed using Nix.</para></listitem>
|
|
|
|
<listitem><para>The Nix expression language makes it easy to describe
|
|
variability in components (e.g., optional features or
|
|
dependencies).</para></listitem>
|
|
|
|
<listitem><para>Nix is ideal for building build farms that do
|
|
continuous builds of software from a version management system, since
|
|
it can take care of building all the dependencies as well. Also, Nix
|
|
only rebuilds components that have changed, so there are no
|
|
unnecessary builds. In addition, Nix can transparently distribute
|
|
build jobs over different machines, including different
|
|
platforms.</para></listitem>
|
|
|
|
<listitem><para>Nix can be used not only for software deployment, but
|
|
also for <emphasis>service deployment</emphasis>, such as the
|
|
deployment of a complete web server with all its configuration files,
|
|
static pages, software dependencies, and so on. Nix's advantages for
|
|
software deployment also apply here: for instance, the ability
|
|
trivially to have multiple configurations at the same time, or the
|
|
ability to do rollbacks.</para></listitem>
|
|
|
|
</itemizedlist>
|
|
|
|
</para>
|
|
|
|
<para>This manual tells you how to install and use Nix and how to
|
|
write Nix expressions for software not already in the Nix Packages
|
|
collection. It also discusses some advanced topics, such as setting
|
|
up a Nix-based build farm, and doing service deployment using
|
|
Nix.</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
|
|
<ulink
|
|
url='http://www.cs.uu.nl/~eelco/pubs/nspfssd-lisa2004-final.pdf'><citetitle>Nix:
|
|
A Safe and Policy-Free System for Software
|
|
Deployment</citetitle></ulink> gives a more general discussion of Nix
|
|
from a system-administration perspective.</para></note>
|
|
|
|
</chapter>
|