Snappy与Nix和Guix有何关系？

我搜索了一个比较，但发现没有比较，并且我现在还不足够了解此事。

它们都提供事务更新，但是包含不同级别的限制。

• 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，您可以轻松区分包装的任何变体，并将它们彼此相邻存储。任何更改（例如，不同的构建过程，库升级，编译器升级）都会产生新的哈希，从而可以将任何可能的变体彼此相邻存储。

• 以允许一个包找到它的依赖性，尼克斯结合他们静态为可执行（例如通过修改RPATH一个ELF二进制的），或通过在设置适当的环境变量的脚本（例如包裹它们CLASSPATH，PYTHONPATH，PERL5LIB等等）。

  瞬间组成的容器中的可执行文件可以找到它们的依赖于他们共同的FHS位置，如/lib和/bin

  但是，Nix也支持Snappy的容器方法，但这仅在极少数情况下使用。使用容器化方法的最杰出的Nix软件包是NixOS中的Steam，因为Steam本身是具有冲突属性的部署工具。

• Snappy Ubuntu Core使用所谓的“ A / B”分区方案来升级（并回滚）基本系统。当时它仅支持有限数量的版本（通常为两个）。

  相比之下，NixOS（基于Nix的Linux发行版）也由 Nix商店中的Nix包组成基本系统，功能更强大。您可以回滚到尚未进行垃圾收集的任何先前配置。而且，各代之间可以共享相似的系统软件包。

• 两种工具均支持无特权的用户安装。但是，Snappy将所有文件存储在用户的主目录中。如果两个用户碰巧安装了相同的软件包，那么他们将在系统上安装两次。

  相反，Nix软件包还允许普通用户在中央Nix商店中安装软件包，以便可以在用户之间共享相同的软件包。部分由于命名约定（使用哈希），因此可以安全的方式完成。

• Snappy 开箱即用地限制了软件包的运行时行为，而Nix则没有

• Snappy似乎无法帮助用户从源代码构造程序包。Nix具有DSL，使人们可以很轻松地做到这一点，并在需要时自动安装所有构建时依赖项（编译器，构建工具，库等）。

• Snappy几乎不支持模块化和重用。在示例包中，所有库依赖项都被静态捆绑在一起，从而消耗更多的磁盘空间和RAM。而且，文档似乎没有提供除框架以外的任何功能。但是，根据文档说明，框架并不意味着可以重用

  使用Nix模块化软件包并安全地管理依赖项是它的一些关键功能。

完整的博客文章可以在这里找到：http : //sandervanderburg.blogspot.com/2015/04/an-evaluation-and-comparison-of-snappy.html

希望您发现阅读有趣，也许其中有些事情值得您思考。