SUSE Linux Enterprise Server 16 erschien im November 2025 und ist der Generationswechsel dieser Enterprise-Linie: Installation wandert zu Agama, die taegliche Verwaltung zu Cockpit, Ansible kommt mit, und ein ueber zwanzig Jahre altes Modulsystem faellt weg. Die ganze 16er Reihe traegt sechzehn Jahre Unterstuetzung, ueber die Grenze von 2038 hinaus.

Die Versionslinie wechselte eine Generation

Der Eintrag im Verzeichnis mag noch auf 15 SP7 stehen, doch die Wirklichkeit ist weiter: 16.0 oeffnete am 4. November 2025 als Nachfolger der 15er Reihe. Der offizielle Takt sind sieben Nebenausgaben von 16.0 bis 16.6, je eine im November, und jede Nebenausgabe traegt fuenf eigene Jahre, zwei regelmaessige plus drei in der Verlaengerung.

Auch die Namen aenderten sich: was ein Servicepack war, ist nun eine Nebenausgabe, und was Langzeit-Servicepack-Unterstuetzung hiess, heisst schlicht Langzeitunterstuetzung. Geaendert hat sich die Rechnung, denn ein Servicepack lebte einst so lange wie die Hauptversion, und jede Nebenausgabe zaehlt nun fuenf Jahre fuer sich.

YaST tritt in die Wartung zurueck

Das ist die Aenderung, die am deutlichsten gesagt werden muss. YaST ist seit 1996 die Marke von SUSE, und Installieren, Partitionieren, Netzeinrichtung und Dienstverwaltung liefen alle darueber. Ab 16 geht es in den Wartungsmodus: die 15er Reihe behaelt volle Unterstuetzung, und innerhalb der 16er Reihe treten drei Dinge an seine Stelle.

Die Installation geht an Agama, einen webbasierten Installer, dessen ganzer Ablauf im lokalen Browser oder aus der Ferne laeuft; der Kern ist in Rust geschrieben und bietet eine vollstaendige HTTP-Schnittstelle, was den Einbau in eine Automatisierungskette leicht macht. Er bleibt zu den alten Konfigurationsdateien kompatibel, sodass die meisten vorhandenen automatischen Installationen direkt gelesen werden, und er bietet zusaetzlich eine eigene JSON-Form, die nur die zu aendernden Teile beschreibt statt eines ganzen Partitionierungsplans.

Die taegliche Verwaltung geht an Cockpit, eine Webkonsole, in der Zustand, Protokolle und Leistung im Browser geprueft werden. SUSE hat einige eigene Anwendungen ergaenzt, sodass Softwarequellen, Paketinstallation und Aboverwaltung, die einst nur YaST konnte, nun auf einer Seite laufen. Die Automatisierung geht an Ansible, diesmal im System enthalten, mit Standardrollen fuer Firewall, Cluster, Sicherheitsrichtlinie und Container-Laufzeit; Salt kommt nicht mehr mit dem System und lebt nur als Teil eines Verwaltungsprodukts fuer mehrere Linux-Varianten weiter.

Das Modulsystem ist weg

Die Modulteilung der 15er Reihe, bei der Grundsystem, Serveranwendungen und Entwicklungswerkzeuge je ein Modul mit eigenem Paketvorrat und eigenem Aktualisierungskanal hielten, ist in 16 aufgehoben. Der offizielle Grund ist Vereinfachung: eine geschichtete Verzeichnisstruktur machte die Suche nach Flicken und die Entscheidung ueber Aufstiege schwerer, und ihr Wegfall verbesserte die Aktualisierungsleistung der Paketverwaltung.

Der Preis sind geaenderte Gewohnheiten. Erst ein Modul hinzufuegen, dann ein Paket installieren, gibt es nicht mehr, und Software kommt direkt aus dem Hauptverzeichnis; Nebenausgaben tragen weiter eigene Verzeichnisse, also zaehlt der Aufstiegspfad weiter nach Nebenausgabe. Fuer eine Maschine mit wenigen Diensten ist das einfacher, und fuer eine Umgebung, die mit Modulen ein zugeschnittenes Abbild schnitt, heisst der Umzug, neu zu ermitteln, was installiert war.

Momentaufnahmen und Ruecklauf werden Standard

Dateisystem-Momentaufnahmen mit Btrfs und Snapper kamen mit 12, und diese Ausgabe dehnt sie auf Wolkenabbilder aus, sodass das Verhalten auf Blech, in einer virtuellen Maschine und in der Wolke gleich ist. Wenn die Paketverwaltung oder die Webkonsole eine Aktualisierung anwendet, nimmt das System automatisch eine Aufnahme und haelt eine feste Zahl davon bereit; weil die Aufnahme auf der Ebene des Dateisystems sitzt, zeigt sie, welche Dateien sich aenderten, statt nur dass irgendeine Aktualisierung lief. Zusammen mit dem Laufzeit-Flicken, das diese Ausgabe in jede Fassung legt statt es einzeln zu verkaufen, lassen sich Kern-Sicherheitskorrekturen ohne Neustart einspielen.

Zwei Grundlagen unter der Sicherheit wechselten

Die verpflichtende Zugriffskontrolle wandert von AppArmor zu SELinux, mit einem Richtliniensatz aus ueber vierhundert Modulen. Fuer langjaehrige Nutzer ist das echte Umzugsarbeit: ein Dienst, den einst ein AppArmor-Profil durchliess, braucht nun eine SELinux-Richtlinie. Das andere Stueck sind reproduzierbare Bauten, bei denen derselbe Quelltext zu einem bytegleichen Ergebnis fuehrt, was mit Signatur und Nachweis belegt, dass ein veroeffentlichtes Abbild unterwegs nicht veraendert wurde. Das plus offene Verwaltung brachte der Distribution die Anerkennung als digitales Gemeingut.

Auch die Streichliste ist lang

Um die Angriffsflaeche zu verkleinern, verdient das Entfernte mehr Aufmerksamkeit als das Hinzugefuegte.

Auch der Schreibtisch schrumpfte mit und traegt nur ein minimales GNOME, das einen Browser, eine Dateiverwaltung und einen Betrachter fuer Bilder und Dokumente fuehrt, denn ein Serversystem muss fuer die gelegentliche grafische Aufgabe keinen ganzen Schreibtischstapel tragen.

Wie das Unterstuetzungsfenster zaehlt

Wer noch auf der 15er Reihe ist, muss sich nicht beeilen: 15 SP7 erschien im Juni 2025 mit regelmaessiger Unterstuetzung bis Ende Juli 2031 und verlaengerter Langzeitunterstuetzung bis Ende Juli 2034, also laufen zwei Generationen lange parallel. Beim Planen eines Aufstiegs zaehlt die Zeile der Nebenausgabe.

Hardwareschwelle und Architekturen

Das offizielle Minimum ist niedrig: eine CPU, 2 GB Arbeitsspeicher, 32 GB Speicher, genug fuer einen Server ohne grafische Oberflaeche. Die Architekturabdeckung ist das alte Stammfeld: x86-64, ARM, IBM Power und IBM Z stehen alle auf der Liste, was fuer ein Rechenzentrum mit gemischten Architekturen echten Wert hat.

Das Produkt kommt auch in mehr als einer installierbaren Form: eine Hochverfuegbarkeitserweiterung fuer Cluster und standortuebergreifendes Umschalten, eine Fassung fuer Hochleistungsrechnen mit paralleler Taktung grosser Cluster, eine Echtzeitfassung fuer bestimmte Taktung und geringe Verzoegerung, containerisierte und unveraenderliche Betriebsformen sowie eine fuer SAP-Anwendungen vorbereitete Fassung. Diese Ausgabe bringt zudem eine Host-Seite fuer das Model Context Protocol und holt Agenten-KI auf die Ebene des Betriebssystems, was derzeit jedoch eher eine Richtung als eine sofort nutzbare Funktion ist.

Wer es erwaegen sollte

Es passt zu Organisationen, die Server als langfristige Werte behandeln und einen klaren Horizont samt benannter Verantwortung brauchen: sechzehn Jahre, reproduzierbare Bauten und die Anerkennung als digitales Gemeingut gehoeren alle in Beschaffungs- und Pruefunterlagen. Es passt auch zu Umgebungen auf IBM Power oder IBM Z, wo kommerzielle Distributionen mit diesen Architekturen ohnehin knapp sind.

Umgekehrt ist eine ruhig laufende 15er Reihe kein Grund, am ersten Tag zu wechseln, denn YaST behaelt dort volle Unterstuetzung. Wirklich Arbeit machen Automatisierungsskripte, die auf Modulverzeichnissen beruhen, und Dienste, die AppArmor-Regeln durchliessen; diese zwei sind der Groessenteil der Umzugskosten, und sie vorher zu verstehen schlaegt das Jagen nach einer Versionsnummer.

SLES 16 ist ein Generationswechsel der Werkzeuge: Agama uebernimmt die Installation, Cockpit die Verwaltung, Ansible kommt mit, das Modulsystem faellt, Momentaufnahmen und Laufzeit-Flicken werden Standard. Es ist auch ein Generationswechsel des Wegwerfens, denn X11, Xen, VNC, eine Reihe alter Grafikbibliotheken und die 32-Bit-Unterstuetzung gehen alle. Sechzehn Jahre Unterstuetzung und zwei parallel laufende Generationen lassen Raum, im eigenen Takt umzuziehen.