Die nächste SUSE-Generation wirft ihre Schatten voraus und gleichzeitig experimentiere ich im Nutzungsalltag mit modernen unveränderbaren Linux-Distributionen. Zeit also, sich genauer mit MicroOS zu befassen.
Unterschiede zwischen MicroOS und anderen unveränderbaren Systemen
Nach ein paar Wochen mit Fedora Silverblue auf meinem Alltagsgerät kann ich bereits konstatieren, dass das Konzept unveränderbare Distribution + Flatpaks für mich funktioniert. Ich hatte das Experiment mit GNOME durchgeführt, weil dieser Desktop traditionell bei Fedora am besten integriert ist. Obwohl ich Adwaita hübsch finde und die Konsistenz des Desktops schätze, bin ich insgesamt damit nicht warm geworden. Zu oft stand mit der Desktop bzw. zugehörige Dinge wie der Dateidialog im Weg. Mit Kinoite bietet Fedora eine weitere unveränderbare Variante mit KDE Plasma als Desktop an.
In den Kommentaren und per Mail erreichten mich jedoch die Hinweise, dass MicroOS viel weiter wäre, als ich dachte und durchaus produktiv nutzbar sein soll. SUSE ALP wird zudem konzeptionell stark an MicroOS angelehnt sein und viele der von dort bekannten Werkzeuge nutzen. Deshalb habe ich mir in einem zweiten Schritt nach Fedora Silverblue nun openSUSE MicroOS mit KDE Plasma angeschaut. Der Desktop wird noch als Alpha geführt, während GNOME schon RC-Status hat. Das verfälscht natürlich etwas den Vergleich zu Silverblue, aber nach ein paar Tagen Test finde ich den Alpha-Status unbegründet.
MicroOS ist genau wie Fedora Silverblue oder Endless OS eine sogenannte unveränderbare Distribution. Das System wird während der Laufzeit schreibgeschützt eingehängt und Aktualisierungen via Neustart eingespielt. Änderungen am Basissystem durch den Nutzer sind nicht vorgesehen. Anwendungen kommen als Flatpaks oder in einem Container mit einem klassischen Linux-Paketverwaltungssystem.
Hier hören die Gemeinsamkeit mit Silverblue aber schon auf. Während dort mit rpm-ostree eine völlig andere Paketverwaltung zum Einsatz kommt, hat man bei MicroOS bewährte SUSE-Techniken weiterentwickelt. Das System wird mittels transactional-updates verwaltet, das im Hintergrund aber weiter auf dem bewährten Zypper aufbaut und RPMs nutzt. Diese werden lediglich als feststehende Sammlung gebündelt und ausgeliefert. Um jederzeit zum vorherigen Stand zurückspringen zu können, verwendet MicroOS Btrfs-Schnappschüsse. Ebenfalls für SUSE-Anwender ein vertrautes Werkzeug. Mittels transactional-updates kann man – ähnlich wie bei den rpm-ostree Layern – weitere Pakete zum Basissystem hinzufügen. Das ist aber kein Ersatz für eine klassische Paketverwaltung, sondern soll nur bei unbedingt erforderlichen Paketen erfolgen. Bei mir brauchte es z.B. noch firmware-sof für die Soundausgabe.
Die Unterschiede machen nicht beim Basissystem halt. MicroOS nutzt für Anwendungen ebenfalls Flatpaks, verzichtet aber auf die umstrittene eigene Quelle. Beim initialen Start richtet das System stattdessen Flathub ein und versucht sofort Firefox von dort zu installieren. Anstelle des von Fedora bekannten Toolbox nutzt MicroOS zudem Distrobox für Anwendungen, die nicht als Flatpaks ausgeliefert werden (können). Wobei Toolbox und Distrobox im Hintergrund beide auf podman aufbauen.
Aufbau von MicroOS
Das Basissystem umfasst mit KDE Plasma circa 1300 Pakete. Das ist im Prinzip der Kern, den jedes Desktop-Linux benötigt. Kernel, Wayland, X-Server, Dracut, CUPS, NetworkManager Qt, Gtk etc. pp. Hinzu kommt noch Plasma mit ein paar Kernprogrammen wie Dolphin, der Konsole und Discover für die grafische Installation von Anwendungen. Aktuell wird auch noch Kate im Basissystem mitgeliefert, weil dieses via Flatpak noch nicht zufriedenstellend funktioniert. Puristen werden die mangelnde Anpassungsmöglichkeit kritisieren, aber ich wüsste gar nicht, was davon noch deinstalliert werden sollte.
Dieser Kern stammt beim „normalen“ MicroOS aus Tumbleweed und bei der Leap-Variante aus dem aktuellen Leap-Zweig. Das bedeutet beim „normalen“ MicroOS, das es eine quasi rollende Basis hat, die sich ca. 1x pro Woche erneuert. Ich persönlich finde ja, dass die Mehrwerte eines solchen Systems sich bei dieser rollenden Basis noch gar nicht richtig zeigen können und erst mit SUSE ALP und Red Hat 10 (?) wirklich zum Tragen kommen werden, wenn stabile Grundlagen mit aktuellen Anwendungen und Container-Umgebungen gepaart werden.
Auf dieser beschriebenen Basis setzen die Flatpaks und die Distroboxes auf, mit denen der Anwender Anwendungen installiert. Mittels Flatpak kann man ein ziemliches normales KDE Desktopsystem einrichten:
Name Anwendungskennung Version Zweig Installation
Vorta com.borgbase.Vorta v0.8.10 stable system
Tor Browser Launcher com.github.micahflee.torbrowser-launcher 0.3.6 stable system
RSS Guard io.github.martinrotter.rssguard 4.3.3 stable system
Freedesktop Platform org.freedesktop.Platform 22.08.9 22.08 system
Mesa org.freedesktop.Platform.GL.default 21.3.9 21.08 system
Mesa org.freedesktop.Platform.GL.default 22.3.5 22.08 system
Mesa (Extra) org.freedesktop.Platform.GL.default 22.3.5 22.08-extra system
Intel org.freedesktop.Platform.VAAPI.Intel 21.08 system
Intel org.freedesktop.Platform.VAAPI.Intel 22.08 system
openh264 org.freedesktop.Platform.openh264 2.1.0 2.0 system
openh264 org.freedesktop.Platform.openh264 2.1.0 2.2.0 system
Breeze GTK theme org.gtk.Gtk3theme.Breeze 5.27.3 3.22 system
KDE Application Platform org.kde.Platform 5.15-22.08 system
KDE Application Platform org.kde.Platform 6.3 system
Ark org.kde.ark 22.12.3 stable system
digiKam org.kde.digikam 7.10.0 stable system
Gwenview org.kde.gwenview 22.12.3 stable system
KCalc org.kde.kcalc 22.12.3 stable system
KFind org.kde.kfind 22.12.3 stable system
Okular org.kde.okular 22.12.3 stable system
KeePassXC org.keepassxc.KeePassXC 2.7.4 stable system
Thunderbird org.mozilla.Thunderbird 102.9.0 stable system
Firefox org.mozilla.firefox 111.0.1 stable system
VLC org.videolan.VLC 3.0.18 stable system
Zotero org.zotero.Zotero 6.0.23 stable systemCode-Sprache: CSS (css)Ecken und Kanten
Das System hat einige Vorzüge gegenüber der Fedora-Umsetzung eines unveränderbaren Systems. Transactional-Updates ist schneller als rpm-ostree und die KDE-Implementierung SUSE-typisch „sauberer“ als bei Kinoite. Insgesamt merkt man aber die kürzere Entwicklungszeit.
So wird Flathub als User-Quelle eingerichtet. Wenn man bei einem Mehrbenutzersystem Flathub als System-Quelle einrichten, erhält man andauernd Root-Passwortabfragen. Fedora spielt da seine traditionelle Stärke einer wirklich guten PolKit-Integration aus. Kleinere Wartezeiten beim Hoch- und Herunterfahren treten ebenso auf. Die MicroOS-Umsetzung erfordert zudem eine verschlüsselte Boot-Partition, sofern man nicht auf Verschlüsselung komplett verzichten mag, was wiederum nervige Wartezeiten bei der Passworteingabe erfordert.
Hinzu kommen noch Schwächen bei KDE. Discover ist noch nicht so stabil wie GNOME Software und kann Transactionale Updates nicht so gut abbilden wie GNOME Software rpm-ostree abbilden konnte. Man greift deshalb häufiger zur Kommandozeile.
Wirklich schwerwiegend sind diese Probleme aber nicht. Für ein experimentelles Testsystem mit einem Desktop, der als Alpha klassifiziert ist, kann sich das sehen lassen.
Zusammengefasst
MicroOS ist viel weiter als gedacht. Es gibt Ecken und Kanten, aber diese sind nicht gravierend. Es zeigt eindrucksvoll, dass ein gemeinsamer Trend zu unveränderbaren Systemen keinen Einheitsbrei hervorbringt, da es hier viele unterschiedliche Wege geben kann. Wer sich mit solchen Systemen vertraut machen möchte und eine Idee gewinnen will, was mit SUSE ALP kommen könnte, dem sei MicroOS ans Herz gelegt.
Ich war auch immer zwischen Kinoite und MicroOS hinundher gerissen. Der Vorteil, gleich alle Codecs im Browser zu haben und sich RPMFusion sparen zu können, sowie nicht aller 6 Monate rebasen zu müssen, hatten schon was. Aber leider waren die Bootzeiten suboptimal, zumal ich öfters Upgrade-Probleme bekam.
Was ist mit „sauberer“ bezüglich der KDE-Implementierung gemeint?
Bei Fedora Kinoite ist z.B. völlig unnötigerweise das GTK-Konfigurationstool für Firewalld vorinstalliert. Das sind so Kleinigkeiten und deshalb habe ich das auch in Anführungsstriche geschrieben.
Weißt Du, ob es dafür ein Qt-Gegenstück (eventuell als Flatpak) gibt?
Nicht als Flatpak aber KDE hat dafür Plasma-Firewall entwickelt, das anstelle von firewall-config im Baseimage enthalten sein müsste.
Vielen Dank für diesen Bericht. Ich gespannt auf eine Fortsetzung und wie der Test von MicroOS + KDE „ausgeht“.
Da eigene Tests mit unveränderbaren Linux-Distributionen noch in Arbeit sind: Verstehe ich es richtig, dass bei Distrobox auch die Minimalumgebung einer anderen Distribution die Basis sein kann? Ich also unter MicroOS Distroboxen auf z.B. Arch- oder Ubuntu-Basis bauen kann?
Ja richtig. Es lohnt sich aber öfter die gleiche Basis zu nutzen, um von deduplication zu profitieren.
Hey Gerrit 👋🏻,
vielen lieben Dank für deinen Beitrag zu openSUSE MicroOS!
Ja, diese spezielle Variante aus der openSUSE-Welt hat einige Vorteile und aus diesem Grund habe ich sie nun auch schon seit einiger Zeit auf meinen Geräten im Einsatz und das bisher ohne größere Probleme.
Jedoch sollte man sich unbedingt mit der Kommandozeile auskennen, da man je nach Einsatzzweck einige Änderungen darüber tätigen muss.
Lg Steve (@cryinkfly)
Bei mir läuft Micro OS sauber, schnell und sehr sehr stabil …..alle meine Anwendungen sind als Flatpak verfügbar. Daher für mich vollkommen ausreichend. Zur Sicherheit habe ich (wie immer) ein Iso Image der Distro erstellt für den Fall der Fälle. Relevante Daten werden extern 2 mal gesichert ( solte eigentlich jeder mchen). Micro OS verhält sich wie ein System für´s Handy, nunja wer echter FOSS Fan ist wird vielleicht nicht glücklich sein?. Aber dafür gibt es die Vielfalt unter Linux!