Restructuring the Nix manual

1 files changed, 253 insertions, 0 deletions

diff --git a/doc/manual/introduction/about-nix.xml b/doc/manual/introduction/about-nix.xml
new file mode 100644
index 000000000000..38dd7e6657a3
--- /dev/null
+++ b/doc/manual/introduction/about-nix.xml
@@ -0,0 +1,253 @@
+<chapter xmlns="http://docbook.org/ns/docbook"
+      xmlns:xlink="http://www.w3.org/1999/xlink"
+      xmlns:xi="http://www.w3.org/2001/XInclude"
+      version="5.0"
+      xml:id="ch-about-nix">
+
+<title>About Nix</title>
+
+<para>Nix is a <emphasis>purely functional package manager</emphasis>.
+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 <emphasis>Nix
+store</emphasis>, usually the directory
+<filename>/nix/store</filename>, where each package has its own unique
+subdirectory such as
+
+<programlisting>
+/nix/store/nlc4z5y1hm8w9s8vm6m1f5hy962xjmp5-firefox-12.0
+</programlisting>
+
+where <literal>nlc4z5…</literal> 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.</para>
+
+
+<simplesect><title>Multiple versions</title>
+
+<para>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.</para>
+
+<para>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.</para>
+
+</simplesect>
+
+
+<simplesect><title>Complete dependencies</title>
+
+<para>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
+package 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>
+
+<para>Since Nix on the other hand doesn’t install packages in “global”
+locations like <filename>/usr/bin</filename> 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
+<filename>/nix/store/5lbfaxb722zp…-openssl-0.9.8d/include</filename>,
+so if a package builds correctly on your system, this is because you
+specified the dependency explicitly.</para>
+
+<para>Runtime dependencies are found by scanning binaries for the hash
+parts of Nix store paths (such as <literal>r8vvq9kq…</literal>).  This
+sounds risky, but it works extremely well.</para>
+
+</simplesect>
+
+
+<simplesect><title>Multi-user support</title>
+
+<para>Nix has multi-user support.  This means that non-privileged
+users can securely install software.  Each user can have a different
+<emphasis>profile</emphasis>, a set of packages in the Nix store that
+appear in the user’s <envar>PATH</envar>.  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.</para>
+
+<!--
+<para>More details can be found in Section 3 of our <a
+href="docs/papers.html#securesharing">ASE 2005 paper</a>.</para>
+-->
+
+</simplesect>
+
+
+<simplesect><title>Atomic upgrades and rollbacks</title>
+
+<para>Since package management operations never overwrite packages in
+the Nix store but just add new versions in different paths, they are
+<emphasis>atomic</emphasis>.  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.</para>
+
+<para>And since package aren’t overwritten, the old versions are still
+there after an upgrade.  This means that you can <emphasis>roll
+back</emphasis> to the old version:</para>
+
+<screen>
+$ nix-env --upgrade <replaceable>some-packages</replaceable>
+$ nix-env --rollback
+</screen>
+
+</simplesect>
+
+
+<simplesect><title>Garbage collection</title>
+
+<para>When you uninstall a package like this…
+
+<screen>
+$ nix-env --uninstall firefox
+</screen>
+
+the package isn’t deleted from the system right away (after all, you
+might want to do a rollback, or it might be in the profiles of other
+users).  Instead, unused packages can be deleted safely by running the
+<emphasis>garbage collector</emphasis>:
+
+<screen>
+$ nix-collect-garbage
+</screen>
+
+This deletes all packages that aren’t in use by any user profile or by
+a currently running program.</para>
+
+</simplesect>
+
+
+<simplesect><title>Functional package language</title>
+
+<para>Packages are built from <emphasis>Nix expressions</emphasis>,
+which is a simple functional language.  A Nix expression describes
+everything that goes into a package build action (a “derivation”):
+other packages, sources, the build script, environment variables for
+the build script, etc.  Nix tries very hard to ensure that Nix
+expressions are <emphasis>deterministic</emphasis>: building a Nix
+expression twice should yield the same result.</para>
+
+<para>Because it’s a functional language, it’s easy to support
+building variants of a package: turn the Nix expression into a
+function and call it any number of times with the appropriate
+arguments.  Due to the hashing scheme, variants don’t conflict with
+each other in the Nix store.</para>
+
+</simplesect>
+
+
+<simplesect><title>Transparent source/binary deployment</title>
+
+<para>Nix expressions generally describe how to build a package from
+source, so an installation action like
+
+<screen>
+$ nix-env --install firefox
+</screen>
+
+<emphasis>could</emphasis> cause quite a bit of build activity, as not
+only Firefox but also all its dependencies (all the way up to the C
+library and the compiler) would have to built, at least if they are
+not already in the Nix store.  This is a <emphasis>source deployment
+model</emphasis>.  For most users, building from source is not very
+pleasant as it takes far too long.  However, Nix can automatically
+skip building from source and download a pre-built binary instead if
+it knows about it.  <emphasis>Nix channels</emphasis> provide Nix
+expressions along with pre-built binaries.</para>
+
+<!--
+<para>source deployment model (like <a
+href="http://www.gentoo.org/">Gentoo</a>) and a binary model (like
+RPM)</para>
+-->
+
+</simplesect>
+
+
+<simplesect><title>Binary patching</title>
+
+<para>In addition to downloading binaries automatically if they’re
+available, Nix can download binary deltas that patch an existing
+package in the Nix store into a new version.  This speeds up
+upgrades.</para>
+
+</simplesect>
+
+
+<simplesect><title>Nix Packages collection</title>
+
+<para>We provide a large set of Nix expressions containing hundreds of
+existing Unix packages, the <emphasis>Nix Packages
+collection</emphasis> (Nixpkgs).</para>
+
+</simplesect>
+
+
+<simplesect><title>Service deployment</title>
+
+<para>Nix can be used not only for rolling out packages, but also
+complete <emphasis>configurations</emphasis> of services.  This is
+done by treating all the static bits of a service (such as software
+packages, configuration files, control scripts, static web pages,
+etc.) as “packages” that can be built by Nix expressions.  As a
+result, all the features above apply to services as well: for
+instance, you can roll back a web server configuration if a
+configuration change turns out to be undesirable, you can easily have
+multiple instances of a service (e.g., a test and production server),
+and because the whole service is built in a purely functional way from
+a Nix expression, it is repeatable so you can easily reproduce the
+service on another machine.</para>
+
+<!--
+<para>You can read more about this in our <a
+href="docs/papers.html#servicecm">SCM-12 paper</a>.</para>
+-->
+
+</simplesect>
+
+
+<simplesect><title>Portability</title>
+
+<para>Nix should run on most Unix systems, including Linux, FreeBSD and
+Mac OS X.<!-- It is also supported on Windows using Cygwin.--></para>
+
+</simplesect>
+
+
+<simplesect><title>NixOS</title>
+
+<para>NixOS is a Linux distribution based on Nix.  It uses Nix not
+just for package management but also to manage the system
+configuration (e.g., to build configuration files in
+<filename>/etc</filename>).  This means, among other things, that it’s
+possible to easily roll back the entire configuration of the system to
+an earlier state.  Also, users can install software without root
+privileges.  For more information and downloads, see the <link
+xlink:href="http://nixos.org/">NixOS homepage</link>.</para>
+
+</simplesect>
+
+
+<!-- other features:
+
+- build farms
+- reproducibility (Nix expressions allows whole configuration to be rebuilt)
+
+-->
+
+</chapter>
\ No newline at end of file