Разработчики Flatpak собираются добавить в systemd новый компонент systemd-appd

Разработчики ненужно собираются добавить в ненужно новый компонент ненужно-ненужно!

Звучит неплохо

Ненуженки ненужно не нуждают не нуждать в ненужно ненужное ненужно ненужно-ненужно!

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

Так то уже почти все бинарные дистры превратились в какой-то сыстемдэ-срач

Sebastian Wick and Adrian Vovk…

Братья что-ли? :)

Sebastian Wick and Adrian Vovk are planning to develop «systemd-appd» as a new service-d to allow querying running app-d instances-double-d.

Fixed.

А что нужно? Клепать инсталляторы для всех возможных дистров? Есть подобный опыт? Вот например есть некий релиз и надо его выкатить в народ. И есть 20 самых популярных дистров. Что дальше? Ну сборку еще можно как автоматизировать. А тестирование? Ну автотесты не связанные с гуем еще можно, хотя и они под большим вопросом. Если их много часть все равно файлед и бегай за ними еще месяц. А те, что про юзер интерфейс? В 20 виртуалках все проверять? Не ну реально конечно если есть отдельный штат тестировщиков. Но они опять же что-нибудь обязательно найдут, ибо отличия есть, и поведение приложения тоже. И это один релиз, а так для каждого.

Мне лично нравится systemd и Flatpak, просто не мог удержаться от возможности позабавиться.

Прям с языка снял :)

Читаю это и думаю: получается, Flatpak становится зависимым от systemd и перестанет работать в Void, Gentoo, Slackware, Devuan, antiX, Artix, Alpine и прочих.

Немного жаль конечно, но пережить можно.

Flatpak разве что удобен тем, чтобы не добавлять multilib в систему - для Lutris, wine и Steam. Потому что 32-битные архитектуры убирают все кому не лень, и рано или поздно перестанут поддерживать multilib, или наступит 2038-й.

На BSD всё проще: нет Flatpak, нет проблемы. С другой стороны, Flatpak это по сути дистрибутив в дистрибутиве, и он не такой уж и секюрный, и изоляция у него дырявая.

Больше всех будут сокрушаться те, кто не использует systemd и flatpak. Хотя казалось бы, какое им дело. Парадокс.

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

Сделать бинарник, который представляет собой самораспаковывающийся архив tar.gz, что помещает нужные файлы ПО в директории внутри /usr/local или /opt, на выбор.

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

Интеграция с DE делается элементарным текстовым .desktop файлом, что размещается в /usr/share/applications/

Это не теоретические рассуждения. Грамотные люди уже много лет так пакуют ПО под Linux. StarOffice начала 2000-х легко работает на современных дистрибутивах, например.

Проблемы только у тех, кто может лишь через checkinstall собрать .deb пакет под ту Ubuntu LTS, где он разрабатывает.

Очень жду, когда в systemd добавят своё ядро и свои системные утилиты (аналог coreutils). И тогда цепь замкнётся: инит есть (systemd), загрузчик есть (systemd-boot), DE есть (GNOME), логирование есть (journald), формат распространения ПО и всякие примочки есть (flatpak, systemd-appd). Ну прям очередная никому не нужная ОС получится

представляет собой самораспаковывающийся архив tar.gz, что помещает нужные файлы ПО в директории внутри /usr/local или /opt, на выбор.

Очень удобно следить за таким:

• руками искать что и куда установлено (вместо dpkg -l)
• удалять, или обновлять (вместо apt update / remove)
• добавлять ярлыки в меню (deb postinstall может посмотреть что у тебя установлено и правильно раскидать ярлыки)
• руками обновлять PATH

Sebastian Wick and Adrian Vovk are planning to develop «systemd-appd» as a new service to allow querying running app instances. The plans for systemd-appd are for being able to authenticate Flatpak instances and working towards a goal of supporting nested sandboxing. This will also be useful for work around PipeWire, eliminating the D-Bus proxy, and other modernization work.

Три раза перечитал абзац, но так и не понял, для чего это и как будет работать

А что нужно?

Адекватом быть нужно. Есть такая штука как поддерживаемый дистр.

С другой стороны, Flatpak это по сути дистрибутив в дистрибутиве, и он не такой уж и секюрный, и изоляция у него дырявая.

Изоляция флатпака это лапша на уши. Проблема в том, что у людей недостаточно критическое мышление, и они верят в детские разводы.

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

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

А есть предложения по «правильному» подходу?

Флатпак решает по сути две несуществующие проблемы. Первая - «отсутствие системного стабильного API в линуксе». На самом деле, стабильное API есть, особенно сейчас, и оно постоянно улучшается в этом направлении. Есть базовый набор библиотек в системе, для которых обеспечивается обратная совместимость. Поэтому не составляет большого труда, делать кроссдистрибутивные бинарные сборки приложений, без всякой изоляции, которые использовали бы системные библиотеки в той части, которая является общей для всех и поддерживает обратную совместимость по API. А остальные библиотеки приложение может тянуть с собой.

Но если это предложить, люди типа фанатов флатпака начнут орать, потому что в их голове есть несуществующая задача - «каждое приложение надо сделать кроссдистрибутивным». И если так сделать, то получится дикий оверхед при подходе, который я озвучил выше. Поэтому, флатпак решает тут вторую несуществующую проблему - он уменьшает дублирование библиотек между пакетами приложений. Во-первых, он делает это очень плохо, потому что он дедуплицирует внутри себя, но он сам же дублирует библиотеки в хостовой системе. Объем занимаемый все равно получается избыточным, и сильно. Во-вторых, это делать вообще не нужно, потому что большинство, подавляющее, приложений эффективнее поставлять через классические репы, и там нет проблемы дупликации. То есть это DE наборы, базовая система, сами DE и подобные. И лишь только некоторые, жирные, самодостаточные, тяжелые приложения имеет смысл делать кроссдистрибутивными - браузеры, офисные пакеты, Steam, CAD системы типа FreeCAD, монстры типа Blender и подобное. Тогда дупликация некоторая будет, но на фоне размера этих приложений, это будут проценты, не имеют значения они.

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

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

Вопрос в лоб - нафейхоа нам на свободной ОС Линукс такие приложения, которым мы не доверяем?? А если менее радикально, то 99% приложений у нас свободные, а остальные можно в индивидуальном (!) порядке как-то огородить. Технически не составляет труда реализовать. Нафейхоа флатпак заворачивает ВООБЩЕ ВСЕ в песочницу? А потому что песочница там - не для безопасности. Она там by design, вследствие стремления решить несуществующие проблемы.

Второй вопрос - если нам надо огородить недоверенное приложение, то мы должны, по л-логике, ЗАБРАТЬ доступ к /home и ДАТЬ доступ к системным библиотекам. Системные библиотеки - это не те данные, которые мы должны не давать читать. Наши чувствительные данные - в /home. А что делает флатпак по факту? Он делает ровно наоборот! ОТБИРАЕТ систему, но дает доступ к /home!

Да, мне тут возразят что флатпак якобы не дает доступ к /home, но это полная ерунда, для того чтобы приложение работало, нужен доступ к /home и вы его дадите. Да куда вы денетесь? Включили бы голову, люди.

Первая - «отсутствие системного стабильного API в линуксе».

Системное стабильное API есть, проблема в том, что оно не кроссдистрибутивное.

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

Хорошая идея. Есть примеры как это сделать? Может опыт реализации? Вот есть приложение, сборка cmake+gcc. Что дальше? Оно запускается только там где скомпилено.

проблема в том, что оно не кроссдистрибутивное

Да нет же, кроссдистрибутивное как раз. Например, glibc, что там не кроссдистрибутивного, оно конечно разных версий, но ведь там обратная совместимость. Собранное на более старом дистрибутиве будет работать на новых. У меня вот один проект есть, я бинари собрал более 5 лет назад, и до сих пор все работает в последнем арче даже. Причем, это даже не приложение, а плагины для хостового приложения, которое все эти годы обновилось уже N раз. И о чудо - эти плагины выводят GUI! То есть, бинари с GUI запускаются на любом дистрибутиве за последние 5 лет, все работает, значит можно, как бы. А почему оно работает? Потому что все библиотеки, которые оно использует, даже (!) для GUI - обеспечивают обратную совместимость.

Есть примеры как это сделать?

Примеров достаточно, самый первый это Firefox. Его тарбол очень кроссдистрибутивен. Scilab, Steam, Blender, Ardour - это из того что я использовал либо видел. Из проприетарщины, Matlab ставится инсталлятором на любой дистрибутив, работает годами несмотря на обновления, даже в арче. У меня Matlab 2018 только в конце 2025 года протух для арча (!), а в убунте он будет и сейчас работать, скорее всего. Еще проприетарный пример - Reaper. Просто из тарбола распаковывается, работает без проблем везде.

Что дальше? Оно запускается только там где скомпилено.

Есть два условия, которые надо выполнить. Первое - собирать надо на максимально старом дистрибутиве, на котором оно может собраться. В идеале, разрабатывать так чтобы собиралось на пятилетней системе. Второе - есть библиотеки с хорошей обратной совместимостью, которая не ломается 5+ лет, (как само glibc например), есть библиотеки, в основном это плюсовые, у которых похуже. Например Qt - собранное в предыдущей минорной версии, запустится на более новой, но по мажорным там не прокатит. То есть, в пределах пары лет может работать, дальше протухнет. Такие библиотеки надо тогда паковать вместе с приложением, например все тарболы приложений на Qt, пакуют Qt внутрь.

Флатпак решает по сути две несуществующие проблемы. Первая - «отсутствие системного стабильного API в линуксе». На самом деле, стабильное API есть, особенно сейчас, и оно постоянно улучшается в этом направлении. Есть базовый набор библиотек в системе, для которых обеспечивается обратная совместимость. Поэтому не составляет большого труда, делать кроссдистрибутивные бинарные сборки приложений, без всякой изоляции, которые использовали бы системные библиотеки в той части, которая является общей для всех и поддерживает обратную совместимость по API. А остальные библиотеки приложение может тянуть с собой.

Проблема не только в системном API. Взять тот же GTK – ну и какой там «стабильный API», если люди по тысяче лет переписывали свои программы с GTK2 на GTK3, а потом тоже самое повторилось с GTK3 -> GTK4? При условии, что есть куча проектов, написанных с использованием Qt, которые могут быть собраны как с Qt4, так и с Qt5. В целом вся экосистема GNOME/GTK не блещет особой стабильностью, хотя почему-то дистрибутивы предпочитают предустанавливать именно софт, написанный с применением GTK; такого софта полно, а это уж точно говорит о том, что вся эта наркоманская лабудень (gtk, glib, etc.) востребована среди разработчиков, какой бы плохой она не была.

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

На glibc далеко не уедешь. Есть куча либ которые давно разошлись в разных дистрах, а без них никак. Большие приложения делают корпорации, они могут себе позволить тратить ресурсы на изыскания и реализацию кросс-дистрибутивности. А для остальных это не доступно, слишком много сил уйдет на переписывание, сборку, тестирование. Вот вспомнил видосик про это: https://www.youtube.com/watch?v=Z7WuUhPJ-cU.

В Gentoo systemd поддерживается. Есть даже отдельный профиль с ним. Я, правда, на Gentoo его не использовал, но знаю людей, которые пользуются и довольны.

Читаю это и думаю: получается, Flatpak становится зависимым от systemd и перестанет работать в Void, Gentoo, Slackware, Devuan, antiX, Artix, Alpine и прочих

вероятно проблема решится также как с elogind и eudev.

Есть куча либ которые давно разошлись в разных дистрах

То что разошлось, просто пакуется вместе с приложением, тут нет проблем. Я в своем проекте даже и не пакую, хватает стабильного в системе даже для GUI, но правда у меня там GUI на cairo реализован.

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

Писать сразу надо с умом, а то как виндузятники, завяжутся на .NET + WinAPI по самые помидоры, потом героически портируют Компас на линукс 10 лет.

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

Ну есть же systemd-cron, но пользоваться им никто не заставляет. Думаю вполне опционален будет, или нет?

Как ты тестишь? У тебя куча виртуалок? Даже в пределах одного дистра надо проверять на разных версиях.

Взять тот же GTK

Сувать в тарбол.

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

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

Конкретно это я собираю на виртуалке со старой Ubuntu, и на виртуалке со старым Debian. Дальше, если это работает на виртуалке и работает на текущем Арче, который у меня основная система, я экстраполирую ситуацию на все остальные версии, потому что так устроена система обратной совместимости. Я удостоверился, что обратная совместимость не сломана на текущей роллинг системе, и удостоверился что на достаточную для меня глубину по старости дистрибутива все работает. Между оно тоже работать будет. Такого практически не бывает, что совместимость сломали, а потом внезапно она опять появилась.

То есть, проще говоря, если работает на самом старом который интересует, и на самом новом - на версиях между оно тоже будет работать. Между дистрибутивами одного года заморозки, разница минимальная по либам.

Если сразу составить список либ, что берется из системы а что пакуется в тарбол с приложением, и сделать это с умом, дальше вероятность запуска на чем угодно стремится к 100%.

И лишь только некоторые, жирные, самодостаточные, тяжелые приложения имеет смысл делать кроссдистрибутивными

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

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

Сувать в тарбол

Никто не запрещает это делать. Но я писал скорее не о распространении ПО, а о нестабильном API :)

Пытался тут одну прогу запаковать в AppImage. Но вместо обычного AppImageKit решил использовать AppImage Builder. Он автоматически кладёт в AppImage необходимые зависимости. В итоге по сравнению с deb-пакетом вес AppImage был примерно в 34 (!!) раза больше. Просто потому что это чудо (AppImage Builder) решило добавить в пакет помимо нужных зависимостей (коих не так много) просто туеву хучу каких-то шрифтов и библиотек для сжатия данных. При условии что у программы нет какой-то жёсткой зависимости от конкретного шрифта (использует установленные по умолчанию обычный и моноширинный шрифты и только), а сжатием данных она не занимается и в целом никакой из её зависимостей эти либы вроде как не нужны. В общем и из AppImage пришлось весь этот мусор вычищать — 136 мб -> 11 мб. Конечно, работоспособность этого урезанного пакета ещё тестировать, но в целом на типичных Linux-дистрибутивах для десктопа оно уже должно работать.

А потом в бубунте с точно таким же обоснованием начинают всё подряд засовывать в snap.

Snap не нужен. Буду краток.

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