about summary refs log tree commit diff
path: root/doc/manual
diff options
context:
space:
mode:
authorEelco Dolstra <e.dolstra@tudelft.nl>2005-03-15T13·21+0000
committerEelco Dolstra <e.dolstra@tudelft.nl>2005-03-15T13·21+0000
commitb376565b86717c4da2bdea5ee0bc73978ff9bc78 (patch)
tree53fa42bbb8096b3d2a06c720b1b030ca451e393d /doc/manual
parentbacd3a6cfa3af1879ef01e693178c74839d66f70 (diff)
* Manual updates.
Diffstat (limited to 'doc/manual')
-rw-r--r--doc/manual/bugs.xml59
-rw-r--r--doc/manual/introduction.xml12
-rw-r--r--doc/manual/manual.xml1
-rw-r--r--doc/manual/package-management.xml12
4 files changed, 13 insertions, 71 deletions
diff --git a/doc/manual/bugs.xml b/doc/manual/bugs.xml
index 6097b2aa00d4..8a56a28c5079 100644
--- a/doc/manual/bugs.xml
+++ b/doc/manual/bugs.xml
@@ -20,25 +20,6 @@
 
     <listitem>
       <para>
-        Unify the concepts of successors and substitutes into a
-        general notion of <emphasis>equivalent expressions</emphasis>.
-        Expressions are equivalent if they have the same target paths
-        with the same identifiers.  However, even though they are
-        functionally equivalent, they may differ stronly with respect
-        to their <emphasis>performance characteristics</emphasis>.
-        For example, realising a closure expression is more efficient
-        that realising the derivation expression from which it was
-        produced.  On the other hand, distributing sources may be more
-        efficient (storage- or bandwidth-wise) than distributing
-        binaries.  So we need to be able to attach weigths or
-        priorities or performance annotations to expressions; Nix can
-        then choose the most efficient expression dependent on the
-        context.
-      </para>
-    </listitem>
-
-    <listitem>
-      <para>
         <emphasis>Build management.</emphasis>  In principle it is already
         possible to do build management using Nix (by writing builders that
         perform appropriate build steps), but the Nix expression language is
@@ -52,41 +33,6 @@
       </para>
     </listitem>
 
-    <listitem>
-      <para>
-        There are race conditions between the garbage collector and
-        other Nix tools.  For instance, when we run
-        <command>nix-env</command> to build and install a derivation
-        and run the garbage collector at the same time, the garbage
-        collector may kick in exactly between the build and
-        installation steps, i.e., before the newly built derivation
-        has become reachable from a root of the garbage collector.
-      </para>
-
-      <para>
-        One solution would be for these programs to properly register
-        temporary roots for the collector.  Another would be to use
-        stop-the-world garbage collection: if any tool is running, the
-        garbage collector blocks, and vice versa.  These solutions do
-        not solve the situation where multiple tools are involved,
-        e.g.,
-
-        <screen>
-$ nix-store -r $(nix-instantiate foo.nix)</screen>
-
-        since even if <command>nix-instantiate</command> where to
-        register a temporary root, it would be released by the time
-        <command>nix-store</command> is started.  A solution would be
-        to write the intermediate value to a file that is used as a
-        root to the collector, e.g.,
-        
-        <screen>
-$ nix-instantiate foo.nix > /nix/var/nix/roots/bla
-$ nix-store -r $(cat /nix/var/nix/roots/bla)</screen>
-
-      </para>
-    </listitem>
-
 <listitem><para>For security, <command>nix-push</command> manifests
 should be digitally signed, and <command>nix-pull</command> should
 verify the signatures.  The actual NAR archives in the cache do not
@@ -94,11 +40,6 @@ need to be signed, since the manifest contains cryptographic hashes of
 these files (and <filename>fetchurl.nix</filename> checks
 them).</para></listitem>
 
-<listitem><para>We should switch away from MD5, since it has been
-more-or-less cracked.  We don't currently depend very much on the
-collision-resistance of MD5, but we will once we start sharing build
-results between users.</para></listitem>
-
 <listitem><para>It would be useful to have an option in
 <command>nix-env --delete-generations</command> to remove non-current
 generations older than a certain age.</para></listitem>
diff --git a/doc/manual/introduction.xml b/doc/manual/introduction.xml
index 5eb43f3d77c5..9f94b2d5394d 100644
--- a/doc/manual/introduction.xml
+++ b/doc/manual/introduction.xml
@@ -130,11 +130,7 @@ collection.  It also discusses some advanced topics, such as setting
 up a Nix-based build farm, and doing service deployment using
 Nix.</para>
 
-<warning><para>This manual is a work in progress.  It's quite likely
-to be incomplete, inconsistent with the current implementation, or
-simply wrong.</para></warning>
-
-<note><para>Some background information on Nix can be found in two
+<note><para>Some background information on Nix can be found in three
 papers.  The ICSE 2004 paper <ulink
 url='http://www.cs.uu.nl/~eelco/pubs/immdsd-icse2004-final.pdf'><citetitle>Imposing
 a Memory Management Discipline on Software
@@ -145,6 +141,10 @@ different versions and variants of packages.  The LISA 2004 paper
 url='http://www.cs.uu.nl/~eelco/pubs/nspfssd-lisa2004-final.pdf'><citetitle>Nix:
 A Safe and Policy-Free System for Software
 Deployment</citetitle></ulink> gives a more general discussion of Nix
-from a system-administration perspective.</para></note>
+from a system-administration perspective.  The CBSE 2005 paper <ulink
+url='http://www.cs.uu.nl/~eelco/pubs/eupfcdm-cbse2005-final.pdf'><citetitle>Efficient
+Upgrading in a Purely Functional Component Deployment Model
+</citetitle></ulink> is about transparent patch deployment in
+Nix.</para></note>
 
 </chapter>
diff --git a/doc/manual/manual.xml b/doc/manual/manual.xml
index 9ff13d9dfca6..645afa5e6c91 100644
--- a/doc/manual/manual.xml
+++ b/doc/manual/manual.xml
@@ -36,6 +36,7 @@
     </author>
     <copyright>
       <year>2004</year>
+      <year>2005</year>
       <holder>Eelco Dolstra</holder>
     </copyright>
   </bookinfo>
diff --git a/doc/manual/package-management.xml b/doc/manual/package-management.xml
index 4e86b26010d3..53773be5c303 100644
--- a/doc/manual/package-management.xml
+++ b/doc/manual/package-management.xml
@@ -189,12 +189,12 @@ of the Subversion component might be stored in a directory
 while another version might be stored in
 <filename>/nix/store/58823d558a6a...-subversion-0.34/</filename>.  The
 long hexadecimal numbers prefixed to the directory names are
-cryptographic hashes<footnote><para>128 bit MD5 hashes, to be
-precise.</para></footnote> of <emphasis>all</emphasis> inputs involved
-in building the component — sources, dependencies, compiler flags, and
-so on.  So if two components differ in any way, they end up in
-different locations in the file system, so they don't interfere with
-each other.  <xref linkend='fig-user-environments'
+cryptographic hashes<footnote><para>160-bit truncations of SHA-256
+hashes, to be precise.</para></footnote> of <emphasis>all</emphasis>
+inputs involved in building the component — sources, dependencies,
+compiler flags, and so on.  So if two components differ in any way,
+they end up in different locations in the file system, so they don't
+interfere with each other.  <xref linkend='fig-user-environments'
 /><footnote><para>TODO: the figure isn't entirely up to date.  It
 should show multiple profiles and
 <filename>~/.nix-profile</filename>.</para></footnote> shows a part of