Suse Linux Enterprise 16 und openSUSE Leap 16: So könnte es weitergehen

1 min


Während die Entwicklung von SUSE Linux Enterprise (SLE) 15.4 und openSUSE Leap 15.4 auf Hochtouren laufen, sinnieren wir heute über die nächste Version von SLE und Leap.

Anlass ist ein Beitrag von Stefan Behlert auf der openSUSE Mailing Liste, der die einzuschlagende Richtung der nächsten Version grob skizziert. Immerhin erschien SLE 15 bereits im Jahr 2018 und nach nun rund vier Jahren darf langsam nach einem Nachfolger gefragt werden, wenn auch gleich SLE traditionell mit Langzeitpflege kommt.

Während bislang die „Closing the Gap“ Thematik, also der Zustand der Binärkompatibilität zwischen SLE und Leap im Fokus stand, scheint, nachdem diese Hürde erfolgreich mit 15.3 genommen wurde, nun der Blick Richtung Zukunft zu gehen.

So scheint die Zukunft von SLE in Richtung verschiedener Ebenen zu gehen. Also ein Kernbetriebssystem, welches um diverse Layer für Applikationen etc erweitert wird. Hierbei scheinen die Applikationen bei SLE über Software-Container und bei Leap via Flatpak realisiert zu werden.

Mit der nächsten Generation von Enterprise-Releases wollen wir die oben genannten Probleme angehen. In der Absicht, radikale Änderungen vorzunehmen (hinsichtlich Technologie, aber auch in Bezug auf das Design), wählen wir „Adaptable Linux Platform“ oder kurz „ALP“ als Codenamen für diese nächste Generation. Das deutet schon an, dass einiges ganz anders sein wird, als es ein „bloßes“ SLE 15 wäre 😉

[…]

Ein weiterer wichtiger Punkt ist, dass wir beabsichtigen alles, was eng miteinander verflochten ist, in zwei Teile aufzuteilen: Ein kleineres Art Betriebssystem zur Hardwaresteuerung, also eine Art „Host-Betriebssystem“, und die Schicht, die Anwendungen bereitstellt und unterstützt, welche Container (und VM) basiert sein wird.

Stefan Behlert

Weiter werden weiterführende Informationen über die Zukunftspläne für die kommenden Wochen in Aussicht gestellt. Letztlich war diese Entwicklung auch zu erwarten. Bereits heute experimentiert man mit MicroOS an einer entsprechenden Technologievorschau, die eine strikte Trennung von OS und App Layer realisiert. Auch im Hause Red Hat verfolgt man mit Fedora Silverblue ebenfalls diesen Ansatz.

Der Weg, ein Kernbetriebssystem anzubieten, welches dann um Layer für Anwendungen und Programme, die in verschiedenen Containerlösung realisiert werden, erweitert wird, zeichnet sich also bereits heute ab. Das traditionelle Systemkonzept von heute scheint perspektivisch abgelöst zu werden und muss sich an die Zeit anpassen. Natürlich nicht sofort und jetzt und gleich aber mittel- und langfristig dürfte sich dieses oder ein darauf basierendes Konzept durchsetzen und auch bei anderen Linux Distributionen Einsatz halten.


4 Comments

Deine E-Mail-Adresse wird nicht veröffentlicht. Erforderliche Felder sind mit * markiert

  1. Containerisierung von Anwendungen bedeutet ein Aufblähen der Datenmenge bei gleichzeitiger Verschlechterung der Performance. Das wäre der zweite große Irrtum der Linux-Welt nach systemd, und ein Grund mehr, sich mit FreeBSD zu befassen.

  2. Da SUSE so etwas nicht aus “Spass an der Freude” implementiert, sondern in Zusammenarbeit mit z.B. SAP oder Siemens (Solid Edge), macht so eine Lösung durchaus Sinn. Ich gehe davon aus, daß sich der Wartungsaufwand, vor allem für propietäre Software damit verringert. Nicht ohne Grund ist z.B. SAP nur für ganz wenige Distributionen zertifiziert. Und eine Flatpak-basierte openSUSE Lösung hat auch für den Privatnutzer Vorteile. Die Software kommt jetzt (vorzugsweise) direkt vom Hersteller und Katastrophen beim Paketieren (“Debian openSSL Bug”) werden vermieden.

  3. @F.Fischer:
    Gemäß SAP PAM wird SLE weiter unterstützt. Auch wird SUSE für SLE LTS Support anbieten. Also SLE12 und SLE15 werden nicht von heute auf morgen aus dem Support gehen. SLE selbst wird ja von ALP abgelöst: https://www.michlfranken.de/suse-veroeffentlicht-adaptable-linux-plattform-prototyp/
    Wie sich das dann auf eine SAP Installation auf ALP Basis auswirkt, da bin ich auch mal gespannt, denn als Flatpak Container gibts das nicht und ich denke auch nicht, dass Flatpak hier die Lösung sein wird, sondern Kubernetes für Enterprise Lösungen wie SAP.

  4. @MichlFranken:
    Da habe ich mich wohl unklar ausgedrückt. Ich meinte natürlich, dass eine Containerlösung möglicherweise SLES ersetzen wird und eine Flatpaklösung möglicherweise LEAP ersetzen wird. Beide Lösungen (ALP und Micro OS Desktop) scheinen im Unterbau ja ziemlich ähnlich zu sein.
    SUSE/openSUSE wird sich in Zukunft also rein auf den Unterbau konzentrieren. In ferner Zukunft wäre sogar eine Echtzeitlösung, basierend auf RTAI oder Xenomai, für die Automatisierungsbranche denkbar (da wo richtig Geld verdient wird, der Unterbau aber auch unbedingt stabil sein muss). Schließlich ist SUSE nur ein paar Kilometer von Siemens Automation in Erlangen entfernt. 😉 Warten wir es ab.
    Das alles kann man jetzt mögen oder hassen, aus Sicht von SUSE kann ich die neue Richtung jedenfalls verstehen.