diff options
author | Eelco Dolstra <e.dolstra@tudelft.nl> | 2005-03-15T13·21+0000 |
---|---|---|
committer | Eelco Dolstra <e.dolstra@tudelft.nl> | 2005-03-15T13·21+0000 |
commit | b376565b86717c4da2bdea5ee0bc73978ff9bc78 (patch) | |
tree | 53fa42bbb8096b3d2a06c720b1b030ca451e393d /doc/manual | |
parent | bacd3a6cfa3af1879ef01e693178c74839d66f70 (diff) |
* Manual updates.
Diffstat (limited to 'doc/manual')
-rw-r--r-- | doc/manual/bugs.xml | 59 | ||||
-rw-r--r-- | doc/manual/introduction.xml | 12 | ||||
-rw-r--r-- | doc/manual/manual.xml | 1 | ||||
-rw-r--r-- | doc/manual/package-management.xml | 12 |
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 |