Zusammenfassung

  • Ob ein einzelner Patch in einen stabilen Zweig aufgenommen wird, ist eine andere Prüfung als die Frage, wie lange eine ältere Kernel-Serie gepflegt werden kann.
  • Kernel.org verknüpft die Laufzeit mit dem Bedarf nachgelagerter Nutzer und der Verfügbarkeit der Maintainer. Ein prognostiziertes Enddatum ist daher kein kommerzielles Supportversprechen.

Ein älterer Kernel kann für ein Gerät noch Jahre nach seiner Veröffentlichung sinnvoll sein. Daraus folgt weder, dass jede vorgeschlagene Korrektur in seinen stabilen Zweig gelangt, noch dass dieser Zweig so lange gepflegt wird, wie das Produkt verkauft wird. Bei Linux gibt es hier zwei verschiedene Hürden. Wer sie vermischt, liest ein nützliches Versionsetikett als Zusage, die niemand gemacht hat.

Die erste Hürde gilt für jeden Patch. Die Regeln für stabile Kernel verlangen, dass die Korrektur oder eine gleichwertige Lösung bereits im Hauptzweig vorhanden ist. Sie muss offensichtlich richtig und getestet sein, darf einschließlich Kontext höchstens 100 Zeilen umfassen, muss den Einreichungsregeln folgen und entweder ein reales Nutzerproblem beheben oder eine Gerätekennung ergänzen. Als Beispiele nennt das Regelwerk Abstürze, Hänger, Datenverlust, echte Sicherheitsprobleme, Hardwarebesonderheiten und Buildfehler. Theoretische Risiken ohne Erklärung, wie sie ausgenutzt werden könnten, und Änderungen ohne Nutzen für Nutzer sind ausgeschlossen. Diese Grenzen erleichtern die Prüfung eines Backports und senken das Risiko, einen neuen Fehler in einen bereits eingesetzten Zweig einzuführen. Die Regeln für stabile Kernel beschreiben Kriterien und Einreichungswege.

Mit der Zulassung endet die Prüfung nicht. Das dokumentierte Verfahren legt angenommene Kandidaten in eine Warteschlange, bezieht Entwickler und den Maintainer des betroffenen Subsystems ein und testet das Ergebnis in Release-Kandidaten. Ein Einwand kann dazu führen, dass ein Patch wieder herausgenommen wird. Dass eine Änderung zuerst im Hauptzweig vorliegt, klärt ihre Herkunft; es verspricht nicht, dass jede ältere Serie sie automatisch erhält. Sie muss auf den Zielzweig passen und dort die Prüfung bestehen.

Die zweite Hürde betrifft die Lebensdauer des Zweigs selbst. Kernel.org beschreibt Langzeitserien als ältere Bäume, die wichtige Fehlerkorrekturen erhalten, meist seltener als aktive stabile Zweige. Bei der Auswahl spielen laut Release-Dokumentation größere neue Funktionen, der Bedarf kommerzieller Distributionen, die Nachfrage von Geräteherstellern sowie Arbeitslast und Verfügbarkeit der Maintainer eine Rolle. Eine neue Langzeitserie beginnt mit einem prognostizierten Enddatum. Dieses kann verlängert werden, wenn genügend Interesse aus der Industrie eine längere Pflege unterstützt. Die Prognose ist ausdrücklich nicht in Stein gemeißelt. Die für diesen Artikel abgerufene Seite ist auf den 25. Februar 2026 datiert; ihre Erläuterung der Auswahlpolitik ist brauchbar, ihre Versionsliste aber kein Stand für Oktober 2026. Kernel.orgs Release-Seite erläutert die Auswahlfaktoren und die Prognosen.

Greg Kroah-Hartmans Rolle ist wichtig, macht ihn aber nicht zum alleinigen Träger des Systems. Die Linux Foundation bezeichnet ihn als Fellow und als Maintainer des stabilen Linux-Zweigs sowie mehrerer Subsysteme. Das Dokument zum Entwicklungsprozess nennt Greg und Sasha Levin im Stable-Team und beschreibt auch die Beteiligung der zuständigen Maintainer und Reviewer. In einem Interview aus dem Jahr 2018 erinnerte sich Greg daran, einer der Entwickler gewesen zu sein, die 2005 beim Start stabiler Kernel-Releases freiwillig mitarbeiteten. Er sagte auch, dass er später mehr Zweige gleichzeitig pflegte, und stellte diese Arbeit in den Zusammenhang mit der Sicherheit bereits eingesetzter Geräte. Das ist seine rückblickende Schilderung, weder eine aktuelle Zahl gepflegter Zweige noch ein Beleg dafür, dass er allein über jede Langzeitserie entscheidet. Das Profil der Linux Foundation, das Dokument zum Kernel-Entwicklungsprozess und Gregs Interview grenzen seine Rolle ein.

Für Betreiber verändert dieser Unterschied, was ein Supportetikett aussagt. Eine Langzeitserie von Kernel.org ist eine gemeinschaftlich gepflegte Codebasis. Eine Distribution kann einen darauf basierenden Kernel ausliefern, eigene Änderungen ergänzen oder nach eigenem Zeitplan einen anderen Baum pflegen. Kernel.org verweist Nutzer von Distributionskerneln an den Support ihrer Distribution und weist darauf hin, dass Kernelentwickler diese Builds möglicherweise nicht unterstützen. Betreiber müssen deshalb feststellen, wer den Kernel im tatsächlich ausgerollten Image pflegt, welcher Weg Sicherheitskorrekturen und Regressionen abdeckt und ob die Zusage des Anbieters die Einsatzdauer des Produkts umfasst. Das LTS-Etikett beantwortet keine dieser Vertragsfragen. Die Kernel.org-FAQ und die Release-Seite unterscheiden diese Supportbereiche.

Der wirtschaftliche Mechanismus ist einfach, auch wenn eine Versionsnummer ihn verdecken kann. Jeder länger gepflegte Zweig kostet Arbeit: Jemand muss Korrekturen bewerten, Backports prüfen, Releases testen und auf Regressionen reagieren. Öffentliche Quellen beziffern weder die Stunden noch die Kosten. Sie zeigen aber, dass nachgelagerter Bedarf und die Verfügbarkeit der Maintainer beeinflussen, welche Serien länger Aufmerksamkeit erhalten. Nachfrage aus der Industrie kann den Aufwand rechtfertigen; sie ersetzt nicht die Menschen, die ihn leisten.

Heng Lus Note 64 liefert eine hilfreiche analytische Frage: Ein Koordinationsdokument kann einen künftigen Zustand beschreiben, setzt ihn aber nicht allein in Betrieb. Dieser Artikel behauptet nicht, Linux sei nach dieser Note entworfen worden. Als begrenzte Perspektive macht die Unterscheidung verständlich, warum „langfristig“ und ein prognostiziertes Enddatum keine selbstvollziehende Garantie sind. Sie beschreiben eine Vereinbarung, die weiter angenommen und gepflegt werden muss. Note 64 ist ein analytischer Bezugspunkt, keine Quelle zur Kernelpolitik.

Analyse

Die zwei Hürden verteilen Risiken auf unterschiedlichen Ebenen. Patchregeln begrenzen, was in einen bestehenden Zweig gelangt; die Auswahl von Langzeitserien begrenzt, wie viele ältere Zweige die Community weitertragen kann. Strengere Patchregeln schaffen keine jahrelange Personalkapazität, und eine hohe Industrienachfrage macht einen ungeprüften Backport nicht sicher. Eine praktische Zusage besteht nur, solange sowohl die Korrektur als auch die Pflegekapazität für ihren Zweig tragfähig bleiben.

Der Zeithorizont hängt von einer Koalition ab, die sich verändern kann. Gerätehersteller können ältere Kernel für bereits ausgelieferte Geräte benötigen, Distributionen eine stabile Basis für ihre Releases, und Maintainer brauchen Zeit für Prüfung und Tests. Öffentliche Quellen erklären weder die Aufteilung dieser Beiträge noch die Verhandlungsmacht einzelner Beteiligter. Sie zeigen aber, dass die Supportdauer von Bedarf und verfügbarer Arbeit abhängt und nicht allein vom Alter einer Versionsnummer.

Quellen