In „Flatpak is Not the Future“ ist momentan die gesammelte Kritik an Flatpak zu lesen und wird gegenwärtig durchgereicht. Dabei ist der Blogartikel eigentlich nur eine wilde Mixtur aus tendenziösen Informationen, Mischmasch mit Kritik an Fedora und einer gehörigen Portion „Perfektion als Feind des Guten“.
Eigentlich wollte ich mich nicht dazu im Detail äußern, weil ich in einer Aufstellung zur Paketverwaltung vs. Flatpak/Snap usw. mal alles zusammengestellt habe, was man dazu meiner Meinung nach sagen muss. Da ich mich aber scheinbar in der ganzen Flatpak-Debatte exponiert habe und entsprechend oft deshalb kontaktiert werde, muss ich nun wohl doch etwas dazu schreiben, bevor ich die 20. E-Mail-Antwort dazu verfasse.
Analysegrundlage
Einige Fakten gleich mal vorweg, weil das argumentativ bei vielen immer unterschlagen wird und die ganze Diskussion ins Absurde zieht. Darum möchte ich bei dem Thema immer gerne eine gemeinsame Grundlage herstellen.
- Flatpaks und Snaps sollen die klassische Paketverwaltung nicht vollumfänglich ersetzen. Niemand hat das nirgendwo gefordert.
- Es gibt keinen Zwang zu Flatpaks / Snaps. Es kann und wird sicherlich auch zukünftig Distributionen geben, die klassisch paketieren. Zumal für speziellere Einsatzszenarien auf leistungsschwächerer Hardware. Es ist freie Software, gemacht wird, was nachgefragt wird.
- Die klassische Paketverwaltung ist nicht perfekt. Es gibt Sachen, die damit nicht oder nicht gut funktionieren und die sich deshalb als Folgewirkungen durch das Linux-Ökosystem ziehen (Stable vs. RR, inkompatible Bibliotheken, Softwareverteilung für upstream, Einsatz knapper Ressourcen bei den Distributionen usw.). Es gibt also mithin Verbesserungspotenzial bzw. Handlungsdruck. Das muss natürlich nicht bei Flatpak enden, sondern kann auch anders gelöst werden.
- Die Paketverwaltung hat nichts mit freier Software zu tun. Die BSD-Systeme sind auch freie Software und haben ganz andere Softwareverteilungsmechanismen entwickelt. Sie muss deshalb argumentativ nicht direkt auf einen Sockel neben der GPL stehen.
- Konzepte wie sogenannte „unveränderbare Systeme“ um Systeme stabil oder über komplett verifizierte Bootvorgänge sicherer zu machen, sind mit bisherigen Systeme nicht umzusetzen. Es gäbe hier sicher auch andere denkbare Ansätze als Flatpaks & Co für die Anwendungsverteilung, aber in diese Richtung geht es jetzt nun mal. Das ist wie bei Elektro vs. Wasserstoff im PKW. Es setzt sich das durch, was auch praktisch da ist und verbessert werden kann und nicht das theoretisch bessere Konzept, während die Verfechter eben jenes besseren Konzepts im Alltag praktisch beim Verbrenner stehen bleiben.
Flatpak Is Not the Future – Die Kernargumente im Detail
Warnung: Es könnte etwas knapp und leicht polemisch werden.
Ich setze für diesen Artikel explizit voraus, dass der Blogbeitrag „Flatpak Is Not the Future“ gelesen wurde, weil ich mich direkt darauf beziehe und nicht den kompletten Inhalt wiedergeben möchte.
Unter der Überschrift „Size“ ergeht sich der Autor sehr lange im Speicherplatzverbrauch. Dazu hat sich ein GNOME/EndlessOS-Entwickler bereits geäußert. Man muss halt auch andere Entwicklungen im Linux-Umfeld rezipieren und kann Flatpak nicht singulär betrachten. Jedes MB aufzurechnen und irgendwelche Low-Budget-Hardware von vor 6 Jahren oder Spezialsachen wie Raspberry Pi heranzuziehen, ist im Linux-Umfeld ein beliebtes Argument, um Entwicklung zu blockieren. Das kennen wir schon von jeder Veränderungsdebatte der letzten 20 Jahre. Deshalb hat Debian ~10 unterstützte Architekturen aber Probleme mit Sicherheitsupdates. Aber ich schweife ab, worauf ich hinaus will: Genau das Gleiche hatten wir bei der verbreiten Abschaffung der 32bit-Architektur in vielen Distributionen – hat bis auf ein paar Meckerköppe, die genau dafür wohl ihren Pentium III aus dem Keller holten, niemanden interessiert.
Das fährt letztlich in der gleichen Kategorie wie die langjährigen Klagen über den vermeintlich exorbitanten „RAM-Verbrauch“. Was man sich wohl von leerem Speicherplatz und Arbeitsspeicher kaufen kann? Das ist übrigens das nächste Argument im Artikel.
Danach kommt die Startzeit. Hier springt der Autor aber argumentativ von Flatpak zu Snap, weil dort mehr Probleme in der Richtung existieren. Klar, man kann sich die Dinge immer so legen, wie man sie braucht. Unbestritten: Flatpak und Snaps brauchen länger für den ersten Start. Danach nicht mehr, aber das zählt ja wohl nicht. Ob der Autor schon mal was von der verbreiteten Nutzung von Standby durch normale Anwender gehört hat? Auf Uralt-Hardware merkt man die Startzeit natürlich. Fraglich, wer da Fedora mit GNOME verwendet. Es ist ja nicht so, dass Flatpaks diktatorisch verordnet werden und es nicht spezialisierte Distributionen für andere Anforderungen geben könnte. Ach wartet mal, die gibts ja schon…
Bei „Drivers“ findet Autor, dass bisher alles paletti ist und es mit Flatpaks & Co nur schlimmer wird. Okay, paletti ist es nur bei Rolling Release Distributionen, was die Mehrheit gar nicht nutzt und definitiv nicht das Ziel des Flatpak-Konzepts ist, aber egal: Alles ist gut! Veränderung gar nicht notwendig.
Bei „Security“ können wir uns eine krude Mischung aus Kritik an den schlechten Voreinstellungen mancher Flatpaks, Kritik an der Erlaubnis, auf das gesamte Dateisystem bzw. das Homeverzeichnis zuzugreifen und die Unterstellung, die Flatpaks würden veraltete Versionen von Bibliotheken ausliefern. Die Argumentationsführung ist extrem schwach, das eigentliche Ziel ist ein anderes: Beim Leser soll hängen bleiben, Sandboxes bringen nichts. Komisch nur, dass alle Betriebssysteme von Android bis macOS heutzutage darauf setzen. Alles ahnungslose Idioten. Linux is King! Auf die Schwächen aktueller Rechtekonzepte ohne Sandbox geht er nicht ein. Wir wissen ja: Aktuell ist alles gut! Am Schluss des Artikels findet der Autor übrigens, dass Sandboxes das Beste an Flatpak sind und irgendwie übernommen werden sollten.
Danach geht es in einem Unterkapitel noch über die Portal-Implementierung. Das scheint für ihn aus Entwicklersicht nicht gut gelöst zu sein. Kann ich nicht beurteilen. Scheint viele andere Entwickler nicht zu stören.
Woher er dann die Autokonversion bei Fedora herzieht und was die dort argumentativ sucht: Keine Ahnung. Hier werden dann wahllos Fedora-Spezifika – über die man sicher streiten kann, z. B. was den Sinn eines eigenen Flatpak-Repo betrifft – mit Kritik am Flatpak-Konzept vermischt.
Unter „Complexity“ nähern wir uns dem Kern der Argumentation. Der Autor hat scheinbar keine Lust, der Entwicklung zu folgen und möchte zurück zu einfachen Prinzipien. Das Argument höre ich mindestens 4 mal pro Jahr von irgendwelchen Entwicklern oder Administratoren. Ist halt nicht. Er schreibt es nicht aus, aber der Abschnitt könnte auch mit KISS überschrieben sein. Möchten wir nicht alle zurück in eine vermeintlich weniger komplexe Welt mit einfacheren Mustern? Ich wünsche mir auch eine Wissenschaft ohne „publish or perish“ aber arbeiten muss ich dennoch mit dem Publikationsoutput der Gegenwart.
Unter „Services“ wird es dann richtig lustig. Es wird kritisiert, dass man für die Nutzung von Flatpak, Snap oder AppImage einen Systemdienst braucht. Das Problem muss man erst mal finden. Klassische Pakete laufen auf meinem Kernel durch den Willen Gottes?
Der Autor sieht hinter allen Lösungen sowieso nur den kommerziellen Masterplan „App Stores“ unter Linux zu verbreiten.
Im Abschnitt „Backwards Compatibility“ können wir dann lesen, dass des A.) nicht so schlimm ist B.) immer besser wird und C.) die Entwickler schlicht zu faul sind. Okay, gut das wir das geklärt haben. Sollen wir einen Link zu dem Abschnitt jedem Hilfesuchen geben, der nach einem Major-LTS-Upgrade wieder inkompatible Programme hat? Angeblich soll das dann zukünftig auch ohne Flatpaks besser werden. Das Argument ist etwas schwer nachzuvollziehen.
Danach wird uns erklärt, dass Kompatibilität sowieso ein spezifisches GTK-Problem ist. Der ein oder andere Punkt ist hier sicherlich richtig und nachvollziehbar, aber der Versuch, alle Probleme mit den Limitationen der Paketverwaltung in Richtung GNOME/GTK zu externalisieren ist leicht zu durchschauen. Beim anderen großen Toolkit Qt ist schließlich auch nicht alles perfekt. Die letzten Toolkit-Aktualisierungen liefen dort auch nicht problemlos und die gegenwärtig essenzielle Unterstützung von Qt5 wird nur durch das KDE-Team gewährleistet. Ohne stünden wir alle im Regen.
Am Schluss wird es dann in „Is Flatpak Fixable?“ ein bisschen versöhnlicher. Hier sind Sandboxes dann wieder toll, obwohl die oben doof waren. Das Problem ist nur, dass der Autor hier die komplette aktuelle Entwicklung in Richtung „immutable“ Systeme ignoriert.
Ein paar Worte zum Schluss
Unzweifelhaft ist auch, dass Flatpaks und Snaps Mehrwerte generieren müssen. Zum Beispiel durch aktuellere Software, sicherere Systeme, längere Kompatibilität, leichtere Upgrades, neue Distributionsmodelle. Wenn die neuen Systeme letztlich durch Kompatibilität und Konformitätsdruck in die Pfadabhängigkeit des bisherigen Linux-Ökosystems gezwängt werden und es keinen funktionalen Mehrwert zur klassischen Paketverwaltung gibt, dann braucht auch niemand Flatpaks und Snaps.
Flatpaks, Snaps & Co sind gegenwärtig alles andere als perfekt. Es gibt zweifelsohne Risiken z. B. durch die Bündelung mit Bibliotheken und die muss man im Blick behalten. Welche Lösung sich technisch durchsetzt und ob es nicht noch mal einen neuen Anlauf gibt, weiß niemand. Wie sich das Ökosystem genau ausgestaltet, ob es bei Flathub als zentraler Quelle bleibt, wie die Sicherheitsstandards in Zukunft sein werden etc. pp. Vieles ist „work in progress“ und wird stetig weiter modifiziert und verbessert. So wie die Linux-Paketverwaltung 2005 auch noch nicht perfekt war und danach noch viele Verbesserungen erhalten hat. Nicht umsonst arbeiten die Projekte bei Fedora oder openSUSE mit Silverblue und MicroOS in speziellen Zweigen, um hier voranzukommen, bevor man die Anwender großflächig damit konfrontiert.
Eine Kritik, die wild beliebige Argumente durcheinander wirft und mit Fedora-Spezifika vermengt, existierende Probleme leugnet oder kleinredet und aktuelle Entwicklungen ignoriert, kann ich aber nur begrenzt ernst nehmen.
Das Konzept selbst ist aber in der Welt und wird nicht mehr verschwinden.
Der Artikel „Flatpak Is Not the Future“ – Eine knappe Analyse erschien zuerst auf [Mer]Curius
