Flatpak wird künftig voraussichtlich von systemd abhängen

• Flatpak hat bislang mit dem Vorteil geworben, „Apps für jede Distribution zu bauen“, doch in der nächsten Hauptversion dürfte eine Abhängigkeit von systemd entstehen
• Flatpak Next oder Flatpak 2.0 ist eher ein Neuentwurf als eine einfache Weiterentwicklung, um die jahrzehntealten Designgrenzen von 1.x zu überwinden, befindet sich aber noch in der Planungsphase
• Der neue Dienst systemd-appd übernimmt eine Schlüsselrolle: Er speichert App-Identifikatoren und Berechtigungen, stellt diese anderen Komponenten zur Abfrage bereit und ermöglicht Sub-Sandboxing
• Für Distributionen ohne systemd gab es zwar Spielraum für eine eigenständige Daemon-Implementierung wie elogind, doch nach der eskalierten Debatte scheint die Bereitschaft der Entwickler zur Rücksichtnahme nachgelassen zu haben
• Wenn die systemd-Abhängigkeit strenger wird, könnte die Nutzung von Flatpak auf Distributionen wie Void, Guix und Alpine erschwert werden, und auch die Distributionsneutralität könnte darunter leiden

---

Mögliche Veränderung von Flatpaks Distributionsneutralität

• Die Flatpak-Website nennt als ersten Vorteil „Build for every distro: create one app and distribute it to the entire Linux desktop market.“ und führt in der Liste unterstützter Distributionen auch Void Linux, Guix und Alpine auf, die statt systemd andere Init-Systeme verwenden
• Derzeit müssen sich Flatpak-Nutzer nicht darum kümmern, welches Init-System sie verwenden, doch in der nächsten Hauptversion dürfte eine Abhängigkeit von systemd entstehen
• Falls diese Änderung tatsächlich eingeführt wird, ist die zentrale Frage, ob Distributionen ohne systemd Flatpak weiterhin anbieten können

Flatpak Next und die Richtung des Redesigns

• Arian Vovk und Sebastian Wick hielten auf dem Linux App Summit einen Vortrag über die Zukunft von Flatpak
• Die aktuelle Flatpak-Version soll zwar weiter verbessert werden, doch es wird zunehmend schwieriger, die Grenzen des jahrzehntealten Designs zu umgehen
• Das unter dem Namen Flatpak Next oder Flatpak 2.0 laufende Vorhaben kommt faktisch einem Neuentwurf gleich, der die seit Flatpak 1.x gesammelten Erfahrungen berücksichtigt
• Das neue Design soll moderne Technologien und Ideen nutzen, die sich seit dem ursprünglichen Entwurf von Flatpak etabliert haben
• Der Vortrag beschreibt bislang nur Planungen; da noch keine einzige Codezeile geschrieben wurde, kann sich das Ergebnis in den kommenden Jahren der Entwicklung noch stark verändern

systemd-appd und die Verlagerung der Berechtigungsverwaltung

• Eine der wichtigsten Änderungen in Flatpaks Entwicklungsrichtung ist die Verlagerung der Berechtigungsverwaltung aus dem Inneren von Flatpak in eine Service-Ebene
• Der neue Dienst systemd-appd weist Anwendungen Identifikatoren zu, speichert Berechtigungen und ermöglicht anderen Komponenten des Systems, diese Daten abzufragen
• Diese Struktur macht mehrere Funktionen möglich; besonders wichtig ist dabei Sub-Sandboxing (subsandboxing)
• Der aktuelle Plan ist, diese Funktion in die heutige Flatpak-Version einzuführen, wodurch für Flatpak eine systemd-Abhängigkeit entsteht

Spielraum für Distributionen ohne systemd

• Laut Vovks Erklärung gab es die Absicht, gegenüber Distributionen und Nutzern ohne systemd „sehr rücksichtsvoll“ zu sein
• Ein naheliegendes Modell wäre ähnlich wie bei systemd-logind, das als separater Daemon elogind ausgelagert wurde, sodass Distributionen mit anderen Init-Systemen trotzdem Desktop-Umgebungen nutzen können, die von systemd-logind abhängen
• Auch die Flatpak-Entwickler scheinen versucht zu haben, bei systemd-appd möglichst viel realistischen Spielraum für eine ähnliche eigenständige Daemon-Implementierung zu lassen
• Wäre dieser Ansatz beibehalten worden, hätte Flatpak vermutlich auch auf Distributionen ohne systemd weiter angeboten werden können

Eskalierende Debatte und veränderte Reaktion der Entwickler

• Nutzer von Distributionen wie Void oder Alpine äußerten die Sorge, dass Flatpak auf ihren Systemen nicht mehr funktionieren könnte, falls es stark von systemd abhängig wird
• Fragen häuften sich an eine Person, die technisch nicht an der Flatpak-Entwicklung beteiligt war, und ihre Antworten waren teils nicht hilfreich, beleidigend oder provozierend
• Da viele irrtümlich annahmen, diese Person sei an der Flatpak-Entwicklung beteiligt, verschärfte sich die Lage durch die Vermischung aus ernsthaften, freundlichen Fragen und heftigen Reaktionen mit anti-systemd-Tendenz
• In der Folge zeigten die Flatpak-Entwickler in einer Reaktion, dass sie keine Zeit darauf verwenden möchten, auf Distributionen und Nutzer ohne systemd Rücksicht zu nehmen
• Wenn sich diese Entwicklung fortsetzt, dürfte die systemd-Abhängigkeit strenger werden, und eine eigenständige Daemon-Implementierung, die systemd-appd nachbildet, könnte deutlich schwieriger werden als ursprünglich erwartet

Erwartete Folgen und Bedeutung

• Nach der aktuellen Lage ist es wahrscheinlich, dass Flatpak in den kommenden Jahren eine Abhängigkeit von systemd bekommen wird
• Ebenso ist es möglich, dass Rücksicht darauf entfällt, eine eigenständige Alternative zu schaffen, die auf Distributionen ohne systemd die Funktionen von systemd-appd ersetzt
• In diesem Fall könnte Flatpak kaum noch mit seiner Distributionsneutralität werben, also damit, mit einer einzigen App alle Distributionen bedienen zu können
• Da Flatpak ein Werkzeug ist, das unabhängig vom verwendeten Init-System eine reale Nachfrage hat, würde diese Änderung den Verbreitungsradius von Linux-Desktop-Anwendungen direkt beeinflussen

[GN⁺]

Lobste.rs-Kommentare

• Ich verstehe nicht, warum systemd so sehr gehasst wird. Meiner Meinung nach bietet es nützliche Funktionen mit einer einfach zu handhabenden API und einem sinnvollen Abhängigkeits- und Konfliktmanagement
  Diejenigen, die systemd nicht mögen, nennen oft nur vage Gründe wie „nicht Unix-artig“, „zu zentralisiert“ oder „das Dateiformat von systemd-journald ist kein Plaintext“
  Wenn man dagegen ist, würde ich gern konkrete Gründe und Lösungen hören und warum andere Init-Systeme besser sein sollen. Dann kann ich erklären, warum rc-Skripte ein furchtbar chaotischer Hack sind

  • Ein großer Teil der verlinkten Mastodon-Debatte ist im Kern weniger gegen systemd als vielmehr gegen Zentralisierung. Wenn Flatpak von systemd abhängt, verlieren Linux-Varianten mit anderen Init-Systemen den Zugang zu Flatpak
    Die Linux-Philosophie drehte sich zumindest für mich immer grundlegend um Wahlfreiheit, und wenn Flatpak ein bestimmtes Init-System verlangt, haben Nutzer weniger Auswahl bei der Konfiguration ihres Systems, um das gewünschte Ergebnis zu erreichen
  • Ich nutze systemd gern, aber im Fall von Flatpak kann ich den Widerstand nachvollziehen. Flatpak ist im Kern etwas, das „auf jeder Linux-Distribution funktionieren soll“, und eine Abhängigkeit von systemd schmälert diesen Nutzen ein Stück weit
  • Mein unbearbeiteter Frust mit systemd sieht etwa so aus: Die journald-Implementierung gefällt mir nicht besonders, aber die Idee selbst ist okay, und bei der eigentlichen Abstraktion, mit der systemd Units verwaltet — der Job Queue — gibt es seltsame Grenzfälle, die nicht dokumentiert sind oder sich nur schwer finden lassen
    Es sollte leichter in Container-Images unterzubringen sein, und user systemd sollte Lesezugriff auf die API der Systeminstanz haben, damit man Units zumindest mit Dingen wie After und Requires einplanen kann
    Trotzdem halte ich es für das Beste, was Linux seit der Entfernung von HAL passiert ist, und ich habe Lennart sogar schon die Hand geschüttelt, um ihm für das Projekt zu danken
  • Projekte wie Chimera, die tatsächlich einen glaubwürdigen alternativen Stack implementieren, verbreiten kein FUD und treten freundlich und bescheiden auf. Dagegen hat der Online-Wutmob ausdrücklich keine Lösung und wird auch künftig keine haben
    Was diese „Gegner“ praktisch fordern, kommt eher der Haltung nahe, dass überhaupt keine Lösung existieren sollte. Sie benehmen sich wie eine HOA für Linux und wirken auf mich eher wie reaktionäre Politik, die den Fortschritt behindert, mit dem tatsächlich solide, benutzbare und konkurrenzfähige Systeme proprietäre Betriebssysteme verdrängen könnten
  • Ich hasse systemd nicht, wenn es nur auf Systemen eingesetzt wird, die Webseiten bereitstellen oder Webseiten in einem GUI-Browser anzeigen. Auch systemd-Units direkt für Deployments auf einem VPS zu verwenden, ist für mich okay; mit SysV init oder upstart hätte ich ebenfalls kein großes Problem gehabt
    Auf einem Laptop will ich aber etwas anderes. Ich habe bestimmte Vorstellungen davon, wie meine persönliche Umgebung funktionieren soll, möchte auch Komfortfunktionen, die normale Linux-Nutzer vielleicht nicht wollen, und ich möchte nicht, dass Dinge passieren, um die ich nicht ausdrücklich gebeten habe. Ich hasse den Aufwand, etwas nicht funktionieren zu lassen, viel mehr als den Aufwand, etwas zum Laufen zu bringen
    Der Hauptgrund, warum ich NixOS wegen systemd verlassen habe, war der ständig wachsende Umfang und die meinungsstarken Defaults. Mit integrierter Energieverwaltung und Login-Verarbeitung musste ich immer wieder korrigieren, dass das Schließen des Deckels automatisch Suspend auslöst; Änderungen am Geltungsbereich von linger haben nohup und screen kaputtgemacht, die von POSIX verlangt werden; und eine strengere VT-Verwaltung zwang dazu, Dinge wie „einmal einloggen und mehrere Xorg-Instanzen starten“ oder „ein VT abgreifen“ im systemd-Stil neu zu entwerfen
    Am Ende kam ich zu dem Schluss, dass ein minimales Init wie sinit und gar keine Dienstüberwachung besser sind, und schrieb meine Shell-Boot-Skripte selbst; einige Systemfunktionen implementierte ich in der Shell, andere in Common Lisp. Auf einem Laptop laufen Dinge wie PostgreSQL, wenn sie einmal gestartet sind, einfach weiter; wenn sie stoppen, merke ich das, und wenn ein Neustart reicht, ist es simpel, und wenn er nicht reicht, kann auch ein Service Supervisor nicht helfen
    Beispiele für verlorenes Vertrauen sind: journald auf einer HDD zeigte bei kaltem Cache auch nach Minuten keine Logs an; ich war selbst von https://github.com/systemd/systemd/issues/2913 betroffen; und man schien keine Skrupel zu haben, nohup kaputtzumachen
    Auch im Entwicklungsprozess hat mein Vertrauen gelitten, etwa durch eine Haltung wie in https://github.com/systemd/systemd/issues/437, die auf mich wirkte wie „wir liefern gute Defaults, aber wenn die Defaults schlecht sind, kann die Distribution sie ja ändern“, sowie durch Einstellungen wie in http://lists.freedesktop.org/archives/systemd-devel/…, wo man sich vor dem Versprechen stabiler APIs drückt
    Allerdings sind das alles alte Beschwerden. Nachdem ich gesehen hatte, wie systemd manche Probleme löst und zugleich andere schafft, die beide nicht meine ursprünglichen Probleme waren, bin ich auf dem Laptop zu Shell-Skripten fürs Booten gewechselt, und die laufenden Kosten, das einfach so beizubehalten, sind jetzt so niedrig, dass ich keinen Grund sehe, systemd noch einmal auszuprobieren. Auf dem VPS nutze ich systemd innerhalb des vertrauten Rahmens von Debian

• Es ist frustrierend, dass diese Sache von jemandem, der kein Flatpak-Entwickler ist, mit Fehlinformationen angestoßen wurde, dann emotionale Reaktionen auslöste und im Verlauf des ursprünglichen Threads immer schärfer formuliert wurde, sodass Leute auf das Flatpak-Projekt und den Ruf seiner Entwickler losgingen
  Daher überrascht es mich auch nicht, dass die eigentlichen Flatpak-Entwickler emotional davon betroffen waren und Abstand zu der wütenden Menge gewinnen wollten
  Ich hoffe, alle beruhigen sich und blasen die Sache nicht weiter auf. Wenn es Zweifel oder Bedenken gibt, sollte man mit den tatsächlichen Maintainers sprechen, Unterstützung dafür zeigen, einen Mittelweg zu finden, und deutlich machen, dass dies ein isolierter Vorfall einzelner Personen ist und nicht die gesamte Community repräsentiert
  So wie die Idee einer systemd-Abhängigkeit noch nicht beschlossen war, sondern nur eine Idee, ist meines Erachtens auch die Möglichkeit noch nicht vom Tisch, dass die Maintainers ihre Unterstützung für vielfältigere Projekte noch einmal überdenken

• Ich hoffe, dass es den Leuten gut genug geht, um weiterhin auch Systeme zu unterstützen, die nicht unter systemd laufen. Flatpak und andere Container-Ansätze helfen Nutzern dabei, Pakete auszuführen, die sich für die Zielplattform nicht leicht bauen lassen, und wenn man bestimmte Software braucht, wäre es schön, Flatpak auch auf solchen Systemen nutzen zu können
  Container erfüllen zwar eine ähnliche Rolle, aber in ausreichend ungewöhnlichen Setups Dinge wie x11docker sauber zum Laufen zu bringen, ist unerquicklich kompliziert

  • Ich benutze Void seit über 10 Jahren zufrieden. Ich kann mich nicht einmal erinnern, wann ich mir zuletzt Gedanken über das Init-System oder die systemd-Integration gemacht habe. Danke für all die Arbeit, die in Void gesteckt wurde

• Ich nutze Void auf einem Laptop; es ist effizient zum Arbeiten und auch die Dokumentation ist ziemlich gut. Vielen Dank für all die Arbeit der Entwickler, und hoffentlich wird die Änderung bei Flatpak nicht zu belastend.

• „Das ist modernes Linux, und es gibt nur systemd.“
  Das ruft deutlich in Erinnerung, dass die Linux-Community eher WeWork als eine Gemeinschaft ist. Rundherum werden alle dafür bezahlt, von der Existenz von Red Hat abhängig zu sein, während irgendjemand GNU readline gratis hackt.

  • Es ist schwer zu sagen, dass der Beitrag an dieser Stelle falschliegt: Gemeint ist die Passage, in der es heißt, man ziehe „fanatische Anti-systemd-Red-Hat-Verschwörungstheoretiker (und Schlimmeres)“ an.

• An diesem Punkt ist es noch zu früh, um definitiv zu sagen, dass es „davon abhängig werden wird“; das wirkt stark spekulativ.

• Interessant ist, dass der Titel viel bestimmter klingt als der eigentliche Text. Viele Kommentare reagieren offensichtlich nur auf den Titel, und zum Glück nicht alle, aber dieses Phänomen ist im Internet nicht neu.
  In letzter Zeit sehe ich auf lobste.rs auch oft, dass Leute nur auf einen Titel oder auf einen einzelnen Satz in einem langen Kommentar reagieren, und das macht mir Sorgen. Meist lassen sie kaum Raum für andere Möglichkeiten als ihre erste, oft aggressive Interpretation.
  Wenn man den Beitrag liest, scheint bei der Flatpak-2.0-Debatte etwas Ähnliches passiert zu sein. Es sah so aus, als hätte man Spielraum für andere Init-Systeme lassen wollen, aber der Diskurs darum wurde schnell feindselig, sodass man es faktisch aufgegeben hat.

• Aus Sicht von jemandem, der ein alternatives Init-System nutzt, ist das wirklich frustrierend. Ich betreibe einen Laptop mit Alpine Linux und habe Flatpak genutzt, um Software auszuführen, die nur unter glibc läuft. Diese Änderung wird mich dazu bringen, diese Umgebung zu verlassen.
  Ich hasse systemd nicht. Meine Gentoo-Systeme basieren alle auf systemd. Mir gefällt nur nicht, wie systemd freie und Open-Source-Software dazu bringt, immer stärker von GNU/Linux abhängig zu werden.

• Das ist eindeutig etwas Gutes.
  systemd besteht aus Daemons mit stabilen, wohldefinierten APIs, daher sollte jeder Teil von systemd, von dem Flatpak künftig abhängt, mit genügend Aufwand sauber von Grund auf neu implementiert werden können.
  Das ist das bestmögliche Ergebnis. Fragmentierung nimmt ab, und Menschen mit speziellen Anforderungen bekommen ein stabiles Ziel für Reimplementierungen.

  • Ich habe zuerst weitergelesen, weil ich dachte, es sei Satire, aber das war es nicht.
    Die systemd-APIs sind oft nur vage in Manpages definiert, und da man auf systemd-Seite nicht mit anderen Implementierungen rechnet, sind sie auch nicht in beide Richtungen stabil oder versioniert.
    Bei der notify-Socket-API ist es sogar nur in die andere Richtung stabil. Die Ergänzung von vsock-Unterstützung hat Daemons, die ohne Abhängigkeit von libsystemd implementiert wurden, faktisch kaputtgemacht. Dass dieser Bruch nicht sehr bekannt ist, liegt daran, dass vsock hauptsächlich für systemd-zu-systemd-Kommunikation über Virtualisierungsgrenzen hinweg gedacht war. Wenn das sauber entworfen worden wäre, hätte man es als Erweiterung nur für diesen Grenzfall gebaut.
    Man spricht von „Daemons“, aber in Wirklichkeit sind es überwiegend logind und systemd, und diese beiden legen die gesamte API-Oberfläche offen, weshalb die Kombinierbarkeit begrenzt ist. Das geschieht über einige DBus-Schnittstellen, inzwischen auch varlink, und eine einzelne Bibliothek.
    Um systemd zu ersetzen, muss man entweder alles als Ganzes ersetzen und das interne Modell mühsam so anpassen, dass es systemd-artige APIs exponiert, oder man muss zunächst die API-Designentscheidungen von systemd entflechten und eine Zwischenschicht mit austauschbaren Backends schaffen.
    Ich beschäftige mich seit Jahren mit diesem Problem. Viele Designprinzipien von systemd halte ich für sinnvoll, aber das aktuelle Design schiebt den meisten Menschen unnötige Komplexität nach vorn. Ein modulareres und austauschbareres Design ist möglich, und einfache, trennbare Schnittstellen ließen sich relativ leicht entwerfen oder aus Bestehendem wiederverwenden.
    Problematisch ist aber Software, die sich für eine Abhängigkeit von systemd-APIs entschieden hat. Damit sie mit etwas anderem funktioniert, muss man entweder Patches upstream unterbringen, die den an libsystemd gebundenen Funktionssupport auftrennen, oder Support für neue einzelne APIs hinzufügen; Ersteres war nie erfolgreich, und Letzteres wird wegen des Wartungsaufwands für unreife oder wenig genutzte APIs nur schwer akzeptiert.
    Oder man implementiert nur die APIs, die die Software tatsächlich nutzt. Zum Beispiel, indem man einen login1-DBus-Service verwendet, der die meisten APIs gar nicht implementiert. Aber dann kollidiert das mit anderen Implementierungen, die andere Teile der API ersetzen wollen, und man muss drei Varianten implementieren: die ursprünglich saubere API, die logind/systemd-DBus-API und noch die API für varlink.
    Langfristig könnte die Lösung ein Router sein, der die vollständige systemd- oder logind-API implementiert und dahinter auf getrennte APIs abbildet. Allerdings ist das wegen extremer Redundanz und starker systemd-Spezifik im aktuellen Design sehr komplex, wenn man es richtig machen will.
    Ob das beabsichtigt war, weiß ich nicht, aber nach dem, was systemd-Entwickler sagen, war es zumindest ein Problem, um das man sich bewusst nicht gekümmert hat. Ohne eine komplexe Zwischenschicht zu bauen oder systemd neu zu schreiben, ist es sehr schwierig, einen systemd-Ersatz zu schaffen, und selbst wenn Anwendungen nur von einem Teil der APIs abhängen, die sich als isolierte Stücke bereitstellen ließen, ist es faktisch schwer, nur einen Teil von systemd sauber zu ersetzen.
  • Stimmt es denn überhaupt noch mit der Realität überein, dass man Teile von systemd sauber von Grund auf neu implementieren kann? Im Beitrag wird elogind als Beispiel genannt.

• Mir gefällt nicht, wie viel Kontrolle Red Hat über das Linux-Ökosystem bekommt.

  • Sehe ich genauso, aber ich weiß nicht, wie viel Kontrolle Red Hat heute tatsächlich noch über systemd hat.
  • Das ist schon zwiespältig. Kontrolle zu zentralisieren ist schlecht, aber Leute dafür zu bezahlen, freie und Open-Source-Software zu entwickeln, ist gut. Und ein großer Teil der Kontrolle, die sie dadurch gewinnen, entsteht gerade daraus, dass sie Leute dafür bezahlen, freie und Open-Source-Software zu entwickeln.
    Trotzdem mildert die Tatsache, dass Red Hat freie Software angenommen hat, die Sorge über diesen Einfluss etwas ab. Wenn man auf die Technologien schaut, die im Lauf der Jahre übernommen wurden, sieht man auch Fälle, in denen sie selbst für Dinge freie und Open-Source-Upstreams geschaffen haben, die vorher keinen Upstream hatten. Besonders Dogtag PKI und 389 Directory Server fallen mir da ein.
    Insgesamt war das für das Ökosystem eher nicht schlecht, und ich würde sagen, dass sie mehr vorangebracht als beschädigt haben.

• Ich bin von dieser Debatte nicht direkt betroffen, aber hier gibt es nichts, was meine Sorgen über die weiter zunehmende unnötige Komplexität und Abstraktion auf Linux-Systemen verringern würde.
  Linux wird schnell zum Java der Betriebssysteme. Das ist wirklich traurig.