Snap flatpack в чем разница

Сравнение самодостаточных пакетов

В данной статье мы попытаемся в полной мере оценить достоинства и недостатки самых распространённых форматов самодостаточных пакетов Flatpak, Snap.

Введение

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

Репозитории

Flatpak

Способен работать с любым количеством подключённых OSTree-репозиториев. Данные репозитории не требуют наличия какого-либо специализированного ПО на сервере, т.к. представляют собой совокупность обычных статических файлов, которые могут раздаваться любым веб-сервером, либо при помощи CDN.

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

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

Привязан к единственному репозиторию и магазину приложений — Snap Store, поддерживаемому компанией Canonical. Исходный код эталонной реализации закрыт, поэтому развёртывание собственного репозитория в настоящее время не представляется возможным.

Использование Магазина требует обязательной аутентификации посредством учётной записи Canonical. Это позволяет легко распространять платные проприетарные приложения с подпиской, но посягает на приватность пользователей особенно в дистрибутивах, отличных от Ubuntu.

Общее

Оба формата позволяют создавать и распространять сборки приложений в виде самодостаточных файлов, которые могут устанавливаться без доступа к соответствующим репозиториям. Для Snap этот файл представляет собой непосредственно образ с приложением, а для Flatpak — срез репозитория OSTree.

Формат пакетов

Flatpak

Использует OSTree — Git-подобное хранилище для двоичных файлов. Загрузка выполняется из удалённого репозитория, а извлечение посредством жёстких ссылок.

Таким образом, флатпаки работают напрямую с файловой системой без использования каких-либо прослоек.

Snap использует образы в формате squashfs (специальный неизменяемый формат сжатой файловой системы). Образ подключается к хостовой системе в качестве loopback устройства, после чего монтируется находящаяся внутри образа файловая система.

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

Установка приложений

Flatpak

За все операции отвечает либо само приложение flatpak, либо библиотека libflatpak при использовании внешних графических оболочек (Gnome Software, Discover и т.д.).

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

Большинство операций выполняет работающий с привилегиями суперпользователя системный сервис snapd. Он устанавливает, обновляет и удаляет приложения, взаимодействует с Магазином, а также управляет профилями AppArmor.

Среда выполнения

Flatpak

Файловая система песочницы состоит из следующих составных частей:

Среда выполнения, а также её SDK (software development kit) — это отдельный набор динамических библиотек, которые могут быть использованы приложениями.

Существует несколько популярных и широко используемых при создании флатпаков SDK:

Возможна также и сборка своих собственных SDK, но в этом случае потребуется их распространять вместе с приложением в репозитории, либо составе бандла.

Поддерживаются Core Snap. По функциональности они практически полностью идентичны рантаймам, но представляют собой минимальное окружение дистрибутива Ubuntu.

Core snap монтируется в качестве корневой файловой системы внутри песочницы, а само приложение доступно по тому же пути, что и на хосте.

Технически возможно создание не связанных с Ubuntu core snap’ов, однако на момент публикации данной статьи таковые не применялись.

Изоляция приложений

Flatpak

Для изоляции используются пространства имён ядра Linux, поэтому приложение имеет доступ лишь к своим собственным процессам, файлам и прочим объектам ядра. Для фильтрации системных вызовов применяется Seccomp.

Управление песочницами осуществляется посредством bubblewrap, а для работы с процессами внутри опционально может применяться systemd.

В дистрибутивах, на которых создание пространства имён запрещено для пользователя, для исполняемого файла bwrap применяется SUID-бит.

В случае использования таких глобальных разрешений, как —filesystem=host, —filesystem=home или —talk-name=org.freedesktop.Flatpak, фактически приложение не имеет изоляции, что позволяет ему общаться с хостом и даёт возможность покинуть собственную песочницу.

Для изоляции от основной системы применяется система мандатного ограничения доступа AppArmor. Профили AppArmor генерируются автоматически и загружаются для каждого Snap приложения при помощи системного сервиса snapd.

В системах без поддержки AppArmor, все снапы работают без какой-либо изоляции вообще.

Более того, система изоляция полагается на ряд специфичных системных вызовов ядра Linux, которые присутствуют лишь в Ubuntu и реализуются при помощи downstream-патчей, не принятых в ядро Linux, поэтому полная изоляция в настоящее время не функционирует в отличных от Ubuntu дистрибутивов, использующих систему мандатного доступа AppArmor.

Снапы с активным classic confinement также не изолированы.

Межпроцессное взаимодействие

Общее

Обе системы могут применять xdg-dbus-proxy для взаимодействия при помощи D-Bus — особый фильтрующий прокси, который пропускает лишь разрешённые вызовы.

Для предоставления доступа к файлам, принтерам и прочим объектам хостовой системы может использоваться xdg-desktop-portal.

Литература и благодарности

Редакция выражает большую благодарность участнику чата Russian Fedora Filippe LeMarchand за написание данной статьи.

При написании использовалась литература из следующих источников:

Источник

Техническое сравнение 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 только в начале своего пути и им нужно дать, как минимум, время расцвести.

Источник

Блог начинающего линуксоида.

советы, руководства, инструкции.

Страницы

среда, 7 февраля 2018 г.

Разбираемся с самодостаточными пакетами Flatpak, Snap и Appimage

На сегодняшний день существует несколько вариантов самодостаточных пакетов, отличающихся методом работы, установки и использования. Остановимся на тройке лидеров: Flatpak от компании Red Hat, Snap от компании Canonical и Appimage, развиваемый сообществом.

Flatpak

sudo apt install flatpak

Далее подключим репозитории Flathub и KDE Apps:

Обновление списка пакетов выполняется командой flatpak update. Для того чтобы посмотреть список доступных пакетов в конкретном репозитории (например Flathub) нужно ввести команду:

flatpak remote-ls flathub

Если вы хотите установить скачанный отдельно flatpak-пакет, например, с LibreOffice, то команда для установки будет такой:

А теперь о плюсах и минусах:

sudo apt install snapd
sudo snap login вашлогин

Далее можно ставить программы:

snap install имяпрограммы

Для поиска используется команда find:

Чтобы посмотреть список установленных snap-пакетов, введите:

Чтобы обновить программу, установленную из Snap, наберите команду:

snap refresh имяпрограммы

snap remove имяпрограммы

Программа может быть установлена из нескольких каналов: stable, candidate, beta и edge, в порядке убывания стабильности и повышения свежести. Для этого нужно добавить соответствующий ключ в команду установки пакета:

Если же вы скачали Snap-пакет с сайта разработчика, то для его установки не потребуется аккаунт Ubuntu, только режим разработчика:

Помимо этого имеются ещё две интересные команды: snap buy, с помощью которой можно купить платное приложение в пакете snap, и snap revert, с помощью которой можно откатить пакет к предыдущей версии. Последняя команда очень полезна при появлении серьёзных багов в новой версии программы. Это важное отличие от Flatpak, хотя технология OStree, на которой тот построен, позволяет более гибко откатывать изменения, подобно Git. Но в настоящее время этот интерфейс для Flatpak в разработке, а в Snap доступен уже сейчас. Более подробно о командах можно узнать из man-страницы snapd:

Это что касается интерфейса командной строки. Многие графические менеджеры пакетов, включая таковые в GNOME и свежих версиях KDE, поддерживают Snap из коробки, достаточно лишь ввести название интересующей программы в строку поиска и установить как обычно.

Appimage

Источник

Flatpak или Snap?

Недавно узнал о Snap и Flatpak, что всё таки лучше? У кого какие минусы и плюсы и за кем будущее?

P.S. Я думаю что Snap поинтереснее будет, он ведь пренадлежит Canonical, а это одни из главых двигателей Пингвина.

Это неправильная постановка вопроса. В реальном мире ты, скорее всего, поставишь оба, потому что одни приложения в одном формате, другие в другом, а третьи в AppImage. Инжой ё фридом оф чойс.

Лучше Flatpak, так как Snap скоро закопают, скриньте.

Как только flatpak станет работать не только на десктопе (лет через пять).

а это одни из главых двигателей Пингвина

Будущее и настоящее за Flatpak. См. Fedora Silverble и Endless OS.

Unity вполне была популярна и самобытна, некоторым нравилось.

Unity вполне была популярна и самобытна, некоторым нравилось.

Ну ок. Unity, видимо, делала линукс лучше. Но только для звания главного двигателя линукса, этого как-то маловато.

Пакетами и зависимостями надо рулить вручную:)

Зачем ты используешь компьютер, если можно считать на абаке?

Все эти апты, днф-ы и прочие пакманы приводят мозг линуксоида к деградации. Файлами и каталогами надо рулить вручную:)

Лучше уж вообще тогда электричеством не пользоваться.

appimage уже советовали?

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

AppImage объективно хуже любого из них.

AppImage объективно хуже любого из них.

Ты объективно — балабол. Потому что не привёл аргументов.

AppImage не хуже, он для разных целей. Основное преимущество Snap и Flatpak — в изоляции программ, в репозиториях и обновлении, а AppImage — удобный портативный софт в одном файле, когда, например, нужно воспользоваться программой всего один раз.

Если совсем коротко, я бы сказал так: с технической стороны Flatpak лучше, но для разработчика Snap удобнее.

Ещё стоит иметь в виду, что Snap не кросс-дистрибутивный, вопреки заявлениям. Он до сих пор отсутствует в официальных репозиториях некоторых мейнстримных дистрибутивах, а его изоляция полагается на патченный, специфичный для Убунты apparmor, патчи в апстрим не приняты (и вряд ли будут), так что на не-убунте изоляция приложений работают лишь частично (если вообще).

Можно или собирать несвободное ПО вместе с LGPL либами в одном AppImage. Статически линковать их нельзя, например. GPL и вовсе. Не получится ли нарваться на юридические проблемы при использовании AppImage?

«You cite no new arguments to a previously well-debated issue. Just saying that you are wrong is, therefore, a sufficient response.»

Удобство однократного запуска — это настолько нишевая цель, что ей можно пренебречь.

А основная цель у всех трёх одна и та же: быть the one and only (потому что иначе точно не взлетит) альтернативой куче пакетных менеджеров для всякой (обычно проприетарной) херни, которую нормально опакетить не представляется возможным.

Я думаю что Snap поинтереснее будет, он ведь пренадлежит Canonical, а это одни из главых двигателей Пингвина

Все велосипеды от Canonical рано или поздно выбрасываются ими же самими.

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

AppImage объективно хуже любого из них.

Только в мозгу у наркоманов и шизофреников. AppImage объективно лучше, так как решает реальные проблемы.

Основное преимущество Snap и Flatpak — в изоляции программ, в репозиториях и обновлении

Прямо как AppImage, только хуже. AppImage тоже поддерживает обновления, есть репозитории, есть поддержка изоляции в песочнице.

Можно или собирать несвободное ПО вместе с LGPL либами в одном AppImage. Статически линковать их нельзя, например. GPL и вовсе. Не получится ли нарваться на юридические проблемы при использовании AppImage?

AppImage уже взлетел. Пользователи просят делать AppImage для удобства установки свежих версий приложений, не дожидаясь их попадания в репозиторий.

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

Далёкое будущее конечно же за Nix.

Будущее за WebAssembly и отсутствием нормальных локальных приложений. Сейчас место wasm временно занимает electron.

Всё что в них есть повторяет содержимое репозиториев или собрано в deb-пакеты как discord, vscode.

Opera имеет версию без проблемную с кодеками только в snap, PyCharm так же в snap (иначе tar.gz), gimp от авторов только в flatpak

«You cite no new arguments to a previously well-debated issue. Just saying that you are wrong is, therefore, a sufficient response.»

Оправдание балабола. «Proof or gtfo».

А основная цель у всех трёх одна и та же: быть the one and only

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

Ничего из вами перечисленного AppImage не имеет. Внутри AppImage может быть скрипт для пересборки версии новее, но обновлений как таковых нет, репозиториев нет (но есть каталог AppImage, со ссылками на сайты разработчиков), изоляции нет (но есть поддержка прямого запуска appimage в firejail).

AppImage объективно хуже любого из них.

Зачем вообще сравнивать AppImage с Snap и Flatpak? Они имеют совершенно разные use case.

AppImage тоже поддерживает обновления, есть репозитории, есть поддержка изоляции в песочнице.

Да? Можно подробнее?

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

Есть несколько механизмов обновлений. См. packaging guide.

репозиториев нет (но есть каталог AppImage, со ссылками на сайты разработчиков)

Сам себе противоречишь. И да: есть каталог с собранными образами. Также никто не мешает сделать свой.

изоляции нет (но есть поддержка прямого запуска appimage в firejail).

Опять сам себе противоречишь.

Каталог с образами не является репозиторием. Он не централизованный, его нельзя куда-либо прописать, чтобы программы обновлялись автоматически. Это обычная веб-страница со списком программ, доступных в виде AppImage.

Есть несколько механизмов обновлений.

Есть AppImageUpdate, забыл про него.

Поддержка изоляции в AppImage отсутствует. AppImage не предоставляет механизмов изоляции. Существует поддержка файлов AppImage в firejail, но это сторонняя программа, и в файле AppImage не содержатся профили изоляции. Предполагается, что пользователь их создаст самостоятельно.

В чём проблема? nih, всё должно иметь свой собственный внутренний dhcp-клиент?

файле AppImage не содержатся профили изоляции. Предполагается, что пользователь их создаст самостоятельно.

Давай определимся, что от чего ты хочешь изолировать?

Если ты подозреваешь, что в скачанной программе вирусня, то очень странно доверять каким-то там профилям пришедшим вместе с ней.

Если ты тупо хочешь огородить программу на всякий случай, то есть тысяча и один способ разной хуёвости этого достичь, и для пользователя, и для автора программы. Если тебе приспичило встроить 1002-ой способ в инсталятор, то повторяю вопрос про dhcp-клиент.

Давай определимся, что от чего ты хочешь изолировать?

В Snap программа по умолчанию не имеет доступа к файлам пользователя. Она запускается в самодостаточном контейнере, а-ля Docker. Профили Snap позволяют гибко указывать, какие привилегии есть у Snap-программы, с какими другими программами и директориями она может взаимодействовать, с какими не может, какие у нее сетевые привилегии.

AppImage — просто портативная программа, не контейнер. По умолчанию, у неё такие же возможности, как у любой другой программы, запущенной от имени пользователя. У Snap и Flatpak — не так.

Основное концептуальное отличие Snap и Flatpak от AppImage и репориториев вообще — разделение привилегий, внедрение модели привилегий Android/iOS на компьютеры.

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

Кто их пишет? Автор пакета, как я понимаю? Почему ты доверяешь ему, что он действительно сделает ограничение для сетевых привилегий?

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

Кто их пишет? Автор пакета, как я понимаю? Почему ты доверяешь ему, что он действительно сделает ограничение для сетевых привилегий?

Этим snapd занимается, а не автор приложения. В snap пакете будет написано использует ли интернет или нет.

Не получится просто так использовать сеть, и не прописав это в разрешениях.

AppImage конечно, всё остальное дерьмо не взлетело и не взлетит никогда.

Этим snapd занимается, а не автор приложения. В snap пакете будет написано использует ли интернет или нет.

Не получится просто так использовать сеть, и не прописав это в разрешениях.

Кто это прописывает в разрешения? Таки человек? И почему я должен доверять этому человеку, что он пропишет это правильно?

Андроид, например, всегда славился тем, что каждая игрушка хочет доступ к твоим контактам.

snapd даёт пользователю перед инсталяцией пакета возможность проверить прописанные разрешения?

Или может я — старый дебил и это всё теперь автоматически происходит?

Этим snapd занимается, а не автор приложения. В snap пакете будет написано использует ли интернет или нет.

Не получится просто так использовать сеть, и не прописав это в разрешениях.

И таки в чём преимущество перед запуском appimage в firejail?

Они имеют совершенно разные use case.

Да, но в головах людей они конкурируют за один и тот же слот.

ValdikSS

Да, но в головах людей они конкурируют за один и тот же слот.

flatpak или snap могут один другого победить или оба сдохнуть. В appimage продложат паковать в любом случае, потому что он единственный сам в себе.

Источник