The man-pages generated from the DocBook documentation are ugly. Generations properly form a tree. E.g., if after switching to generation 39, we perform an installation action, a generation 43 is created which is a descendant of 39, not 42. So a rollback from 43 ought to go back to 39. This is not currently implemented; generations form a linear sequence. Unify the concepts of successors and substitutes into a general notion of equivalent expressions. 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 performance characteristics. 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. Build management. 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 not yet powerful enough to make this pleasant (?). The language should be extended with features from the Maak build manager. Another interesting idea is to write a make implementation that uses Nix as a back-end to support legacy build files. The current garbage collector is a hack. It should be integrated into nix-store. It should delete derivations in an order determined by topologically sorting derivations under the points-to relation. This ensures that no store paths ever exist that point to non-existant store paths. There are race conditions between the garbage collector and other Nix tools. For instance, when we run nix-env 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. 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., $ nix-store -r $(nix-instantiate foo.nix) since even if nix-instantiate where to register a temporary root, it would be released by the time nix-store 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., $ nix-instantiate foo.nix > /nix/var/nix/roots/bla $ nix-store -r $(cat /nix/var/nix/roots/bla) For security, nix-push manifests should be digitally signed, and nix-pull should verify the signatures. The actual NAR archives in the cache do not need to be signed, since the manifest contains cryptographic hashes of these files (and fetchurl.nix checks them). 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. It would be useful to have an option in nix-env --delete-generations to remove non-current generations older than a certain age.