Ein Projektziel der Fedora Strategy 2028 lautet, Silverblue als Immutable-Variante an die Stelle der jetzigen Workstation-Edition zu setzen, ohne den User zum dann umbenannten Silverblue zu zwingen. Eine RPM-Edition soll auch weiterhin angeboten werden. Bei der Immutable-Ausgabe wird der Paketbestand durch Flatpaks realisiert.
Fedora Flatpak oder Flathub?
Der bekannte Fedora- und GNOME-Entwickler Michael Catanzaro geht in einem ausführlichen Blogeintrag auf die Herausforderungen ein. An erster Stelle sieht er die fehlende Vorkonfiguration von Flathub zugunsten eines eigenen Flatpak-Repositories bei Fedora. Dieses Repository kommt nicht unbedingt gut bei allen Nutzern an und wurde deshalb bereits 2022 infrage gestellt. Viele Anwender sind sich offenbar auch nicht bewusst, dass ihre Flatpaks nicht von Flathub stammen.
Die Apps aus beiden Repositories unterscheiden sich primär darin, aus welchen Quellen sie gebaut werden. Während die Fedora-Flatpaks aus den eigenen RPMs gebaut werden, werden die Pakete auf Flathub entweder von den Entwicklern der Software selbst oder von Dritten erstellt. Von den derzeit 3.064 Flatpaks auf der Seite sind 1.656 verifiziert und durch einen blauen Haken hinter dem Namen der App als offiziell überprüft gekennzeichnet.
Viel Arbeit steht bevor
Bevor Silverblue die Rolle als Workstation-Edition übernehmen kann, muss eine Reihe von Mängeln in Flathub behoben werden. Viele der Flatpaks auf Flathub sind nicht auf deren Infrastruktur gebaut, sondern beispielsweise auf GitHub. Niemand kann ausschließen, dass zwischen der Veröffentlichung des Codes auf GitHub und dem Flatpak, das auf dem Computer installiert wird, etwas am Code geändert wurde. Deshalb sollten laut Catanzaro alle Flatpaks auf Flathub reproduzierbar sein.
Runtimes für Flatpaks sind oft noch lange in Benutzung, nachdem ihr Lebensende erreicht ist, und erhalten somit keine Sicherheits-Updates mehr. Das sieht dann so aus:
Die Entwickler müssen angehalten werden, solche veralteten Laufzeitumgebungen zeitnah auszutauschen, oder sie müssen mit der Entfernung ihrer App rechnen. In meinem Fall wird die Runtime für Warpinator benötigt, welches vom Linux-Mint-Team entwickelt wird. Eine Runtime, die bald ein Jahr über das EOL ist, ist schon enttäuschend und nicht hinnehmbar. Catanzaro hat ermittelt, dass derzeit fast ein Drittel aller Flatpaks auf der Plattform mit EOL-Runtimes laufen.
Er schlägt eine Reihe von Lösungen für diese und andere Probleme vor, die sowohl von Fedora als auch von Flathub umgesetzt werden müssen. Überdies gibt es eine Debatte über die genaue Art und Weise, in der sowohl die traditionellen als auch die unveränderlichen Varianten von Fedora zu Flathub wechseln. Eine Idee ist, dass alle standardmäßig installierten Kernanwendungen unter der Kontrolle von Fedora bleiben, während alles andere von Flathub installiert wird.
Die Zukunft muss es zeigen
Ob das der richtige Weg ist, muss sich zeigen. Der Wegfall des Maintainers als Stallwart für die Einhaltung der Richtlinien und als Bindeglied zwischen Distribution und Anwender ist für mich keine gute Idee. Andererseits muss Linux, wenn es weiter wachsen und dazu Anwender von Windows herüberholen will, resistenter gegen Fehlbedienungen werden. Das wird durch unveränderliche Distributionen gewährleistet. Fedora wird den entscheidenden Schritt gehen, so viel scheint festzustehen. Was denkt ihr über eine unveränderliche Fedora Workstation Edition?
Ein sehr ambitioniertes Ziel dass in 3 Jahren verwirklichen zu wollen.
Für mich ein völlig falsche Richtung was Immutable und Flatpack anbetrifft, aber vielleicht bin ich auch einer der letzten verfechter von Selbstbestimmung.
Ich meine, am Ende geht für mich immer mehr der Gedanke von Freiheit in Linux verloren. Und wenn man mal ehrlich zu sich sellbst ist, erinnert mich dieser ganze Kram an die Anfänge von Android und IOS. Bin mal gespannt wann die ersten kostenpflichtigen Flatpaks kommen. Mittlerweile, alles nur eine Frage von Zeit…………
Ich kann den Sinn / Mehrwert von Immutables durchaus verstehen, und sie haben in meinen Augen auch ihre Daseinsberechtigung. Problematisch wird es aber immer dann wenn zusätzliche Kernel-Module benötigt werden (z.B. OpenZFS), die lassen sich nicht so ohne weiteres installieren. Anstatt nur die eine oder andere Art von Distribution zu bewerben, sollten beide gleichwertig präsentiert und erklärt werden. So hat der User alle Freiheit, sich für eine der beiden zu entscheiden.
Flatpaks nutze ich als letzten Ausweg, bei mir aktuell die Linux-Clients des Plex-Ökosystems und halte es angesichts der ausgereiften Repository-Techniken der verschiedenen Distributionen für falsch, von den nativen Paketen wieder wegzugehen.
Bei den Immutables wird es nicht anders gehen, die kann man am Ende nur mit sowas wie Flatpak oder Snap erweitern.
Ich halte das Ganze für unausgegoren.
Flatpaks sind an sich nichts Schlechtes, aber man hat sie als universelle Lösung für Alles betrachtet, ohne sich dabei allzu viele Gedanken über vertrauenswürdige Strukturen zu machen. Die Vorstellung, dass Softwareentwickler ohne jede Kontrollinstanz Binärpakete direkt an den User ausliefern, ist der reinste Sicherheitsalbtraum gewesen.
Jetzt im Nachhinein klare Verantwortlichkeiten und Transparenz anzuflanschen ist recht schwierig geworden.
Vielleicht solle man bei seinen Überlegungen nochmal zwei Schritte zurück gehen um auf eine passende Lösung zu kommen.
Flatpaks haben in meinen Augen lediglich einen Vorteil für Firmen, da sie es ermöglichen neue Softwareversionen unabhängig von Releasezyklus der Distribution auszurollen und den Zeitpunk eines Softwareupgrades an interne Mitarbeiterschulungen zu knüpfen.
Während konventionelle Rolling Release Distributionen weiterhin wichtig bleiben für eine organische Softwareentwicklung in der Breite, könnte flatpak sich auf die Pflege von LTS-Versionen von Anwendersoftware begeben um diesen Bedarf zu decken.
Davon gänzlich unabhängig solle das Vorhaben sein, ein unzerstörbares Linux für den ahnungslosen Endverbraucher zu kreieren um Linux als massentaugliches Produkt um zu gestalten.
Anstatt ein zweites Android zu kreieren, sollte man sich hier doch eher auf die Punkte Datensicherung und einfache Systemwiederherstellung konzentrieren.
Suse hatte das ja auch schon versucht, und nun gibt es glückerweiße doch wieder ein “normales Leap”. Denke der Aufschrei war doch zu groß.
Ich persönlich halte von dem Imutable-Ding nichts.
Flatpaks nutze ich nur in äußersten Notfällen.
Ich könnte jetzt wieder alle möglichen Punkte aufführen warum nicht. Bringt aber nichts. Ich hoffe einfach, dass es sich nicht durchsetzen wird. Nur soviel. Das immer wieder aufgeführte Argument, die Anwendung läuft immer weil vom Entwickler ist falsch. Warum sollte sie auch stimmen.
Ich sehe einfach nur, dass die Distributionen Verantwortung und Arbeit abgeben wollen. Das führt zu dem was man momentan in jeder Branche sieht….
Das zweite was mich aber fast noch mehr an der Imutable-Geschichte nervt, ist das ständige reboot bei jedem Mist was nicht von flatpack kommt. Wenn ich das gut finden würde, dann kann ich gleich bei W***** bleiben.
Und dann wird, vieles noch mit docker/podman im container erledigt. Ich kann euch sagen, wenn eine Sofware vorher direkt auf dem Server lief und nun im container, dass kann sowas von nervig und zeitintensiv sein. Aber, die Distris haben Personal gespart. Meinen sie zumindes.
Also … nur noch mal zusammengefasst: Man möchte in Zukunft statt der jetzigen Workstation Version diese atomic Version als Workstation Edition standardmäßig anbieten. Und die Pakete sollen alle als Flatpaks mitkommen.
Ich persönlich nutze diese atomic/immutable Distros nicht, aber ich sehe da schon Einsatzmöglichkeiten und mit den A/B root Partitionen interessante Eigenschaften. Aber ob man das will oder braucht, muss ja letztlich der Nutzer respektive die Nutzerin entscheiden.
Aber das dann als Standard-Workstation Edition anzubieten … ist schon ein großer Schritt würde ich meinen. Das gilt auch für Flatpaks als Standard. Ich nutze auch Flatpaks, aber eher als Ergänzung neben den normalen .deb Versionen. Dass dann als einziges Format Flatpak verfügbar ist … bin ich mir auch nicht so sicher ob das eine gute Idee ist. Auf jeden Fall müsste man dann entweder Flatseal oder irgendeine eingebaute Möglichkeit zum Einstellen der Berechtigungen mitliefern. Und wie die OBS-Angelegenheit in der Vergangenheit gezeigt hat, können die Fedora Flatpaks so eine Sache sein.
Letztlich wird man wohl sehen müssen, was dann auf dem Tisch liegt und wie das läuft und funktioniert.
Die RPM-Variante soll ja bleiben, tritt nur aus dem Rampenlicht. Das soll dann Immutable und Flathub gehören.
”Die RPM-Variante soll ja bleiben, tritt nur aus dem Rampenlicht.”
Letzteres ist hier wohl der Punkt. Ich meine, wenn etwas nicht mehr ”beleuchtet” wird und im Schatten verweilt, kann man es auch leichter los werden. Aber das ist natürlich nur eine persönliche Meinung von mir.
Flatpak ist auch noch lange nicht komplett. So wie ich das verstanden habe werden momentan noch die Rechtevergabe von Entwicklern vorgegeben und ausgeliefert. Das wird wohl bald auch dynamisch funktionieren. Es gibt auch noch keine Aliases, sodas man im Terminal sowas wie flatpak install firefox eingeben kann usw. Aber das wird wohl noch kommen. Man arbeitet ja auch noch am Flathub und einem Bezahlsystem. Das passiert noch einiges und dann kommen hoffentlich auch die AAA Hersteller wie AutoDesk, Ableon, Steinberg… und dann geht das alles ganz schnell und Windows befindet sich im freiem Fall.
Ich persönlich liebe Silverblue und das Konzept. Freut mich das das weiter ausgebaut wird.