Сравнение самодостаточных пакетов для Linux или почему Flatpak привнёс долгожданную “платформу Linux”

Статья обновлена 2022-04-23.

Это попытка объяснить, почему среди трёх самых популярных проектов (AppImage, Snap, Flatpak), по созданию самодостаточных пакетов для Linux, — удачным вышел только Flatpak. Если есть вопросы или замечания — добро пожаловать в наш чат.

TL;DR: Используйте Flatpak и будет вам счастье

Для начала нужно понять, зачем эти самодостаточные пакеты необходимы. Представим, что я написал прекрасную программу для Linux: как мне её распространять? Без самодостаточных пакетов, мне придётся создать один deb-пакет для текущей Ubuntu LTS (который, скорее всего, заведётся и на Debian Stable), если в самой последней Ubuntu сломана совместимость в нужной библиотеке, то пакет придётся сделать и для неё, ещё нужны два rpm-пакета для двух последних релизов Fedora, один rpm-пакет для openSUSE Leap и ещё один для Tumbleweed, PKGBUILD для Arch Linux и это только самые популярные дистрибутивы. А иногда, создание новой версии пакета невозможно для дистрибутива со слишком старыми версиями библиотек. Так, например, в Debian Stable очень часто наблюдается плачевная ситуация с браузерами.

На первый взгляд может показаться, что проблема создания пакетов разработчиками ПО не так страшна: пакеты для разных версий одного дистрибутива будут отличаться не сильно, а для популярного ПО мейнтейнеры дистрибутивов сами сделают пакет. Но у, казалось бы, такой популярной и замечательной читалки манги Komikku пакеты сделаны (на момент написания этого текста — 2021.12.02) только для Fedora, для Arch (AUR — придётся тратить время на сборку из исходного кода), Gentoo, Void и Guix. Из действительно популярных дистрибутивов — только первые два, а вот для Debian, Ubuntu и openSUSE сборок нет. Желающих мейнтейнеров не оказалось, а самому разработчику не нужно это ковыряние в версиях библиотек разных дистрибутивов и сборка пакетов под каждый дистрибутив. Он сделал один Flatpak и всё. Об этих проблемах, ещё в 2014 году, рассказывал сам автор ядра Linux — Линус Торвальдс. И так, какие решения данной проблемы есть сейчас?

0. Статическая линковка и тарболы

Можно просто положить все необходимые библиотеки и ресурсы в один архив и отдавать его так. Так делает Mozilla со своим браузером, Telegram и Blender. Не самый ужасный способ, но этот архив надо где-то распаковать и хранить, а ещё придётся сделать “ярлык” для запуска приложения. Также, могут быть проблемы с обновлением такого софта. И про изоляцию тоже можно забыть.

Короче, неплохой способ для разработчика убедиться, что приложение будет запускаться на всех ± мейнстримных дистрибутивах (при корректной сборке), но при этом это довольно неудобно для пользователей.

1. AppImage

Способ похож на предыдущий, но вместо архива предлагается единый исполняемый файл, где находится всё необходимое (если разработчик не допустил ошибок при сборке) для работы приложения. Песочница также отсутствует. Есть средства автоматической интеграции в систему, но они ни в одном дистрибутиве не работают из коробки и смысла от них в такой ситуации не очень много. Поэтому проблемы ± те же. Пользователю самому надо решать, где хранить приложение, озаботиться .desktop файлом для запуска софта из меню приложений и думать про обновления. Либо поставить софт, который будет делать всё это сам.

На практике, разработчики пакетов AppImage часто косячат со сборкой и забывают что-нибудь в него положить, что выливается в неработоспособность пакетов на некоторых дистрибутивах. Тоже, не самый удобный вариант для пользователя. Хотя, пожалуй, наилучший вариант для портабельных версий ПО, ведь AppImage не нужно устанавливать в систему.

2. Snap

Snap, будучи типичной разработкой Canonical, вообще самый худший из всех вариантов. В теории, конкурент Flatpak. Тоже формат самодостаточных пакетов, но вот только часть из его проблем:

  1. У Snap есть только один репозиторий — Snapcraft. Нельзя подключить другой репозиторий, создать свой или поставить софт не из Snapcraft.
  2. Приложения Snap запускаются медленно, я тестировал Firefox 93 на одной и той же виртуалке с Ubuntu 21.10: Snap — 15 секунд самый первый запуск, 7с. холодный запуск, 2с. горячий запуск; Flatpak — 6с/3с/1.5с; deb — 2с/1.75с/1.5с. Как Snap умудряется быть на треть медленнее с запуском из кэша — одному Шаттлворту известно. Проблема со скоростью запуска Snap известна Canonical (см. твит от бывшего сотрудника Canonical), но им плевать.
  3. Изоляция Snap является фикцией — многие приложения запускаются без песочницы, а даже если с ней, песочница Snap работает неполноценно на дистрибутивах, отличных от Ubuntu, потому что завязана на Ubuntu-специфичные патчи ядра и AppArmor, который по-дефолту выключен на большинстве дистрибутивов.
  4. Приложения Snap обновляются автоматически и имеют только текущую версию и предыдущую — больше никаких опций для отката не предусмотрено.
  5. Snap активно насаждается компанией Canonical. Некоторые deb-пакеты в Ubuntu теперь являются заглушками и устанавливают свой Snap-аналог.

Всё ещё думаете, что снапы не такие уж и плохие? Посмотрите на комментарии под одним из постов на r/linux_gaming!

https://imgur.com/a/ArPci3O

Никто не любит Snap'ы

3. Flatpak

Flatpak — формат самодостаточных пакетов. При разработке Flatpak, все силы были направлены на то, чтобы создать наилучший формат пакетов для десктопных приложений:

  1. Flatpak позволяет подключать сколько угодно репозиториев и создавать свои. Самый популярный репозиторий, где и хранится основной костяк ПО — Flathub.
  2. Flatpak приложения имеют концепцию зависимостей, хоть и не такую гибкую, как у классических пакетов. Каждое приложение зависит от определённого рантайма и его версии. Есть три самых популярных рантайма — org.gnome.Platform (для приложений GNOME и Gtk), org.kde.Platform (для приложений KDE и Qt) и org.freedesktop.Platform (для всех остальных, в том числе, для Electron приложений). Поскольку у каждого приложения, прописан рантайм и его конкретная версия (полностью зафиксировано окружение), то приложения хорошо работают на разных дистрибутивах и защищены от прекращения разработки — старые приложения всё ещё будут работать на новых дистрибутивах. Здесь есть исключение в виде базовых технологий, таких как аудиосервер и графическая система, но в Linux новые разработки в этих направлениях сохраняют обратную совместимость, так что проблем возникнуть не должно. Помимо этого, если конкретное приложение не использует никаких возможностей последних версий Flatpak, то это приложение запросто будет работать на десять раз устаревшем дистрибутиве. Например, после прекращения поддержки RHEL7, на нём ещё продолжительное время будет работать последний Firefox из Flathub.
  3. Место экономится настолько, насколько это возможно: общие рантаймы переиспользуются и не занимают дополнительного места, а файлы между разными рантаймами дедуплицируются.
  4. Песочница создаётся посредством утилиты bubblewrap, для изоляции используются уже традиционные для Linux технологии: namespaces и seccomp. Есть система статических и динамических разрешений. Изменения в статических разрешениях (указываются в манифесте Flatpak-приложения) применяются только после перезапуска приложения, ведь не задумывались для редактирования пользователем. Хотя возможность переопределения разрешений пользователем всё равно есть, через утилиту Flatseal. Динамические разрешения влияют на работу порталов, набора специальных API для запроса приложениями доступа к ресурсам компьютера. Например, есть портал для работы в фоне и автозапуска, доступа к камере, микрофону, etc. Есть порталы, которые выводят пользователю системное окно, чтобы он мог выбрать, каким ресурсом поделиться. Так работает портал доступа к файлам, записи видео с экрана и создания скриншотов.
  5. Приложения Flatpak можно легко октатывать на много версий назад, закреплять текущую установленную версию и многие приложения даже поддерживают одновременную установку нескольких версий из разных веток (stable, development, nightly).
  6. Обновление приложений Flatpak происходит автоматически в фоне, если у вас установлен GNOME Software, хотя это выключается одним тумблером в настройках. Обновленная версия приложения запускается в момент его повторного запуска, никаких изменений “на лету” не происходит, что важно для стабильности. Также, обновления скачивают только изменившиеся части (delta-обновления), чтобы экономить трафик.

Таким образом, получается удобный и надёжный формат приложений для десктопного Linux, который готов к тому, что некоторые приложения не являются друзьями пользователю (изолирует приложения в песочнице). Теперь разработчики действительно могут “создавать и распространять ПО под Linux” и не важно, на каком дистрибутиве ПО будет запускаться. Это и есть она — долгожданная платформа Linux.

Ответы на вопросы и частые заблуждения

Песочница Flatpak не имеет смысла, ведь у многих приложений выставлены очень свободные разрешения

Во первых, GNOME Software всегда предупреждает о закрытости исходного кода и опасных разрешениях у каждой программы:

https://imgur.com/a/zcjN3Sd

Во вторых, все не устраивающие разрешения могут быть отредактированы пользователем через Flatseal. Самые опасные из них: чтение/запись всей файловой системы или домашнего каталога, прямой доступ к устройствам, полный доступ к D-Bus (--socket=system-bus и --socket=session-bus) и доступ к D-Bus шине Flatpak (--talk-name=org.freedesktop.Flatpak — позволяет запускать код вне песочницы). Статистику по разрешениям на Flathub можно посмотреть здесь.

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

Заключение

Скорее всего, Минта и других форков Ubuntu не коснётся безумие Canonical, потому что команда Mint и другие активно борются с насаждением Snap и предоставляют .deb пакеты, от которых избавились в Ubuntu.

Сами Canonical ещё пару лет попытаются пропихнуть свой vendor-lock в лице Snap и уберут его куда-нибудь в IoT, где Snap ещё немного побрыкается и проиграет OCI. На десктопах останутся классические пакеты (rpm, deb, etc.) для системных вещей и критически важного ПО, а основная часть десктопного софта уйдёт на Flatpak. Сейчас к Flatpak присматриваются Valve (с bubblewrap они уже два года плотно работают), а разработчикам профессионального ПО более не нужно поддерживать разные версии своего ПО для RHEL, SLED и Ubuntu. Будет легко ставить проф. ПО даже на такие дистрибутивы, которые ранее не поддерживались. DaVinci Resolve сейчас поддерживает только CentOS 7.3 и имеет чертовски костыльный скрипт установки, после которой, система сильно засирается. Перейдя на Flatpak, дела станут сильно проще. Red Hat даже выпустила RHEL Flatpak Runtime, чтобы таким компаниям, как Blackmagic, было проще перейти на Flatpak.

Canonical постоянно городят свои велосипеды, а потом либо их выбрасывают, либо оставляют для специфичных рынков. Так было с upstart, Mir, Unity, Ubuntu Touch и так будет со Snap. И пока Canonical занимается ИБД и страдают от синдрома NIH, Red Hat активно занимаются развитием экосистемы Linux, добавляя инструменты для удобства пользователей и разработчиков ПО.

Я согласен с Линусом Торвальдсом, что классические пакеты имеют смысл для системных вещей, таких как ядро, компилятор, DE и для минимального набора графического ПО (браузер, текстовый редактор, etc). Но большую часть графического ПО просто нет смысла собирать 100500 раз, отдельно под каждый дистрибутив. Это бессмысленная трата времени и сил.

Полезные ссылки