* Manual updates.
This commit is contained in:
parent
bacd3a6cfa
commit
b376565b86
4 changed files with 13 additions and 71 deletions
|
@ -18,25 +18,6 @@
|
|||
</para>
|
||||
</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>
|
||||
<para>
|
||||
<emphasis>Build management.</emphasis> In principle it is already
|
||||
|
@ -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>
|
||||
|
|
|
@ -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>
|
||||
|
|
|
@ -36,6 +36,7 @@
|
|||
</author>
|
||||
<copyright>
|
||||
<year>2004</year>
|
||||
<year>2005</year>
|
||||
<holder>Eelco Dolstra</holder>
|
||||
</copyright>
|
||||
</bookinfo>
|
||||
|
|
|
@ -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
|
||||
|
|
Loading…
Reference in a new issue