Package names are not guaranteed to be unique at all - they might be unique for a particular repository, that's all. Secondly, the user can craft his own deriva

Package names are not guaranteed to be unique at all - they might be unique for a particular repository, that's all. Secondly, the user can craft his own derivations of the same software that some maintainer has already released, which might use the same version but different configuration options. And as I stated previously, the DVCS revision number does not become part of the package name. They typically have a separate major-minor versioning scheme which covers a broad range of commits to the code. I don't disagree that they could do better, by perhaps using a postfix of some smaller signature of the package, but I just think the argument is irrelevant, because they're were not intended to be read by humans - they are handled by the Nix software. I've not needed to manually browse into /nix/store to find something yet. File paths are primary keys in a relational data store which is the filesystem. The filesystem is crafted for quite a specific purpose, so is not as general as say, sqlite. Nix has relational data and uses the filesystem because it needs to be compatible with the rest of the system. We could in theory use sqlite to store everything we need for nix, then mount the database with some hypothetical FUSE filesystem to reveal it to the common namespace in some pretty way. That just requires additional effort for no real gain. Public-key signing does absolutely nothing to verify that a package was built from an unmodified source using an unmodified build process. Signing merely proves who the package came from (that nobody has modified it since the packager built it). It does not identify whether or not they have ill intent. We should learn from recent NSA revelations and cases like Lavabit, that they may be forced to insert malicious code against their own volition. We can't inspect binaries and make sure they match up to the source code, but if we had reproducible builds, then N people could build the same software, resulting in the same binaries, and we could have a web-of-trust model, where you only install a binary package if there's a consensus on it's hash, and have a pretty high confidence rate that it's safe (A malicous party would need to produce a hash collision). Trusting N > 1 randomly selected people is probably better than trusting 1. Part of the reason for having configuration management on top of Nix is much the same reason as the package manager itself. The aim is to remove "hidden knowledge" that the packager or administrator used to build or configure some service, so that everything required to reproduce it exactly is well defined in a declarative programming language. Existing CM services like Puppet are unsuitable for the task because they make many assumptions (such as how other package managers work, or that there's only one derivation of a package on the system), that are broken with Nix. A new CM service which removes those assumptions was needed, and it happened to be built on top of Nix because it can assign identity to a configuration. There model has other uses. Hydra for example, is a continuous build system which uses nixpkgs. There's potential for replacement or improvement of existing build tools like make (which have plenty of flaws). pkg-config isn't necessary for example, when we're dealing with dependencies which are specific by design. It's not that it's "combining many different things into one", but rather, rebuilding a bunch of services upon different assumptions than what is already available. It should be noted that you can use the package manager without any CM, but NixOS uses the CM ubiquitously to give a clear specification of the OS and how to reproduce it from scratch. For me, Nix is a step towards removing the distinction between developer and user. The future I see is where there is zero friction to go from using an app to hacking on it, because you have the source code readily available, plus a completely automated build process you probably don't need to mess with. There's no hidden knowledge. I cannot count the amount of time I've wasted in the past trying to build software and dependencies of software because they're not well defined or documented. Quite often a day has passed before I can actually start modifying the code.