Die Zukunft von Flatpak könnte Distributionen ohne Systemd ins Hintertreffen geraten lassen

Das künftige Sandboxing-Konzept von Flatpak könnte sich stärker auf systemd-Dienste stützen, was Fragen hinsichtlich der Kompatibilität mit Systemen aufwirft, die nicht auf systemd basieren.
Eine Übersetzung von 🇬🇧 Linuxiac.com

Flatpak-Entwickler diskutieren derzeit über umfassende architektonische Änderungen, die systemd zu einem zentralen Bestandteil des Sandboxing-Modells der nächsten Generation von Flatpak machen könnten, was Fragen hinsichtlich der langfristigen Kompatibilität des Projekts mit Linux-Distributionen ohne systemd aufwirft.

Im vergangenen November veröffentlichte Sebastian Wick, ein Flatpak-Betreuer, ein Projekt-Update. Er merkte an, dass sich die Entwicklung verlangsamt habe, nachdem sich einige Betreuer zurückgezogen hatten, doch seitdem habe die Aktivität wieder zugenommen, wobei der Fokus nun erneut auf ausstehenden Merge-Anfragen, OCI-Unterstützung, vorinstallierten Anwendungen und der Berechtigungsverwaltung liege.

Die größte Sorge gilt der langfristigen Ausrichtung von Flatpak Next, einer frühen Designinitiative für eine zukünftige Architektur, die zu einer umfassenden Neugestaltung im Stil von Version 2.0 führen könnte. Wick und Adrian Vovk diskutierten dies vor einigen Tagen öffentlich auf dem Linux App Summit 2026.

Ein Schlüsselelement dieser zukünftigen Arbeit ist systemd-appd, eine vorgeschlagene systemd-Komponente, die Informationen über laufende Anwendungsinstanzen bereitstellen soll. Wick erklärt, dass systemd-appd die Authentifizierung von Flatpak-Instanzen unterstützen, verschachtelte Sandboxing-Umgebungen ermöglichen, die PipeWire-Integration verbessern und schließlich das aktuelle D-Bus-Proxy-Modell von Flatpak ersetzen soll.

Dies ist von Bedeutung, da die derzeitige Architektur von Flatpak mit einigen Einschränkungen daherkommt. In früheren Entwurfsdokumenten wird darauf hingewiesen, dass Flatpak systemd bereits anweist, Anwendungsinstanzen den entsprechenden cgroups zuzuweisen, obwohl dieser Schritt derzeit ohne Folgen fehlschlagen kann. Zukünftige Entwürfe erfordern möglicherweise eine cgroup für jede Anwendungsinstanz, die entweder von systemd oder direkt verwaltet wird, um die Identitäts- und Metadatenverfolgung von Anwendungen zu unterstützen.

Die technische Motivation ist klar: Flatpak benötigt robustere Methoden, um laufende Anwendungen zu identifizieren, Berechtigungen zu verwalten, verschachtelte Sandboxes zu unterstützen und sich in Desktop-Dienste wie Portale und PipeWire zu integrieren. Diese Verbesserungen sind besonders wichtig für komplexe Anwendungen, darunter Browser und Apps mit interner Sandboxing-Funktion.

Diese vorgeschlagene Ausrichtung wirft jedoch eine heikle Frage im Linux-Ökosystem auf: Soll eine distributionsübergreifende Anwendungsplattform von systemd abhängig sein? Wie zu vermuten ist, betrifft diese Sorge in erster Linie Nicht-systemd-Distributionen wie Alpine, Void, Devuan und andere, die systemd bewusst meiden.

Derzeit ist Flatpak eher mit dem breiteren Linux-Desktop als mit einer bestimmten Distributionsfamilie verbunden. Sollten zukünftige Flatpak-Versionen systemd-appd ohne kompatible Alternative erfordern, müssen diese Distributionen möglicherweise Downstream-Patches anwenden, eine Ersatzschicht pflegen oder auf die vollständige Flatpak-Unterstützung verzichten.

🎓 Schließlich ist es wichtig zu beachten, dass Flatpak derzeit in stabilen Versionen kein systemd-appd benötigt und systemd-appd noch keine fertige oder weit verbreitete Komponente ist.

Die aktuelle Diskussion betrifft die zukünftige Architektur, insbesondere Flatpak Next, und die Arbeiten, die Entwickler für notwendig halten, um seit langem bestehende Designbeschränkungen zu beheben. Allerdings wird das Sandboxing der nächsten Generation auf einer Infrastruktur aufgesetzt, die es deutlich schwieriger machen könnte, systemd zu umgehen.

Spendieren Sie Bobby einen ☕ Ko-fi

s3n🧩net wünscht viel Vergnügen