openSUSE Leap 15.4 in den Startlöchern

openSUSE lässt sich traditionell am Ende der Entwicklungs-Roadmap viel Zeit. Am 27. April erschien die RC-Version, einen Monat später erfolgte heute der Gold-Master-Build. Früher liefen dann die CD-Pressen an. Heute wartet man noch ein wenig bevor in zwei Wochen die Version final freigegeben wird. Höchste Zeit für einen tiefen Blick in die neue Version.

Diese Version ist im Wesentlichen eine Fortentwicklung der früheren Versionen der Leap 15-Serie:

Umstürzende Änderungen sind bei den Minor-Versionen einer Hauptserie nicht geplant. Ein umfassender Test entfällt daher, genau wie bei den Vorversionen auch schon. Stattdessen möchte ich ein wenig auf das Leap-Entwicklungsmodell eingehen, das immer noch bei vielen für Verwirrung sorgt, weil es nicht der von Debian geprägten “Standardnorm” für LTS-Distributionen entspricht.

Das Leap-Entwicklungsmodell

Die neue Version ist die jüngste Inkarnation der 15er-Serie von openSUSE Leap. Diese ist höchstwahrscheinlich die letzte traditionelle Linux-Distribution aus dem Hause SUSE/openSUSE, bevor man mit Version 16 in zwei Jahren auf die neue SUSE Adaptable Linux Platform wechselt. Die 15er Version folgt einem Wechselsystem. Auf eine sehr zurückhaltende Version – das war die letzte Version 15.3 – folgt eine Version mit mehr Aktualisierungen.

Um ein etwas schiefes Bild zu benutzen: Durch den Entwicklungsprozess von openSUSE gleicht die neue Version einem Menschen im fortgeschrittenen Lebensalter, dem man ein paar Organe erneuert und die Gesichtshaut ordentlich hinter die Ohren gezogen hat. Optisch ganz gut anzusehen und sollte noch eine Weile laufen, aber im Kern eben doch schon ein paar Jahre alt.

Der Hintergrund ist, dass jede openSUSE Leap Version sich an den Service Packs von SLE orientiert und eine Weiterentwicklung der Hauptversion darstellt. Ein solcher Zyklus kann durchaus mehrere Jahre gehen. Leap 15.0 erschien 2018, seitdem entwickelt man auf dieser Basis weiter. Die Anwender müssen dabei immer auf die neueste Minor-Version aktualisieren, um weiterhin Sicherheitsaktualisierungen zu erhalten. Das ähnlich ähnlich wie bei Red Hat, aber anders als bei z. B. Debian oder Ubuntu, wo alle zwei Jahre eine neue LTS zusammen gebaut wird, die dann 3-5 Jahre eingefroren wird und keine substanziellen Änderungen mehr erfährt.

Im Gegensatz zu den Debian-Entwicklern glaubt man bei SUSE (und mit Abstrichen auch Red Hat) diese Versionsaktualisierungen hinreichend gut testen zu können. Dahinter steht die Überzeugung, dass eine vorsichtige Aktualisierung unterm Strich mehr bringt als eine Bugsammlung über Jahre einzufrieren. Gleichzeitig sind einschneidende Änderungen neuen Hauptversionen vorbehalten. So ist bei Leap 15.4 der usr-merge ebenso noch nicht erfolgt, wie die weitere Einbeziehung von systemd-Diensten anstelle z. B. von chrony oder cronie. Den Wechsel auf Plasma 6 würde man – so er denn irgendwann mal kommt – sicherlich auch nicht in einer Minorversion vollziehen, den Sprung von 5.18 auf 5.24 aber eben schon.

Schaut man tiefer in die Paketquellen, sieht man, dass viele Pakete direkt von SUSE aus SLE kommen (Versionen enden auf 150400). Andere Pakete stammen von openSUSE (Versionen enden auf lp154 oder bp154). Ebenso gibt es unterschiedliche Updatequellen für SLE- und openSUSE-Pakete. Diese Feinheiten müssen Anwender aber eigentlich nicht interessieren.

Versionen

Das bedeutet konkret für die Versionen, dass die Desktopumgebungen von KDE Plasma 5.24 über GNOME 41 bis zu MATE 1.26 und Xfce 4.16 relativ aktuell sind und teils aktueller als bei komplett “neuen” Distributionen wie dem vor zwei Monaten veröffentlichten Ubuntu 22.04.

Der Kernel ist mit 5.14 schon ein wenig abgehangener, ebenso systemd 249. Beides aber nicht dramatisch alt und vermutlich nur relevant für Anwender von sehr aktueller Hardware oder sehr neuen Funktionen in systemd.

Schaut man dann tief in den Kern, sind Sachen wie glibc in Version 2.31 oder auch PolKit 0.116 richtig alt. Standardmäßig kommt für den GNU C Compiler die Version 7.5 zum Einsatz, GCC 10 und GCC 11 in aber in den Paketquellen enthalten. Eingefleischte openSUSE-Anwender werden das kaum seltsam finden, aber für Außenstehende wirkt das etwas seltsam. Unerwünschte Nebenwirkungen sind in meinen Tests aber nicht aufgetreten.

Installation und Vorkonfiguration

Installation und Vorkonfiguration wurden nicht verändert. Hier ist ein neuer Test also überflüssig. Als Standarddateisystem kommt Btrfs zum Einsatz, das mittels Snapper Betriebssystemschnappschüsse bei Updates anlegt. Datenpartitionen werden standardmäßig mit XFS angelegt, was bei einer dezidierten Home-Partition auch für diese zum Einsatz kommt.

Als Bootloader nimmt openSUSE GRUB 2.06. Man unterstützt Secure Boot und mittels Trusted Boot auch ein rudimentäres TPM-Measurement für den Boot-Prozess.

Die Verschlüsselung geschieht bei der Installation immer noch mit LUKS1 und das System benötigt weiterhin einen dezidierten root-Account. Neu ist die Möglichkeit bei der Installation SELinux anstelle von AppArmor aktivieren zu können. Die SELinux-Integration steckt bei SUSE aber noch in den Kinderschuhen und ich persönlich würde bei einem Produktivsystem davon absehen.

Nutzungserlebnis

Die Entwickler haben aus manchen vergangenen Fehlern gelernt. Die SLE-Updatequellen sind so schon seit längerem eingebunden. Allerdings ist der Entwicklungsprozess immer noch etwas schwierig und die Kommunikation zwischen SLE-Teams und openSUSE klappt manchmal nicht. Das hatte in der RC-Phase durch plötzliche massive Änderungen bei SLE SP4 einige Verzögerungen ausgelöst. Trotzdem halte ich unliebsame Überraschungen direkt nach dem Release dieses Jahr für nahezu ausgeschlossen.

Im täglichen Nutzungserlebnis profitiert man von der gut abgehangenen Basis, die lediglich an relevanten Stellen wie Kernel oder Mesa behutsam modernisiert wurde und den gleichzeitig aktuellen Desktopanwendungen. Da es hier bei den Desktopumgebungen quasi von KDE Plasma bis MATE und bei den Anwendungen von LibreOffice bis Firefox in den letzten Jahren keine umstürzenden Änderungen gab, sind diese aktuell sehr ausgereift und es entsteht eine wirklich gelungene Gesamtkomposition.

Fazit

Ein rundum gelungenes Release. Bestehende Anwender von openSUSE Leap können gefahrlos und mit Vorfreude aktualisieren. Ob Wechselwillige die Version zum Anlass nehmen umzusteigen, steht auf einem anderen Blatt. Nächstes Jahr kommt planmäßig dann noch mal eine deutlich moderatere Wartungsversion, bevor 2024 dann vermutlich revolutionäre Änderungen anstehen.

Leider haben die Entwickler nicht alle notwendigen Änderungen für systemd-homed zurück portiert, weshalb ich wohl bei Tumbleweed bleibe, da ich mich sehr an die TPM-Entsperrung mit zusätzlich abgesicherten Nutzerprofilen gewöhnt habe.

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. Die alten GLIBC Versionen sind ein wirkliches Hindernis. Android Studio und IntelliJ setzen für den file notifier zum Beispiel GLIBC 2.33 voraus.
    Auch im wine Umfeld, wie zum Beispiel spielen mit Lutris kann das durchaus mal Probleme verursachen.

  2. Ich tanze momentan zwischen openSUSE Leap und Fedora hin und her. Beide gefallen mir. openSUSE wegen seinen Tools und Flexibilität, Fedora wegen moderne Software und einem runden Gnome-Desktops, welches sehr hochwertig wirkt. Wenn aber GLIBC wirklich schon sehr veraltet ist, das manche Software, wie Android Studio evtl. Probleme machen, dann nutze ich lieber Fedora. Tumbleweed ist mir leider zu RR.

  3. Hallo Gerrit,
    ich danke dir für deine immer interessanten Artikel.

    Ohne dich hätte ich gar nichts davon mitbekommen, dass ich meine openSUSE auch mit TPM und verschlüsseltem Home-Verzeichnis einrichten kann. Bisher hatte ich nur SecureBoot mit Verschlüsselung genutzt. Dank dir konnte ich nun (endlich) sowohl TPM aktivieren für System mit LUKS2 und mein Home mit systemd-home verschlüsseln. Verlief reibungslos. Danke!

  4. Das viel kritisierte Stable-Paradigma von Debian scheint offenbar kein Hindernis zu sein, die aktuelle Kernellücke schnell zu beheben, während ich bei openSUSE noch keine aktuellen Pakete sehe.

Kommentieren Sie den Artikel

Ergänzungen dienen der Diskussion über die Inhalte des Artikels. Nachfragen, Anmerkungen und Ergänzungen sind dezidiert erwünscht. Ergänzungen werden vor der Veröffentlichung moderiert. Wir behalten uns vor Kommentare ohne inhaltlichen Bezug oder abseitige Diskussionen nicht zu veröffentlichen.

Bitte geben Sie Ihren Kommentar ein!
Bitte geben Sie hier Ihren Namen ein

Weitere Artikel