about summary refs log tree commit diff
path: root/doc/manual/introduction.xml
diff options
context:
space:
mode:
Diffstat (limited to 'doc/manual/introduction.xml')
-rw-r--r--doc/manual/introduction.xml98
1 files changed, 92 insertions, 6 deletions
diff --git a/doc/manual/introduction.xml b/doc/manual/introduction.xml
index 77a5f917ee71..974cdedd8fae 100644
--- a/doc/manual/introduction.xml
+++ b/doc/manual/introduction.xml
@@ -15,17 +15,17 @@
       <title>Build management</title>
 
       <para>
-	  Build management tools are used to perform <emphasis>software
+	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>
+	<itemizedlist>
 	  <listitem>
 	    <para>
 	    </para>
 	  </listitem>
-	  </itemizedlist>
+	</itemizedlist>
       </para>
 
     </sect2>
@@ -34,12 +34,12 @@
       <title>Package management</title>
 
       <para>
-	  After software has been built, is must also be
+	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>
+	<itemizedlist>
 	  <listitem>
 	    <para>
 	      The <emphasis>creation</emphasis> of packages from some formal
@@ -60,12 +60,98 @@
 	      the system administrator should be constant, not linear).
 	    </para>
 	  </listitem>
-	  </itemizedlist>
+	</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>