Съдържание на статията
Опасения за дистрибуциите с различни инит системи
Разговорите около бъдещата архитектура на Flatpak показват, че проектът може да се опре още по‑силно на systemd, което поставя под въпрос какво очаква дистрибуциите, изградени без тази инит система. Темата се превръща в ключова, защото засяга не само технически решения, а и философския баланс в Linux екосистемата.
След период на по‑бавна разработка поддръжниците на Flatpak отново активизираха работата по натрупани заявки, OCI поддръжка, предварително инсталирани приложения и по‑строго управление на разрешенията. Тази нова вълна от активности съвпада с обсъждането на Flatpak Next. Това е ранна концепция за бъдеща архитектура, която може да доведе до сериозна промяна, сравнима с версия 2.0. Именно там се появява и най‑спорният елемент: systemd‑appd.
Какво представлява systemd‑appd и защо е толкова важно
systemd‑appd е предложен компонент, който трябва да предоставя информация за работещите инстанции на приложения. Идеята е чрез него Flatpak да може да удостоверява отделните инстанции, да поддържа вложени пясъчници, да подобри интеграцията с PipeWire и в перспектива да замени сегашния D‑Bus прокси модел.
Това не е случайно, защото настоящата архитектура на Flatpak има ограничения, които стават все по‑видими при сложни приложения като браузъри или програми с вътрешно sandboxing решение. Още в предишни документи се посочва, че Flatpak вече разчита на systemd за поставяне на приложенията в подходящи cgroup, макар че при неуспех процесът продължава. В бъдеще обаче може да стане задължително всяка инстанция да има собствен cgroup, управляван от systemd или чрез директен механизъм, за да се осигури надеждна идентификация и проследяване на метаданни.
Защо това тревожи част от Linux общността
Тук се появява чувствителният въпрос: трябва ли универсална платформа за приложения да зависи от systemd?
Дистрибуции като Alpine, Void, Devuan и други, които умишлено избягват systemd, биха се оказали в неудобна позиция. Ако бъдещите версии на Flatpak изискват systemd‑appd без алтернативен слой, тези проекти ще трябва да поддържат собствени пачове, да изграждат заместител или да приемат ограничена поддръжка на Flatpak.
Това би променило съществено и ролята на Flatpak,считана за технология, асоциирана с широкия Linux десктоп, което може да се превърне в решение, което на практика обслужва само systemd‑базираните системи.
Какво е ясно към момента
Важно е да се подчертае, че в стабилните версии на Flatpak няма изискване за systemd‑appd. Самият компонент още не е завършен и не е широко внедрен.
Текущите дискусии засягат бъдещата архитектура и начините, по които разработчиците искат да решат дългогодишни ограничения. Но посоката засега изглежда е видима: следващото поколение sandboxing вероятно ще бъде тясно обвързано с инфраструктура, която прави избягването на systemd значително по‑трудно.
Повече можете да научите от официалния блог пост.
