Сравнение менеджеров пакетов Linux: AppImage, Snap и Flatpak
Менеджеры пакетов позволяют упаковывать, распространять, устанавливать и поддерживать приложения в операционной системе. С учетом современных настольных, серверных и IoT-приложений операционной системы Linux и сотен существующих различных дистрибутивов становится необходимым перейти от методов упаковки, специфичных для конкретной платформы, к методам, не зависящим от платформы. В этом посте рассматриваются три таких инструмента, а именно AppImage, Snap и Flatpak, каждый из которых призван стать будущим развертывания и управления программным обеспечением в Linux. В конце мы суммируем несколько ключевых выводов.
1. Изображение приложения
AppImage следует концепции «Одно приложение=один файл». Под этим следует понимать AppImage, представляющий собой обычный независимый «файл», содержащий одно приложение со всем, что ему необходимо для запуска, в указанном файле. После того как AppImage станет исполняемым, его можно будет запускать как любое приложение на компьютере, просто дважды щелкнув его в файловой системе пользователя.[1]
Это формат для создания портативного программного обеспечения для Linux, не требующий от пользователя установки указанного приложения. Этот формат позволяет первоначальным разработчикам программного обеспечения (начальным разработчикам) создавать независимую от платформы и дистрибутива (также называемую независимой от дистрибутива двоичную) версию своего приложения, которая в основном будет работать на любой версии Linux.
AppImage существует уже давно. Klik, предшественник AppImage, был создан Саймоном Питером в 2004 году. Проект был закрыт в 2011 году, так как не прошел стадию бета-тестирования. Примерно в то же время Саймон создал проект под названием PortableLinuxApps, и его формат был подхвачен несколькими порталами, предлагающими программное обеспечение для пользователей Linux. В 2013 году проект был снова переименован в его нынешнее имя AppImage, и в GitHub поддерживается репозиторий (ссылка на проект) со всеми последними изменениями с 2018 года.[2][3]
AppImage, написанный в основном на C и пользующийся лицензией MIT с 2013 года, в настоящее время разрабатывается Проектом AppImage. Это очень удобный способ использования приложений, о чем свидетельствуют следующие функции:
- AppImages может работать практически в любой системе Linux. Как упоминалось ранее, приложения получают большую функциональность от операционной системы и нескольких общих библиотек. Это обычная практика в мире программного обеспечения, поскольку, если что-то уже сделано, нет смысла делать это снова, если вы можете выбирать, какие части того же самого использовать. Проблема в том, что во многих дистрибутивах Linux могут отсутствовать все файлы, необходимые для запуска конкретного приложения, поскольку включение необходимых пакетов остается на усмотрение разработчиков этого конкретного дистрибутива. Следовательно, разработчикам необходимо отдельно включать зависимости приложения для каждого дистрибутива Linux, для которого они публикуют свое приложение. Используя формат AppImage, разработчики могут включить в файл AppImage все библиотеки и файлы, которые, по их мнению, не могут быть в целевой операционной системе. Следовательно, один и тот же файл формата AppImage может работать в разных операционных системах и машинах без необходимости детального контроля.
- Философия «одно приложение — один файл» означает, что взаимодействие с пользователем является простым и элегантным, поскольку пользователям нужно загрузить и запустить только один файл, который будет соответствовать их потребностям в использовании приложения.
- Нет требований к корневому доступу. Системные администраторы потребуют от людей root-доступа, чтобы они не могли вмешиваться в работу компьютеров и их настройки по умолчанию. Это также означает, что люди, не имеющие root-доступа или привилегий суперпользователя, не могут устанавливать нужные им приложения по своему усмотрению. Такая практика распространена в общественных местах (например, на компьютерах библиотек, университетов или в корпоративных системах). Файл AppImage не требует от пользователей ничего «устанавливать», поэтому пользователям нужно только загрузить указанный файл и сделать его исполняемым, чтобы начать его использовать. Это устраняет дилеммы доступа, с которыми сталкиваются системные администраторы, и упрощает их работу, не жертвуя при этом удобством работы пользователей.
- Не влияет на основную операционную систему. Формат приложений AppImage позволяет использовать приложения с полной функциональностью без необходимости изменения или даже доступа к большинству системных файлов. Это означает, что что бы ни делали приложения, основные настройки операционной системы и файлы остаются нетронутыми.
- AppImage может быть создан разработчиком для конкретной версии своего приложения. Любая обновленная версия создается как другой AppImage. Таким образом, пользователи при необходимости могут тестировать несколько версий одного и того же приложения, запуская разные экземпляры с использованием разных изображений приложений. Это бесценная функция, когда вам нужно протестировать свои приложения с точки зрения конечного пользователя, чтобы заметить различия.
- Возьмите свои приложения с собой куда угодно. Как упоминалось ранее, AppImages — это архивированные файлы всех файлов, которые требуются приложению, и их можно использовать, не устанавливая и даже не беспокоясь о дистрибутиве, который использует система. Следовательно, если у вас есть набор приложений, которые вы регулярно используете, вы можете даже смонтировать несколько файлов AppImage на флэш-накопитель и взять их с собой для использования на нескольких компьютерах с несколькими разными дистрибутивами, не беспокоясь, будут ли они работать или нет.
Кроме того, AppImageKit позволяет пользователям любого уровня подготовки создавать свои собственные AppImages из уже имеющихся у них приложений или для приложений, которым не предоставил AppImage их вышестоящий разработчик.
Менеджер пакетов не зависит от платформы, но ориентирован в первую очередь на распространение программного обеспечения среди конечных пользователей на их настольных компьютерах с помощью специального демона AppImaged для интеграции форматов AppImage в соответствующие среды рабочего стола. AppImage теперь изначально поддерживается различными дистрибутивами, такими как Ubuntu, Debian, openSUSE, CentOS, Fedora и т. д., а другие могут настроить его в соответствии со своими потребностями. AppImages также можно запускать на серверах с ограниченной функциональностью с помощью включенных инструментов CLI.
Чтобы узнать больше о AppImages, перейдите на официальную страницу документации AppImage.
Рекомендуем прочитать:
- Интеграция изображений приложений в меню приложения с помощью AppImageLauncher
- Поиск приложений Linux на платформах AppImage, Flathub и Snapcraft
2. Быстрый
Snappy — это система развертывания программного обеспечения и управления пакетами, такая как AppImage или любой другой менеджер пакетов для этого экземпляра. Первоначально он был разработан для ныне несуществующей операционной системы Ubuntu Touch. Snappy позволяет разработчикам создавать пакеты программного обеспечения для использования в различных дистрибутивах на базе Linux. Первоначальная цель создания Snappy и развертывания "snaps" в системах на базе Ubuntu состоит в том, чтобы получить единый формат, который можно было бы использовать во всем: от устройств IoT до полноценных компьютерных систем, на которых работала какая-либо версия Ubuntu. и в более широком смысле сам Linux.[4]
Ведущим разработчиком проекта является Canonical, та же компания, которая управляет пилотным проектом Ubuntu. Ubuntu имела встроенную поддержку Snap начиная с версии 16.04 LTS, и в наши дни все больше и больше дистрибутивов поддерживают ее «из коробки» или посредством простой настройки. Если вы используете Arch, Debian или openSUSE, вам будет легко установить поддержку менеджера пакетов с помощью простых команд в терминале, как описано далее в этом разделе. Это также стало возможным благодаря тому, что необходимые файлы платформы Snap доступны в соответствующих репозиториях.[5]
Snappy имеет следующие важные компоненты, составляющие всю систему менеджера пакетов.[6]
- Snap – формат файлов самих пакетов. Отдельные приложения, развертываемые с помощью Snappy, называются «Snaps». Любое приложение может быть упаковано с использованием предоставленных инструментов для создания оснастки, предназначенной для запуска в другой системе под управлением Linux. Snap, как и AppImage, представляет собой комплексный файл и содержит все зависимости, которые приложение должно запускать, не предполагая, что они являются частью целевой системы.
- Snapcraft – инструмент, позволяющий разработчикам делать снимки своих приложений. По сути, это команда, которая является частью системы привязок, а также инфраструктурой, которая позволит вам создавать свои собственные привязки.
- Snapd – это фоновый демон, который поддерживает все снимки, установленные в вашей системе. Он интегрируется в среду рабочего стола и управляет всеми файлами и процессами, связанными с работой со снапами. Демон snapd также обычно проверяет наличие обновлений 4 раза в день, если не установлено иное.
- Snap Store – это своего рода онлайн-галерея, которая позволяет разработчикам загружать свои снимки в репозиторий. Snap store также является средством обнаружения приложений для пользователей и позволяет пользователям видеть и работать с библиотекой приложений перед их загрузкой и установкой.
Компонент snapd написан в основном на C и Golang, тогда как платформа Snapcraft построена с использованием Python. Хотя оба модуля используют лицензию GPLv3, следует отметить, что Snapd имеет собственный код Canonical для операций на стороне сервера, а только клиентская часть публикуется под лицензией GPL. Это главный предмет разногласий с разработчиками, поскольку он предполагает, что разработчики подписывают форму CLA для участия в разработке Snap.[7]
Если углубиться в детали менеджера пакетов Snappy, можно отметить следующее:
- Как отмечалось ранее, снимки включают все необходимые файлы (зависимости), необходимые для запуска приложения. Следовательно, разработчикам не нужно делать разные снимки для разных дистрибутивов, на которые они нацелены. Помнить о средах выполнения — это все, что необходимо, если базовые среды выполнения исключены из привязки.
- Пакеты Snappy предназначены для поддержки транзакционных обновлений. Такое транзакционное обновление является атомарным и полностью обратимым, что означает, что вы можете использовать приложение во время его обновления, и что, если обновление не ведет себя так, как должно, вы можете отменить то же самое без каких-либо других эффектов. Эту концепцию также называют дельта-программированием, при которой в качестве обновления передаются только изменения в приложении, а не весь пакет. Производная версия Ubuntu под названием Ubuntu Core фактически обещает быстрый протокол обновления самой ОС.[8]
- Ключевое различие между снапами и AppImages заключается в том, как они обрабатывают различия версий. При использовании AppImages разные версии приложения будут иметь разные AppImages, что позволит вам одновременно использовать две или более разных версий одного и того же приложения. Однако использование привязок означает соответствие системе транзакционных или дельта-обновлений. Хотя это означает более быстрое обновление, это не позволяет вам одновременно запускать два экземпляра одного и того же приложения. Если вам нужно использовать старую версию приложения, вам необходимо отменить или удалить новую версию. Snappy поддерживает функцию под названием "параллельная установка", которая позволит пользователям достигать аналогичных целей, однако она все еще находится на экспериментальной стадии и не может считаться стабильной реализацией. Snappy также использует каналы, что означает, что вы можете использовать бета-версию или ночную сборку приложения и стабильную версию одновременно.[9]
- Обширная поддержка со стороны основных дистрибутивов Linux и крупных разработчиков, включая Google, Mozilla, Microsoft и т. д.[4]
- Snapd, инструмент интеграции с рабочим столом, поддерживает создание снимков текущего состояния всех установленных снимков в системе. Это позволит пользователям сохранять текущее состояние конфигурации всех приложений, установленных через менеджер пакетов Snappy, и возвращаться к этому состоянию, когда они этого пожелают. Эту же функцию можно также настроить на автоматическое создание снимков с частотой, которую пользователь считает необходимой. Снимки можно создавать с помощью команды snap save в среде snapd.[10]
- Snaps предназначены для изолирования во время работы. Это обеспечивает столь необходимый уровень безопасности и изоляции для пользователей. Пользователям не нужно беспокоиться о том, что приложения на основе Snap будут портить остальное программное обеспечение на их компьютере. Песочница реализуется с использованием трех уровней изоляции: классический, строго и режим разработчика. Каждый уровень изоляции предоставляет приложению разные уровни доступа к файловой системе и компьютеру.[11]
С другой стороны, снимки широко критикуются за то, что они ориентированы на образ действий Canonical. Большинство обязательств по проекту вносят сотрудники или подрядчики Canonical, а другие участники должны подписать форму выпуска (CLA). Функция изолированной программной среды, действительно очень важная с точки зрения безопасности, имеет недостаток в том, что изолированная программная среда фактически требует запуска некоторых других основных служб (таких как Mir), в то время как приложения, работающие на рабочем столе X11, не поддерживают указанную изоляцию, что делает указанная функция безопасности не имеет значения. Сомнительные пресс-релизы и другие маркетинговые усилия Canonical, а также «центральный» и закрытый репозиторий приложений также являются аспектами Snappy, подвергающимися широкой критике. Кроме того, размеры файлов различных снимков также сравнительно очень велики по сравнению с размерами приложений пакетов, созданных с помощью AppImage.[7]
Более подробную информацию можно найти в официальной документации Snap.
Связанное чтение:
- Установить пакеты Snap в Arch Linux и Fedora
3. Флэтпак
Как и упомянутый выше Snap/Snappy, Flatpak также является инструментом развертывания программного обеспечения, целью которого является упрощение распространения и использования программного обеспечения в Linux. Flatpak ранее был известен как xdg-app и был основан на концепции, предложенной Леннартом Поеттерингом в 2004 году. Идея заключалась в том, чтобы хранить приложения в безопасной виртуальной песочнице, позволяющей использовать приложения без необходимости получения root-прав и без ущерба для безопасности системы. Алекс начал работать с Klik (считается, что это бывшая версия AppImage) и хотел лучше реализовать эту концепцию. Александр Ларссон, который в то время работал с Red Hat, в 2015 году написал реализацию под названием xdg-app, которая стала предшественником текущего формата Flatpak.
Flatpak официально вышел в 2016 году при поддержке Red Hat, Endless Computers и Collabora. Flathub — официальный репозиторий всех пакетов приложений Flatpak. На первый взгляд Flatpak, как и другие, представляет собой платформу для создания и упаковки приложений, не зависящих от распространения, для Linux. От разработчиков просто требуется соблюдение нескольких рекомендаций по среде рабочего стола, чтобы приложение было успешно интегрировано в среду Flatpak.
Платформа Flatpak, ориентированная в первую очередь на три популярные реализации настольных компьютеров: FreeDesktop, KDE и GNOME, написана на C. > и работает по лицензии LGPL. Доступ к репозиторию обслуживания можно получить по ссылке GitHub здесь.
Ниже перечислены некоторые особенности Flatpak, которые выделяют его. Обратите внимание, что функции Flatpak, общие с AppImage и Snappy, здесь опущены.
- Глубокая интеграция с популярными средами рабочего стола Linux, такими как GNOME и KDE, чтобы пользователи могли просто использовать Flatpaks с помощью графических инструментов управления программным обеспечением, а не прибегать к терминалу. Flatpak теперь можно установить из репозиториев по умолчанию для основных настольных сред, и как только сами приложения будут настроены, их можно будет использовать и предоставлять функции, аналогичные обычным настольным приложениям.[12][13]
- Прямая совместимость. Пакеты Flatpaks создаются с нуля с учетом ядра операционной системы и среды выполнения. Следовательно, даже если вы обновите или обновите свой дистрибутив, имеющиеся у вас Flatpaks все равно должны работать, если не будет обновления ядра. Это особенно важно для людей, которые предпочитают продолжать использовать бета-версии или разрабатываемые версии своих дистрибутивов. Для таких людей, поскольку недостатки самой ОС обычно не устраняются, приложение Flatpak будет работать без проблем, не завися от файлов или библиотек ОС для своей работы.[13]
- Изолированная среда с использованием Bubblewrap: снимки также по умолчанию помещаются в изолированную программную среду, поскольку они выполняются изолированно от остальных приложений, работающих во время использования компьютера. Однако Flatpaks по умолчанию полностью изолирует приложение от доступа к файлам ОС и пользовательским файлам во время его работы. По сути, это означает, что системные администраторы могут быть уверены, что пакеты Flatpaks, установленные в их системах, не смогут использовать компьютер и содержащиеся на нем файлы, тогда как для конечных пользователей это будет означать, что для доступа к некоторым конкретным функциям или пользовательским данным требуется root-право. [14]
- Flatpak изначально поддерживает децентрализованное распространение приложений, однако команда Flatpak по-прежнему поддерживает центральный онлайн-репозиторий приложений/Flatpaks под названием Flathub. Фактически пользователи могут настроить Flatpak для использования нескольких удаленных репозиториев по своему усмотрению. В отличие от Snap, вы можете иметь несколько репозиториев.[13]
- Модульный доступ через песочницу. Хотя эта возможность сопряжена с большими потенциальными затратами для целостности системы, платформа Flatpak позволяет создавать каналы через «песочницу» для обмена конкретной информацией из «песочницы» с хост-системой или наоборот. Канал в этом случае называется порталом. Недостатки этой функции обсуждаются далее в этом разделе.[14]
Однако одним из наиболее критикуемых аспектов Flatpak является сама функция песочницы. Песочница — это то, как менеджеры пакетов, такие как Snappy и Flatpak, реализуют важные функции безопасности. Песочница по существу изолирует приложение от всего остального в системе, позволяя только пользователю осуществлять обмен информацией изнутри песочницы наружу. Недостаток этой концепции в том, что песочница не может быть неуязвимой по своей сути. В конечном итоге данные должны быть переданы между двумя доменами, и простые команды Linux могут просто избавиться от ограничений песочницы, а это означает, что вредоносные приложения потенциально могут выйти из указанной песочницы.[15]
Это в сочетании с худшими, чем ожидалось, обязательствами по развертыванию обновлений безопасности для Flatpak привело к широкой критике высоких заявлений команды о предоставлении безопасной среды. В блоге (под названием Flatkill), ссылка на который приведена в конце этого руководства, на самом деле упоминается пара эксплойтов, которые не были устранены командой Flatpak так быстро, как следовало бы.[15]
Для более подробной информации предлагаю вам прочитать официальную документацию Flatpak.
Связанное чтение:
- Руководство по Flatpak для начинающих
- Как легко настроить разрешения приложений Flatpak с помощью Flatseal
AppImage против Snap против Flatpak
В приведенной ниже таблице суммированы все вышеизложенные выводы в кратком и техническом сравнении трех систем.
Feature | AppImage | Snappy | Flatpak |
Unique feature | Not an appstore or repository, its simply put a packaging format for software distribution. | Led by Canonical (Same company as Ubuntu), features central app repository and active contribution from Canonical. | Features an app store called FlatHub, however, individuals may still host packages and distribute it. |
Target system | Desktops and Servers. | Desktops, Servers, IoT devices, Embedded devices etc. | Desktops and limited function on servers. |
Libraries/Dependencies | Base system. Runtimes optional, Libraries and other dependencies packaged. | Base system or via Plugins or can be packaged. | GNOME, KDE, Freedesktop bundled or custom bundled. |
Developers | Community Driven led by Simon Peter. | Corporate driven by Canonical Ltd. | Community driven by flatpak team supported by enterprise. |
Written in | C. | Golang, C and Python. | C. |
Initial release | 2004. | 2014. | 2015. |
Sandboxing | Can be implemented. | 3 modes - strict, classic, and devmode with varying confinement capabilities. Runs in isolation. | Isolated but Uses system files to run applications by default. |
Sandboxing Platform | Firejail, AppArmor, Bubblewrap. | AppArmor. | Bubblewrap. |
App Installation | Not necessary. Will act as self mounted disc. | Installation using snapd. | Installed using flatpak client tools. |
App Execution | Can be run after setting executing bit. | Using desktop integrated snap tools. Runs isolated with user defined resources. | Needs to be executed using flatpak command if CLI is used. |
User Privileges | Can be run w/o root user access. | Can be run w/o root user access. | Selectively required. |
Hosting Applications | Can be hosted anywhere by anybody. | Has to be hosted with Canonical servers which are proprietary. | Can be hosted anywhere by anybody. |
Portable Execution from non system locations | Yes. | No. | Yes, after flatpak client is configured. |
Central Repository | AppImageHub. | Snap Store. | Flathub. |
Running multiple versions of the app | Possible, any number of versions simultaneously. | One version of the app in one channel. Has to be separately configured for more. | Yes. |
Updating applications | Using CLI command AppImageUpdate or via an updater tool built into the AppImage. | Requires snapd installed. Supports delta updating, will automatically update. | Required flatpak installed. Update Using flatpak update command. |
Package sizes on disk | Application remains archived. | Application remains archived. | Client side is uncompressed. |
Вот длинное табличное сравнение функций AppImage, Snap и Flatpak. Обратите внимание, что сравнение выполняется с точки зрения AppImage.
- https://github.com/AppImage/AppImageKit/wiki/Similar-projects#comparison
Заключение
Хотя все три эти платформы имеют много общего друг с другом и стремятся быть независимыми от платформы в подходе, они предлагают разные уровни компетенций в нескольких областях. Хотя Snaps может работать на различных устройствах, включая встроенные, AppImages и Flatpaks созданы с учетом потребностей пользователей настольных компьютеров. С другой стороны, AppImages популярных приложений имели превосходные размеры упаковки и портативность, тогда как Flatpak действительно блестит своей прямой совместимостью, когда он используется в системе «установи и забудь».
Ссылки:
- [1] Концепции — документация AppImage
- [2] Slashdot — установка программного обеспечения Linux с помощью Point-and-klik
- [3] История проекта AppImage
- [4] Snapcraft — Snaps – это универсальные пакеты Linux
- [5] Установка snapd – документация Snap
- [6] Документация Snap
- [7] О Snappy и Flatpak: в отделе пропаганды Canonical дела идут как обычно
- [8] Snap Updates становится меньше, и вот почему
- [9] Что такое Snap-пакеты Linux? Зачем их использовать?
- [10] Снимки – документация Snap
- [11] Фиксация Snap – документация Snap
- [12] Интеграция с рабочим столом — документация Flatpak
- [13] Введение в Flatpak – документация Flatpak
- [14] Разрешения для песочницы – документация Flatpak
- [15] Flatpak — кошмар безопасности