How does Snappy relate to Nix and Guix?

Question

I searched for a comparison but found non and am not quite well informed enough to do it myself right now.

All of them provide transactional updates, but different levels of containment.

• Snappy statically compiles in libraries to provide multiple versions of binary dependencies. It declares provided (and needed?) services as metadata. The package is provided as a single image?
• Nix deals with dynamic linking to provide multiple versions of binary dependencies? It declares provided and needed services as metadata. The package is provided through a repository dealing with dependencies.
• Guix is like Nix, but features GNU integration.

A more in depth comparison between Nix and Guix is given by Sander van der Burg, which I did not study in detail. I would guess someone at Canonical has made an analysis of existing solutions. There are other deployment systems based on images, like CoreOS I was told.

So, how does Snappy Ubuntu relate to Nix and Guix? What are major differences?

Answer 1

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.