Flatpak und Snap sind nicht die Lösung des Problems, sondern machen es noch schlimmer

Im Moment wird heftig darüber diskutiert, ob der Support von Flatpak in Fedora 27 weiter ausgebaut werden soll oder nicht.

Ich persönlich halte Flatpak und Snap für den völlig falschen Ansatz, das Problem mit der Bereitstellung von Software für verschiedene Distributionen zu lösen. Beide haben in meinen Augen das große Problem, das im Grunde jedes Snap-/Flatpak-Paket seine eigenen Versionen von benötigten Shared-Objects mitbringt und man damit irgendwann so etwas ähnliches, wie die DLL-Hölle von Windows hat: zig verschiedene Versionen eines Shared-Object von denen die meisten im schlimmsten Fall auch noch verwundbar für Angriffe sind.

Zumal die meisten technisch unbedarften Anwender wahrscheinlich davon ausgehen werden, das der Paketmanager des Systems (z.B. dnf oder PackageKit) auch die Shared-Objects der Flatpak-Pakete aktualisiert, was aber eben genau nicht der Fall ist. Stattdessen müssen sich die Nutzer darauf verlassen, das die Anbieter der von ihnen verwendeten Flatpaks/Snaps verwundbare Versionen der von ihren Apps verwendeten Shared-Object zeitnah aktualisieren – eine Wette, die ich persönlich nicht eingehen möchte. Das funktioniert ja schon bei Windows Anwendungen eher bescheiden, warum sollte es dann diesmal besser klappen?

Nein, Flatpak und Snap sind in meinen Augen das, was man sprichwörtlich „den Teufel mit dem Beelzebub austreiben“ nennt: ein Problem lösen und dabei ein anderes Problem schaffen. Man macht es einfacher, Anwendungen für verschiedene Distributionen bereit zu stellen, öffnet damit aber ohne Not zusätzliche Angriffsvektoren, indem man dem Paketmanager die Kontrolle über einen Teil der installierten Software entreißt und die Anwender damit zwingt darauf zu vertrauen, das Dritte – von denen man im Grunde nicht weiß, wie vertrauenswürdig sie sind – ihre Hausaufgaben machen!

IMHO ist der Kommentar von Fedora-Blog.de.
IMHO = In My Humble Opinion (Meiner bescheidenen Meinung nach).

Von Heiko

Gründer, Admin und Hauptautor von Fedora-Blog.de. Benutzt Fedora seit Core 4, hat nach Core 6 aber bis zum Release von Fedora 12 einen Abstecher zu CentOS gemacht, ist inzwischen aber wieder zu Fedora zurückgekehrt und plant auch nicht, daran in naher Zukunft etwas zu ändern.

11 Kommentare

  1. Ich stimme dir absolut zu! Die Paketverwaltung von Linux-Distributionen ist eines der Dinge, die Linux so stark machen!
    Eine Stelle die Qualität und Aktualität der Pakete sicherstellt – dieses Konzept wurde ja auch für Smartphones übernommen.

    Und jetzt kommen die Snap/Flat-Nasen auf die Idee, das aufzuweichen anstatt Arbeit in’s konventionelle Paketieren zu stecken. Völliger Irrsinn!

    1. Soweit ich weiß haben sich Flatpack und Snap bei Android inspiriert. Zudem werden soweit ich weiß die Programme dann auch in einer Sandbox ausgeführt, ist zwar auch nur eine Bekämpfung eines Symptoms statt der Ursache aber immerhin trotzdem sicherer als das DLL-Beispiel aus der Windows-Welt. Steam unter Linux löst das ganz gut, die geben einfach die Versionen der Abhängigkeiten einheitlich vor an die sich jedes Spiel halten muss welches für Steam in Linux veröffentlicht werden soll, hat dafür den Nachteil das hier nur veraltete Abhängigkeiten genutzt werden können.

      1. Das ändert aber nichts daran, das man die Flatpaks separat aktualisieren muss, was viele technisch unbedarfte Anwender sicher verwirren wird, da sie sich darauf verlassen, das die Paketverwaltung ihr System up2date hält.

  2. Endlich mal jemand der das genau so sieht wie ich!
    Eigentlich wollte ich immer mal einen Artikel schreiben zu diesem Thema.
    Wobei ich schon gemerkt habe das einige Projekte tatsächlich nur noch flatpacks oder snaps anbieten, wo ein Krebs…
    Ich meine ich kann es verstehen da es meiner Ansicht nach unglaublich schwierig ist vernünftig Informationen zu finden wie ein Paket gebaut werden muss und vor allem wie man es in die offiziellen Paketquellen bekommt.
    Ggf gibt es da auch nochholbedarf von der community die vernünftige Anleitungen schreiben könnte. Aber auf der anderen Seite müssten die Distribution es auch zumindest verständlicher machen was sie haben möchte.
    Oder wie siehst du das?

    Grüße Jkoan

    1. Der Clou ist die Zusammenarbeit. Niemand erwartet von Upstream Projekten, dass sie selbst paketieren. Viel einfacher wäre es, freundlich Druck auf die Packager bzw. Maintainer auszuüben. Nachfragen, Hilfe anbieten etc.

  3. Der Vergleich mit der „DLL-Hölle“ passt nicht so richtig. Das Problem war gerade, dass man systemweit nur eine Version einer DLL hatte. Also genau das Gegenteil von Flatpak und Snap.

    1. Die Anspielung auf die DLL-Hölle war auch eher so gemeint, das man im schlimmsten Fall halt x Versionen eines Shared-Objects im System hat, die von der Paketverwaltung abgekoppelt und von denen im schlimmsten Fall einige total veraltet und voller Lücken sind.

    1. Keine Ahnung. Vielleicht so eine Art Meta-Specfile, das man für alle gängigen Distribtionen nutzen kann. Frei nach dem Motto: „Write once build everywhere“.
      Wenn es die einzelnen Distributionen dann noch einfacher machen würden, auch fremde Paketformate zu bauen (z.B. deb-Pakete unter Fedora) wären wir sicher auch schon ein gutes Stück weiter.

  6. Ich verstehe den Autor, die alten Probleme die Flatpak und Snap erneut hervorrufen sind das Problem. Jede „App“ ist entweder eine statische Binary oder liefert alle dyanmischen Libraries mit, der verschwendet nicht nur unmengen an Hauptspeicher sondern ist auch ein Wartungs und Sicherheitsproblem. Eine wichtiger Bugfix an einer weit verbreitetende Library (nehmen wir mal libpng als Beispiel) loest eine gigantische Updatewelle aus, oder schlimmer, eben nicht. Und mein Computer wird auch noch langsamer.

    Der beste Kommentar zur Gesamtsituation: http://kmkeen.com/maintainers-matter/index.html

    Maintainerarbeit und Paketierung ist Fleissarbeit, sie muss staendig und mit hoher Qualitaet erfuehlt werden. Aber genau das bringt dann die Vorteile eine moderen Paketverwaltung, ein sauberes und schlankes System. Und wer diese Rolle abschafft, packt die ganze Arbeit auf den Entwickler oben drauf und den Endanwender, den Rest darf der Hauptspeicher ausbaden.

    Es gibt durchaus Ansatzpunkte und einen Sinn hinter dem ganzen:
    Bequeme Installation ueber mehre Distributionen hinweg, bequeme Installation mehrere identische Versionen gleichzeitig und die Abschottung ueber Control-Groups.
    Ob Flatpak die Antwort ist? Keine Ahnung, Snap raeume ich weniger Chancen ein, weil Ubuntu in etwas so geschickt vorgeht wie Oracle. Wieder ein Eigenbau von Canonical, niemand hat klar gemacht wo SNAP den jetzt besser ist als Flatpack und dann zielt es genau gegen GNOME auf das man gerade zurueckwechselt.

    Flatpak kann Sinn machen:
    Wenn die Pakete schlank bleiben, also praktisch gar keine Dependencies mitliefern (Hauptspeicher wird entlastet + Sicherheit steigt durch Abschottung + nicht so viel mehr Aufwand fuer den Entwickler) und damit der Fokus auf Multi-Distributionsunterstuetzung und Sicherheitsgewinn liegen kann. So kann ein Flatpak dann Sinn machen, fallfs etwas Valve Steam mit allen Abhaengigkeiten in Kopie als Flatpak ausliefert funktioniert der Ansatz nicht.

Kommentare sind geschlossen.