Linux: Kernel und Distribution

„Ich nutze Linux.“ – „Welches?“ Und schon gibt es vier mögliche Antworten: Kernel, Distribution, Release und „das, was mein Cousin installiert hat“.

Kurz gesagt

Genau genommen ist „Linux“ der Kernel: das Kernprogramm, das Prozesse, Speicher, Geräte und Netzwerk verwaltet. Was die meisten installieren, ist eine Distribution, die diesen Kernel mit Werkzeugen, einer Paketverwaltung und einem Release- und Supportplan kombiniert. „Welches Linux?“ braucht also mindestens zwei Antworten: welche Distribution mit welchem Release, und welcher Kernel.

So funktioniert’s

1. Der Kernel sitzt zwischen Programmen und Hardware. Programme bitten den Kernel über Systemaufrufe (System Calls) um Dienste. Die Linux-Handbuchseiten nennen den Systemaufruf „die grundlegende Schnittstelle zwischen einer Anwendung und dem Linux-Kernel“; angesprochen wird er meist über Wrapper-Funktionen einer Bibliothek wie glibc. Alles oberhalb dieser Grenze (Shell, Bibliotheken, Desktop, deine eigenen Programme) heißt User Space.
2. Der Kernel hat seinen eigenen Rhythmus. Das Kernel-Projekt arbeitet mit einem lose zeitgesteuerten, fortlaufenden Releasemodell. Ein neues Mainline-Release erscheint etwa alle neun bis zehn Wochen. Jeder Zyklus beginnt mit einem Merge-Fenster von rund zwei Wochen, in dem neuer Code aufgenommen wird; danach folgen etwa wöchentlich „rc“-Versionen (Release Candidates), in denen nur noch Korrekturen erlaubt sind, bis zum finalen Release.
3. Es gibt vier Arten von Kernel-Releases. Prepatch-Versionen (rc) sind für Entwickler und Enthusiasten. Mainline ist der Zweig, in dem neue Funktionen entstehen. Stable-Kernel sind die Mainline-Releases nach ihrer Veröffentlichung; Fehlerkorrekturen werden aus Mainline übernommen, meist etwa wöchentlich. Longterm-Kernel sind einige wenige Releases, die deutlich länger Korrekturen bekommen, aber nur wichtige. Welches Release Longterm wird, hängt davon ab, ob ein Maintainer Bedarf und Zeit hat, es zu betreuen.
4. Die meisten nutzen einen Distributionskernel. Wer nicht selbst einen Kernel von kernel.org geladen, kompiliert und installiert hat, betreibt einen Distributionskernel. Distributionen pflegen eigene Kernel, die auf denen von kernel.org beruhen können, aber nicht müssen, und die Kernel-Entwickler können dafür keinen Support leisten. Richtige Anlaufstelle ist dein Distributor. Ein Schnelltest: Steht hinter dem Bindestrich in der Ausgabe von uname -r noch etwas, etwa 5.6.19-300.fc32.x86_64, ist es ein Distributionskernel.
5. Eine Distribution liefert alles andere. Sie wählt Kernel-Version, Bibliotheken, Init-System (das erste Programm, das alle anderen startet), Paketquellen und Update-Zyklen und veröffentlicht, wie lange jedes Release unterstützt wird. Darum ist „Linux-Version“ ohne Distribution und Release zu ungenau, um damit etwas anzufangen.
6. Support gilt je Release. Als Beispiel für einen veröffentlichten Zeitplan führt Canonical Ubuntu 24.04 LTS (Release April 2024) mit regulärer Sicherheitspflege bis Mai 2029 und erweiterter Sicherheitspflege, die zu Ubuntu Pro gehört, bis Mai 2034.

In der Praxis

Zwei Befehle verraten dir, was du betreibst:

uname -r              # Kernel-Release
cat /etc/os-release   # Distribution und Release

Ein Beispiel aus dem Bytearium-Inventar (Lesung vom 14. Okt. 2026): Die Docker-VM läuft mit Ubuntu 24.04.5 LTS, einem Point-Release der Serie 24.04 LTS, für die Canonical reguläre Sicherheitspflege bis Mai 2029 nennt. Welcher Kernel läuft, ist nicht erfasst. uname -r würde es zeigen, und ein Zusatz hinter der Versionsnummer hieße: Ubuntus eigener Kernel-Build, nicht einer direkt von kernel.org.

Woher die Software kommt: Pakete und Repositories

Eine Distribution wählt nicht nur einen Kernel; sie liefert Tausende Programme als Pakete (.deb bei Debian und Ubuntu, .rpm bei Fedora und Verwandten) aus Repositories, die sie signiert und pflegt. Der Paketmanager (apt, dnf, zypper, pacman) löst Abhängigkeiten auf, prüft Signaturen und protokolliert, was installiert ist. Deshalb ist „ich habe ein Tarball heruntergeladen und make install ausgeführt“ der schnellste Weg zu einem System, das niemand mehr aktualisieren kann. Die Rangfolge für einen Server: das Repository der Distribution, dann das signierte Repository des Herstellers für genau diese Distribution, dann ein Container-Image, und erst als letzter Ausweg ein eigener Bau, den du dokumentierst.

Updates, die laufen, während du schläfst

Ubuntu installiert das Paket unattended-upgrades standardmäßig und spielt Sicherheitsupdates automatisch ein, einmal täglich und nur aus den offiziellen Sicherheits-Repositories; Pakete aus einem Repository, das du selbst hinzugefügt hast, bleiben unberührt, solange du dessen Herkunft nicht in die Konfiguration einträgst. Ob die Maschine von selbst neu startet, ist ein eigener Schalter, Unattended-Upgrade::Automatic-Reboot, standardmäßig aus, und mit Automatic-Reboot-Time wählst du eine ruhige Stunde statt „sofort“. Fürs Homelab ist die vernünftige Einstellung: Sicherheitsupdates an, automatischer Neustart an zu einer Zeit, in der niemand streamt oder sichert, und einmal pro Woche ein Blick in /var/log/unattended-upgrades. Ein Kernel-Update ohne Neustart lässt den alten Kernel weiterlaufen; der Prüflistenpunkt zu uname -r existiert genau für diesen Fall.

Eine Distribution für den Heimserver wählen

Die ehrlichen Kriterien sind langweilig: wie lange das Release unterstützt wird, wie gut die Software, die du brauchst, dafür paketiert ist, und wie vertraut dir die Werkzeuge nachts um zwei sind. LTS-Releases (Long-Term Support) wie Ubuntu 24.04 oder Debian stable ändern sich über Jahre kaum und sind die Voreinstellung für alles, was einfach laufen muss. Rolling-Distributionen folgen den Projekten dicht und passen zu einer Workstation, auf der du die neuesten Versionen willst und gelegentliche Brüche hinnimmst. Beides auf derselben Maschine zu mischen oder auf einem LTS Fremd-Repositories zu stapeln, um neuere Pakete zu bekommen, ist der Anfang der meisten „Linux ist instabil“-Geschichten.

Prüfliste

• Notiere Distribution, Release und Kernel-Version, wenn du ein Linux-System meldest oder vergleichst.
• Schlage das Supportende deines Distributions-Releases nach und trag es in deinen Kalender ein.
• Prüfe, ob du einen Distributionskernel betreibst, bevor du bei kernel.org um Hilfe bittest; frag stattdessen die Supportkanäle deiner Distribution.
• Installiere Pakete nur aus Quellen, denen du vertraust und deren Updates du einplanst.
• Vergleiche nach einem Update uname -r mit dem neuesten installierten Kernel und starte neu, wenn beide abweichen.
• Entscheide bewusst, ob unbeaufsichtigte Updates die Maschine neu starten dürfen, und zu welcher Zeit.