Während der Versionssprung von KDE Plasma 5 auf 6 bei Tumbleweed und Leap geräuschlos verlaufen dürfte, nimmt die Umstellung auf die neue Architektur von OpenSuse Leap 16 Zeit in Anspruch.

OpenSuse-Anwendern stehen Veränderungen ins Haus: Die beliebte Desktop-Umgebung KDE wagt den Sprung zur neuen Major-Version 6 (Abbildung 1). OpenSuse Leap, die Spielart ohne rollend aufgefrischte Softwareversionen, muss ihren Entwicklungsprozess wegen Veränderungen bei der Enterprise-Sparte [1] von Suse, auf die Leap aufbaut, ebenfalls grundlegend umstellen.

Als Suse vermeldete, das Flaggschiff SLE in eine Container-Laufzeit-Umgebung umzuwandeln, die nur noch aus einem minimalen Grundsystem besteht, drohte für OpenSuse-Leap die Hauptquelle der mitgelieferten Pakete wegzubrechen. Inzwischen nähren experimentelle Vorabtests [2] die Hoffnung, dass sich Leap in ähnlicher Form auch auf der Basis der neuen Enterprise-Produkte erstellen lässt. Zudem hat sich Suse zu der Ankündigung durchgerungen, das klassische Leap fürs Erste weiter ohne Containerisierung und immutables Dateisystem anbieten zu wollen [3].

Während also der neue KDE-Desktop Tumbleweed-Anwender bereits im März 2024 erreicht und Leap-Anwender mit der nächsten Ausgabe 15.6 gegen Ende des Jahres, ist mit der neuen Leap-Architektur nach aktueller Planung frühestens 2025 zu rechnen.

Abbildung 1: Plasma 5 (oben) und 6 gleichen sich, doch Neuerungen spendieren die Entwickler nur noch Plasma 6.

Widerstand zwecklos

Bei Linux-Veteranen ruft das Thema KDE-Major-Versionssprung immer noch Erinnerungen an die Umstellung vom stabilen, ausgereiften KDE 3 auf das lange Zeit technisch wacklige KDE 4 wach. Dessen viele neue Bedienkonzepte stießen anfangs auf wenig Gegenliebe.

Beim Umstieg von KDE 4 auf KDE 5 spielten sich die Veränderungen, abgesehen von einer aufgefrischten Optik, größtenteils unter der Haube ab. Das galt vor allem beim Umstieg auf Qt 5 als Bibliothek für die Anzeige grafischer Oberflächen. Der 2023 endende Support des jetzt eingesetzten Qt 5 ist, wie schon beim Übergang von KDE 4 zu 5, einer der bestimmenden Faktoren für das Erscheinen der neuen KDE-Plasma-Version 6.

Eine Notwendigkeit, den Desktop für KDE Plasma 6 von Grund auf umzukrempeln, sahen die Entwickler erneut nicht, wie die handliche Liste der die Anwender betreffenden Änderungen zeigt [4]. Zusätzlich erwähnenswert sind zwei technische Verbesserungen: KDE stellt den Mauszeiger endlich hardwarebeschleunigt dar, sodass nun bei Mausbewegungen keine CPU-Last mehr anfällt. Das spart auf Laptops etwas Strom. Zudem zieht der Mauszeiger nun beim Einsatz einer Nvidia-Karte und eingeschaltetem Unschärfe-Filter auf semitransparenten Oberflächen keine hässlichen Schlieren mehr hinter sich her.

Auch noch nicht ausgeräumte Bugs von Plasma 6 listen die Entwickler auf [5]. Wer auf die Links Plasma**6 issues , Frameworks**6 issues**+ Plasma**6 issues oder All Qt6-related issues klickt, findet im KDE-Bugtracker 300 und mehr gemeldete Fehler, die allerdings überwiegend nicht alle Anwender betreffen. Insgesamt scheint die Fehlerzahl für ein Projekt mit diesem Umfang und vielen Anwendern eher durchschnittlich. Zumindest im Kurztest traten keine gravierenden Fehlfunktionen oder Abstürze zutage, und zwar sowohl unter X11 als auch unter Wayland.

Während Tumbleweed-Nutzer KDE Plasma 6 bald nach Erscheinen Ende Februar als reguläres Update erhalten, müssen Leap-15.5-Anwender die KDE-Version aus dem Repository KDE-unstable [6] installieren, um KDE 6 begutachten zu können. Es ist nicht möglich, KDE 5 und 6 parallel zu installieren. Ist Version 5 eingerichtet, führt ein Upgrade auf Version 6 im Paketmanager zu zahlreichen Abhängigkeitskonflikten, ebenso wie der umgekehrte Versuch, nach KDE 6 auch noch KDE 5 zu installieren (Abbildung 2).

Abbildung 2: Viele KDE-5- und KDE-6-Komponenten stehen in Konflikt zueinander und lassen sich nicht gleichzeitig installieren.

Prinzipiell lassen sich die Konflikte durch Wahl der richtigen Optionen bei entsprechenden Meldungen im Paketmanager auflösen, indem man stets die auslösende KDE-5-Komponente deinstalliert. Als wesentlich einfacher erweist es sich, das System zuvor ganz vom alten KDE-Desktop zu befreien (Abbildung 3), was der Aufruf zypper rm *kde* erledigt. Noch einfacher ist es, mit einer Neuinstallation zu starten, bei der Sie einen anderen Desktop als KDE wählen (Abbildung 4). Gegebenenfalls können Sie später nach Deinstallation aller Plasma-6-Pakete KDE Plasma 5 neu installieren.

Abbildung 3: Plasma-5-Pakete verursachen bei der Installation des Plasma-6-Desktops Konflikte und müssen weichen. Am besten gelingt dies auf der Kommandozeile statt in YaST.

Abbildung 4: Installieren Sie ein Leap-System mit KDE Plasma 6 neu, wählen Sie am besten die Option Allgemeiner Desktop: Das beschleunigt die Installation. Eine X-Term-Konsole, um den KDE-Desktop einzuspielen, findet sich sogar im IceWM-Startmenü.

Das OpenSuse-Wiki nennt die URLs der KDE-6-Repositories [7]. Für Leap 15.5 verwenden Sie im Falle eines Falles die als Root auszuführenden Kommandozeilenaufrufe aus den ersten sechs Zeilen von Listing 1. Ein passender Aufruf von zypper dup (Zeile 7) vollzieht danach eine Umstellung der Systempakete auf die neuen Repositories, zu guter Letzt installieren Sie die Desktop-Umgebung (Zeile 8). Kommt es zu Dateikonflikten, wählen Sie Fortfahren, um einen vollständigen lauffähigen Desktop zu erhalten. Die Umstellung geht allerdings nicht immer ganz ohne nervige Abhängigkeitskonflikte über die Bühne.

# zypper ar -p 75 https://download.opensuse.org/repositories/KDE:/Qt5/openSUSE_Leap_15.5/ kde6_qt5
# zypper ar -p 75 https://download.opensuse.org/repositories/KDE:/Qt6/openSUSE_Leap_15.5/ kde6_qt6
# zypper ar -p 75 https://download.opensuse.org/repositories/KDE:/Frameworks5/openSUSE_Leap_15.5/ kde6_frameworks5
# zypper ar -p 75 https://download.opensuse.org/repositories/KDE:/Frameworks/openSUSE_Leap_15.5/ kde6_frameworks6
# zypper ar -p 75 https://download.opensuse.org/repositories/KDE:/Applications/KDE_Frameworks5_openSUSE_Leap_15.5/ kde6_applications
# zypper ar -p 75 https://download.opensuse.org/repositories/KDE:/Extra/KDE_Applications_openSUSE_Leap_15.5/ kde6_extras
# zypper dup --allow-vendor-change
# zypper in -t pattern kde_plasma6

Fundamentaler Umbruch

Zwar befindet sich die KDE-Entwicklung auf einem guten Weg, doch haben sich viele in letzter Zeit besorgt gefragt, ob das auch für OpenSuse gilt: Seit Stefan Behlert, Produktmanager von des Suse-Enterprise-Linux SLE, im April 2022 einen radikalen technischen Wandel bei der Enterprise-Distribution SLE (Abbildung 5), der Basis von Leap, angekündigt hat, brodelte es in der Gerüchteküche.

Abbildung 5: Basis für Leap 15 war der kommerzielle Suse Linux Enterprise Server 15, den Freiwillige mit eigenen Paketen anreicherten.

Klar war damit, dass der bisherige Entwicklungsprozess der Leap-Ausgaben, der auf eine stabile Basis aus der Enterprise-Distribution SLE aufsetzt und diese mit aktuelleren Anwendungen aus Tumbleweed anreichert, nicht mehr wie bisher fortzuführen war. Zudem äußerte das damalige OpenSuse-Board-Mitglied Axel Braun auf der OpenSuse-Konferenz 2022 die Ansicht, das bisherige Leap-Release-Modell sei ohnehin am Ende [8], da die stabile, aber veraltete SLE-Systembasis sich zu sehr als Hemmschuh für die Bereitstellung aktueller Anwendungen auswirke.

Um den im Enterprise-Bereich offenbar verstärkt geforderten Spagat zwischen einem stabilen, zertifizierbaren Systemkern und dennoch ausreichend aktuellen Anwendungen zu ermöglichen, entwarf Suse das Konzept der Adaptable Linux Platform (ALP [9]). Dabei bildet ein sehr schmales Grundsystem die Basis für in abgeschotteten Containern installierte Anwendungen. Für zusätzliche Sicherheit soll ein im laufenden System nur lesbar eingehängtes (“immutables”) Root-Dateisystem sorgen.

Abgeschottet bedeutet bei der ALP-Architektur: Jeder Container bringt seine eigenen Abhängigkeiten (Bibliotheken) mit. Es ist dann gleichgültig, wie aktuell oder abgehangen das Grundsystem ausfällt. Im Unternehmensumfeld ist es schon lange Praxis, vorinstallierte Container im standardisierten OCI-Format zu nutzen: Dass derselbe Container auf SLE-, Red-Hat- oder Debian-Systemen unterschiedlichster Version seinen Dienst tut, erleichtert es, Anwendungen in gründlich getesteter Version auf vielen Rechnern auszurollen.

Massentauglich?

Auf einem Server im Unternehmen laufen allerdings meist nur eine Handvoll Dienste. Dagegen kommen bei Desktop-Anwendern schnell über hundert Programme zusammen, um den ganzen Arbeitsalltag abzudecken. Die Palette reicht von Webbrowser und E-Mail-Client über Software zur Foto- und Grafikbearbeitung bis hin zu Hobby-Programmen, etwa für den 3D-Druck.

Tatsächlich gibt es eine auf Heimanwender zugeschnittene Container-Technologie, die diese Anforderungen mit zwischen den einzelnen Anwendungen geteilten, jedoch ebenfalls vom Grundsystem unabhängigen Laufzeitumgebungen bewältigt: Flatpak  [10]. Die distributionsübergreifend lauffähigen Pakete lassen sich auch unter OpenSuse installieren (Abbildung 6).

Abbildung 6: Das Flathub-Repository stellt unzählige auf allen gängigen Linux-Distributionen einsetzbare Anwendungspakete bereit.

Mit Containern aus dem Enterprise-Bereich und der Suse-ALP-Architektur haben Flatpaks hinsichtlich der Bedienung wenig gemeinsam. Anwender installieren Flatpaks komfortabel in App Stores nachempfundenen Anwendungen (Abbildung 7), in denen sich Smartphone-Besitzer sofort heimisch fühlen. Ein Kommandozeilenwerkzeug gibt es mit flatpak [11] ebenfalls. Dass es sich bei Flatpak letztlich um eine Container-Technologie handelt, können Durchschnittsanwender getrost ignorieren.

Abbildung 7: Der Gnome-Software-Store (links) und sein KDE-Gegenstück erschließen sich Einsteigern rasch.

Im September führte Suse eine Umfrage unter den ehrenamtlichen OpenSuse-Entwicklern durch, für welchen zukünftigen Aufbau von Leap sie sich engagieren würden [12]. Die Umfrage ergab einen eher knappen Sieg für die Option Linarite [13]. Das ist der Name für eine experimentelle Leap-Fassung in Form einer konventionell aufgebauten Distribution, jedoch auf Basis der ALP-Paketquellen der zukünftigen Suse-Enterprise-Distribution Granite.

Über Suse Granite weiß man bisher wenig, außer dass es sich dabei um die künftige Enterprise-Fassung handeln soll, die dem bisherigen SLE-System mit vollem Desktop- und Server-Paketumfang am nächsten kommt. Ungeachtet des knappen Siegs für eine Release-Prozess-Variante zeigt das Umfrageergebnis aber vor allem eines deutlich: dass derzeit nur wenige freiwillige Entwickler überhaupt ihre Beteiligung zusagen wollen.

Willensbekundung

Umso dankbarer dürften Anhänger der stabilen OpenSuse-Fassung Leap eine Mitteilung der Firma Suse im Januar 2023 aufgenommen haben [3], die eine neue Leap-Major-Version 16.0 für Ende 2025 ankündigte (Abbildung 8). Dabei sicherte das Unternehmen eine durchgängige Unterstützung von Leap sowie ausreichend Zeit für den Umstieg und praktikable Upgrades auf die neue Major-Version zu. Sollte die Ablösung durch Leap 16 länger als geplant dauern, dann steht eine weitere Leap-Fassung 15.7 nach bisherigem Strickmuster an. Das siebte Service-Pack von SLE 15 als Basis dafür ist jedenfalls beschlossene Sache.

Abbildung 8: Für die Ankündigung der Planung zu Leap 16 haben die Entwickler ein goldenes Namensschild gemalt.

Die Ankündigung erwähnt, dass Leap 16 dann tatsächlich auf ALP-Grundlage basiert, also auf einer Container-basierten Architektur. Da diese durchschnittlichen Heimanwendern das Verständnis und die Administration ihres Leap-Systems erschweren oder gar unmöglich machen würde, wird Leap selbst jedoch nicht so aufgebaut sein, jedenfalls nicht in der Standardfassung.

Tatsächlich steht ein so strukturiertes OpenSuse-Leap-System mit Leap Micro (Abbildung 9) schon seit einiger Zeit bereit [14]. Die News-Meldung kündigt nun parallel zu Leap 16.0 eine neue Version dieser Sonderform von Leap, Leap Micro 6, an. Sie erscheint als freies OpenSuse-Pendant zum kostenpflichtigen MicroOS der Enterprise-Sparte.

Abbildung 9: Das für kleine, monitorlose Geräte optimierte Leap-Micro-System wird ebenfalls weitergeführt.

Wenn überhaupt, dann wäre die Container-basierte Desktop-Fassung Aeon als Leap-Ersatz prädestiniert [15]. Sie baut auf MicroOS auf, ist aber dank ihres fertig eingebundenen Gnome-Containers als Desktop-Linux konzipiert. Den Namen MicroOS möchte Suse in Zukunft für den Server-Bereich reservieren, weswegen die Umbenennung von MicroOS Desktop in Aeon erfolgte. Die OpenSuse-Tipps 12/2023 haben Aeon (Abbildung 10) bereits getestet und als vielversprechenden Ansatz befunden. Allerdings kam Aeon seit dem Test nicht aus dem Release-Candidate-Status heraus. Eine KDE-Ausgabe mit vergleichbarer Architektur, Kalpa, befindet sich noch in einem frühen Entwicklungsstadium.

Abbildung 10: Ein containerisiertes, als MicroOS aufgebautes System kann einen Desktop beherbergen, hier als OpenSuse Aeon mit Gnome-Login. Anwendungen sind als Flatpaks zu installieren.

Doch auch Aeon und Kalpa sollen nicht die Standard-Leap-Ausgabe ersetzen: “Aeon is NOT for everyone”, heißt es in der Produktbeschreibung klar und deutlich. Die OpenSuse-Entwickler sind sich durchaus bewusst, dass sich bei der klassischen Systemarchitektur ohne Read-only-Systempartition um die von den meisten Leap-Anwendern bevorzugte Option handelt.

Oft zitieren die OpenSuse-Entwickler auf ihrer Mailing-Liste die Download-Statistiken, bei denen Leap vor Tumbleweed liegt [16]. Dieses Augenmerk auf die Nutzerzahlen ist vor dem Hintergrund zu sehen, dass sich beim heutigen Umfang eines Linux-Systems eine qualitativ hochwertige Enterprise-Distribution keinesfalls mehr allein auf Basis firmeninterner Tests realisieren lässt. Die Unternehmenssparte ist heute auf die Bug Reports der OpenSuse-Anwender angewiesen und will auf die Leap-Benutzer dabei nicht verzichten.

Wenn also die Rede davon ist, dass Leap 16 auf der neuen ALP-Platform “basieren” soll, bedeutet das, dass es seine Pakete von dort bezieht. Dass es die containerisierte Systemarchitektur der ALP-Unternehmens-Systeme übernimmt, folgt daraus nicht zwingend: Wie erwähnt ist den Entwicklern klar, dass eine solche Verkomplizierung viele Leap-Anwender vor den Kopf stoßen würde.

Neu aufgestellt

Die Pakete des Grundsystems hat Leap bisher schon von der Enterprise-Sparte bezogen. Allerdings weicht künftig die SLE-Basis, ein breit ausgelegtes System für den Server- und Desktop-Einsatz, einer mutmaßlich schmäler aufgestellten Distribution auf ALP-Basis. Auf der Habenseite bedeutet ALP für Suse, dass die Firma nicht mehr nur das eine System SLE für alle Unternehmensanforderungen anbieten kann, sondern mehrere, mit unterschiedlich schnellen oder konservativen Release-Zyklen.

Das nährt die Hoffnung, dass nicht länger zu alte Komponenten des Grundsystems der konservativen SLE-Basis die Aktualisierung der Desktop-Programme in Leap blockieren. Als Preis dafür könnte die Paketausstattung in Leap kleiner ausfallen als bisher, sodass nicht OpenSuse-spezifische Flatpaks die bisher ausschließlich nativen Pakete ergänzen.

Es ist fest geplant, im Leap-Installer wie bisher die Installation eines klassischen Linux-Systems ohne Immutabilität/Read-Only-Systempartition anzubieten. Schon jetzt kennt der Installer die Option Transaktionaler Server, richtete also ein Immutable-System ein, wenngleich lediglich mit einer Paketauswahl ohne GUI für den Server-Bereich. Nun soll die Immutability-Option auch für eine Desktop-Paketauswahl zur Verfügung stehen.

Der Leap-Installer erweitert also schlicht seinen Umfang auf immutable und nicht immutable Desktop- und Server-Systeme mit unterschiedlichsten Arbeitsumgebungen (Abbildung 11). Der Installer der einheitlichen DVD stellt alle verfügbaren Desktops zur Wahl. In Zukunft braucht OpenSuse Leap dann keine Spins mehr für Spielarten mit unveränderlichem Dateisystem, wie Fedora Silverblue [17]: Auch diese Option wird der Standard-Installer abdecken.

Abbildung 11: Einmal grün statt bunte “Flavors”: Der OpenSuse-Installer auf der einheitlichen DVD bietet viele Desktops zur Auswahl an.

Tatsächlich setzt OpenSuse ja schon lange auf eine Btrfs-Systempartition mit einem bei jeder Softwareinstallation automatisch angelegten Schnappschuss. Der Unterschied zwischen einem immutablen und einem nicht immutablen System liegt dann praktisch nur in einer Veränderung der Konfigurationsdatei /etc/fstab. Als Konsequenz des Read-only-Dateisystems ruft man zur Softwareinstallation nicht mehr zypper auf, sondern transactional-update (Abbildung 12), das dem Zypper-Aufruf vollautomatisch die Snapshot-Verwaltung vorschaltet.

Abbildung 12: Wer Zypper zur Paketinstallation gewohnt ist, braucht es auf immutablen Systemen nur durch Transactional-update zu ersetzen und den Befehlen install, remove und update das Wort pkg voranzustellen.

Der Vorteil einer nur lesend eingehängten Systempartition, neuhochdeutsch immutabel oder System mit transaktionalen Updates genannt, besteht vordergründig im Schutz gegen Schadsoftware. In der Praxis bedeutsamer ist aber die Tatsache, dass hier Updates automatisch im Hintergrund vonstattengehen, ohne das laufende System zu tangieren. Zur für ihn passenden Zeit startet der Anwender den neuen Systemzustand per Reboot. Transaktional bedeutet, dass der neue System-Snapshot nur dann zustande kommt, wenn das Update vollständig und ohne Fehler durchläuft (Abbildung 13).

Abbildung 13: Kein Zwangs-Reboot: Im Hintergrund stellt Aeon Upgrades in einem nach dem Neustart aktiven Snapshot bereit. Leap soll auf Wunsch in Zukunft diese Systemarchitektur ebenfalls anbieten.

Integrieren die Leap-Entwickler in immutabel eingerichtete Systeme noch das Tool Health-checker, wie jetzt schon bei Aeon, dann kehrt Leap sogar automatisch zum letzten als funktionierend bekannten Snapshot zurück, sollte nach einem Update zum Beispiel die Desktop-Umgebung nicht mehr starten.

Fazit

Leap soll von seiner Ausrichtung und Architektur her gemäß der inzwischen klar kommunizierten Planung bleiben, was es ist: ein möglichst stabiles Desktop-System, das nicht durch allzu häufige Updates und Versionssprünge nervt.

Wer das nicht möchte, braucht sich nicht mit Neuerungen wie immutablen Systemen oder gar Container-Payloads herumzuschlagen – außer vielleicht beim vermehrten Einsatz von Flatpak-Paketen. Doch die lassen sich in ihren Smartphone-Pendants nachempfundenen App Stores installieren, ohne dass der Anwender überhaupt wissen muss, dass es sich dabei um Container-Technologie handelt.

Ohnehin erreicht diese Umstellung frühestens Ende 2025 die Anwender, die eigentliche Entwicklungsarbeit hat noch nicht einmal begonnen. Suse kommuniziert nun jedoch eine klare Richtung, nachdem gut eineinhalb Jahre verschiedene Gerüchte und experimentelle Ansätze die Anwender verwirrt haben. Die Verwirrung sollte man Suse nachsehen: Immerhin hat das Unternehmen klar einem offenen Prozess gegenüber einer Entscheidung hinter verschlossenen Türen den Vorzug gegeben. (uba)