Snap vs Flatpak.

Заголовок горячий, как знойный день в Африке, но постараюсь с холодной головой выдать вам что известно на сегодняшний день про две конкурирующие технологии по предоставлению самодостаточных приложений.

Сначала должен искренне признаться что с Flatpak активно не работал, только читал официальные инструкции. Для понимания упаковки ПО в snap и заливки в Ubuntu Store, корпел над LanguageTool и сейчас занят упаковкой русского проекта, который никогда не был представлен в репозиториях, как и LT.

Чтобы не допускать серьёзного перекоса, постараюсь выдать вам известные на сегодняшний день плюсы и минусы обеих технологий. Воспринимайте статью не как сравнение конкурентов, а как заметку в одном месте про их возможности.

Общее

• Обе технологии пытаются упаковать программу со всеми её зависимостями, чтобы в любом линукс дистрибутиве работать, не требуя ничего.
• В операционной системе пакет snap и flatpak обновляется атомарно, с возможностью откатиться к старой версии при проблемах.
• Внутри пакета частичное обновление компонентов невозможно, вы должны установить целиком новый пакет от его создателя.
• Для организации песочницы для программы используется мощь мандатного доступа, но различные их представители. Об этом ниже в разделе Различия.
• Не сильная зависимость, но она есть от системы инициализации systemd. Flatpak использует systemd --user для настройки cgroups песочницы. Snap юзает systemd для монтирования сжатого пакета snap.
• Невозможность предоставить гарантированную безопасность и изоляцию ПО друг от друга при использовании в системе старого дисплейного сервера X11 (Xorg).

Flatpak

Snap

Различия

	Snap	Flatpak
Изоляция	фильтры системных вызовов seccomp и система мандатного доступа AppArmor.	фильтры системных вызовов seccomp и система мандатного доступа SELinux.
Разработка и поддержка	Canonical	Разработчик из RedHat Alexander Larsson и разработчики из проекта Gnome.
Реализация вывода графики	упор на Mir	упор на Wayland
Безопасность	Упор сделан на песочницу для программы в виде профиля AppArmor, который создаётся из файла snap.yaml, описанного в декларативном стиле. Для соединений между пакетами или с пакетом-система используются plugs-slots.	Возведена в абсолют. Очень сильная изоляция от системы с доступом к ограниченному числу библиотек. Общение со внешней средой через DBus.
Стратегия инкапсуляции	В пакете должно быть всё нужное данной программе. Если в системе есть готовое для программы, то можно сделать коннект к нужному. Тяжёлые runtime будут оформлены в отдельные snap пакеты.	Упор на понятия runtime (GNOME, KDE) и bundle, связанное с программой. Может быть несколько runtime (GNOME 3.18, GNOME 3.20) для удовлетворения требований программ.
Размеры пакетов	Snap гипотетически должен быть крупнее flatpak из-за своей стратегии.	Flatpak гипотетически должен быть меньше snap.
Использование на серверах	Да, даже есть Snappy Ubuntu Core.	Flatpak упор делает на десктоп. Теоретически никто не мешает создать пакет серверам.
Хранилище	Уже точно есть Ubuntu Store и могут быть свои хранилища других дистрибутивов linux.	Планов нет и нет единого хранилища. Пока рассматривается вариант с GitHub.

Выводы и мысли

Хотел бы с вами поделиться следующими наблюдениями:

• Возможно это совпадение и мне просто многое мерещется, но ситуация Snap vs Flatpak напоминает мне ситуацию Mir vs Wayland. Есть некий вяло разрабатываемый проект, типа если в рамках его что-то получится, то потом можно начать его использовать. Но стоит Canonical заявить о чём-то конкурирующем, как резко все активизируются. У Canonical масса недоброжелателей в среде разработчиков и многие демонстративно (в пику) оказывают внимание конкуренту. Так было с Wayland и так происходит с Flatpak. Шучу, но мы должны быть благодарны Canonical за активизацию деятельности других проектов.
• Мои бодания с упаковкой в snap пакеты программ LanguageTool и ещё-одна-gtk3-программа-пока-не-скажу с помощью инструмента snapcraft развеяли мои страхи по поводу жирности самодостаточных пакетов. Личный пример c LanguageTool показал разницу в жалкие пару мегабайт между версией с официального сайта и ею же упакованной с OpenJava 8. Возможно выручает Squashfs, сильно сжимающий snap. Есть парадоксы в лице Krita и LibreOffice 5.2 Beta, которые в snap меньше, чем в deb пакетах.
• Если образно представить ваш пакет snap с вилками (plugs), то пока их можно воткнуть в гнезда (slot), представляемые самой системой через ubuntu-core. Разработчики обещают, но пока это не реализовано, другие snap пакеты тяжёлых runtime enviroment и можно будет не упаковывать к примеру gtk3 в пакет, а просто попросить соединить со слотом snap пакета gtk3. Не путайте только зависимости в мире deb и коннекты в мире snap.
• Очень рад что flatpak и snap идут на десктопы, так как считаю что сопровождающие просто технически не успевают за ростом ПО и являются, по моему мнению, лишней сущностью между автором ПО и пользователем. Подробнее.
• Разработчики snap проговорились в почтовой рассылке, когда запрашивал у них помощи по разным вопросам, что сейчас создаётся утилита, которая графически покажет текущие соединения и позволит удобно манипулировать ими - коннект/дисконнект. Напомню, что в момент создания пакета snap её автор запрашивает нужное через plugs: [network, network-bind, ...]. Но сам пользователь может разорвать конкретное соединение, если отдаёт себе отчёт. В данный момент такое возможно только в консоли. Ещё они сказали, что слот home, дающий доступ к домашней папке, настолько важен, что ведутся дебаты как быть с такой важной сущностью. Ведь есть софт, чей функционал не подразумевает доступа к домашней папке, но автор пакета его затребовал.

Главное помните, что snap и flatpak только в начале своего пути и им нужно дать, как минимум, время расцвести.

Дата последней правки: 2023-12-27 15:06:19