Fedora Workstation mit Silverblue
Screenshot: ft

Mit Fedora 29 veröffentlichte das Projekt erstmals eine Workstation-Variante namens Silverblue auf der Basis von Flatpak und OSTree und der Möglichkeit, das System beim Auftreten eines Fehlers bei der Aktualisierung zurückzurollen.

Zukunft der Fedora Workstation?

Mit der gerade erschienenen Veröffentlichung der Beta-Version zu Fedora 30 erscheint ein Blick auf diese interessante moderne Variante einer Distribution angebracht. Vor einem Jahr entstand die Idee zu Silverblue, die aus der Atomic Workstation eine für jedermann sinnvoll einsetzbare Variante der Fedora Workstation machen will.

Recht stabil

Mit Fedora 30 gilt Silverblue zwar immer noch als Beta, ist aber schon recht stabil in der Benutzung. Viele der Hürden, die vor einem Jahr zu meistern waren, sind mittlerweile abgehakt. So werden Flatpak und Flathub von der Paketverwaltung GNOME Software vollständig unterstützt, wie GNOME-Entwickler und Red-Hat-Manager Matthias Clasen zum ersten Geburtstag schreibt.

Atomare Updates

Fedora Silverblue will ein modernes grafisches Betriebssystem für Laptops, Tablets und Desktop-Computer sein. Es soll zudem die nächste Generation der Fedora Workstation werden, die problemlose Upgrades, eine klare Trennung zwischen Betriebssystem und Anwendungen sowie sichere und plattformübergreifende Anwendungen verspricht. Der grundlegende Betriebssystemkern ist ein unveränderliches OSTree Image, dass nur im Lesemodus gestartet wird. Alle Anwendungen in Silverblue sind Flatpaks.

Was ist OSTree?

Was genau ist nun OSTree aka libostree, wie es neuerdings heißt? Es handelt sich dabei sowohl um eine gemeinsam genutzte Bibliothek als auch um eine Reihe von Kommandozeilenwerkzeugen. Wenn man unter OSTree ein Paket installiert, erstellt OSTree zunächst einen Wiederherstellungspunkt. Dann wird das Paket installiert und die Änderungen am Dateisystem werden in einem Verzeichnis protokolliert und künftig weiterverfolgt. Wenn dieses Paket einen Schaden anrichtet, geht man zurück zu dem Wiederherstellungspunkt und alles ist wie vorher.

Darauf baut Silverblue auf, indem es das Dateisystem schreibgeschützt einbindet und als Anwendungen standardmäßig nur Flatpaks vorgesehen sind. So erhält man neben den Vorteilen von OSTree zusätzlich die Isolation des Flatpak-Systems.

Fedora Workstation mit Silverblue
Nach einem Upgrade wird in das neue System gebooted

Gefahrloses Upgrade

Ein Upgrade des Betriebssystems berührt die vorhandene Instanz zunächst nicht, sondern wird separat ausgerollt. Nach einem Reboot befindet man sich im aktualisierten System. Stellt sich das System als instabil heraus, geht man zurück auf die vorherige Version. Das gleicht ein wenig den Snapshots von Btrfs.

Auch für Entwickler

Soll Silverblue als Entwicklungsbasis dienen, führen zwei Wege zur Installation nötiger Tools, Editoren und SDKs. Indem man das System in einen schreibfähigen Zustand versetzt, lassen sich RPMs per rpm-ostree installieren. Damit verliert man aber den Vorteil des schreibgeschützten und zurückrollbaren Systems. Alternativ können benötigte Entwicklungswerkzeuge per Container eingebunden werden. Dabei hilft die Fedora-Toolbox.

Mit Fedora 31 sollen die jetzt noch nicht integrierten Teile wie die Toolbox möglichst Teil von Silverblue sein und den Einsatz des Terminals zum Aufsetzen der Toolbox überflüssig machen.

Beitrag kommentieren

Alle Kommentare
  • Nick

    12.04.2019, 09:16 Uhr

    Ich bin auch skeptisch was dieses Konzept angeht. Zwar erkenne ich an was man hier zu lösen versucht, aber das Thema Flatpak stösst mir immer noch negativ auf. Zumal der Nutzer über die Feinheiten der Sandbox keine Kontrolle hat, und der Entwickler eines Flatpaks quasi willkürlich Ausnahmen definieren kann, was die grundlegende Isolation wiederum aushebeln könnte. Mir fehlt hier eine klare Linie und ein klar definierter Basisschutz, der ähnlich zu Firejail nicht durch den Entwickler untergraben werden kann. Nicht das Programm hat das Sagen sondern der Nutzer, und nur dieser alleine bestimmt was ein Programm darf und was nicht. Und selbst wenn via Sandbox grundlegende Funktionalitäten abgewürgt werden, dann hat auch das seine legitimen Gründe. Von daher sind mir Konzepte ala Snaps und Flatpaks zu lasch, und bei weitem nicht restriktiv genug. Allerdings wenn diese Einflussnahme seitens des Entwicklers abgeschafft wird, und die Sandbox je Programm stetig über die Community weiter verfeinert wird, dann wäre das durchaus annehmbar. Denn Firejail hat bereits eine Basis von über 800 Sandbox-Profilen, die man einfach portieren könnte. Andernfalls ist das nicht ansatzweise eine gleichwertige Alternative zu Firejail.