* Use setre[ug]id() instead of setres[ug]id(), since the former is

more common than the latter (which exists only on Linux and
  FreeBSD).  We don't really care about dropping the saved IDs since
  there apparently is no way to quiry them in any case, so it can't
  influence the build (unlike the effective IDs which are checked by
  Perl for instance).

configure.ac

@@ -151,10 +151,10 @@ if test "$setuid_hack" = "yes"; then
     AC_DEFINE(SETUID_HACK, 1, [whether to install Nix setuid])
 fi
 
-AC_CHECK_FUNC(setresuid, [HAVE_SETRESUID=1], [HAVE_SETRESUID=])
+AC_CHECK_FUNC(setreuid, [HAVE_SETREUID=1], [HAVE_SETREUID=])
-AM_CONDITIONAL(HAVE_SETRESUID, test "$HAVE_SETRESUID" = "1")
+AM_CONDITIONAL(HAVE_SETREUID, test "$HAVE_SETREUID" = "1")
-if test "$HAVE_SETRESUID" = "1"; then
+if test "$HAVE_SETREUID" = "1"; then
-    AC_DEFINE(HAVE_SETRESUID, 1, [whether we have setresuid()])
+    AC_DEFINE(HAVE_SETREUID, 1, [whether we have setreuid()])
 fi
 
 AC_ARG_WITH(nix-user, AC_HELP_STRING([--with-nix-user=USER],

doc/manual/bugs.xml

@@ -1,7 +1,6 @@
-<appendix>
+<appendix><title>Bugs / To-Do</title>
-  <title>Bugs / To-Do</title>
 
-  <itemizedlist>
+<itemizedlist>
 
     <listitem>
       <para>
@@ -99,17 +98,18 @@ $ nix-store -r $(cat /nix/var/nix/roots/bla)</screen>
       </para>
     </listitem>
 
-    <listitem>
+<listitem><para>For security, <command>nix-push</command> manifests
-      <para>
+should be digitally signed, and <command>nix-pull</command> should
-        For security, <command>nix-push</command> manifests should be
+verify the signatures.  The actual NAR archives in the cache do not
-        digitally signed, and <command>nix-pull</command> should
+need to be signed, since the manifest contains cryptographic hashes of
-        verify the signatures.  The actual NAR archives in the cache
+these files (and <filename>fetchurl.nix</filename> checks
-        do not need to be signed, since the manifest contains
+them).</para></listitem>
-        cryptographic hashes of these files (and
-        <filename>fetchurl.nix</filename> checks them).
-      </para>
-    </listitem>
 
-  </itemizedlist>
+<listitem><para>We should switch away from MD5, since it has been
+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>
+
+</itemizedlist>
 
 </appendix>

doc/manual/introduction.xml

@@ -1,17 +1,70 @@
-<chapter>
+<chapter><title>Introduction</title>
-  <title>Introduction</title>
 
-  <epigraph>
+<epigraph><para><quote>The number of Nix installations in the world
-    <para><quote>The number of Nix installations in the world has grown to 5,
+has grown to 5, with more expected.</quote></para></epigraph>
-        with more expected.</quote></para>
-  </epigraph>
 
-  <para>
+<para>Nix is a system for the deployment of software.  Software
-    Nix is a system for software deployment.  It supports the
+deployment is concerned with the creation, distribution, and
-    creation and distribution of software packages, as well as the installation
+management of software components (<quote>packages</quote>).  There
-    and subsequent management of these on target machines (i.e., it is also a
+are many tools for this, but they tend to ignore some important
-    package manager).
+requirements for deployment:
-  </para>
+
+<itemizedlist>
+
+<listitem><para><emphasis>Correctness</emphasis>.  The basic goal of
+software deployment is to transfer software from one machine (e.g.,
+the developer's, where it presumably works) to another machine (e.g.,
+the end user's).  The software should work exactly the same on the
+target machine as on the source machine.  But this in practice turns
+out to be rather difficult due to <emphasis>dependencies between
+components</emphasis> and <emphasis>interference between
+components</emphasis>.  If we deploy a component that depends on other
+components, then we should deploy those dependencies as well.  If they
+are missing on the target system, the component probably won't work.
+If they <emphasis>are</emphasis> present but are not the right
+version, the component might not work.  And if even if they are the
+right version, they may have been built with different flags or
+options, which can cause incompatibilities.  Interference occurs when
+components <quote>collide</quote> with each other in the file system.
+For instance, different versions of the same package tend to overwrite
+each other, so they cannot be installed at the same time.  But always
+picking the latest version might break components that only work with
+some older version.</para></listitem>
+
+<listitem><para><emphasis>Variability</emphasis>.  Many package
+management tools have difficulty supporting the installation of
+multiple versions or variants of the same component.  This is bad
+because as ...</para></listitem>
+
+</itemizedlist>
+
+</para>
+
+<para>Here are some of Nix's main features:
+
+<itemizedlist>
+
+<listitem><para>Nix can quite reliably figure out the dependencies
+between components.</para></listitem>
+
+</itemizedlist>
+
+</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
+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
+Deployment</citetitle></ulink> discusses the hashing mechanism used to
+ensure reliable dependency identification and non-interference between
+different versions and variants of packages.  The LISA 2004 paper
+<citetitle>Nix: A Safe and Policy-Free System for Software
+Deployment</citetitle> gives a more general discussion of Nix from a
+system-administration perspective.</para></note>
 
   <para>
     Nix solves some large problems that exist in most current deployment and

src/Makefile.am

@@ -4,7 +4,7 @@ SUBDIRS = bin2c boost libutil libstore libmain nix-store nix-hash \
 SETUID_PROGS = nix-store nix-instantiate nix-env
 install-exec-hook:
 if SETUID_HACK
-if HAVE_SETRESUID
+if HAVE_SETREUID
 	cd $(DESTDIR)$(bindir) && chown @NIX_USER@ $(SETUID_PROGS) \
 	  && chgrp @NIX_GROUP@ $(SETUID_PROGS) && chmod ug+s $(SETUID_PROGS)
 else

src/libmain/shared.cc

@@ -169,9 +169,9 @@ static void initAndRun(int argc, char * * argv)
 }
 
 
-#if HAVE_SETRESUID
+#if HAVE_SETREUID
-#define _setuid(uid) setresuid(uid, uid, uid)
+#define _setuid(uid) setreuid(uid, uid)
-#define _setgid(gid) setresgid(gid, gid, gid)
+#define _setgid(gid) setregid(gid, gid)
 #else
 /* Only works properly when run by root. */
 #define _setuid(uid) setuid(uid)
@@ -208,7 +208,7 @@ void switchToNixUser()
     /* !!! Apparently it is unspecified whether getgroups() includes
        the effective gid.  In that case the following test is always
        true *if* the program is installed setgid (which we do when we
-       have setresuid()).  On Linux this doesn't appear to be the
+       have setreuid()).  On Linux this doesn't appear to be the
        case, but we should switch to the real gid before doing this
        test, and then switch back to the saved gid. */