diff options
Diffstat (limited to 'doc/manual/introduction.xml')
| -rw-r--r-- | doc/manual/introduction.xml | 337 |
1 files changed, 0 insertions, 337 deletions
diff --git a/doc/manual/introduction.xml b/doc/manual/introduction.xml deleted file mode 100644 index 21b1df1564..0000000000 --- a/doc/manual/introduction.xml +++ /dev/null @@ -1,337 +0,0 @@ -<chapter xmlns="http://docbook.org/ns/docbook" - xmlns:xlink="http://www.w3.org/1999/xlink" - xml:id="chap-introduction"> - -<title>Introduction</title> - - -<section><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) - ---> - -</section> - - -<section><title>About us</title> - -<para>Nix was originally developed at the <link -xlink:href="http://www.cs.uu.nl/">Department of Information and -Computing Sciences</link>, Utrecht University by the <link -xlink:href="http://www.cs.uu.nl/wiki/Trace/WebHome">TraCE -project</link> (2003-2008). The project was funded by the Software -Engineering Research Program <link -xlink:href="http://www.jacquard.nl/">Jacquard</link> to improve the -support for variability in software systems. Further funding was -provided by the NIRICT LaQuSo Build Farm project. Development is -currently supported by <link -xlink:href="http://www.logicblox.com/">LogicBlox</link>.</para> - -</section> - - -<section><title>About this manual</title> - -<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 distributed multi-platform building.</para> - -</section> - - -<section><title>License</title> - -<para>Nix is free software; you can redistribute it and/or modify it -under the terms of the <link -xlink:href="http://www.gnu.org/licenses/lgpl.html">GNU Lesser General -Public License</link> as published by the <link -xlink:href="http://www.fsf.org/">Free Software Foundation</link>; -either version 2.1 of the License, or (at your option) any later -version. Nix is distributed in the hope that it will be useful, but -WITHOUT ANY WARRANTY; without even the implied warranty of -MERCHANTABILITY or FITNESS FOR A PARTICULAR PURPOSE. See the GNU -Lesser General Public License for more details.</para> - -</section> - - -<section><title>More information</title> - -<para>Some background information on Nix can be found in a number of -papers. The ICSE 2004 paper <citetitle -xlink:href='http://www.st.ewi.tudelft.nl/~dolstra/pubs/immdsd-icse2004-final.pdf'>Imposing -a Memory Management Discipline on Software Deployment</citetitle> -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 -xlink:href='http://www.st.ewi.tudelft.nl/~dolstra/pubs/nspfssd-lisa2004-final.pdf'>Nix: -A Safe and Policy-Free System for Software Deployment</citetitle> -gives a more general discussion of Nix from a system-administration -perspective. The CBSE 2005 paper <citetitle -xlink:href='http://www.st.ewi.tudelft.nl/~dolstra/pubs/eupfcdm-cbse2005-final.pdf'>Efficient -Upgrading in a Purely Functional Component Deployment Model -</citetitle> is about transparent patch deployment in Nix. The SCM-12 -paper <citetitle -xlink:href='http://www.st.ewi.tudelft.nl/~dolstra/pubs/servicecm-scm12-final.pdf'> -Service Configuration Management</citetitle> shows how services (e.g., -web servers) can be deployed and managed through Nix. An overview of -NixOS is given in the JFP article <citetitle -xlink:href="http://www.st.ewi.tudelft.nl/~dolstra/pubs/nixos-jfp-final.pdf">NixOS: -A Purely Functional Linux Distribution</citetitle>. The Nix homepage -has <link xlink:href="http://nixos.org/docs/papers.html">an up-to-date -list of Nix-related papers</link>.</para> - -<para>Nix is the subject of Eelco Dolstra’s PhD thesis <citetitle -xlink:href="http://igitur-archive.library.uu.nl/dissertations/2006-0118-200031/index.htm">The -Purely Functional Software Deployment Model</citetitle>, which -contains most of the papers listed above.</para> - -<para>Nix has a homepage at <link -xlink:href="http://nixos.org/"/>.</para> - -</section> - - -</chapter> |