nix-super/doc/manual/introduction.xml

<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>
	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:
	<itemizedlist>
	  <listitem>
	    <para>
	    </para>
	  </listitem>
	</itemizedlist>
      </para>

    </sect2>

    <sect2>
      <title>Package management</title>

      <para>
	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:
	<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>
	</itemizedlist>
      </para>
    </sect2>

  </sect1>


  <!--######################################################################-->

  <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:
-->