is nix safe?

[ixnod]

Found this recently, thought maybe in a few months it could get implemented down the road.

http://www.linux.com/feature/155922


it looks a bit command line intensive, but somewhere, it could be GUI I don't know.

[ADDENDUM]

Nix

Nix is another "purely functional" package manager. It is purely functional in the sense that each version of a package has its own directory. As with Zero Install, "upgrading" creates a new directory for the new version, rather than modifying the existing one. Unlike Zero Install, however, whether a package is installed affects the behaviour of the system. For example, running "firefox" when Firefox isn't installed produces an error in Nix, whereas in Zero Install it will install Firefox first if missing and then continue. In other words, installation has side-effects in Nix.

Additional feeds (e.g. for pre-built binaries) can be registered using "nix-channel --add", which appears to work much like "0launch --feed", although each channel can contain binaries for multiple packages. The channel "MANIFEST" file doesn't appear to have a digital signature. Presumably this will be added at some point.

Each version of a package has a digest (hash), which includes all build dependencies (e.g. the version of the compiler used), just as it does in Zero Install (for packages built using 0compile, at least).

An important difference between the two is that the Nix hash is a hash of the inputs used to build the package, whereas the Zero Install hash is a hash of the resulting binary. Nix does this to support binaries that hard code their own paths, since the final hash needs to be known at compile time. For source (non-compiled) packages, the Nix hash is a hash of the contents, as with Zero Install. The Zero Install hash often happens to include the inputs, since it covers the "build-environment.xml" file which 0compile places in each binary package. Zero Install doesn't allow binaries to include hard-coded paths.

Update: Nix is planning to use binary hashes everywhere in future (zeroing out self-references for the purposes of calcuating the hashes). The same thing was proposed a few years ago for Zero Install (the relocation table). It relies on the cache directory being at a fixed location, whereas people often have Zero Install set up to use their home directory, but it's basically a good idea.

Another difference between Nix and Zero Install is that Nix treats configurations as packages. Changing your configuration is like "upgrading" your configuration package to a new version. Rolling back a change is like reverting to a previous version. Zero Install doesn't generally handle configuration settings, preferring to let the user use subversion (or similar) for that, but it's an interesting idea.

Building a Nix package involves creating a "Nix expression" in a (custom) functional language. The expression fills the same role as a Zero Install source feed: it says where to download the source, what its digest is, what the build dependencies are, and how to build it.

While Zero Install is mainly targeted at adding additional packages to an existing system, Nix aims to manage the whole system (although it installs cleanly alongside your existing package manager). Nix packages have short names (like "perl") not full URIs, and thus it appears to assume a centrally-controlled repository.

In Nix, mutually untrusting users cannot share packages. The manual says "A setuid installation should only by used if the users in the Nix group are mutually trusted, since any user in that group has the ability to change anything in the Nix store". Because the Nix hash is a hash of the inputs, it is not possible for the system to verify that a package is valid (it would have to download the sources and compile the program itself; Nix can share binaries in this case). Because Zero Install hashes are always hashes of the package contents, it does support sharing.

Excerpt from here. http://0install.net/links.html

http://lists.debian.org/debian-devel/20 ... 01027.html <--what the debianians say about it.