Auf die Beta vom 3. März folgte nun die stabile Veröffentlichung von openSUSE Leap 15.4. Die Veröffentlichung basiert auf dem vor rund einem Monat erschienenen SUSE Linux Enterprise Server 15 SP4 (SLES) und ist mit diesem binärkompatibel.
Desktop-Umgebungen
Wie gewohnt ist KDE die Hausmarke von Leap 15.4 und wird als Plasma 5.24 LTS ausgeliefert. Dazu gehören auch KDE Frameworks 5.90.0 und KDE Gear 21.12.2, alles basiert auf Qt 5.15.2. Daneben wird Leap 15.4 auch mit GNOME 41.5 und Xfce 4.16 und in einer Rescue-Edition als Live-Editionen für x86_64 und ARM 64-Bit (aarch64) ausgeliefert. Ferner stehen LXQt, LXDE, Cinnamon, Mate 1.26, Enlightenment 0.25.3, der Wayland-Compositor Sway 1.6 und, neu hinzugekommen, Deepin 20.3 zur Installation bereit. Als Kernel kommt Linux 5.14.21 zum Einsatz.
SLE 15 SP4 als Basis
Die Paketbasis stammt von SLE 15 SP4, die aktualisierte Toolchain bietet unter anderem systemd 249.10, Mesa 21.2.4, LLVM 13.0, Python 3.10, PHP 8.1, Perl 5.26.1, Rust 1.59, Ruby 2.5 und Go 1.17. Die Abteilung Künstliche Intelligenz (AI) wird durch TensorFlow 2.6.2, PyTorch 1.4.0, ONNX 1.6 vertreten. Als Analyse- und Visualisierungswerkzeuge für den Einsatz auf Servern kommen Grafana 7.5.12 und Prometheus 2.2.3 hinzu.
Als Browser sind Firefox 91 ESR, Chromium 99 oder Gnome Web mit an Bord, LibreOffice wird in Version 7.2.5.1 ausgeliefert. In der Abteilung Audio werkeln PipeWire, WirePlumber und der Synthesizer LV2 , im Bereich Video unter anderem Blender, Kdenlive und Krita.
LEAP Micro 5.2
Neu mit Leap 15.4 ist Leap Micro 5.2, ein leichtgewichtiges, unveränderliches (immutable) Betriebssystem, das sich für Container und virtualisierte Workloads eignet und für die Erstellung und Weiterverarbeitung von Containern auf Fedoras Podman setzt. Es bietet sich für dezentrale Computerumgebungen, Edge-Anwendungen und Embedded/IoT-Implementierungen an. Workloads können auf SLES 15 SP4 oder SLE Micro verschoben werden.
Wie bereits beim Vorgänger Leap 15.3 können Benutzer auf SLES migrieren und die Workloads wie gewohnt weiterlaufen lassen. Mit dieser Version werden die Migrationsfähigkeiten weiter ausgebaut, da das YaST-Team ein vereinfachtes Migrationswerkzeug für Migrationen zu SLES entwickelt hat.
Abbilder für viele Zwecke
Neben den Live-Abbildern sind Offline-Installations-Images für 64-Bit-Desktops, PowerPC (ppc64le)-Server, UEFI ARM 64-Bit (AArch64)-Server und -Desktops sowie IBM System Z und LinuxONE (s390x)-Server verfügbar. Abbilder für virtuelle Maschinen und OpenStackgehören ebenfalls zum Angebot. Weitere Einzelheiten hält die Ankündigung der Veröffentlichung bereit.
Weiß jemand wie das mit Leap Micro funktioniert?
Vermutlich muss man dann von standard darauf Umstellen. Hat das jemand schon probiert?
Leap Micro 5.2 Demo (visual tutorial)
Bei der Installation musst Du den transaktionellen Server auswählen (bei der Auswahl der DEs). Aktuell gibt es im Gegensatz zu Tumbleweed MicroOS noch keine Desktop-Variante von Leap Micro.
Danke, genau das hatte ich schon probiert. Aber ohne Desktop ist halt auch doof. Wäre ne gute alternative zu Fedora Silverblue und co.
Da wird MicroOS zukünftig das Gegenstück zu Silverblue/Kinoite sein, sobald der Beta-Status mit Gnome, bzw. der Alpha-Status bei KDE durch ist. Ein Upgrade dort soll sich an den wöchentlichen Tumbleweed-Snapshots richten. Bis jetzt ist es aber nur zum Testen geeignet, da noch viele Baustellen zu meistern sind.
MicroOS gibt es auch als Desktop-Variante. Einfach MicroOS runterladen und bei der Installation Gnome auswählen. Gnome ist im Moment die unterstützte Umgebung während KDE noch im Alpha Stadium ist.
Wenn die Spekulation von distrowatch stimmt, wird Leap spätestens nach 15.5 eingestellt und User sollen nach SLES migrieren. Dazu passt das vorantreiben der Migrationstools. Das heißt, für die meisten war es das dann mit einem kostenlosen Community-SUSE, es sei denn man will Tumbleweed (also die Rolling Release Variante) nutzen und somit unbezahlter Tester für SLES werden.
Vielleicht gibt es dann für Developer eine kostenlose Variante von SLES, ähnlich wie bei RHEL, oder einen freien Fork, wie Alma oder Rocky Linux. Darauf wetten würde ich aber nicht.
Panikmache…
Leap hängt davon ab was SUSE mit SLE 16 vorhat. Da das aktuell noch niemand weiß, gibts nur eine Leap-Planung bis 15.5. Wenn SLE 16 ein minimales transactional System wird, dann Leap 16 eben auch. Das meinen die mit Ende von 15. Mehr nicht.
Und auf RHEL braucht man da nicht schauen. Die laufen in die gleiche Richtung.
Jetzt ist halt der harte Punkt erreicht. Das alte Linux der 90er und 2000er muss sterben, damit Linux eine Zukunft hat.
Dem letzten Absatz stimme ich bedingt zu. Für den Privatanwender darf das herkömmliche Linux gerne so bleiben, wie es ist. Viele Anwender sind sogar strikt gegen die anstehenden Veränderungen. Das ist aber normales menschliches Verhalten – wir wollen den Status quo erhalten. Treibende Kraft bei den Veränderungen ist Enterprise. Aber ohne Enterprise findet heutzutage kaum noch Entwicklung bei Linux statt.
Nichts anderes mein ich doch. Was Privatmensch will ist völlig egal und hat 0 Einfluss auf die Entwicklung von Linux. Wenn Enterprise glaubt das jetzt so machen zu müssen, weil es nur dann eine Zukunft für Linux gibt, dann läufts in diese Richtung. Privatanwender müssen dann mitspielen oder sich eine andere Plattform suchen. Wenn SUSE, Red Hat und Canonical ihre Pläne wirklich umsetzen, dann macht auch Debian bald was in die Richtung wenn die nicht endgültig aus Big Business rausfliegen möchten.
Debian wird hauptsächlich in der Freizeit erstellt, und nicht im “Big Business”. Damit gelten da etwas andere Randbedingungen. Debian lebt hauptsächlich von ihrem riesigen User-Land-Repo. Sollte Linux in Bezug auf Freizeitnutzung disfunktional werden, kommt da ganz schnell die Diskussion über alternative Kernel auf.
Generell hat LEAP immer wieder Ressourcen Probleme bei den Maintainern. Die meisten Maintainer und Nutzer arbeiten mit Tumbleweed und im openSUSE Management gibt es dazu immer mal wieder Diskussionen.
Bei Debian sieht es ähnlich aus, da hat sich z.B. kürzlich der KDE-Maintainer verabschiedet und ist zu Arch gewechselt. Dazu gibt es immer mal wieder Diskussionen.
Es hat nur einen einzigen Reboot gebraucht und mir war klar dass die Susi und ich auch dieses mal keine Freunde werden.
https://paste.opensuse.org/30146753
Ein uraltes Problem, dessen Lösung sich anscheinend immer noch nicht herumgesprochen hat (tritt vor allen Dingen auf wenn man openSUSE in einer VM startet):
Restart=on-failure
RestartSec=120s