Як Snappy ставиться до Nix та Guix?

Я шукав порівняння, але виявив, що не є достатньо поінформованим, щоб зробити це сам зараз.

Усі вони надають транзакційні оновлення, але різні рівні стримування.

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

Більш глибоке порівняння між Ніксом та Гікс дає Сандер ван дер Бург , якого я не вивчив докладно. Я б здогадався, хтось із Canonical зробив аналіз існуючих рішень. Є й інші системи розгортання на основі зображень, як, наприклад, CoreOS, про який мені казали.

Отже, як Snappy Ubuntu ставиться до Nix та Guix? Які основні відмінності?

Нещодавно я робив оцінку сам. Я насправді довідник Nix / NixOS та колишній дослідник, зацікавлений у технології розгортання.

Я намагався якомога більше дотримуватися фактів, але, мабуть, неможливо залишатися повністю неупередженим. Підсумовуючи свої висновки:

• Обидва підходи зберігають пакети ізольовано . Snappy зберігає програми та рамки у папках, використовуючи таку умову імені:, /app/name/version.vendorтоді як Nix використовує /nix/store/hash-name-version.

  Іменування Nix є більш потужним, оскільки він використовує хеш - префікси , які є похідними від всіх залежностей buildtime . За допомогою Nix ви можете легко розмежувати будь-який варіант пакету та зберігати їх поруч. Будь-яка зміна (наприклад, інша процедура збирання, оновлення бібліотеки, оновлення компілятора) дає новий хеш, що дозволяє зберігати будь-який можливий варіант поруч.

• Щоб пакет , щоб знайти його залежності, Нікс пов'язує їх статичний до виконуваного (наприклад, змінивши RPATHз виконуваного файлу ELF) або загортаючи їх у сценаріях , які встановлюють відповідні змінні оточення (наприклад CLASSPATH, PYTHONPATH, PERL5LIBі т.д.).

  Snappy створює контейнери, в яких виконувані файли можуть знайти свою залежність у своїх загальних місцях FHS, таких як /libта/bin

  Однак Nix також підтримує контейнерний підхід Snappy, але він використовується лише в дуже рідкісних випадках. Найвідомішим пакетом Nix, який використовує контейнерний підхід, є Steam в NixOS, оскільки Steam - це сам інструмент розгортання з конфліктуючими властивостями.

• Snappy Ubuntu Core використовує так звану схему розподілу "A / B" для оновлення (та відкочування) базової системи. Він підтримує лише обмежену кількість версій (як правило, двох) на той час.

  На відміну від цього, NixOS (дистрибутив на базі Nix Linux) також складає базову систему з пакетів Nix в магазині Nix і є набагато потужнішою. Ви можете повернутись до будь-якої попередньої конфігурації, яка ще не збирала сміття. Більше того, подібні системні пакети можуть поширюватися між поколіннями.

• Обидва інструменти підтримують непривілейовані користувацькі установки . Однак Snappy зберігає всі файли в домашній директорії користувача. Якщо двоє користувачів встановлюють один і той же пакет, вони встановлюються двічі в системі.

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

• Snappy обмежує час виконання пакетів поза пакетом, тоді як Nix цього не робить

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

• Snappy навряд чи підтримує модуляризацію та повторне використання . У прикладних пакетах всі залежності бібліотеки вбудовані в статичну форму і споживають значно більше дискового простору та оперативної пам'яті. Більше того, здається, що документація не передбачає будь-якого обладнання, крім рамки. Однак, згідно з документацією, рамки не призначені для повторного використання

  Завдяки пакетам модуляції Nix та безпечному керуванню залежностями - це деякі його ключові особливості.

Повну публікацію в блозі можна знайти тут: http://sandervanderburg.blogspot.com/2015/04/an-evaluation-and-comppare-of-snappy.html

Сподіваємось, вам буде цікаво читати, і, можливо, в цьому є деякі речі, про які вам здається варто подумати.