Flatpack или snap что лучше

Техническое сравнение Snap и Flatpak.

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

Сравнение Snap, как систему с мандатным доступом (MAC), с традиционным миром Deb, как систему с избирательным доступом (DAC), вы можете прочесть Snap vs Deb.

Flatpak с первого взгляда

Пакет Flatpak, подобно snap, поставляется с необходимыми компонентами внутри самодостаточного архива, поэтому его легко и просто можно развернуть на различных дистрибутивах Linux. Компоненты и среда выполнения (Runtime) объединены в один файл в формате Open Container Initiative (OCI).

В общем случае, приложение в формате flatpak собрано вместе с runtime + дополнительные библиотеки. На сегодняшний день 21 дистрибутив Linux заявляет о поддержке и запуске программ в flatpak. Кроме того, приложения помещаются в песочницу с помощью Bubblewrap, который использует механизмы безопасности ядра linux и пространства имён (namespace) для создания непривилегированных контейнеров. Связь программы вне песочницы с системой возможна через механизм порталов (portals), которые дают дозированный доступ к конкретному системному ресурсу.

Для конечных пользователей пакеты flatpak доступны в основном через Flathub, который является одновременно и магазином приложений и местом сборки, будучи частично связанным с проектом Flatpak. Отправка на Flathub выполняется в виде запросов на GitHub (pull requests) и требует одобрения администраторов. Аналогичным образом, издатели проприетарного программного обеспечения вынуждены вручную запрашивать включение своих приложений. Приложения Flatpak также иногда доступны в виде ссылок для скачивания вручную. Механизм автоматического обновления не доступен по умолчанию.

В целом Flatpak спроектирован в первую очередь для поддержки десктопных приложений с графическим интерфейсом, в то время как snap был разработан для работы с демонами на серверах, с облачной инфраструктурой и устройствами Интернета вещей (IoT) в дополнение к работе с десктоп программами.

Предыдущая моя статья Snap vs Flatpak.

Snap с первого взгляда

Управление snap осуществляется через сервис snapd. Таким образом, если в системе есть snapd, то можете запускать программы в snap формате. На сегодняшний день 41 дистрибутив Linux заявляет о поддержке.

С точки зрения безопасности, snap изолирован от системы комбинацией из нескольких механизмов: AppArmor, SecComp, cgroups и другие. По умолчанию snap не могут получить доступ к системных ресурсам за пределами своей песочницы. Дозированный доступ предоставляется пользователем через интерфейсы.

Snap идёт вместе с надёжной инфраструктурой разработки и развёртывания, включая инструмент командной строки snapcraft для создания пакетов, а так же онлайн сервис build.snapcraft.io, который собирает ваш софт под 6 различных аппаратных архитектур (если вам нужно) и отправляет в официальный Snap Store. Компании и энтузиасты могут создать свои собственные учётные записи и публиковать свои пакеты snap напрямую со своих сборочных серверов. Чтобы пользователь смог легко и просто увидеть и установить программу:

Типичное использование

Для конечного пользователя использование snap и flatpak очень схоже. В обоих случаях, пользователь может найти и установить ПО через GUI или CLI.

Однако есть отличия при работе в консоли. В случае с snap поиск (search) и установка (install) интуитивно понятнее и легче из-за использования имени приложения и классического автодополнения (BASH autocompletion). Flatpak использует трёхкомпонентный идентификатор для каждой программы в виде tld.company.application. Для примера GIMP идёт как org.gimp.GIMP, а в snap просто gimp. Это означает, что в случае с flatpak, поиск в графических инструментах KDE Discover или Ubuntu Software Center (GNOME Software) может отличаться от поиска в терминале. Flatpak предназначен для работы с несколькими удалёнными источниками софта, одним из которых является Flathub, поэтому во время установки также необходимо указывать ресурс.

flatpak install flathub org.gimp.GIMP

Краткое изложение отличий

Заключение

Есть много общего как flatpak и snap решают задачи упаковки и доставки софта пользователям Linux. В некотором смысле, их можно воспринимать как конвергентную эволюцию в экосистеме Linux. Есть отличия в обновлении, параллельной установке и поддерживаемых дистрибутивах. Snap, помимо классического десктопа, ещё трудятся на серверах и доменах IoT, в то время как Flatpak позволяют пользователям указывать дополнительные хранилища.

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

Источник

Snap vs Flatpak.

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

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

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

Общее

Flatpak

Snap

Различия

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

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

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

Источник

snap & flatpack — трагедия общин

Лонгрид варнинг: вас предупредили, много букв.

Уже давно ведётся разработка формата дистрибуции приложений, которые были «свободны» от общесистемных зависимостей. Ubuntu очень, очень активно продвигает свой snap, gnome — flatpack. Оба обещают рай и свободу от rpm/deb. Давайте же подумаем про проблему, которую они хотят решить, и цену, которую они просят за решение этой проблемы.

Библиотеки

Никто в современном мире не может написать приложение, не используя чужого кода. Причин несколько:

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

Пример для осознания масштаба драмы: допустим, ваше приложение принимает на вход две строки как опциональные аргументы и выводит их вместе, после нормализации. Если вы пишете индустриальное приложение (приложение, которое похоже на «настоящее»), то:

Понятно, что такая сложность для задачи «двух строк» это грубый overengineering, но как только вы начинаете делать что-то больше, идея «всё сам(а)» начинает выходить за пределы обозримого и реализуемого.

Как вы думаете, сколько библиотек нужно, чтобы гарантированно отработать curl http(s)://. Много. Вы будете использовать одну, но зависимости ваших зависимостей — это ваши зависимости.

Copypaste & vendoring VS dynamic linking

При том, что использование библиотек неизбежно, само использование может различаться по реализации. Обратите внимание, у нас появилось два важных слова «использование» и «реализация использования». Что значит «использование»? В самом грубом виде — возможность вызвать код библиотеки, когда это нужно. А вот реализации этого:

В чём же различие между этими методами? Я кратко приведу аргументы, они кратно обсуждались в множестве статей. Каждый из этих аргументов остаётся валидным несмотря на наличие соседних контраргументов:

Все эти вопросы многократно разбирались ранее. Вместо этого я хочу сфокусироваться на социальных аспектах водораздела «всё своё» и «всё общее».

Социальный контракт и власть мейнтейнеров

Общие библиотеки — это кооперация, власть и ответственность. Люди, определяющие какие общие библиотеки доступны в операционной системе диктуют производителям ПО, какие общие библиотеки они могут использовать. Многое ПО может использовать разные библиотеки, и указание на то, какую точно версию нужно использовать остаётся на усмотрение линкера (для компилируемых языков) или обработчика файла зависимостей (pip, bundler, etc). Если все приложения в дистрибутиве собраны с одинаковыми требованиями, то наступает благодать: если в какой-то библиотеке есть ошибка, мейнтейнер этой библиотеки обновляет версию, и исправление автоматически применяется ко всем приложениям. Даже если приложение релизится раз в два года, фикс в условном openssl будет применён в течение недели. Если в конкретной ОС принято решение об отказе от старого протокола, каких-то модификациях (например, интерфейса пользователя), то эти изменения так же применятся для всех. Look&feel в общем стиле, который (быть может) может быть изменён пользователем один раз и для всех. Это ли не благодать?

Власть и борьба за неё

… Эта благодать требует, чтобы все приложения могли работать с выбранной версией библиотеки. А что, если какое-то приложение хочет очень-очень новую функцию из библиотеки, а все остальные приложения не хотят его использовать, потому что это, допустим, не LTS-релиз библиотеки, т.е. она не достаточно стабильна? А ведь дистрибутив может отказываться переходить на новые версии «из принципа», ибо мы обещали пользователям только багфиксы, а новые версии — только в следующей версии ОС, которая (вроде бы), выйдет через пол-года. И это вызывает сопротивление со стороны авторов приложения. Да кто вы такие, чтобы мне рассказывать с какими версиями мне работать? Я автор, я так вижу. Мне нужна libfoobar 3.14-pre2 или новее, а не ваша древняя унылая libfoobar 3.10.

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

То же самое происходит в ситуации, когда есть несколько дистрибутивов, некоторые новее, некоторые старее. Поддерживать более старые дистрибутивы, тестировать с разными библиотеками — это сложно. Так что вариант «отгрузить со своими библиотеками» возникает почти сразу же.

Трагедия общин

Это создаёт предпосылки для возникновения трагедии общин:

При этом, чем больше приложений идут со своими библиотеками, тем меньше польза от системных библиотек. Помните про «благодать»? Чем менее она «всеобщая», тем меньше она благодать. Если общая библиотека используется 5 разными приложениями из 995 других, то польза этой библиотеки — 0.5%. Обидно, да. Причём, это задевает всех пользователей, даже тех, кто, в принципе, не имеет острой потребности в новой фиче — но если приложение доступно только в вендоринговом виде, то у пользователя нет вариантов.

Получается, у нас есть глобальный экстремум: все приложения используют только общие библиотеки (максимум общей благодати, неудобства у авторов отдельных приложений) или «каждый сам по себе» (толстенный дистрибутив, с кучей приложений у которых могут быть незамеченные, но широко используемые уязвимости, жрущий кучу памяти, но автором каждого приложения удобно).

Вот именно тут мы и приходим к спору rpm/deb VS snap/flatpack

Свобода или рабство?

Ubuntu очень, очень сильно ратует за snap’ы. GNOME уверен, что будущее за flatpack’ами. Каждый из них — это фреймворк для глубоко индивидуалистических приложений. Всякие electron’ы, у которых с собой не только подкапотный браузер, но и подкапотная операционная система. Свой libc, свой libssl, свои регэкспы, свои ncurses, etc. Общим выступает только ядро, т.е. по сути это то же контейнеризированное приложение, но для десктопа. Дай каждому своё ядро, и получится appliance в форме виртуалки. Допишите метаданные — и получится контейнер Docker’а.

Индивидуализм приложений (авторов приложений) понятен, но кто тогда выступает за общее благо? Локальное крупное улучшение компенсируется незначительным общим ухудшением дистрибутива помноженным на число приложений. Если все делают себе локальные улучшения, то сумма ухудшений становится больше выгоды от суммы улучшений.

Казалось бы, в этом месте создатели дистрибутивов должны выступать в качестве хранителей общего интереса. Однако.

Политика

Ubuntu зависит от Debian куда больше, чем хотелось бы Canonical (компания, выпускающая Ubuntu). Ценность Ubuntu — не в усилиях мейнтейнеров Ubuntu, а в огромном репозитории ПО, идущем из Debian в форме, когда все приложения хорошо работают друг с другом усилиями тысяч мейнтейнеров отдельных пакетов, являющихся «владельцами» дистрибутива Debian. Canonical добавляет поверх этого свои усилия по полировке результата — и за это любима некоторыми. Добавим чуть-чуть маркетинга и фиксированный lifecycle, который по нраву энтерпрайзу, и получается отличный продукт.

… Который зависит от воли тысяч добровольцев где-то там.

Что совершенно не устраивает почти любую коммерческую компанию. Как разорвать эту зависимость? Правильно, сделав свой комплект приложений. Чем больше своих приложений, тем меньше «взбрыки» в апстриме будут задевать компанию. Достаточно вспомнить историю, когда голосование в Дебиан по поводу systemd похоронило upstart, разрабатывавшийся Canonical.

Но мейнтейнить несколько десятков тысяч приложений, некоторые из которых — свой космос (erlang, go, perl, python, R, julia, etc), а некоторые — монстры в соответствующей предметной области (браузеры, emacs, tex, pacemaker, etc) — это неподъёмная работа. Не зря это тысячи мейнтейнеров.

… И тут есть идея. А, пусть, авторы приложений сами мейнтейнят приложения. Выдадим каждому по песочнице, пусть копаются. Авторы получают свободу, Canonical — приложения, которые не зависят от Debian и которые хоть кто-то мейнтейнит бесплатно. Пользователи получают.

… приложения, которые жирные, тяжёлые, у которых обновления нерегулярные и которые с лёгкостью могут держать уязвимости неисправленными годами… Зато некоторые из них shiny new.

И что дальше?

Представьте себе мир, в котором все всё везут с собой… Знаете как это выглядит? Посмотрите на chefsdk. Он отгружает с собой внутри свою postgresql (со своими зависимостями), свой rabbitmq (который зависит от своего erlang’а), плюс chef-server тоже на erlang’е, так что у него тоже свой erlang. Внезапно, у нас внутри одного приложения два erlang’а и несколько десятков копий одних и тех же библиотек, чуть-чуть различающихся по версии. Это не финальный вариант, т.к. внутри между компонентами всё-таки есть общие библиотеки. Если мы их распилим дальше, то получится несколько десятков копий openssl и libc на одно приложение. Даже не в финальном виде это выглядит как 600Мб на одно приложение.

… Что, конечно, кратно больше, чем среднее приложение на electron.… И в 12 раз больше, чем целый mariadb сервер (целая СУБД!), или krita или gimp (огромные приложения для работы с графикой).

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

Я понимаю, зачем Canonical пушит snap. Я это понимаю, и не одобряю.

Источник

Appimage, Flatpak, Snap: что лучше/перспективнее?

а у меня krita из snap в меню появилась.

Не могу найти ссылку, по который я прочитал что они активно контрибьютили во Flatpak. Плюс они его весьма быстро запилили в репы, в то время как Snap болтался в Sid с момента появления. Только недавно в тестинг переместили.

а у меня krita из snap в меню появилась.

Странно. вчера ставил в Ubuntu (Unity) и ничего. Запускал из менеджера приложений. Ставил через него же.

Лол, что? Какая слака? Я ей в жизни не пользовался.

Такое частенько в убунте встречается.

Кстати, а что там про FatELF было? Или это просто один бинарник на все архитектуры?

поясни, как собрать deb-пакет?

открыл несколько первых туториалов, по ним везде требуется указать путь до архива с исходниками

а у меня нет никаких исходников, есть набор бинарей и всё

есть ссылка на нормальную инструкцию?

Закопать поглубже все три, протравить заразу дустом.

Я бы лучше вот этот Dependency Hell закопал:

Развели, блджд, эпидемию.

76M krita-3.0-x86_64.appimage — Вот. Красивенько. Запустил, поработал, выключил. И система девственная, не изнасилованная KDE3, KDE4, KDE5 хламом.

Так что AppImage и прочее — несомненный +. Жирный плюс.

Я бы лучше вот этот Dependency Hell закопал:

Теперь я понимаю, что значит «латентный макофил».

Чел, я собрал Krita в PPA, и он при установке тянет за собой только Opencolorio https://launchpad.net/

P.S. при установке в KDE естественно. Для других DE не вижу проблемы качнуть KF5 и держать его в системе. Тут вон Flatpak предлагает целые рантаймы тянуть, весом от 100 мегабайт.

Для других DE не вижу проблемы качнуть KF5 и держать его в системе.

Проблема не в том, что KDE-зависимости занимают место. Проблема в том, что KDE-зависимости изгаживают систему:

Snap победит потому что Ubuntu.

Зависимости не нужны.

Захламление системы не нужно.

Люди хотят использовать софт любой версии на любой операционке просто перетащив директорию с файлами или подключив внешний диск.

Люди хотят управляю своим компьютером, а не подчиняться билам, стивам или рандомному джо верному своей религии мейтейнеру.

необходимость регистрации в Ubuntu One для установки даже просто скаченного snap-пакета

Был баг, его закрыли. Регистрация не нужна, аккаунт не нужен.

все это просто прекрасно, уже есть кучки аппимеджей от васянов, которые вряд ли кто-то проверит на безопасность
впрочем, не желающие держать у себя лишние либы вполне этого заслуживают

Лол, а вес самого appimage вы не хотите посчитать?

Appimage, в отличие от snap и flatpak — самостоятельный ELF-файл. Для запуска Appimage-приложений не требуется установка какой-либо программы, а можно сразу запускать. Такое портабельное приложение, которое не предназначено для установки привычным образом. А Snap и Flatpak предназначены для установки.

А вот в Appimage можно сделать так, чтобы при запуске он предлагал добавить ярлык вместе с иконками тебе в систему (в хомяк естественно).

А это можно сделать как-то без демона?

Appimage, конечно. Остальное — overcomplicated bloatware, требующее каких-то демонов, установок и прочее-прочее. AppImage запустится где угодно (достаточно FUSE и поддержки SquashFS в ядре). Остальные два уродца требуют установленного рантайма, да ещё и демонов запущенных. К тому же код Flatpak и Snap очень сложен, а AppImage понятен даже одному человеку. К тому же для безопасности Snap и Flatpak являют свои велосипеды, прибитые гвоздями, а с AppImage можно юзать firejail, или не юзать firejail вообще, или юзать любой другой инструмент для сэндбоксинга, который делает только это, но делает хорошо.

Это по поводу «лучше».

А «перспективнее», конечно же, Snap. Самое говно всегда побеждает.

41 пакет весом чуть больше 200 Mb против одного файла весом 76 Mb

Мне, как дистрибутору, просто нет времени и желания создавать пакеты для каждой версии дистрибутива. Бизнес не готов тратить деньги на то, что можно не делать и сделать малой кровью. Поэтому: Docker + образ на основе CentOS6 + нужный дополнительный свежий софт и свежий компилятор, в полученном образе (создаётся один раз и на долго, хорошая воспроизводимость) собирается целевой софт, при помощи скрипта, ldd и patchelf формируется бандл с нужными либами и после чего генерируется AppImage, который практически гарантированно запустится на всех glibc-совместимых системах (а может даже на каком-нить AlpineLinux тоже).

Ну. вообще для AppImage можно тоже запустить демон, как миниумум по дефолту он смотрит в

/Downloads и сканирует на предмет появления новых AppImage пакетов, после чего регистрирует их у пользователя: так что через меню можно достучаться к нему (XDG).

От себя: его ещё и создавать проще. Была бы ещё серебряная пуля для создания AppDir.

Согласен полностью. Уже заагитировал OpenOrienteering Mapper добавить билды в формате AppImage (попутно отговорив от планов на Snap/Flatpak)

вообще для AppImage можно тоже запустить демон

Я в курсе. Но он опционален (чисто для любителей «рабочего стола» и «меню приложений»), AppImage спокойно можно использовать без него (что я успешно и делаю), в отличие от Snap и Flatpak, где без него нельзя.

От себя: его ещё и создавать проще. Была бы ещё серебряная пуля для создания AppDir.

Спасибо, скоро второе приложение пакетировать, погляжу.

Стоп, а при чём тут список зависимостей? Я про то, что бы сканировать бинарь и собирать необходимые библиотеки в локальный бандл. Пока мне хватает linuxdeployqt + немного рукоприкладства.

Я даже не хочу говорить, до какой степени это всё не нужно. У меня не установлено ни одного snap пакета, при этом snapd – крупнейший потребитель памяти и процессора в свежеустановленной системе.

при этом snapd – крупнейший потребитель памяти и процессора в свежеустановленной системе.

У AppImage подобных проблем нет.

Но предоставляет ли он, например, песочницу, чтобы простой пользователь мог без страха ставить пакеты от Васи?

Имхо, будущее за flatpak’ом.

AppImage здесь не конкурент, т.к. не даёт никакой изоляции. М.б. appimage + firejail, но у последнего проблемы.

В общем с нетерпением ждём новостей от космонавта о выпиливании ещё одной своей поделки.

Мне больше Appimage понравился за его простоту. Просто берёт и работает без необходимости что-то ещё ставить, удобно. Это перевешивает все его недостатки. С остальными форматами даже не приходилось связываться к счастью.

Но предоставляет ли он, например, песочницу, чтобы простой пользователь мог без страха ставить пакеты от Васи?

AppImage создан в первую очередь для авторов программ: сейчас авторы не хотят создавать бинарники для Linux из-за ‘зоопарка’ дистрибутивов, и обычно для Linux-пользователей предлагают только исходники и инструкцию по компиляции.

Если автор создает один AppImage, то этот AppImage будет работать почти на всех Linux-based ‘зверях’.

AppImage идеальный для прикладного ПО, потому как исчезает зависимость от пакетного менеджера

AppImage создан в первую очередь для авторов программ: сейчас авторы не хотят создавать бинарники для Linux из-за ‘зоопарка’ дистрибутивов, и обычно для Linux-пользователей предлагают только исходники и инструкцию по компиляции.

Всё правильно. Сборкой дистроспецифичных пакетов должны заниматься мейнтенеры соответствующего дистрибутива

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

Мейнтейнеры должны работать над самим дистром, а не над ‘подгонкой’ прикладного ПО.

AppImage освобождает мейнтейнеров дистров от распыления своего времени, и работа ПО покладывается на авторов поограммы, как и должно быть в среде десктгпов и прикладного ПО.

Мейнтейнеры должны работать над самим дистром, а не над ‘подгонкой’ прикладного ПО.

Прикладное ПО должно быть правильно подогнано под конкретный дистрибутив, как минимум для обновления.

Для десктопа и прикладного ПО как раз и нужен подход винды. AppImage делает легким для обычного пользователя использование Linux-based ОС на своем десктопе, а обновление путем скачивания нового AppImage дает возможность даже домохозяйкам легко работать с прикладными программами.

Источник