Von Linux-Kernelgeschichte: Entscheidungen mit Folgen
Von Linux 0.01 bis 7.x: Erfahren Sie, warum GPL, Microkernel-Streit, Git und LTS den Kernel geprägt haben und was das für heutige Server bedeutet.
Die Kurzfassung der Linux-Kernelgeschichte
Die Geschichte des Linux-Kernels reicht von Version 0.01 im September 1991 bis zur heute auf Servern gestarteten 7.x-Serie. Die Liste der Releases ist dabei der am wenigsten interessante Teil. Eine kleine Anzahl von Entscheidungen prägte die Struktur des Kernels. Jede davon wirkt sich noch heute auf einen Server aus, den Sie am Nachmittag mieten. Warum 1991 überhaupt ein neuer Kernel erforderlich war, gehört zu der längeren Geschichte von Unix, der AT&T-Lizenzierung und des Rechtsstreits, der BSD ausbremste.
Die Datums- und Versionsangaben stammen von kernel.org und aus der dort veröffentlichten Release-Historie. Stand August 2026: 7.0 erschien am 12. April 2026, 7.1 am 14. Juni 2026, und 7.2 befindet sich in der Phase der 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 weitergegeben wird, und enthielt eine weitere, wichtigere Zeile: „Sie dürfen diese Software nicht gegen eine Gebühr weitergeben, nicht einmal gegen Kosten für die ‚Abwicklung‘.“ 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 Release-Hinweisen zu Version 0.12 im Januar 1992 angekündigt und trat am 1. Februar 1992 in Kraft. Version 0.95 war im März 1992 die erste unter dieser Lizenz veröffentlichte Version. Auf dieser Änderung beruht jedes Unternehmen, das später auf Linux aufgebaut wurde.
Der Kernel steht ausschließlich unter der 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 geänderte Kopie dieses Codes akzeptieren muss. Gesperrte Hardware betrachtete er als die eigene Geschäftsentscheidung des Herstellers. 2017 veröffentlichten Kernel-Entwickler die Kernel Enforcement Statement, die dennoch einen Teil von GPLv3 übernimmt: 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 Folgen. Die Kernel-Binärdatei, mit der Sie booten, beinhaltet das Recht auf den zugehörigen Quellcode. Niemand kann Ihnen daher einen Linux-Kernel übergeben, den Sie nicht untersuchen oder neu erstellen dürfen. Außerdem besagt der Copyright-Hinweis im Kernel, dass die Lizenz keine Benutzerprogramme abdeckt, die Kernel-Dienste über normale Systemaufrufe verwenden. Deshalb werden proprietäre Datenbanken und Monitoring-Agenten für Linux ausgeliefert, ohne dadurch gegen die Lizenz zu verstoßen. Eine permissive Lizenz erzeugt den entgegengesetzten Druck. Diesen Unterschied sollten Sie verstehen, bevor Sie eine Plattform auswählen: 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 ausgeführt werden, gehörten dagegen der Zukunft. Außerdem sei Linux fest an den Intel 386 gebunden und würde 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 auf 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 ausgeliefert werden.
lsmod | head
modinfo virtio_net | head -5lsmod 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 starten, die es zuvor noch nicht gesehen hat. Der Kernel meldet lediglich neue Hardware. Ein Daemon im User Space entscheidet, welches Modul geladen wird und welchen Namen das Gerät erhält. Auf diese Weise wurde die Geräteverwaltung Teil des Init-Systems. Das ist auch ein Grund dafür, warum systemd schwer zu vermeiden wurde.
Module ermöglichten diese Flexibilität ohne die Kosten, die das Mikrokernel-Design mit sich brachte. Einen Treiber in einem eigenen Prozess zu isolieren, erfordert bei jedem Aufruf einen Kontextwechsel und eine Nachricht. Im Jahr 1992 waren diese Kosten erheblich.
Die Kosten, die Linux weiterhin verursacht, 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. Bei Out-of-Tree-Modulen zeigt sich dieses Problem besonders deutlich. Ein Herstellertreiber, der nicht im Mainline-Kernel enthalten ist, muss für jeden neuen Kernel neu gebaut werden. Das übernimmt DKMS während eines Upgrades. Wenn dieser Build fehlschlägt, fehlt das Gerät nach dem Reboot einfach.
Warum die SMP-Unterstützung fünfzehn Jahre brauchte
Linux 2.0 war im Juni 1996 der erste Kernel mit Unterstützung für symmetrisches Multiprocessing (SMP). Damit konnten mehrere CPUs denselben Kernel ausführen. Die erste Implementierung verwendete eine einzelne Sperre, die Big Kernel Lock (BKL). Deshalb konnte sich immer nur ein Prozessor gleichzeitig im Kernel-Code befinden. Eine zweite CPU half dadurch bei einer Arbeitslast, die im User-Space rechnet. Bei einer Arbeitslast mit Systemaufrufen war der Vorteil gering, weil diese hinter derselben Sperre warten mussten.
Das Entfernen dieser Sperre dauerte fünfzehn Jahre. Die verbleibenden Verwendungen wurden größtenteils von Arnd Bergmann auf feingranulare Sperren umgestellt. Anschließend wurde die BKL in 2.6.39 entfernt. Diese Version wurde am 18. Mai 2011 veröffentlicht. Der Scheduler entwickelte sich in einem ähnlich langsamen Zeitraum weiter: 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 bezeichnet CPU-Zeit, die Ihr Kernel verwenden wollte, die der Host aber einem anderen Gast zugewiesen hat. Keine Anpassung innerhalb Ihres Kernels kann diese Zeit zurückgewinnen.
Wie die 2.6-Serie die Erstellung des Kernels 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 veröffentlicht und 2.6 am 17. Dezember 2003. Daher warteten Benutzer fast drei Jahre auf die nächste stabile Serie. Distributionen konnten nicht so lange warten und übernahmen Patches aus neueren Versionen. Zwei Anbieter, die beide „2.4“ auslieferten, lieferten Kernel aus, die sich um Tausende von Patches unterschieden.
Nach 2.6 wurde die Aufteilung abgeschafft. Der Mainline-Kernel öffnet nun ein etwa zweiwöchiges Merge-Fenster, nimmt neue Änderungen auf, veröffentlicht anschließend Release Candidates, bis sich die Entwicklung stabilisiert, und erscheint alle 9 bis 10 Wochen. Diese Kadenz wird weiterhin auf kernel.org dokumentiert. Die andere Hälfte des Modells kam am 4. März 2005 mit der ersten Veröffentlichung des Stable Trees hinzu. Dabei handelte es sich um eine Aktualisierung von 2.6.11, die 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 Nebenwirkung war, dass die Versionsnummer keine Zusage mehr darstellte. 3.0, 4.0, 5.0 und 7.0 sind keine vollständigen Neuentwicklungen. Torvalds erhöht die erste Zahl, wenn die zweite Zahl groß genug wird, um ihn zu stören. Deshalb folgte 7.0 im April 2026 auf 6.19. Für einen Server ist entscheidend, welchen Zweig die Distribution verfolgt 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 in BitKeeper entwickelt, einem proprietären verteilten Versionsverwaltungssystem des Unternehmens BitMover von Larry McVoy. Dies begann mit der 2.5-Serie. BitMover stellte Kernel-Entwicklern eine kostenlose Lizenz unter bestimmten Bedingungen bereit: Sie durften nicht an einem konkurrierenden Versionsverwaltungswerkzeug arbeiten und BitKeeper nicht zurückentwickeln. Viele Entwickler lehnten es ab, einen freien Kernel mit einem Werkzeug zu entwickeln, dessen Quellcode sie nicht lesen durften.
Im April 2005 zerbrach diese Vereinbarung, 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 damit mitten in einem Entwicklungszyklus sein Versionsverwaltungssystem.
Die Arbeit an git begann am 3. April 2005. Torvalds kündigte git am 6. April an. Am 7. April war git selbst-hostingfähig. Das bedeutet, dass die eigene Versionsgeschichte von git bereits in git verwaltet wurde. Der erste Merge mehrerer Branches lief am 18. April. Im Juni 2005 verwaltete git das Release von 2.6.12. Kurz danach übergab Torvalds die Wartung an Junio Hamano und wandte sich wieder dem Kernel zu.
Das Design ergab sich unmittelbar aus dem Problem: Tausende Mitwirkende und Maintainer, die über ein Netzwerk voneinander Änderungen übernehmen, dem niemand vertraut. Jedes Objekt wird nach dem Hash seines Inhalts benannt. Wenn sich ein Byte einer älteren Versionsgeschichte ändert, ändert sich dadurch der Name jedes darauf folgenden Commits. Deshalb ist ein Clone ein Beleg und keine bloße Behauptung. Jede Deployment-Pipeline, jedes Konfigurations-Repository, der Code-Host, auf den die meisten Teams pushen, und der git-Server, den Sie selbst betreiben können entstand aus einem Lizenzstreit über einen Kernel.
Was das LTS-Modell verspricht und was nicht
Mainline ist nicht die Version, die Sie betreiben. Eine Mainline-Version wird 9 bis 10 Wochen später abgelöst. Der Stable-Zweig erhält noch einige Wochen nach jeder Veröffentlichung Fehlerbehebungen. Longterm-Zweige, meist als LTS bezeichnet, erhalten diese ü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 ausgeliefert. Der Zweig wurde bis Februar 2016 gepflegt, also mehr als sechs Jahre nach seiner Veröffentlichung. Red Hat ging noch weiter und pflegte seinen auf 2.6.32 basierenden Kernel mit eigenen Backports bis zum Ende von RHEL 6 im Jahr 2020. Eine solche Unterstützung über ein Jahrzehnt kostenlos nachzubilden, ist der gesamte Grund dafür, dass CentOS entstand und durch Rocky Linux und AlmaLinux ersetzt wurde.
Das Versprechen wurde mehr als einmal angepasst. Zunächst waren es zwei Jahre, bei einigen Zweigen dann sechs Jahre. 2023 verkürzten die Stable-Maintainer den Standard wieder auf zwei Jahre, weil Backports in alte Quellbäume Zeit der Maintainer kosten und alte Zweige nur wenig praktisch getestet werden. Am 25. Februar 2026 veröffentlichte Greg Kroah-Hartman nach Gesprächen mit den Unternehmen, die von diesen Zweigen abhängen, erneut längere Prognosen. Das aktuelle Modell reicht von drei bis sechs Jahren.
The data behind this chart
[
{
"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-Zweige. Der älteste, 5.10, wird beim Ende seiner Pflege 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 denn als Vertrag. Die Prognosen für 6.6 und 6.12 wurden im Februar 2026 beide verlängert. Ein Zweig, den niemand verwendet, kann jedoch stattdessen eingestellt werden. Ihre Distribution trifft diese Auswahl normalerweise für Sie: Debian 13 wird mit 6.12 ausgeliefert, Ubuntu 26.04 LTS mit 7.0. Dieser Unterschied ist der praktische Inhalt der Frage LTS oder Interim-Version auf einem Server. Er bestimmt, was sich tatsächlich unter Ihnen ändert, wenn Sie Ubuntu 24.04 auf 26.04 aktualisieren.
Daraus ergibt sich eine typische Falle. uname -r auf Ubuntu 24.04 gibt etwas wie 6.8.0-51-generic aus. Dabei handelt es sich um eine Upstream-Basis mit den eigenen Backports der Distribution. Die Versionsnummer zeigt daher, wo der Zweig begonnen hat, nicht welche Fehlerbehebungen 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 offen, 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 experimentelle Kennzeichnung. Damit sind C, Assembler 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. Ändert ein C-Maintainer eine Schnittstelle, kann er Rust-Bindings beschädigen, die er nicht selbst prüft. Strittig ist, wer diese Bindings reparieren muss.
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 auf den Mailinglisten eingegangen war. Das Dokument wurde am 23. Dezember 2025 übernommen und befindet sich inzwischen 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 einreicht, prüft ihn und trägt die Verantwortung dafür.
Hinter der Richtlinie steht der Aufwand für Reviews. Einen Patch zu generieren dauert Sekunden, sein Review beansprucht den Nachmittag eines Maintainers. Ein Tag beseitigt dieses Ungleichgewicht nicht. Er bewahrt jedoch die Herkunftsinformationen: 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 ermöglicht es Ihnen, den Kernel zu lesen und neu zu bauen, den Ihr Anbieter startet. Deshalb läuft darauf auch proprietäre Software.
- Das monolithische Design ist der Grund dafür, dass ein Fehler in einem Treiber den gesamten Rechner neu startet. Außerdem muss ein Out-of-Tree-Modul bei jedem Kernel-Upgrade neu gebaut werden.
- Das Release-Modell ist der Grund dafür, dass die Versionsnummer nur wenige Informationen liefert. Der Branch und sein End-of-Life-Datum sagen dagegen fast alles aus.
- Die Virtualisierungsart legt fest, was Sie überhaupt tun können: Bei KVM starten Sie Ihren eigenen Kernel und laden Module. Bei Container-Virtualisierung wird der Kernel des Hosts gemeinsam verwendet. Dort zeigt
uname -rdie Version des Hosts an,modprobeschlägt fehl, und mehrere sysctl-Werte sind schreibgeschützt.
FAQ
Warum ist der Linux-Kernel weiterhin unter GPLv2 und nicht unter GPLv3 lizenziert?
Torvalds lehnte GPLv3 2007 ab, hauptsächlich wegen der Anti-Tivoisierungsklausel. Diese verlangt, dass ein Gerät, das GPL-Code ausliefert, auch eine modifizierte Version dieses Codes akzeptiert. 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 keine Abtretungsvereinbarung als Grundlage vorhanden ist. Der Kernel steht unter GPL-2.0-only. Daher kann Code, der ausschließlich unter GPLv3 angeboten wird, nicht integriert werden.
Ist der Linux-Kernel ein monolithischer Kernel oder ein Microkernel?
Er ist monolithisch und unterstützt ladbare Module. Treiber und Dateisysteme laufen im Adressraum des Kernels. lsmod zeigt, welche davon derzeit geladen sind. 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 Stillstand bringen. Bei einem Microkernel würde dagegen nur ein Prozess ausfallen. Seit 1992 wurde dieses Modell durch FUSE-Dateisysteme im Userspace 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 bezeichnet den Entwicklungszweig von Torvalds. Er wird alle 9 bis 10 Wochen veröffentlicht, und neue Funktionen werden zuerst dort aufgenommen. Stable basiert auf der jüngsten Mainline-Version und erhält einige Wochen lang Fehlerkorrekturen. Longterm-Zweige erhalten über Jahre hinweg weitere Fehlerkorrekturen. Auf ihnen bauen Distributionen ihre Kernel auf. kernel.org führt die aktuellen Longterm-Zweige jeweils mit dem voraussichtlichen End-of-Life-Datum auf.
Nimmt der Linux-Kernel Code an, der von einer KI geschrieben wurde?
Ja, gemäß einer im Dezember 2025 festgelegten Richtlinie. Das verwendete Tool muss in einem Assisted-by:-Tag genannt werden. Ein KI-Agent darf keine Signed-off-by-Zeile hinzufügen. Der generierte Code muss mit GPL-2.0-only kompatibel sein. Der menschliche Einreicher bestätigt die Einreichung. Damit erklärt er, dass er den Patch geprüft hat und gemäß dem Developer Certificate of Origin die Verantwortung dafür übernimmt.
Welche Kernel-Version sollte ich auf einem Server ausführen?
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 auf den neuen Zweig dessen End-of-Life-Datum.