==============
== morph.sh ==
==============
Einfach mal was mit Holz machen.

Distrowars 2020: Fedora Silverblue

de linux distrowars-2020

Runde eins in den “Distrowars 2020”: Fedora Silverblue 32!

Was Silverblue anders macht

Silverblue geistert mir seit einer Weile durch den Kopf, weil es ein paar radikal andere, zukunftsweisende Ansätze verfolgt. So besteht unter anderem das Root-Filesystem nicht aus einfachen Dateien, die auf einer Partition liegen, sondern nutzt OSTree. Das kann man sich vorstellen wie Git: eine Zusammenstellung an Dateien beinhalten einen Commit, und beim Booten wird festgelegt, welcher Commit read-only nach / gemountet wird. Somit ist man unglaublich flexibel und kann zu jedem beliebigen Stand des Systems zurückspringen (was wohlgemerkt nur Systemupdates, in den OSTree installierte Pakete usw. umfasst und keine Nutzdaten oder Einstellungen; /var und /etc sind mutable).

OSTree, Flatpak oder Toolbox?

Der OSTree ist allerdings nur für Pakete gedacht, die als “Teil des Systems” gesehen werden; die Dokumentation hält dazu an, das sogenannte Package Layering “sparingly” zu verwenden. Hilfreich dabei ist, dass nach jeder Paketinstallation per rpm-ostree das System rebootet werden muss; das hilft, die Versuchung in Schach zu halten :)

Screenshot vom rpm-ostree Befehl

Stattdessen gibt es zwei andere Methoden, Software zu installieren: Flatpak für Desktopanwendung und Toolboxes für CLI-Tools. Flatpak kennt man ja inzwischen; anders als bei Ubuntu finde ich, dass dessen gleichnamiger Paketmanager beim Installieren von Software geradezu vorbildlich detaillierten Output ausgibt. Das können apt und co. von mir aus in Zukunft auch gerne so machen :)

Screenshot vom flatpak-Befehl

Für CLI-Applikationen gibt es sogenannte Toolboxen. Dabei handelt es sich um wenig mehr als um Podman-Container mit einem dünnen Wrapper drumherum, der die Bedienung vereinfacht. Die Idee ist, dass man Kommandozeilenprogramme, aber auch zB Softwareentwicklungs-Dependencies in eigene Container verbannt, um das System “schlank” zu halten und leicht eine “wegwerfbare” Umgebung zu schaffen. Eine Toolbox fühlt sich von innen auch so an wie eine Shell auf dem Hostsystem, es ist sogar dessen $HOME gemountet, und es sind Befehle wie dnf verfügbar, die es auf dem Hostsystem logischerweise nicht gibt.

Und sonst so?

Alles in allem bin ich sehr überrascht, wie “natürlich” sich die Verwendung von Silverblue anfühlt; am Ende des Tages hat man als Anwender ja auch großenteils ein normales Fedora Workstation vor sich. Initiale Einrichtung, Treiber etc. funktionieren wie gewohnt reibungslos, das völlig andere “Backend” sieht man erst auf den zweiten Blick. Ich habe in meiner Testphase auch etwas mit OSTree, Rollbacks etc. herumgespielt und alles hat für meinen Eindruck so funktioniert, wie es sollte, auch wenn mir manche konzeptuellen Dinge noch nicht so klar sind (was heißt “alles außer /var ist immutable” eigentlich, wenn sowieso alles auf /var symlinkt? Was passiert mit state in /etc nach einem Rollback? Soll ich Toolboxen langfristig anlegen oder als wegwerfbar sehen und wenn letzteres, wie verwalte ich sie sinnvoll? Wie mache ich Backups?). Wie auch die offizielle Dokumentation, die gezielt nur auf die Eigenheiten von Silverblue eingeht und ansonsten auf Fedora Workstation verweist, kann ich nur sagen, dass Silverblue per se wenig auffällig ist und fast wie ein normales Fedora wirkt.

Fazit

Fedora Silverblue ist ein beeindruckendes Stück Software, wird aber fürs erste nicht mein Hauptbetriebssystem werden. Das Konzept wirkt auf mich noch etwas unausgereift; drei Arten, Software zu installieren, die alle gravierende Nachteile haben, finde ich wenig einladend. Mich schreckt auch ab, dass ich im “Panikfall”, in dem es schnell gehen muss und ich alle meine Werkzeuge griffbereit haben will (Sysadmins kennen das :) ) erstmal nachdenken muss, in welcher Toolbox was liegt, ob ich irgendwas noch bauen muss und ob die Flatpak-Apps die nötigen Berechtigungen haben, im Zweifel miteinander, mit dem Host oder den Toolboxen sprechen zu können.

Ich würde Silverblue allerdings durchaus schon als geeignet ansehen für Menschen, die

  • viel container-basierte Workflows nutzen (wobei zu klären wäre, wie gut das vorinstallierte Podman bei Dockerfiles aus bestehenden Projekten mitspielt)
  • dazu neigen, ihre OS-Installationen zu kaputtzubasteln
  • viel neue Software ausprobieren
  • und all das wartungsarm und anwenderfreundlich haben wollen.

So oder so werde ich Silverblue im Auge behalten - vielleicht ist es ja bei meiner nächsten Distro-Neuorientierung etwas reifer. Außerdem habe ich gehört (leider ist mir die Quelle nicht mehr bekannt), dass Silverblue in absehbarer Zeit zum “normalen” Fedora werden soll bzw. Fedora Workstation ablösen soll. Wenn basierend darauf die Paketmanagements-Experience noch etwas smoother wird und sich die Nutzerbasis vergrößert, könnte es definitiv zu meinem “daily driver” werden.