* Manual updates.

This commit is contained in:
Eelco Dolstra 2005-03-15 13:21:32 +00:00
parent bacd3a6cfa
commit b376565b86
4 changed files with 13 additions and 71 deletions

View file

@ -18,25 +18,6 @@
</para> </para>
</listitem> </listitem>
<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> <listitem>
<para> <para>
<emphasis>Build management.</emphasis> In principle it is already <emphasis>Build management.</emphasis> In principle it is already
@ -52,41 +33,6 @@
</para> </para>
</listitem> </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 <listitem><para>For security, <command>nix-push</command> manifests
should be digitally signed, and <command>nix-pull</command> should should be digitally signed, and <command>nix-pull</command> should
verify the signatures. The actual NAR archives in the cache do not 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 these files (and <filename>fetchurl.nix</filename> checks
them).</para></listitem> 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 <listitem><para>It would be useful to have an option in
<command>nix-env --delete-generations</command> to remove non-current <command>nix-env --delete-generations</command> to remove non-current
generations older than a certain age.</para></listitem> generations older than a certain age.</para></listitem>

View file

@ -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 up a Nix-based build farm, and doing service deployment using
Nix.</para> Nix.</para>
<warning><para>This manual is a work in progress. It's quite likely <note><para>Some background information on Nix can be found in three
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
papers. The ICSE 2004 paper <ulink papers. The ICSE 2004 paper <ulink
url='http://www.cs.uu.nl/~eelco/pubs/immdsd-icse2004-final.pdf'><citetitle>Imposing url='http://www.cs.uu.nl/~eelco/pubs/immdsd-icse2004-final.pdf'><citetitle>Imposing
a Memory Management Discipline on Software 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: url='http://www.cs.uu.nl/~eelco/pubs/nspfssd-lisa2004-final.pdf'><citetitle>Nix:
A Safe and Policy-Free System for Software A Safe and Policy-Free System for Software
Deployment</citetitle></ulink> gives a more general discussion of Nix 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> </chapter>

View file

@ -36,6 +36,7 @@
</author> </author>
<copyright> <copyright>
<year>2004</year> <year>2004</year>
<year>2005</year>
<holder>Eelco Dolstra</holder> <holder>Eelco Dolstra</holder>
</copyright> </copyright>
</bookinfo> </bookinfo>

View file

@ -189,12 +189,12 @@ of the Subversion component might be stored in a directory
while another version might be stored in while another version might be stored in
<filename>/nix/store/58823d558a6a...-subversion-0.34/</filename>. The <filename>/nix/store/58823d558a6a...-subversion-0.34/</filename>. The
long hexadecimal numbers prefixed to the directory names are long hexadecimal numbers prefixed to the directory names are
cryptographic hashes<footnote><para>128 bit MD5 hashes, to be cryptographic hashes<footnote><para>160-bit truncations of SHA-256
precise.</para></footnote> of <emphasis>all</emphasis> inputs involved hashes, to be precise.</para></footnote> of <emphasis>all</emphasis>
in building the component — sources, dependencies, compiler flags, and inputs involved in building the component — sources, dependencies,
so on. So if two components differ in any way, they end up in compiler flags, and so on. So if two components differ in any way,
different locations in the file system, so they don't interfere with they end up in different locations in the file system, so they don't
each other. <xref linkend='fig-user-environments' interfere with each other. <xref linkend='fig-user-environments'
/><footnote><para>TODO: the figure isn't entirely up to date. It /><footnote><para>TODO: the figure isn't entirely up to date. It
should show multiple profiles and should show multiple profiles and
<filename>~/.nix-profile</filename>.</para></footnote> shows a part of <filename>~/.nix-profile</filename>.</para></footnote> shows a part of