openSUSE MicroOS mit KDE Plasma

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       system

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.

Cruiz
Cruizhttps://curius.de
Moin, meine Name ist Gerrit und ich betreibe diesen Blog seit 2014. Der Schutz der digitalen Identität, die einen immer größeren Raum unseres Ichs einnimmt ist mir ein Herzensanliegen, das ich versuche tagtäglich im Spannungsfeld digitaler Teilhabe und Sicherheit umzusetzen. Die Tipps, Anleitungen, Kommentare und Gedanken hier entspringen den alltäglichen Erfahrungen.
  1. 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.

    • 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.

  2. Vielen Dank für diesen Bericht. Ich gespannt auf eine Fortsetzung und wie der Test von MicroOS + KDE „ausgeht“.

  3. 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?

  4. 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)

  5. 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!

Kommentarfunktion ist geschlossen.

Weitere Artikel