Как Снейппи относится к Nix и Guix?

Я искал сравнение, но не нашел и не достаточно хорошо информирован, чтобы сделать это сам сейчас.

Все они предоставляют транзакционные обновления, но разные уровни сдерживания.

• Snappy статически компилируется в библиотеках для обеспечения нескольких версий бинарных зависимостей. Он объявляет предоставленные (и необходимые?) Услуги в качестве метаданных. Пакет предоставляется в виде одного изображения?
• Nix имеет дело с динамическим связыванием, чтобы обеспечить несколько версий бинарных зависимостей? Он объявляет предоставленные и необходимые услуги в качестве метаданных. Пакет предоставляется через репозиторий, работающий с зависимостями.
• Guix похож на Nix, но имеет интеграцию с GNU.

Более глубокое сравнение между 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и т.д.).

  Snappy создает контейнеры, в которых исполняемые файлы могут найти свои зависимости в общих местах FHS, таких как /libи/bin

  Тем не менее, Nix также поддерживает контейнерный подход Snappy, но он используется только в очень редких случаях. Самым известным пакетом Nix, использующим контейнерный подход, является Steam в NixOS, поскольку Steam сам является инструментом развертывания с конфликтующими свойствами.

• Ядро Snappy Ubuntu использует так называемую схему разбиения A / B для обновления (и отката) базовой системы. Он поддерживает только ограниченное количество версий (обычно две) одновременно.

  Напротив, NixOS (дистрибутив Linux на основе Nix ) также создает базовую систему из пакетов Nix в хранилище Nix и является гораздо более мощным. Вы можете вернуться к любой предыдущей конфигурации, которая еще не была собрана сборщиком мусора. Кроме того, подобные системные пакеты между поколениями могут быть общими.

• Оба инструмента поддерживают непривилегированные пользовательские установки . Однако Snappy хранит все файлы в домашнем каталоге пользователя. Если два пользователя установили один и тот же пакет, они дважды устанавливаются в системе.

  Напротив, пакеты Nix также позволяют обычным пользователям устанавливать пакеты в центральном хранилище Nix, чтобы идентичные пакеты могли совместно использоваться пользователями. Частично из-за соглашения об именовании (с использованием хеширования) это можно сделать безопасным способом.

• Snappy ограничивает поведение пакетов во время выполнения, а Nix - нет

• Snappy, похоже, не помогает пользователям создавать пакеты из исходного кода. Однако в Nix есть DSL, позволяющий людям делать это довольно легко и автоматически устанавливать все зависимости времени сборки (компиляторы, инструменты сборки, библиотеки и т. Д.), Когда это необходимо.

• Snappy вряд ли поддерживает модульность и повторное использование . В примерах пакетов все зависимости библиотек статически занимают много места на диске и ОЗУ. Более того, документация, по-видимому, не предоставляет никаких возможностей, кроме фреймворков. Тем не менее, фреймворки не предназначены для повторного использования в соответствии с документацией

  Модульные пакеты Nix и безопасное управление зависимостями - вот некоторые из его основных функций.

Полный пост в блоге можно найти здесь: http://sandervanderburg.blogspot.com/2015/04/an-evaluation-and-comparison-of-snappy.html

Надеюсь, вам будет интересно читать, и, возможно, в нем есть что-то, о чем стоит подумать.