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