问题描述
我搜索了一个比较，但发现没有，而且我现在还没有足够的信息来自己做。
它们都提供事务更新，但包含不同级别的内容。
-
Snappy 在库中静态编译以提供多个版本的二进制依赖项。它将提供的(和需要的？)服务声明为元数据。该软件包作为单个图像提供？
-
Nix 处理动态链接以提供多个版本的二进制依赖项？它将提供和需要的服务声明为元数据。该包是通过处理依赖关系的存储库提供的。
-
Guix 类似于 Nix，但具有 GNU 集成功能。
Sander van der Burg 给出了 Nix 和 Guix 之间更深入的比较，我没有详细研究。我猜 Canonical 的某个人已经对现有解决方案进行了分析。还有其他基于图像的部署系统，比如我被告知的 CoreOS。
那么，Snappy Ubuntu 与 Nix 和 Guix 有什么关系呢？主要区别是什么？
最佳思路
最近，我自己做了一个评估。我实际上是 Nix/NixOS 的贡献者，也是对部署技术感兴趣的前研究员。
我试图尽可能地坚持事实，但要保持完全公正可能是不可能的。总结一下我的发现：
-
两种方法都单独存储包。 Snappy 使用以下命名约定将应用程序和框架存储在文件夹中：
/app/name/version.vendor，而 Nix 使用/nix/store/hash-name-version。 Nix 的命名约定更强大，因为它使用从所有构建时依赖项派生的哈希前缀。使用 Nix，您可以轻松区分包的任何变体并将它们彼此相邻存储。任何更改(例如不同的构建过程、库升级、编译器升级)都会产生一个新的哈希，从而可以将任何可能的变体彼此相邻存储。 -
为了让包找到它的依赖项，Nix 将它们静态绑定到可执行文件(例如通过修改 ELF 二进制文件的
RPATH)或通过将它们包装在设置适当环境变量的脚本中(例如CLASSPATH、PYTHONPATH、PERL5LIB等) . Snappy 组合容器，可执行文件可以在其中找到它们的依赖项在其常见的 FHS 位置，例如/lib和/bin但是，Nix 也支持 Snappy 的容器方法，但这仅在极少数情况下使用。最突出的使用容器化方法的 Nix 包是 NixOS 中的 Steam，因为 Steam 本身就是一个具有冲突属性的部署工具。 -
Snappy Ubuntu Core 使用 so-called “A/B” 分区方案来升级(和回滚)基本系统。它当时只支持有限数量的版本(通常是两个)。相比之下，NixOS(基于 Nix 的 Linux 发行版)也由 Nix 商店中的 Nix 包组成基本系统，并且功能更强大。您可以回滚到任何尚未被垃圾收集的先前配置。此外，可以在几代人之间共享相似的系统包。
-
这两种工具都支持非特权用户安装。但是，Snappy 将所有文件存储在用户的主目录中。如果两个用户碰巧安装了同一个包，那么他们会在系统上安装两次。相比之下，Nix 包还允许普通用户在中央 Nix 存储中安装包，以便用户之间共享相同的包。部分由于命名约定(使用散列)，这可以以安全的方式完成。
-
Snappy 限制了包 out-of-the-box 的运行时行为，而 Nix 没有
-
Snappy 似乎并不能帮助用户从源代码构建包。然而，Nix 有一个 DSL，允许人们很容易地做到这一点，并在需要时自动安装所有构建时依赖项(编译器、构建工具、库等)
-
Snappy 几乎不支持模块化和重用。在示例包中，所有库依赖项都是静态捆绑的，消耗更多的磁盘空间和 RAM。此外，该文档似乎没有提供除框架之外的任何工具。然而，根据文档，框架并不意味着重用。随着 Nix 模块化包和安全管理依赖项是它的一些关键特性。
完整的博客文章可以在这里找到：http://sandervanderburg.blogspot.com/2015/04/an-evaluation-and-comparison-of-snappy.html
希望你觉得它读起来很有趣，也许其中有一些你觉得值得思考的东西。