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?

  • 1
    So you are asking us to read what you do not want to read??? "A more in depth comparison between Nix and Guix is given by Sander van der Burg, which I didn't read " ... "how does Snappy Ubuntu relate to Nix and Guix? What are major differences?" – don.joey Feb 10 '15 at 17:15
  • I was asking here, because I think one of this community has thought about it already or knows an article I didn't found. I just stumbled upon Snappy today, read about it, but I don't consider myself well informed enough about Snappy to decide how it is positioned between these mature package managers. The Snappy articles don't mention these systems at all and I consider it sad to be silent about other free software dealing with similar problems. Also the linked blog article doesn't name snappy and isnt by a person involved in snappy. – payload Feb 10 '15 at 23:32
  • 1
    Fair enough. Downvote reverted. – don.joey Feb 11 '15 at 7:55
  • Snappy does not statically compile in libraries. It allows you to store libraries in the same folder as your binary so that you don't have to depend on system libraries, but it also allows you to rely on system libraries if you don't need a release independent package. So Snappy doesn't remove the benefits of having a stable LTS release. It just makes everything a lot simpler. – Jo-Erlend Schinstad May 1 '15 at 9:25
up vote 27 down vote accepted

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.

  • 2
    Although your answer is 100% correct, it might also become 100% useless if that link is moved, changed, merged into another one or the main site just disappears... :-( Therefore, please edit your answer, and copy the relevant steps from the link into your answer, thereby guaranteeing your answer for 100% of the lifetime of this site! ;-) You can always leave the link in at the bottom of your answer as a source for your material... – Fabby Apr 30 '15 at 21:34
  • 2
    Ok, I just revised my answer. Hopefully this helps! – Sander van der Burg May 1 '15 at 9:04

Your Answer

 

By clicking "Post Your Answer", you acknowledge that you have read our updated terms of service, privacy policy and cookie policy, and that your continued use of the website is subject to these policies.

Not the answer you're looking for? Browse other questions tagged or ask your own question.