lix/doc/manual/introduction.xml

185 lines
4.8 KiB
XML
Raw Normal View History

<chapter>
<title>Introduction</title>
<sect1>
<title>The problem space</title>
<para>
Nix is a system for controlling the automatic creation and distribution
of data, such as computer programs and other software artifacts. This is
a very general problem, and there are many applications that fall under
this description.
</para>
<sect2>
<title>Build management</title>
<para>
2003-08-13 15:17:57 +00:00
Build management tools are used to perform <emphasis>software
builds</emphasis>, that is, the construction of derived products such
as executable programs from source code. A commonly used build tool is
Make, which is a standard tool on Unix systems. These tools have to
deal with several issues:
2003-08-13 15:17:57 +00:00
<itemizedlist>
<listitem>
<para>
</para>
</listitem>
2003-08-13 15:17:57 +00:00
</itemizedlist>
</para>
</sect2>
<sect2>
<title>Package management</title>
<para>
2003-08-13 15:17:57 +00:00
After software has been built, is must also be
<emphasis>deployed</emphasis> in the intended target environment, e.g.,
the user's workstation. Examples include the Red Hat package manager
(RPM), Microsoft's MSI, and so on. Here also we have to deal with
several issues:
2003-08-13 15:17:57 +00:00
<itemizedlist>
<listitem>
<para>
The <emphasis>creation</emphasis> of packages from some formal
description of what artifacts should be distributed in the
package.
</para>
</listitem>
<listitem>
<para>
The <emphasis>deployment</emphasis> of packages, that is, the
mechanism by which we get them onto the intended target
environment. This can be as simple as copying a file, but
complexity comes from the wide range of possible installation
media (such as a network install), and the scalability of the
process (if a program must be installed on a thousand systems, we
do not want to visit each system and perform some manual steps to
install the program on that system; that is, the complexity for
the system administrator should be constant, not linear).
</para>
</listitem>
2003-08-13 15:17:57 +00:00
</itemizedlist>
</para>
</sect2>
</sect1>
2003-08-13 15:17:57 +00:00
<!--######################################################################-->
<sect1>
<title>What Nix can do for you</title>
<para>
Here is a summary of what Nix provides:
</para>
<itemizedlist>
<listitem>
<para>
<emphasis>Reliable dependencies.</emphasis>
</para>
</listitem>
<listitem>
<para>
<emphasis>Support for variability.</emphasis>
</para>
</listitem>
<listitem>
<para>
<emphasis>Transparent source/binary deployment.</emphasis>
</para>
</listitem>
<listitem>
<para>
<emphasis>Easy configuration duplication.</emphasis>
</para>
</listitem>
<listitem>
<para>
<emphasis>Automatic storage management.</emphasis>
</para>
</listitem>
<listitem>
<para>
<emphasis>Atomic upgrades and rollbacks.</emphasis>
</para>
</listitem>
<listitem>
<para>
<emphasis>Support for many simultaneous configurations.</emphasis>
</para>
</listitem>
</itemizedlist>
<para>
Here is what Nix doesn't yet provide, but will:
</para>
<itemizedlist>
<listitem>
<para>
<emphasis>Build management.</emphasis> In principle it is already
possible to do build management using Fix (by writing builders that
perform appropriate build steps), but the Fix language is not yet
powerful enough to make this pleasant. The <ulink
url='http://www.cs.uu.nl/~eelco/maak/'>Maak build manager</ulink>
should be retargeted to produce Nix expressions, or alternatively,
extend Fix with Maak's semantics and concrete syntax (since Fix needs
a concrete syntax anyway). Another interesting idea is to write a
<command>make</command> implementation that uses Nix as a back-end to
support <ulink
url='http://www.research.att.com/~bs/bs_faq.html#legacy'>legacy</ulink>
build files.
</para>
</listitem>
</itemizedlist>
</sect1>
<!--######################################################################-->
<sect1>
<title>The Nix system</title>
<para>
...
</para>
<para>
Existing tools in this field generally both a underlying model (such as
the derivation graph of build tools, or the versioning scheme that
determines when two packages are <quote>compatible</quote> in a package
management system) and a formalism that allows ...
</para>
<para>
Following the principle of separation of mechanism and policy, the Nix
system separates the <emphasis>low-level aspect</emphasis> of file system
object management form the <emphasis>high-level aspect</emphasis> of the
...
</para>
</sect1>
</chapter>
<!--
local variables:
sgml-parent-document: ("book.xml" "chapter")
end:
-->