Что такое флапы linux

Обновлено: 03.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Гб, то не трагедия ли это общин в чистом виде? В каждом взятом моменте мы наблюдаем локальную оптимизацию (и решение чьего-то неудобства), но вместе, сумма этих локальных оптимизаций снижает общую оптимальность системы. На мой взгляд, больше, чем локальный выигрыш каждого из участников.

Есть комп c Linux RH 7.0, squid, ipchains + masq, samba. Две сетевухи - одна в локалку другая в интернет. Замечен следущий глюк - переодически подвисают интернет сервисы, проявляется так - зависает и отваливается ssh клиент, система перестает пинговаться, самба не отвечает, короче как буд-то выдернули сетевой шнур и буквально через несколько секунд(10-40) все само по себе востанавливается. Запустив arpwatch было вычисленно, что в момент подвисание в логе появляется запись, примерно такая:

[дата и время] 192.168.1.107 flip flops "один мак адрес" (другой мак адрес)

Это что смена mac адреса? что такое flip flops? почему это может происходить? как избежать?

А не появляется ли в сети еще одна машина с таким же адресом?

Я тоже думаю, что кто-то еще ставит себе ip сервера. Об этом надо известить администратора, который заведует раздачей ip адресов.

Скажи своему arp'у в каком-нибудь стартовом скрипте, что твой адрес перманентный /sbin/arp -s xxx.xxx.xxx.xxx aa:bb:cc:dd:ee:ff

Mar 19 08:58:23 dedicad arpwatch: flip flop 192.168.1.107 0:90:27:6a:ed:63 (0:4:76:11:3:cf) Mar 19 09:00:58 dedicad arpwatch: flip flop 192.168.1.107 0:4:76:11:3:cf (0:90:27:6a:ed:63) Mar 19 10:11:47 dedicad arpwatch: new station 192.168.1.94 0:1:3:c2:1b:f6 Mar 19 10:15:31 dedicad arpwatch: new station 192.168.1.11 0:4:76:8e:8b:cf Mar 19 10:34:37 dedicad arpwatch: new station 80.240.96.86 0:2:b3:1c:38:5c Mar 19 10:56:37 dedicad arpwatch: flip flop 192.168.1.107 0:90:27:6a:ed:63 (0:4:76:11:3:cf) Mar 19 10:56:38 dedicad arpwatch: flip flop 192.168.1.107 0:4:76:11:3:cf (0:90:27:6a:ed:63) Mar 19 11:28:57 dedicad arpwatch: new station 192.168.1.65 0:20:af:aa:bb:44 Mar 19 12:01:51 dedicad arpwatch: new station 192.168.1.7 0:4:76:21:17:be Mar 19 12:52:47 dedicad arpwatch: flip flop 192.168.1.107 0:90:27:6a:ed:63 (0:4:76:11:3:cf) Mar 19 12:54:06 dedicad arpwatch: new station 192.168.1.1 0:50:bf:61:29:b2 Mar 19 12:54:06 dedicad arpwatch: flip flop 192.168.1.107 0:4:76:11:3:cf (0:90:27:6a:ed:63) Mar 19 13:56:58 dedicad arpwatch: new station 192.168.0.3 0:4:75:81:f1:8b Mar 19 13:58:34 dedicad arpwatch: new station 192.168.2.3 0:4:76:1c:a7:21 Mar 19 14:00:29 dedicad arpwatch: new station 192.168.1.43 0:4:75:81:f1:8b Mar 19 14:41:30 dedicad arpwatch: flip flop 192.168.1.107 0:90:27:6a:ed:63 (0:4:76:11:3:cf) Mar 19 14:42:14 dedicad arpwatch: flip flop 192.168.1.107 0:4:76:11:3:cf (0:90:27:6a:ed:63)

Скажу сразу физически внешняя и внутрення сети объеденены, т.е. нет разницы этот провод внешняя сеть, тот внутренняя.

Мой ответ подразумевал только то, что должен перестать падать интерфейс.
Я не понял, что такое "внешняя и внутрення сети", ведь изначально писалось
"Две сетевухи - одна в локалку другая в интернет", но, если я хоть что-то понял,
попробуй (в тех же стартовых скриптах, не забудь и ручками, если не рестартуешь)
echo "1" > /proc/sys/net/ipv4/conf/eth. /rp_filter (с многоточием сообразишь?), если
"внешняя и внутрення сети" несколько различаются, то будет кайфово.

Огромное спасибо, кажется заработало, вот уже несколько часов подряд пашет как часы :))))). А "внешняя и внутренняя" сети это интернет и локалка соответственно.

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

Представьте, что у вас десятки устройств. Или, например, один из линков между свитчами начинает непрерывно флапаться (это не редкость, особенно при использовании некоторых типов мультиплексоров). Что произойдет? В общем случае, вы получите нечто, похожее на Email Bomb. По этой причине я и мой коллега Павел начали работу над проектом, который мы назвали FlapMyPort.

Получает SNMP-трапы
Собирает эти данные в БД (как для истории, так и для мгновенного анализа)
Анализирует информацию на ходу, предотвращая избыточные уведомления
Позволяет просматривать историю за нужный период и фильтровать вывод
Коммуницирует с мобильными клиентами (о них будет позже)
Генерирует удобные графики

Компонент 1: TrapHarvester

И если произойдет 20 флапов, вы получите 80 писем. А вот как выглядит почтовый ящик в аналогичной ситуации, но с применением TrapHarvester:

Компонент 2: Клиентские приложения

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

Внизу будут даны ссылки на скачивание приложений из соответствующих магазинов (App Store, Google Play), чтобы вы могли попробовать как это работает.

FlapMyPort WEB (HTML, CSS, Angular)
Веб-клиент, получающий данные из API. Как он работает вы можете попробовать прямо сейчас, перейдя по ссылке.

Все флапы в демо-версии не настоящие, они берутся из Virtual API, о котором чуть позже.

FlapMyPort для iPhone (Objective C)
Второе приложение, которое я создал под этот проект, можно загрузить из AppStore. По умолчанию, после установки вы увидите все те же демо-данные из Virtual API.

FlapMyPort для Mac (Objective C)
Десктопное приложение, которое еще больше повышает удобство мониторинга. К тому же, оно начинает прыгать и издавать «падающие» звуки, когда обнаруживает новое событие в сети. А еще из него удобно «копипастить» информацию.

FlapMyPort для Android (Java)
Комплект не был бы полным без приложения под Android, которое любезно написал мой коллега Павел. Теперь оно так же доступно в Google Play.

Компонент 3. FlapMyPort API

Третий ключевой компонент отвечает за коммуникацию с клиентскими приложениями. По сути, принимает запросы от приложений, ходит в базу, рисует графики и возвращает данные в виде JSON-ответа. API написано на PHP.

Virtual API

Для удобства разработки новых клиентов, копия API была размещена в публичном доступе. Код был слегка модифицирован так, чтобы на любой запрос Virtual API выдавало какие-нибудь события. Свежеустановленные приложения и демонстрационная версия Веб-приложения по умолчанию получают данные как раз из Virtual API. Увидеть JSON, который генерирует Virtual API можно здесь.

Я думаю, что неплохой идеей будет наблюдать за ошибками на порту или уровнем сигнала на оптическом ресивере. Если сравнивать эти показатели до и после каких-либо флапов, можно заметить полезную динамику.

Любые ваши идеи будут мне полезны и, возможно, появятся в новых версиях системы.

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

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

Если вам интересно попробовать систему, не стесняйтесь писать мне по любым вопросам, мои контактные данные на сайте проекта. Я всегда рад помочь с внедрением, а так же готов получить bug-reports и feature-requests. Это вдохновит меня на дополнение/улучшение FlapMyPort.

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

Установить приложение в Linux так же просто, как открыть Центр программного обеспечения, найти и установить его. Приложения, недоступные в магазинах приложений, можно установить с помощью пакетов DEB или RPM. Некоторые из них доступны через PPA (для дистрибутивов на базе Debian), а если ничего нет, то можно собрать из исходного кода.

Однако здесь есть некоторые ограничения. Магазины App Store обычно не имеют последних выпусков приложений, работа с зависимостями может быть утомительной, а PPA не всегда безопасны! Кроме того, сборка из исходного кода требует некоторой работы с терминалом.

При наличии нескольких дистрибутивов Linux и систем управления пакетами возникла необходимость в универсальной системе упаковки, которая могла бы запускать приложение независимо от того, какой дистрибутив Linux вы используете. Компания Canonical подумала об этом и создала Snaps. Существует также независимый универсальный пакет программного обеспечения под названием AppImage, с помощью которого вы загружаете приложение и запускаете его без фактической установки приложения.

Наряду с Snaps и AppImage существует еще одна универсальная пакетная система под названием Flatpak. Мы рассмотрим, как установить и использовать Flatpak в большинстве дистрибутивов Linux, а также его преимущества.

Что такое Flatpak?

Основные преимущества Flatpak

Помимо предложения единого пакета для различных дистрибутивов Linux, Flatpak предлагает интеграцию в рабочие столы Linux, что упрощает просмотр, установку и использование приложений Flatpak, например, для установки Flatpak можно использовать Gnome Software Center.

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

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

Хотя Flatpak предоставляет централизованный сервис для распространения приложений, он полностью поддерживает децентрализованное распространение приложений.

Как использовать Flatpak в Ubuntu и других дистрибутивах Linux

Установка Flatpak на Ubuntu и Linux Mint

В Linux Mint и Ubuntu, Flatpak поддерживается по умолчанию. Однако вы можете проверить это, попробовав установить Flatpak еще раз:

sudo apt install flatpak

Установка Flatpak в Debian, Ubuntu, Elementary OS и другие дистрибутивы на базе Ubuntu

Дистрибутивы на базе Debian могут использовать официальный PPA для установки Flatpak. Откройте терминал и выполните следующие команды:

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

Установка Flatpak в дистрибутивы Linux на базе Red Hat и Fedora

Чтобы установить Flatpak в Red Hat и Fedora, достаточно ввести следующую команду:

sudo yum install flatpak

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

Чтобы включить поддержку Flatpak в дистрибутивах Linux на базе openSUSE, используйте следующую команду:

sudo zypper install flatpak

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

Чтобы включить поддержку Flatpak в дистрибутивах Linux на базе Arch, выполните следующую команду:

sudo pacman -S flatpak

Включение поддержки приложений Flatpak в Software Center

Приложениями Flatpak можно полностью управлять через командную строку. Но не всем нравится использовать командную строку для установки приложений, поэтому включение поддержки Flatpak в программном центре GNOME станет спасением.

В некоторых дистрибутивах, таких как Pop!_OS 20.04, вы найдете Flatpak интегрированным в программный центр. Таким образом, вам не нужно ничего отдельно делать.

Однако, если у вас нет интеграции Flatpak по умолчанию, вам понадобится программный плагин GNOME для установки flatpak через графический интерфейс. Для его установки в дистрибутивах на базе Ubuntu используйте следующую команду:

sudo apt install gnome-software-plugin-flatpak

Для других дистрибутивов используйте обычную команду установки пакета для установки gnome-software-plugin-flatpak. После установки перезапустите Software Center или вашу машину.

Теперь вы можете загрузить файл .flatpakref с сайта разработчика приложения или из официального магазина приложений Flatpak, Flathub.

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

Вы также можете щелкнуть правой кнопкой мыши на файле и Открыть с помощью Software Install (по умолчанию), если двойной щелчок не сработал.

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

Использование команд Flatpak (для специалистов среднего и высшего уровня)

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

Прочтите: Как установить браузер Google Chrome в Debian?

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

Добавление репозиториев для установки приложений Flatpak

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

Для этого выполните следующую команду:

Поиск Flatpak через терминал

Вы можете искать доступные приложения Flatpak с помощью опции поиска в команде Flatpak следующим образом:

flatpak search applicationname

Имя приложения не обязательно должно быть точным. Будут показаны все возможные результаты, соответствующие поисковому запросу.

Например, flatpak search libreoffice выводит стабильный выпуск LibreOffice.

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

Общий способ установки приложения Flatpak из репозитория следующий:

flatpak install <remotes> <ApplicationID>.

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

flatpak install flathub org.libreoffice.LibreOffice

Установка Flatpak Flathub

Некоторые разработчики предоставляют свой собственный репозиторий. Вы можете использовать абсолютный путь к flatpakref приложения для установки приложения или через Flathub.

Установка приложений Flatpak из файла flatpakref

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

flatpak install <ApplicationID>.flatpakref

Предположим, вы скачали файл net.poedit.Poedit.flatpakref, команда будет выглядеть следующим образом:

flatpak install net.poedit.Poedit.flatpakref

Как запустить Flatpak

Чтобы запустить приложение Flatpak, вы можете воспользоваться командой, приведенной ниже:

flatpak run <ApplicationID>

Например, если вы установили spotify, вот как будет выглядеть команда:

flatpak run com.spotify.Client

Отображение всех приложений Flatpak, установленных в вашей системе

Вы можете отобразить все приложения Flatpak, установленные в вашей системе, с помощью следующей команды:

Удаление приложения Flatpak

Вы можете использовать опцию uninstall с идентификатором приложения, чтобы удалить установленный пакет Flatpak.

flatpak uninstall <ApplicationID>

Вот как это должно выглядеть:

flatpak uninstall com.spotify.Client

Обновление всех приложений Flatpak одновременно

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

Было бы разумно время от времени чистить систему и освобождать место. Вы можете удалить неиспользуемые режимы выполнения Flatpak с помощью этой команды:

flatpak uninstall --unused

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

Устранение неполадок Flatpak

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

Устранение ошибки установки Flatpak

Если вы столкнулись с ошибкой, подобной этой:

error: runtime/org.freedesktop.Platform/x86_64/1.6 not installed

flatpak update -v

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

Что вы думаете о Flatpak?

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

Flathub для поиска приложений Flatpak

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

Что вы думаете о Flatpak и используете ли вы их? Предпочитаете ли вы его AppImage или Snaps? Сообщите нам, если вы столкнулись с какой-либо проблемой, в разделе комментариев.

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