Linux-Kernelgeschichte: Entscheidungen, die Bestand haben

Die Kurzfassung der Linux-Kernelgeschichte

Die Geschichte des Linux-Kernels reicht von Version 0.01 im September 1991 bis zur 7.x-Serie, die heute auf Servern startet. Die Liste der Releases ist dabei der uninteressanteste Teil. Einige wenige Entscheidungen haben die Struktur des Kernels geprägt. Jede davon wirkt sich noch heute auf einen Server aus, den Sie an diesem Nachmittag mieten.

Die Datums- und Versionsangaben stammen von kernel.org und aus der dort veröffentlichten Release-Historie. Stand August 2026: Version 7.0 erschien am 12. April 2026, Version 7.1 am 14. Juni 2026, und für Version 7.2 gibt es Release Candidates.

Warum die GPL-Entscheidung von 1992 noch immer wichtig ist

Version 0.01 wurde am 17. September 1991 unter einer von Torvalds selbst verfassten Lizenz veröffentlicht. Sie verlangte, dass der Quellcode verteilt wird, und enthielt eine weitere, wichtigere Zeile: "You may not distribute this for a fee, not even 'handling' costs." Im Jahr 1991 wurde Software auf Disketten ausgeliefert, und das Kopieren und Versenden von Disketten kostet Geld. Diese Klausel machte eine kommerzielle Linux-Distribution unmöglich.

Er änderte die Lizenz. Der Wechsel zur GNU General Public License (GPL) wurde in den Versionshinweisen zu Release 0.12 im Januar 1992 angekündigt und trat am 1. Februar 1992 in Kraft. Version 0.95 war im März 1992 das erste unter dieser Lizenz veröffentlichte Release. Jedes Unternehmen, das später auf Linux aufgebaut wurde, beruht auf dieser Änderung.

Der Kernel steht ausschließlich unter GPL version 2 und wurde nie auf version 3 umgestellt. Torvalds lehnte dies 2007 ab, hauptsächlich wegen der Anti-Tivoisierung-Regel in GPLv3. Diese verlangt, dass ein Gerät, das GPL-Code ausliefert, auch eine modifizierte Kopie dieses Codes akzeptiert. Er betrachtete gesperrte Hardware als eigene Geschäftsentscheidung des Herstellers. 2017 veröffentlichten Kernel-Entwickler das Kernel Enforcement Statement. Es übernimmt dennoch einen Bestandteil von GPLv3: Wer einen Verstoß behebt, nachdem er darauf hingewiesen wurde, behält seine Lizenz, statt sie beim ersten Verstoß dauerhaft zu verlieren.

Auf einem Server ergeben sich daraus zwei Konsequenzen. Das von Ihnen gestartete Kernel-Binary gewährt das Recht auf den zugehörigen Quellcode. Niemand kann Ihnen daher einen Linux-Kernel übergeben, den Sie nicht prüfen oder neu bauen dürfen. Außerdem besagt der Copyright-Hinweis im Kernel, dass die Lizenz keine Benutzerprogramme abdeckt, die Kernel-Dienste über normale Systemaufrufe verwenden. Deshalb können proprietäre Datenbanken und Monitoring-Agenten für Linux ausgeliefert werden, ohne gegen die Lizenz zu verstoßen. Eine permissive Lizenz erzeugt den gegenteiligen Druck. Diesen Unterschied sollten Sie verstehen, bevor Sie sich für eine Plattform entscheiden: siehe Linux und FreeBSD als Serverplattformen.

Warum sich der monolithische Kernel in der Praxis durchsetzte

Am 29. Januar 1992 veröffentlichte Andrew Tanenbaum eine Nachricht mit dem Titel "LINUX is obsolete" in der Newsgroup comp.os.minix. Er stellte zwei Behauptungen auf. Monolithische Kernel, bei denen Treiber und Dateisysteme in einem einzigen privilegierten Adressraum ausgeführt werden, seien ein Entwurf aus den 1970er-Jahren. Mikrokernel, bei denen diese Komponenten als normale Prozesse laufen, seien dagegen die Zukunft. Außerdem sei Linux fest an den Intel 386 gebunden und werde daher niemals auf andere Plattformen portiert werden.

Die Behauptung zur Portierbarkeit wurde durch Portierungen widerlegt. Version 1.2 fügte im März 1995 Unterstützung für Alpha, SPARC und MIPS hinzu. Version 2.0 ergänzte im Juni 1996 eine 64-Bit-Portierung für Alpha.

Die Behauptung zum Entwurf wurde durch einen Kompromiss beantwortet. Linux wurde nie zu einem Mikrokernel. Stattdessen erhielt es ladbare Kernelmodule: Objektdateien, die Sie in einen laufenden Kernel laden und wieder entfernen können. Dadurch kann ein Treiber unabhängig von der Kernel-Binärdatei veröffentlicht werden.

lsmod | head
modinfo virtio_net | head -5

lsmod listet auf, was derzeit geladen ist. modinfo gibt die Datei aus, aus der das Modul stammt, sowie die von ihm akzeptierten Parameter. Auf einem virtuellen Server besteht ein großer Teil des Speicher- und Netzwerkpfads aus Modulen. Deshalb kann ein Kernel-Image auf Hardware booten, die es zuvor noch nicht erkannt hat.

Module ermöglichten diese Flexibilität, ohne die Kosten des Mikrokernel-Entwurfs zu übernehmen. Einen Treiber in einem eigenen Prozess zu isolieren, verursacht bei jedem Aufruf einen Kontextwechsel und eine Nachricht. Im Jahr 1992 waren diese Kosten erheblich.

Die von Linux übernommene Einschränkung müssen Sie bei der Planung berücksichtigen: Ein Modul läuft mit vollständigen Kernel-Berechtigungen. Ein fehlerhaftes Modul legt daher die gesamte Maschine lahm und nicht nur einen Prozess. Besonders problematisch sind externe Module. Einen Herstellertreiber, der nicht im Mainline-Kernel enthalten ist, müssen Sie gegen jeden neuen Kernel neu bauen. Genau das erledigt DKMS während eines Upgrades. Wenn dieser Build fehlschlägt, fehlt das Gerät nach dem Reboot einfach.

Warum die SMP-Implementierung fünfzehn Jahre dauerte

Linux 2.0 war im Juni 1996 der erste Kernel mit Unterstützung für symmetrisches Multiprocessing (SMP). Damit konnten mehrere CPUs einen Kernel ausführen. Die erste Implementierung verwendete eine einzelne Sperre, die Big Kernel Lock (BKL). Daher konnte sich immer nur ein Prozessor gleichzeitig im Kernel-Code befinden. Eine zweite CPU half deshalb bei einer Arbeitslast, die im Userspace rechnet. Bei einer Arbeitslast mit Systemaufrufen half sie dagegen kaum, weil diese hinter derselben Sperre warten mussten.

Das Entfernen dieser Sperre dauerte fünfzehn Jahre. Die verbleibenden Verwendungen wurden weitgehend von Arnd Bergmann auf feingranulare Sperren umgestellt. Die BKL wurde in 2.6.39 entfernt, das am 18. Mai 2011 veröffentlicht wurde. Der Scheduler entwickelte sich ebenfalls in diesem langsamen Zeitrahmen: der O(1)-Scheduler in 2.6.0, der Completely Fair Scheduler (CFS) ab 2.6.23 im Jahr 2007 und EEVDF, das CFS in 6.6 im Oktober 2023 ablöste.

Diese Arbeit ist der Grund dafür, dass ein Tarif mit 4 vCPUs heute unauffällig ist. Sie zeigt auch eine wichtige Grenze. Auf einem gemeinsam genutzten virtuellen Server plant Ihr Kernel Ihre Threads ein, und der Hypervisor plant Ihren Kernel ein. Führen Sie top aus und lesen Sie das Feld %st. Steal Time ist CPU-Zeit, die Ihr Kernel verwenden konnte und die der Host einem anderen Gast zugewiesen hat. Keine Optimierung innerhalb Ihres Kernels kann diese Zeit zurückgewinnen.

Warum die 2.6-Serie die Kernel-Erstellung veränderte

Vor 2.6 bestanden Versionsnummern aus zwei Teilen. Eine gerade zweite Zahl bezeichnete eine stabile Serie (2.4), eine ungerade Zahl eine Entwicklungsversion (2.5). 2.4 wurde am 4. Januar 2001 und 2.6 am 17. Dezember 2003 veröffentlicht. Damit warteten Benutzer fast drei Jahre auf die nächste stabile Serie. Distributionen konnten nicht so lange warten und portierten Änderungen zurück. Zwei Anbieter, die beide „2.4“ auslieferten, lieferten Kernel aus, die Tausende von Patches auseinanderlagen.

Nach 2.6 wurde diese Aufteilung abgeschafft. Der Mainline-Kernel öffnet nun ein etwa zweiwöchiges Merge Window, nimmt neue Änderungen auf, veröffentlicht anschließend Release Candidates, bis die Entwicklung zur Ruhe kommt, und erscheint alle 9 bis 10 Wochen. Diesen Rhythmus dokumentiert kernel.org weiterhin. Die andere Hälfte des Modells kam am 4. März 2005 mit der ersten Veröffentlichung des Stable Trees hinzu: ein Update für 2.6.11, das ausschließlich Fehlerbehebungen enthielt und von Greg Kroah-Hartman und Chris Wright gepflegt wurde. Der Stable Tree nimmt Fehlerbehebungen auf und lehnt neue Funktionen ab.

Eine Folge davon war, dass die Versionsnummer keine Zusage mehr darstellte. 3.0, 4.0, 5.0 und 7.0 sind keine Neuentwicklungen. Torvalds erhöht die erste Zahl, wenn die zweite Zahl seiner Ansicht nach groß genug geworden ist. Deshalb folgte 7.0 im April 2026 auf 6.19. Für einen Server ist entscheidend, welchem Zweig die Distribution folgt und ob dieser Zweig weiterhin Fehlerbehebungen erhält.

Wie der BitKeeper-Bruch im April 2005 zu git führte

Ab Februar 2002 wurde der Kernel mit BitKeeper entwickelt, einem proprietären verteilten Versionsverwaltungssystem des Unternehmens BitMover von Larry McVoy. Das begann mit der 2.5-Serie. BitMover stellte Kernel-Entwicklern unter bestimmten Bedingungen eine kostenlose Lizenz bereit: Sie durften nicht an einem konkurrierenden Versionsverwaltungswerkzeug arbeiten und BitKeeper nicht per Reverse Engineering analysieren. Viele Entwickler lehnten es ab, einen freien Kernel mit einem Werkzeug zu entwickeln, dessen Quellcode sie nicht einsehen durften.

Im April 2005 kam es zum Bruch, nachdem Andrew Tridgell ein Programm vorgestellt hatte, das mit BitKeeper-Repositories kommunizierte. BitMover wertete das als Reverse Engineering und entzog die kostenlose Lizenz. Der Kernel verlor sein Versionsverwaltungssystem mitten in einem Entwicklungszyklus.

Die Arbeit an git begann am 3. April 2005. Torvalds kündigte git am 6. April an. Am 7. April war git selbstverwaltend. Das bedeutet, dass die eigene Historie von git bereits in git gespeichert wurde. Der erste Merge mehrerer Branches wurde am 18. April ausgeführt. Im Juni 2005 verwaltete git die Veröffentlichung von 2.6.12. Kurz danach übergab Torvalds die Wartung an Junio Hamano und wandte sich wieder dem Kernel zu.

Das Design ergab sich direkt aus dem Problem: Tausende Mitwirkende und Maintainer, die über ein Netzwerk voneinander Änderungen abrufen, dem niemand vertraut. Jedes Objekt wird nach dem Hash seines Inhalts benannt. Wenn sich ein Byte der alten Historie ändert, ändert sich dadurch der Name jedes nachfolgenden Commits. Deshalb ist ein Clone ein Beleg und keine bloße Behauptung. Jede Deployment-Pipeline, jedes Konfigurations-Repository, die Code-Hosting-Plattform, zu der die meisten Teams pushen und der git-Server, den Sie selbst betreiben können gingen aus einem Lizenzstreit über einen Kernel hervor.

Was das LTS-Modell verspricht und was nicht

Mainline ist nicht das, was Sie ausführen. Ein Mainline-Release wird 9 bis 10 Wochen später abgelöst. Der Stable-Tree enthält nach jedem Release noch einige Wochen lang Fehlerbehebungen. Longterm-Branches, üblicherweise als LTS bezeichnet, enthalten diese Fehlerbehebungen über Jahre. Auf ihnen bauen Distributionen auf.

2.6.32, veröffentlicht im Dezember 2009, war der Beleg dafür, dass dieses Modell funktioniert. RHEL 6, Debian 6, SUSE Linux Enterprise 11 SP1 und Ubuntu 10.04 LTS wurden damit veröffentlicht. Der Branch wurde bis Februar 2016 gepflegt, also mehr als sechs Jahre nach seiner Veröffentlichung.

Die zugesagte Dauer wurde mehr als einmal geändert. Zunächst waren es zwei Jahre, für einige Branches dann sechs Jahre. 2023 verkürzten die Stable-Maintainer den Standard wieder auf zwei Jahre, weil Backports in alte Trees Zeit der Maintainer kosten und alte Branches kaum noch real getestet werden. Am 25. Februar 2026 veröffentlichte Greg Kroah-Hartman nach Gesprächen mit den Unternehmen, die von diesen Branches abhängen, erneut längere Prognosen. Das aktuelle Modell reicht von drei bis sechs Jahren.

[
  {
    "kernel": "5.10",
    "released": "2020-12-13",
    "eol_projected": "Dec 2026",
    "maintained_for": 6.0
  },
  {
    "kernel": "5.15",
    "released": "2021-10-31",
    "eol_projected": "Dec 2026",
    "maintained_for": 5.1
  },
  {
    "kernel": "6.1",
    "released": "2022-12-11",
    "eol_projected": "Dec 2027",
    "maintained_for": 5.0
  },
  {
    "kernel": "6.6",
    "released": "2023-10-29",
    "eol_projected": "Dec 2027",
    "maintained_for": 4.2
  },
  {
    "kernel": "6.12",
    "released": "2024-11-17",
    "eol_projected": "Dec 2028",
    "maintained_for": 4.1
  },
  {
    "kernel": "6.18",
    "released": "2025-11-30",
    "eol_projected": "Dec 2028",
    "maintained_for": 3.1
  }
]

kernel.org listet im August 2026 6 Longterm-Branches. Der älteste, 5.10, wird beim Ende in Dec 2026 bereits 6.0 Jahre lang Fehlerbehebungen erhalten haben. Für den neuesten, 6.18, ist eine Pflege bis Dec 2028 vorgesehen. Das entspricht 3.1 Jahren mit Fehlerbehebungen.

Betrachten Sie diese Termine eher als Untergrenze und nicht als Vertrag. Die Prognosen für 6.6 und 6.12 wurden im Februar 2026 beide nach hinten verschoben. Ein Branch, den niemand verwendet, kann stattdessen auch eingestellt werden. Ihre Distribution trifft diese Entscheidung normalerweise für Sie: Debian 13 wird mit 6.12 veröffentlicht, Ubuntu 26.04 LTS mit 7.0. Dieser Unterschied ist der praktische Inhalt der Frage nach LTS gegenüber einem Interim-Release auf einem Server. Er bestimmt auch, was sich tatsächlich ändert, wenn Sie Ubuntu 24.04 auf 26.04 aktualisieren.

Daraus ergibt sich eine Falle. uname -r auf Ubuntu 24.04 gibt etwas wie 6.8.0-51-generic aus. Das ist eine Upstream-Basis mit den eigenen Backports der Distribution. Die Versionsnummer zeigt daher, mit welchem Branch die Version begonnen hat, aber nicht, welche Fehlerbehebungen darin enthalten sind. Scanner, die einen Kernel anhand seiner Versionszeichenfolge bewerten, erzeugen aus genau diesem Grund Fehlalarme bei Distributionskerneln.

Worüber der Kernel derzeit streitet

Zwei Diskussionen sind aktuell, und bei beiden geht es darum, wer die Arbeit übernimmt.

Rust wurde im Dezember 2022 mit Version 6.1 als Infrastruktur aufgenommen. In 7.0 entfiel die Kennzeichnung als experimentell. Damit sind C, Assembly und Rust die Kernsprachen des Kernels, und für den Build wird kein Nightly-Compiler mehr benötigt. Bei der Auseinandersetzung geht es um die Wartung. Ein C-Maintainer, der eine Schnittstelle ändert, kann Rust-Bindings beschädigen, die er nicht selbst liest. Umstritten ist, wer für deren Reparatur zuständig ist.

Bei der zweiten Diskussion geht es um Beiträge durch KI. Sasha Levin schlug im Juli 2025 eine Richtlinie vor, nachdem eine zunehmende Zahl maschinell unterstützter Patches die Mailinglisten erreicht hatte. Das Dokument wurde am 23. Dezember 2025 eingepflegt und befindet sich jetzt in der Prozessdokumentation des Kernels unter docs.kernel.org/process/coding-assistants.html. Ein KI-Agent darf kein Signed-off-by-Tag hinzufügen, weil diese Zeile das Developer Certificate of Origin (DCO) bestätigt und nur eine Person diese Bestätigung abgeben kann. Die Unterstützung wird mit einem Assisted-by:-Tag angegeben. Dieses wurde während der Überarbeitung von Co-developed-by: geändert, weil ein Tool kein Autor ist. Generierter Code muss mit GPL-2.0-only kompatibel sein. Die Person, die den Patch sendet, prüft ihn und trägt die Verantwortung dafür.

Hinter der Richtlinie steht der Zeitaufwand für Reviews. Einen Patch zu erzeugen dauert Sekunden, ihn zu prüfen einen Nachmittag des Maintainers. Ein Tag beseitigt dieses Ungleichgewicht nicht. Er bewahrt jedoch die Herkunft: In der Historie bleibt festgehalten, wer für jede Änderung signiert hat. Genau diese Eigenschaft sollte das DCO bei seiner Einführung im Jahr 2004 schützen.

Was diese Geschichte für den von Ihnen gemieteten Server bedeutet

• Die Lizenz ist der Grund dafür, dass Sie den Kernel lesen und neu bauen können, den Ihr Anbieter startet, und dass proprietäre Software darauf weiterhin ausgeführt werden kann.
• Das monolithische Design ist der Grund dafür, dass ein Fehler in einem Treiber den gesamten Rechner neu startet und dass ein Out-of-Tree-Modul bei jedem Kernel-Upgrade neu gebaut werden muss.
• Das Release-Modell ist der Grund dafür, dass die Versionsnummer nur wenig aussagt, während der Branch und sein End-of-Life-Datum fast alle wichtigen Informationen liefern.
• Die Art der Virtualisierung entscheidet darüber, was Sie überhaupt tun können: Unter KVM starten Sie Ihren eigenen Kernel und laden Module. Bei einer Container-Virtualisierung, die den Kernel des Hosts gemeinsam nutzt, zeigt uname -r die Version des Hosts an, modprobe schlägt fehl, und mehrere sysctl-Werte sind schreibgeschützt.

FAQ

Warum ist der Linux-Kernel weiterhin unter GPLv2 und nicht unter GPLv3 lizenziert?

Torvalds entschied sich 2007 gegen GPLv3, hauptsächlich wegen der darin enthaltenen Anti-Tivoisierungsklausel. Sie verpflichtet ein Gerät, das GPL-Code ausliefert, auch eine modifizierte Version dieses Codes zu akzeptieren. Er betrachtet gesperrte Hardware als Geschäftsentscheidung des Herstellers. Eine Neulizenzierung ist in der Praxis ebenfalls nahezu unmöglich, weil das Urheberrecht am Kernel bei Tausenden von Mitwirkenden liegt und es keine Abtretungsvereinbarung gibt, auf die man zurückgreifen könnte. Der Kernel steht unter GPL-2.0-only. Code, der ausschließlich unter GPLv3 angeboten wird, kann daher nicht integriert werden.

Ist der Linux-Kernel ein monolithischer Kernel oder ein Mikrokernel?

Er ist monolithisch und unterstützt ladbare Module. Treiber und Dateisysteme laufen im Adressraum des Kernels. lsmod zeigt die aktuell geladenen Module. Das führt einerseits zu hoher Geschwindigkeit und andererseits zu einer größeren Ausfallwirkung: Ein fehlerhaftes Modul kann die gesamte Maschine mit einem Kernel Panic zum Absturz bringen, während bei einem Mikrokernel nur ein Prozess ausfallen würde. Seit 1992 wurde dieses Modell durch FUSE-Dateisysteme im User-Space und eBPF-Programme abgeschwächt, die der Kernel vor ihrer Ausführung überprüft.

Was ist der Unterschied zwischen Mainline-, Stable- und Longterm-Kerneln?

Mainline ist der Entwicklungsbaum von Torvalds. Er wird alle 9 bis 10 Wochen veröffentlicht, und neue Funktionen werden zuerst dort aufgenommen. Stable basiert auf der neuesten Mainline-Version und erhält einige Wochen lang Fehlerkorrekturen. Longterm-Zweige erhalten über Jahre hinweg weitere Korrekturen. Auf ihnen basieren die Kernel der Distributionen. kernel.org listet die aktuellen Longterm-Zweige mit dem jeweils erwarteten End-of-Life-Datum auf.

Akzeptiert der Linux-Kernel von AI geschriebenen Code?

Ja, gemäß einer im Dezember 2025 verabschiedeten Richtlinie. Das verwendete Tool muss in einem Assisted-by:-Tag genannt werden. Ein AI-Agent darf keine Signed-off-by-Zeile hinzufügen. Der generierte Code muss mit GPL-2.0-only kompatibel sein. Der menschliche Einreicher zeichnet den Beitrag ab. Damit bestätigt er, dass er den Patch geprüft hat und nach dem Developer Certificate of Origin die Verantwortung dafür übernimmt.

Welche Kernel-Version sollte ich auf einem Server verwenden?

In fast allen Fällen die Version, die Ihre Distribution pflegt. Ein Distributionskernel besteht aus einem Longterm-Zweig, zurückportierten Fehlerkorrekturen und den Tests des Anbieters. Er entspricht den Annahmen der Images Ihres Providers und Ihrer Supportvereinbarungen. Bauen Sie einen neueren Mainline-Kernel, wenn Sie einen bestimmten Treiber oder eine bestimmte Funktion benötigen. Prüfen Sie vor der Umstellung außerdem das End-of-Life-Datum des Zielzweigs.