Flatpack linux что это

Обновлено: 05.07.2024

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

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

Многие библиотеки настолько серьёзны, что написать их функционал с нуля — это Грандиозная Задача. Примеры — поддержка unicode, рендеринга шрифтов, математики.
Другие библиотеки предлагают довольно скромный набор функций, но написанных так хорошо, что написать хотя бы так хорошо же, почти невозможно. Стандартные библиотеки языков программирования, различные реализации libc, etc.
Стоимость работы по взаимодействию с чужим кодом (чему посвящён этот раздел) чаще всего оказывается ниже, чем цена сопровождения своего кода. Плотность "багов на строк кода" с большой вероятностью будет сравнима, а "свои баги" надо самому же и ловить. Чужие (популярные) библиотеки имеют вероятность быть отлажены и исправлены чужими же руками.

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

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

Вам надо парсер командной строки
Который должен принимать юникод
И, возможно, давать пользователю подсказку, что он опечатался в имени аргумента
Что требует фонетического сравнения
И, возможно, регулярных выражений
В общем случае вам придётся поддерживать не только юникод, но и другие локали, что требует библиотеки поддержки локалей и ВСЁ то, что люди придумали в контексте локалей.
Конкатенация строк с нормализацией — ещё одно применение отдельной библиотеки юникода, сами вы такое не реализуете.
Вывод на экран (справки по командной строке, вашего результата) с большой вероятностью потребует поддержки ncurses — библиотеки, поддерживающей разные терминалы (можно обойтись текстовым режимом, но приложения часто используют цветовые возможности).
Тесты подразумевают использование тестового фреймворка, возможно, библиотеки для моков.

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

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

Мы можем скопировать код, который делает нужные нам операции. В виде куска кода (copy&paste), как отдельный модуль в языке программирования (объектный файл для компилируемых языков), либо как отдельный модуль (для интерпретируемых языков). Где-то тут же рядом идёт и "скопировать исходный файл библиотеки к себе в каталог с приложением". Какие проблемы это создаёт? Главная, основная проблема — мы теряем (навсегда) связь с оригиналом. Даже если автор оригинальной библиотеки исправит ошибку, мы не будем об этом знать. Более того, если мы просто скопировали код, то следующий человек, работающей над программой, даже не сможет узнать, что этот код "чужой". Фактически, мы срезали путь в вопросе "написать с нуля" и взяли чужое. Однако, мы срезали лишь кусочек, потому что если в этом коде будут ошибки (а они там не будут, они там есть), то их исправление потребует от исправляющего пойти и разобраться в сути проблемы до самого низа. Даже если разбирательство потребует чтения нескольких сотен тысяч строк исходного кода и сотен RFC (а так же комментариев о том, что реализации отличаются от RFC), другого пути у нас нет. Ключевой ошибкой в этом месте является то, что мы потеряли информацию о том, что это код чужой. Наличие комментариев в файле может помочь, но потребует деятельного и глубокого участия человека, потому что если мы напишем в комментарии "взято из libfoobar, src/lib/foo.c версии 364a51577f3782dbf8e5d2482ab941980357c492", то кому-то надо будет посмотреть, где libfoobar находится, какая там версия и что поменялось с предыдущей версии". Чтобы упростить этот процесс, нам нужна машиночитаемая метаинформация.
Если мы сопровождаем "чужой код" метаинформацией и используем программы для управления этим кодом (вместо копипаста), то это называется вендоринг, т.е. контролируемое включение чужого кода в свой код. Технически вендоринг может происходить на этапе исходного текста, линковки объектов в исполняемый файл, импорта модулей (в интерпретаторах) из состава приложения, или, даже, динамической линковки с "своей" версией библиотеки (об этом чуть позже).
Наконец, мы можем осуществлять динамическую линковку на этапе запуска приложения. Для компилируемых языков это обычные so'шки, для интерпретируемых — наличие модуля в общесистемном импорте. Если его могут импортировать несколько приложений, то это общая библиотека. Если приложение "принесло свой модуль", то библиотека "своя", даже если её интерфейс подразумевает "общую библиотеку". Например, если приложение использует "свою" версию so'шки, вне зависимости от того, отличается ли она от общей, или нет, то это вендоринг. А если импортируется системная, то это общая библиотека (shared library).

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

Экономию памяти (оперативной и на диске) для so'шек, уменьшение размеров установленной системы. Чем больше приложений использует одну и ту же so'шку, тем большая экономия памяти. Соответственно, обратно, чем больше "своих" библиотек приносит приложение, тем оно "жирнее".
Спор о том, кто следит за уязвимостями — система (предоставляя обновления библиотеки) или автор приложения (вовремя обновляя его).
Разрешение конфликта зависимостей (вендоринг решает эту проблему так как общие библиотеки требуют внимания и аккуратности от всех участников процесса, иногда создавая непреодолимые трудности), тот самый легендарный dll hell.
Новые версии библиотек — либо они появляются по пожеланию авторов приложения, либо по решению авторов дистрибутива. В одном случае автор может принести нужную ему новую фичу, в другом случае, дистрибутив может принести улучшение существующего приложения за счёт поддержки чего-то нового в библиотеке (например, hidpi экраны начали правильно работать во всех приложениях, динамически линкующихся с библиотеками qt/gtk).

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

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

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

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

… В этот момент автор просто пишет в требованиях к приложению libfoobar>=3.14-pre2 . Мейнтейнер берёт и патчит требование, плюс удаляет код, который от этой библиотеки зависел. Может быть. Или просто отказывается принимать новую версию с такой зависимостью, пока эта зависимость (libfoobar 3.16) не окажется в новой версии дистрибутива.

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

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

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

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

При этом, чем больше приложений идут со своими библиотеками, тем меньше польза от системных библиотек. Помните про "благодать"? Чем менее она "всеобщая", тем меньше она благодать. Если общая библиотека используется 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 (огромные приложения для работы с графикой).

А если каждый будет такой? У меня на компьютере установлено 2000 пакетов (не считая -dev и lib)… 2000*300 = 600Гб (За средний размер получившегося я взял половину от chefsdk, т.к. не все настолько ужасны по зависимостям). Сейчас они занимают около 7Гб (включая ресурсы, вроде документации, текстур редакторов, шаблонов CAD-программ и т.д.).

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

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

Особенности Flatpak

Примерно в то же время, что и Flatpak, появился менеджер пакетов snap. По своей сути Flatpak очень похож на snap. Здесь тоже все зависимости находятся внутри установочного пакета, программе внутри пакета разрешен доступ только к тем, ресурсам, которые ей нужны. Но в отличие от snap, flatpak более децентрализован. Никто не контролирует какие репозитории вы создаёте и что в них распространяете. Вы можете создать свой репозиторий, вроде PPA и распространять там свое программное обеспечение. В то же время как для того чтобы попасть в Snap Store надо получить разрешение от Canonical.

Установка Flatpak в Linux

В таких системах, как Fedora пакетный менеджер Flatpak уже поставляется по умолчанию. Но если вы захотите использовать программу в Ubuntu, Debian или в Linux Mint, то вам понадобится её установить:

sudo apt install flatpak

Если в репозиториях вашего дистрибутива нет пакета Flatpak, вы можете установить его из PPA:

sudo add-apt-repository ppa:alexlarsson/flatpak
sudo apt update
sudo apt install flatpak

Если всё же вам надо установить flatpak в дистрибутиве, основанном на Red Hat Enterprice Linux, выполните:

sudo yum install flatpak

Для OpenSUSE команда не сильно отличается:

sudo zypper install flatpak

Да и для ArchLinux тоже:

sudo pacman -S flatpak

После установки вы можете пользоваться flatpak из командной строки. Чуть ниже мы рассмотрим как это делать, но для удобства можно добавить поддержку flatpak в центр приложений. Для этого в Ubuntu достаточно установить такой пакет:

sudo apt install gnome-software-plugin-flatpak

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

Как пользоваться Flatpak

1. Поиск программ на FlatHub

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

Откройте её страницу и нажмите кнопку Install для установки программы с помощью центра приложений:

Кроме того, внизу страницы есть инструкция как установить программу с помощью терминала:

2. Добавление репозиториев

Самый популярный репозиторий Flatpak на момент написания этой статьи - flathub. Если Flatpak уже был установлен в вашей системе, то, скорее всего, и этот репозиторий тоже был установлен. Для добавления репозитория используется такая команда:

$ flatpak remote-add имя_репозитория ссылка_на_репозиторий

Например, для FlatHub выполните:

Кроме того, существует ещё несколько репозиториев, например, репозиторий программ Gnome:

Репозиторий программ KDE:

Другие репозитории вы можете найти в интернете. Посмотреть все добавленные репозитории можно выполнив:

3. Поиск по репозиториям

Вы можете посмотреть все пакеты, которые есть в репозитории. Для этого выполните команду remote-ls и передайте ей имя репозитория:

flatpak remote-ls flathub

Ещё можно искать нужный пакет по имени, для этого используйте:

$ flatpak search имя_пакета

flatpak search pidgin

Для установки программы вам понадобиться имя пакета программы из колонки Application ID и имя репозитория из колонки Remotes.

4. Установка пакетов

Для установки пакета flatpak используйте такую команду:

$ flatpack install имя_репозитория имя_пакета

Например, давайте установим тот же Pidgin, найденный предыдущей командой:

flatpak install flathub im.pidgin.Pidgin

Если вы не хотите добавлять репозиторий в систему, вы можете установить программу по ссылке из сети. Просто скопируйте ссылку на файл flatpakref и передайте её программе:

Если вы уже скачали файл flatpakref, его тоже можно установить.

Посмотреть все установленные программы можно выполнив команду:

5. Запуск программ Flatpak

Программы, установленные с помощью flatpak можно запустить из главного меню. Однако если вы захотите запустить их с помощью терминала. Надо использовать команду flatpak:

flatpak run im.pidgin.Pidgin

6. Удаление программ

Для удаления программы используйте такую команду:

$ flatpak uninstall имя_программы

Например, для Pidgin:

flatpak uninstall im.pidgin.Pidgin

После удаления пакета можно удалить неиспользуемые компоненты, чтобы освободить место на диске:

flatpak uninstall --unused

7. Обновление программ

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

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

Выводы

В этой небольшой статье мы рассмотрели как установить Flatpak, а также как пользоваться этой системой. Как видите, здесь всё немного сложнее по сравнению со snap, зато тут больше свободы. А что вам больше нравится snap или flatpak? Напишите в комментариях!

Нет похожих записей

Статья распространяется под лицензией Creative Commons ShareAlike 4.0 при копировании материала ссылка на источник обязательна.

За последние несколько лет Linux очень сильно продвинулся на пути к обычным пользователям. Изменялся и упрощался интерфейс, добавлялись графические утилиты, исправлялись ошибки и недоработки, дистрибутивы становились лучше. Но теперь изменения добрались до системы установки пакетов. Традиционный способ устанавливать программы - загрузка и установка с репозиториев вашего дистрибутива. Причем форматы пакетов, способы развертывания и даже версии библиотек между дистрибутивами очень отличаются. Это не позволяло скачать программу из интернета и запускать ее на любом linux дистрибутиве.

Но за последние пару лет был сделан шаг и в этом направлении. Были созданы портативные приложения, которые устанавливаются одним файлом, вместе со всеми своими зависимостями и поэтому могут работать абсолютно в любом дистрибутиве, независимо от установленных там программ и библиотек. Сначала энтузиастами был разработан формат AppImage, который представляет из себя ISO образ со всеми файлами программы, затем разработчики Gnome переименовали и взялись за развитие своей платформы контейнерного запуска приложений Flatpak, и примерно в то же время компания Canonical реализовала систему установки пакетов без зависимостей - Snap, которая, как и все предыдущие, может использоваться в любом дистрибутиве.

Чем отличается Snap vs Flatpak vs AppImage?

Как видите, в последнее время было создано очень много решений портативных программ Linux и пора разобраться что лучше и что все-таки использовать. В этой статье мы сравним snap vs flatpak vs appimage. Это самые популярные и известные технологии, хотя были и другие. Попытаемся выяснить у кого больше перспектив для развития, но сначала выясним, что представляет из себя каждая из этих технологий.

Что такое Snap?

О Snap пакетах мы слышали уже давно, сначала они использовались для встраиваемых устройств и в качестве механизма обновления Ubuntu для смартфонов. Как заявляют разработчики из Canonical эта технология была создана изначально для того, чтобы предоставить максимальную удобность обновления пользователям Ubuntu и поднять на новый уровень безопасность мобильных приложений. Основная задача - решить проблемы, неразрешимые для deb и rpm пакетов и обеспечить надежное обновление.

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

Программа, упакованная в snap, выполняется в изолированном окружении, ей недоступны никакие библиотеки из системы и даже конфигурационные файлы. Это реализуется с помощью профилей AppArmor. Она может работать только с тем, что установлено в пакете. Домашняя папка программы тоже в её директории. Для общения с X сервером, файловой системой, окружением рабочего стола и другими компонентами используются интерфейсы, предоставляемые главным пакетом - ubuntu-core. Если программе не разрешить доступ к этим интерфейсам она не сможет работать. Чтобы предоставить доступ программе к файлам пользователя тоже нужно использовать соответствующий интерфейс - home.

На данный момент Snap пакеты работают кроме Ubuntu, на Arch, Debian и Fedora. Также выполняется подготовка образов для Red Hat, CentOS, Elementary, LinuxMint, Gentoo, OpenSUSE. Более подробно про управление Snap пакетами читайте здесь.

Для создания snap пакетов используется специальный инструмент - snapcraft. Он позволяет относительно легко создать пакет для любой платформы. Для сборки программы нужно описать ее и необходимые зависимости в файле snapcraft.yaml и этот процесс немного сложный. Если сравнивать snap vs AppImage, то там все чуть проще, но и нет такого уровня безопасности. Но в целом это довольно интересная технология, благодаря возможностям безопасности.

Что такое AppImage?

Про Appimage мы услышали еще в 2011 году, но тогда программа не набрала популярности несмотря на все ее плюсы по сравнению с традиционными системами упаковки программ.

Здесь, также как и в snap программа упаковывается со всеми своими зависимостями в один файл. Никаких дополнительных файлов, одно приложение - один файл. Для запуска программы не нужно ничего устанавливать, просто скачайте программу из интернета, сделайте исполняемой и запустите. Все. Никакие файлы из корневой файловой системы не будут изменены.

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

Для создания AppImage используется утилита appimagetool. Перед использованием инструмента вам необходимо скопировать все файлы и библиотеки, необходимые программе в специальную папку и сделать конфигурационный файл. Если делать сравнение Flatpak vs AppImage, то там все как-то более организовано и не нужно засорять свою систему.

Что такое Flatpak?

Flatpak - это тоже относительно новая система технология портативных приложений, поддерживаемых в любом дистрибутиве, созданная командой разработчиков GNOME. Раньше этот формат пакетов назывался XDG, но потом был переименован во избежание конфликтов. Он разработан, чтобы изолировать приложения от вашей системы и один от другого. Работает все больше похоже на Snap чем на AppImage. Приложение тоже выполняется в изолированном контейнере, что обеспечивает максимальную безопасность. Но подход к библиотекам здесь немного отличается. Они могут находиться в одном пакете вместе с приложением, или же находится в окружениях, общих для нескольких пакетов, такой подход гибче чем snap, и позволяет программе занимать не так много места.

В отличие от Snap, Flatpak ориентирован больше на децентрализацию. Здесь нет одного центрального репозитория или контролирующего органа. Snap пакеты контролируются Canonical, и чтобы добавить свой пакет в репозиторий нужно подписать соглашение. Flatpak работает подобно тому, как PPA в Ubuntu. Вы находите репозиторий, подключаете в систему и можете устанавливать оттуда программы.

Flatpak можно использовать в большинстве дистрибутивов, так же как и Snap. Создавать Flatpack пакеты можно подобным образом, как и snap. Тоже нужно отредактировать файл конфигурации, правда тут все немного проще. Про установку и использование Flatpak читайте здесь.

Выводы

Мы рассмотрели Snap vs Flatpak vs AppImage. Уже сейчас можно, сказать, что AppImage отходит на задний план и гонка за лидерство происходит между Snap и Flatpak. Appimage предоставляет простоту запуска программ, но здесь нет таких важных возможностей, как безопасность, а без этого сейчас никуда. Flatpak разрабатывается командой Gnome, и у них интересная затея, но за Snap взялась компания Canonical, они будут использовать эту технологию не только для обычных компьютеров, но и для серверных решений. Что будет лучше и более удобно пользователям покажет время. А вы используете портативные приложения?

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

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

Чтобы стать более опытным пользователем в Linux нужно понять, каким образом основные дистрибутивы обрабатывают пакеты программного обеспечения. Поэтому тема сегодняшней статьи - обзор пакетных менеджеров Linux. Мы рассмотрим основные пакетные менеджеры Linux. Главная цель, предоставить основную информацию об этих пакетных менеджерах, но об их использовании будет сказано только несколько слов.

1. DPKG - система управления пакетами Debian

Dpkg - это базовая система управления пакетами в Debian. Может использоваться для установки, удаления, хранения и получения информации о .deb пакетах.

Это инструмент низкого уровня и есть дополнительные утилиты, которые помогают пользователям устанавливать пакеты из репозиториев, разрешать зависимости и искать пакеты по названию. Это такие программы, как:

APT (Advanced Packaging Tool)

Очень популярный, мощный инструмент командной строки с открытым исходным кодом для управления пакетами, который намного увеличивает возможности dpkg. Эта утилита используется в Debian и его производных, таких как Ubuntu, Linux Mint. Я уже писал про apt на этом сайте.

Aptitude Package Manager

Это еще одна популярная утилита командной строки для управления пакетами в Debian. Она работает аналогично Apt, но между ними есть некоторые различия. Первоначально он был разработан для Debian, но сейчас может применяться и в Red Hat дистрибутивах.

Synaptic

Synaptic - это графический менеджер пакетов linux, написанный на GTK и использующий apt в качестве бэкенда. Он отлично подходит для пользователей, которые не хотят работать в командной строке. Здесь есть все те же необходимые функции что и в apt.

Gnome Software

Это центр приложений Gnome. Там есть далеко не все программы, которые есть в репозиториях и подход к установке немного другой. Вы устанавливаете не пакеты по отдельности, а саму нужную программу. Обо всём остальном центр приложений заботиться сам, скрывая от вас подробности. Gnome Software поддерживает не только Deb пакеты, но и Rpm в системах, основанных на RHEL, а также snap и flatpack, о которых мы поговорим ниже.

AppGrid

Простенькая альтернатива для центра приложений Ubuntu. Программе очень далеко до функциональности Synaptic. Она позволяет устанавливать приложения так же, как и центр приложений Gnome Software и выглядит очень похоже на Windows Store.

2. RPM (Red Hat Package Manager)

Это базовый формат и система управления пакетами, созданная в компании Red Hat. Так же как и dpkg, это низкоуровневый инструмент, для которого существует несколько утилит, это такие пакетные менеджеры Linux:

YUM (Yellowdog Updater, Modified)

Это популярный менеджер пакетов linux с открытым исходным кодом для командной строки. Он используется для управления пакетами в дистрибутиве Red Hat. Если сравнивать с инструментом apt, то здесь есть все те же функциональные возможности, правда, работает немного медленнее. Написан на Python 2. Немного больше об отличиях формата пакетов rpm и deb можно прочитать в отдельной статье. А про сам Yum есть такая статья.

DNF – Улучшенный Yum

Это пакетный менеджер linux, используемый в дистрибутиве Fedora начиная с версии 18. Он представляет из себя следующее поколение YUM.

Сначала он был создан только для экспериментов, но начиная с Fedora 22 он используется как пакетный менеджер по умолчанию. Он работает почти также как и YUM, для разрешения зависимостей используется библиотека libsolv и hawkey, но отличие от YUM, написан на Python 3. Здесь можно наблюдать увеличение скорости работы, а также уменьшение потребления памяти.

3. Pacman - менеджер пакетов Arch Linux

Этот менеджер пакетов linux разработан командой программистов для дистрибутива ArchLinux. Сейчас, кроме ArchLinux, он используется в Manjaro и еще нескольких малоизвестных дистрибутивах, основанных на ArchLinux.

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

Программа специально спроектирована для удобной работы с пакетами в Arch Linux. А поскольку это система с режимом выпуска в виде роллинг релизов, то этот пакетный менеджер подходит наилучшим образом. Pacman поддерживает систему в актуальном состоянии синхронизируя списки пакетов из основного сервера. Причем существует только одна версия системы - текущая.

Программа написана на Си, а в качестве пакетов используются файлы формата tar.xz, которые на самом деле являются обычными архивами, внутри которых находятся файлы программы и файл описания установки PKGBUILD. Читайте подробнее про установку пакетов в Arch Linux в отдельной статье.

4. Zypper - пакетный менеджер OpenSUSE

Это пакетный менеджер linux для командной строки в дистрибутиве OpenSUSE и SUSE Linux. Разработан специально для этого дистрибутива и использует библиотеку libzypp, в которой реализованы такие общие возможности, как доступ к репозиторию, установка пакетов, разрешение зависимостей, работа с репозториями и многое другое.

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

5. Portage - пакетный менеджер Gentoo

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

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

6. Snap

Универсальный менеджер пакетов разработанный в Canonical, который можно использовать как в Deb, так и в Rpm дистрибутиве. Здесь используется особый формат пакетов, в котором все зависимости программы упаковываются в пакет с ней, поэтому программа оказывается самодостаточной и может запускаться в любой системе, где установлен этот пакетный менеджер. Кроме того, менеджер пакетов snap добавляет безопасности, программам не разрешено использовать те функции, что им не нужны. Более подробно про snap можно почитать в этой статье.

7. Flatpack

Пакетный менеджер Flatpack разработан для Fedora в качестве конкурента для Snap. Он может практически всё то же самое. В пакет программы упаковываются всё её зависимости и она может работать в любой системе где установлено программное обеспечение Flatpack. Безопасность здесь тоже работает. Главное отличие в том, что Flatpack более открыт, чтобы добавить пакет в Snap Store надо подписать соглашение с Canonical, а Flatpack больше похож на формат PPA. Любой человек может создать свой репозиторий и размещать там всё, что ему надо.

Выводы

Как я уже говорил, основная цель статьи - обзор пакетных менеджеров linux, познакомить пользователей с лучшими пакетными менеджерами, а также показать отличия между ними. Конечно, пользователям определенного дистрибутива придется изучать свой менеджер пакетов более детально. Если я упустил важный момент, об одной из программ, напишите в комментариях!

Читайте также: