How does Snappy relate to Nix and Guix?

Recently, I did an evaluation myself. I'm actually a Nix/NixOS contributor, and former researcher interested in deployment technology.

I have tried to stick myself to the facts as much as possible, but it's probably impossible to remain fully unbiased. To summarize my findings:

• Both approaches store packages in isolation. Snappy stores apps and frameworks in folders using the following name convention: /app/name/version.vendor, whereas Nix uses /nix/store/hash-name-version.

  Nix's naming convention is more powerful, because it uses hash prefixes that are derived from all buildtime dependencies. With Nix you can easily make distinctions between any variant of a package and store them next to each other. Any change (e.g. different build procedure, library upgrade, compiler upgrade) yields a new hash making making it possible to store any possible variant next to each other.

• To allow a package to find its dependencies, Nix binds them statically to an executable (e.g. by modifying the RPATH of an ELF binary) or by wrapping them in scripts that set the appropriate environment variables (e.g. CLASSPATH, PYTHONPATH, PERL5LIB, etc.).

  Snappy composes containers in which executables can find their dependencies in their common FHS locations, such as /lib and /bin

  However, Nix also supports Snappy's container approach but this is only used in very rare cases. The most prominent Nix package using a containerized approach is Steam in NixOS, because Steam is a deployment tool itself with conflicting properties.

• The Snappy Ubuntu Core uses a so-called "A/B" partitioning scheme to upgrade (and roll back) the base system. It only supports a limited number of versions (typically two) at the time.

  In contrast, NixOS (the Nix-based Linux distro) composes the base system out of Nix packages in the Nix store as well and is much more powerful. You can roll back to any previous configuration that has not been garbage collected yet. Moreover, similar system packages among generations can be shared.

• Both tools support unprivileged user installations. However, Snappy stores all files in the home directory of the user. If two users happen to install the same package then they are installed twice on the system.

  In contrast, Nix packages also allow ordinary users to install packages in the central Nix store so that identical packages can be shared among users. Partly because of the naming convention (using hashing) this can be done in a secure way.

• Snappy restricts the runtime behaviour of packages out-of-the-box whereas Nix does not

• Snappy does not seem to help users to construct packages from source code. Nix however has a DSL allowing people to do this quite easily and automatically install all buildtime dependencies (compilers, build tools, libraries etc.) when needed

• Snappy hardly supports modularization and reuse. In the example packages, all library dependencies are bundled statically consuming much more diskspace and RAM. Moreover, the documentation does not seem to provide any facilities except frameworks. However, frameworks are not meant for reuse according to the documentation

  With Nix modularizing packages and safely managing dependencies are some its key features.

The full blog post can be found here: http://sandervanderburg.blogspot.com/2015/04/an-evaluation-and-comparison-of-snappy.html

Hopefully you find it interesting to read and maybe there are some things in it that you find worth thinking about.