Linux-Distributionen: Geschichte und Familienlinien

Was eine Linux-Distribution tatsächlich ist

Die Geschichte der Linux-Distributionen beginnt mit einer Lücke: Der Linux-Kernel allein stellt nichts bereit, das ein Mensch nutzen kann. Er startet und erkennt Hardware. Danach endet der Vorgang. Jemand muss eine Userland-Umgebung hinzufügen, festlegen, wie Software installiert und aktualisiert wird, und zusagen, sie über Jahre hinweg weiter zu pflegen. Eine Distribution ist diese Sammlung von Entscheidungen sowie die Gruppe von Menschen, die anschließend dabei bleibt.

Sie besteht aus fünf Teilen. Ändern Sie einen davon, erhalten Sie eine andere Distribution, auch wenn die meisten Binärdateien übereinstimmen:

• Ein Kernel in einer vom Projekt ausgewählten Version mit den hinzugefügten Patches und Treibern.
• Eine Userland-Umgebung: die C-Bibliothek, die Shell, das Init-System und die Standardbefehle.
• Ein Paketformat und das Tool, das Pakete installiert.
• Eine Release-Policy: Was darf sich ändern, wie häufig geschieht das, und wie lange wird jedes Release korrigiert?
• Menschen: Paketbetreuer, ein Security-Team und jemand, der antwortet, wenn ein Paket fehlschlägt.

Der Kernel ist der gemeinsame Bestandteil. Deshalb liegen zwei Linux-Distributionen einander deutlich näher, als eine von ihnen einem anderen Unix-System liegt. Das sollten Sie berücksichtigen, wenn Sie Linux und FreeBSD als Serverplattformen vergleichen. Bei FreeBSD werden der Kernel und die grundlegende Userland-Umgebung von einem Projekt entwickelt und gemeinsam veröffentlicht. Unter Linux stammen diese Bestandteile aus separaten Upstream-Projekten. Die Distribution sorgt dafür, dass sie zusammen funktionieren.

Eine Geschichte der Linux-Distributionen in drei Familien

Drei Projekte, die 1993 und 1994 gestartet wurden, entwickelten sich zu Familien: Slackware, Debian und Red Hat. Fast jedes Image in einem VPS-Control-Panel gehört heute zu einer dieser Familien oder ist ein Nachkomme davon. Ein Nachkomme übernimmt das Paketformat, die Dateistruktur und meist auch die Release-Gewohnheiten. Deshalb fühlt sich eine Debian-Derivat weiterhin wie Debian an, wenn die ursprüngliche Markenbezeichnung entfernt wurde.

Die unabhängigen Distributionen verdienen eine eigene Zeile, weil sie von keiner anderen Distribution abgespalten wurden. Arch, Gentoo, Alpine, NixOS und Void entwickelten jeweils ihren eigenen Paketmanager und ihre eigenen Regeln. Zwei davon, Arch und Alpine, landeten trotzdem in der Image-Liste Ihres Providers. Der Grund dafür hatte nichts mit dem Desktop zu tun.

1992: Die Distributionen vor den Familien

MCC Interim Linux erschien im Februar 1992. Owen Le Blanc stellte es am Manchester Computing Centre zusammen. Es brachte den Kernel und die GNU-Tools (GNU's not Unix) mit einem menügesteuerten Installer auf zwei Disketten-Images. Es entstand, weil die manuelle Einrichtung einen Arbeitstag kostete.

SLS (Softlanding Linux System), das Peter MacDonald 1992 veröffentlichte, ging weiter und ergänzte X (das X Window System) sowie TCP/IP-Netzwerke. SLS ist der Grund dafür, dass das Wort Distribution seine heutige Bedeutung hat. Es war außerdem fehlerhaft und wurde nur langsam gepflegt. 1993 beschlossen zwei Personen unabhängig voneinander, das Problem zu beheben. Einer baute es neu auf. Der andere begann mit schriftlich festgelegten Regeln von vorn.

Slackware, 1993: Die älteste weiterhin veröffentlichte Familie

Patrick Volkerding veröffentlichte Slackware 1.00 am 16. Juli 1993. Die Distribution basierte auf SLS, wobei die bekannten Fehler entfernt worden waren. Slackware wird weiterhin gepflegt und ist damit die älteste noch bestehende Linux-Distribution.

Ein Slackware-Paket ist ein komprimiertes tar-Archiv, das ein Installationsskript enthält. Eine Abhängigkeitsauflösung gibt es nicht. Es wird nicht geprüft, ob die Bibliothek, die Ihr neues Paket benötigt, bereits auf dem Datenträger vorhanden ist. Diese eine Entscheidung prägte alle weiteren Eigenschaften. Wenn das Werkzeug Abhängigkeiten nicht auflösen kann, muss die veröffentlichte Paketsammlung von vornherein konsistent sein. Deshalb erscheinen neue Releases selten und mit wenigen Änderungen. Slackware 15.0 wurde im Februar 2022 veröffentlicht, sechs Jahre nach 14.2.

Die Familie ist klein. Die ersten SUSE-Releases aus der Mitte der 1990er-Jahre basierten auf Slackware, bevor das Projekt mit YaST und später dem RPM-Paketformat einen eigenen Weg einschlug. Dieser letzte Punkt führt häufig zu Verwirrung. SUSE und openSUSE verwenden RPM-Pakete, sind aber keine Derivate von Red Hat. Das Format wurde übernommen. Die Abstammung blieb unverändert.

Debian, 1993: ein Gesellschaftsvertrag und eine Pipeline mit drei Suiten

Ian Murdock kündigte Debian am 16. August 1993 an, drei Wochen nach Slackware und aus demselben Grund. Der Name setzt den Vornamen seiner Partnerin Debra mit seinem eigenen zusammen. Im Januar 1994 folgte das Debian Manifesto. Es legte die Bedingungen fest: Diese Distribution sollte offen von Freiwilligen gepflegt werden, nicht von einem Unternehmen.

Debian hielt diese Bedingungen anschließend schriftlich fest. Der Debian Social Contract und die DFSG (Debian-Richtlinien für freie Software) wurden im Juli 1997 verabschiedet. Die DFSG bildete 1998 die Grundlage der Open Source Definition. Ein Dokument, das klären sollte, was in eine Distribution gehört, definierte damit eine Lizenzkategorie für die gesamte Branche. Deshalb hat Ihr sources.list Komponenten: main enthält Software, die die Richtlinien erfüllt, contrib und non-free enthalten Software, die sie nicht erfüllt, und Debian 12 fügte non-free-firmware hinzu, damit ein Laptop mit WLAN-Karte ohne langwierige Suche installiert werden kann.

Die Werkzeuge sind die andere Hinterlassenschaft. dpkg installiert ein Paket und bricht ab, wenn etwas fehlt; dabei gibt es dpkg: dependency problems prevent configuration of aus. APT (advanced package tool), das mit Debian 2.1 im Jahr 1999 zum Standard wurde, ermittelt, was zusätzlich abgerufen werden muss und in welcher Reihenfolge. Jeder apt-Befehl auf jedem Debian-Derivat geht auf diese Arbeit zurück.

Die Release-Maschine hat drei Suiten und eine Regel. Ein Maintainer lädt ein Paket nach unstable hoch, das dauerhaft den Codenamen sid trägt. Ein Skript migriert das Paket nach ungefähr 5 bis 10 Tagen nach testing, wenn es auf den Release-Architekturen gebaut wurde und keinen neuen releasekritischen Fehler verursacht hat. Danach wird testing eingefroren. Das Release-Team arbeitet die verbleibenden Probleme ab, und stable wird veröffentlicht, sobald die Fehlerliste kurz genug ist. Das geschieht nicht an einem festgelegten Datum. Deshalb wirkt Debian stable veraltet und verhält sich zuverlässig: Die Versionsnummern bleiben beim Freeze unverändert, während Sicherheitskorrekturen weiterhin zurückportiert werden.

Auch die Governance ist schriftlich festgelegt, mit einem gewählten Projektleiter und verbindlichen General Resolutions. Im Jahr 2014 bestimmte dieses Verfahren systemd zum standardmäßigen Init-System. Die Personen, die damit nicht einverstanden waren, gründeten Devuan als Fork. Devuan veröffentlichte 2017 sein erstes Release. Debian war weder die erste Distribution mit diesem Wechsel noch die letzte. Die Gründe für seine wiederholte Einführung sowie die Einwände, die sich als berechtigt erwiesen, werden in der Darstellung der Ablösung von SysV init durch systemd nachgezeichnet. Zu den größeren Derivaten gehören Ubuntu, Raspberry Pi OS, Proxmox VE, Kali und Linux Mint.

Red Hat, 1994: RPM und die Aufteilung in Fedora und RHEL

Marc Ewing veröffentlichte das erste Red Hat Linux um Halloween 1994. Das Unternehmen von Bob Young kaufte es 1995, und gemeinsam bauten sie das erste Linux-Unternehmen auf, das Support statt Software verkaufte. Red Hat ging am 11. August 1999 an die Börse. IBM schloss die Übernahme des Unternehmens im Juli 2019 für etwa 34 Milliarden Dollar ab. Damit war die Distribution, für die die meiste Unternehmenssoftware zertifiziert wird, seitdem Eigentum von IBM.

Der nachhaltige technische Beitrag ist RPM (Red Hat package manager), das Erik Troan und Marc Ewing 1995 für Red Hat Linux 2.0 entwickelten. Ein RPM deklariert seine Abhängigkeiten und wird aus einer spec-Datei erzeugt, also einer Build-Anleitung, die jeder ausführen kann. Diese zweite Eigenschaft ermöglichte später überhaupt erst unabhängige Rebuilds von Red Hats Enterprise-Produkt.

Red Hat Linux 9 war 2003 die letzte Version der ursprünglichen Produktlinie. Das Unternehmen teilte sie in zwei Produkte auf: Fedora Core 1 erschien im November 2003 als schnelle Community-Version. RHEL (Red Hat Enterprise Linux), das 2002 als Advanced Server 2.1 begonnen hatte, wurde zur langsamen, kostenpflichtigen Variante. Der Grund ist eindeutig. Ein Produkt kann nicht gleichzeitig als Plattform für das Testen neuer Versionen und als Plattform dienen, die eine Bank zehn Jahre lang unverändert betreibt. Die beiden Hälften sind miteinander verbunden: Eine RHEL-Hauptversion wird aus einem Fedora-Release abgezweigt, stabilisiert und anschließend eingefroren. Das Paketwerkzeug entwickelte sich nach demselben Zeitplan weiter, von yum in den 2000er-Jahren zu dnf als Fedora-Standard im Jahr 2015, mit rpm darunter bei beiden.

Warum CentOS kein kostenloser RHEL-Rebuild mehr ist

CentOS startete 2004 mit einer einfachen Aufgabe: die von Red Hat veröffentlichten Quellpakete übernehmen, die Marken entfernen, sie neu bauen und das Ergebnis kostenlos bereitstellen. Die Distribution wurde ein Jahrzehnt lang zur standardmäßigen kostenlosen Serverdistribution. Red Hat übernahm das Projekt 2014.

Am 8. Dezember 2020 kündigte Red Hat an, dass CentOS Linux 8 am 31. Dezember 2021 eingestellt werde. Das war acht Jahre früher als ursprünglich veröffentlicht. Der Name sollte als CentOS Stream weiterbestehen. Stream ist kein Rebuild. Es ist der Entwicklungszweig, aus dem die RHEL-Minor-Releases erstellt werden. Daher liegt Stream vor RHEL und nicht dahinter. Für einen Server, den Sie jahrelang betreiben wollen, ist diese Richtung falsch. Sie erhalten Änderungen, bevor die zahlenden Kunden von Red Hat sie bekommen.

2021 entstanden zwei Rebuilds. Rocky Linux wurde von Gregory Kurtzer gestartet, der CentOS mitbegründet hatte. AlmaLinux wurde von CloudLinux finanziert. Im Juni 2023 stellte Red Hat die Veröffentlichung von RHEL-Quellen überall außer in CentOS Stream und im Kundenportal ein. Rocky hielt am Ziel identischer Rebuilds fest. AlmaLinux änderte sein Ziel in ABI-Kompatibilität (application binary interface). Das bedeutet, dass für RHEL erstellte Software ausgeführt werden kann. Es gibt jedoch keine Zusage, dass die Fehlerliste Zeile für Zeile übereinstimmt. Oracle, SUSE und CIQ gründeten später im selben Jahr OpenELA, um gemeinsame Quellen zu veröffentlichen. Die gesamte Entwicklung, von der Abspaltung 2003 über die Änderung der Quellen 2023 bis zu den aktuellen Zusagen der einzelnen Rebuilds, wird in der ausführlicheren Darstellung von Red Hat, CentOS, Rocky und AlmaLinux beschrieben.

Wenn die Image-Liste eines Providers weiterhin CentOS aufführt, klären Sie vor der Bereitstellung, welches CentOS gemeint ist.

cat /etc/os-release

NAME="CentOS Stream" ist ein fortlaufend aktualisierter Entwicklungszweig, der RHEL vorausgeht. NAME="AlmaLinux" oder NAME="Rocky Linux" ist ein Rebuild, der diesem folgt und einen Zeitraum von zehn Jahren bietet.

Ubuntu, 2004: ein Snapshot von Debian unstable nach Kalender

Ubuntu 4.10 wurde am 20. Oktober 2004 veröffentlicht und von Mark Shuttleworth finanziert. Die Beziehung zu Debian ist technisch und nicht sentimental. Jeder Zyklus beginnt damit, dass Pakete aus Debian unstable in die neue Ubuntu-Version importiert werden. Diese Importe laufen bis zum Debian Import Freeze in der Mitte des Zyklus. Danach verwaltet Ubuntu seine eigenen Änderungen. Viele Ubuntu-Pakete bestehen aus dem Debian-Paket plus einem Delta. Im Changelog ist angegeben, um welche Änderungen es sich handelt.

Die andere Hälfte ist der Kalender. Debian veröffentlicht eine Version, wenn sie bereit ist. Ubuntu veröffentlicht im April und Oktober. Die Versionsnummer entspricht dem Datum: 24.04 wurde im April 2024 veröffentlicht. Jede zweite April-Version ist eine LTS (long term support). Das ist die Version, die ein Anbieter meint, wenn er Ubuntu ohne Zusatzangabe aufführt. Welche der beiden Varianten auf einen Server gehört, ist das zentrale Thema bei der Wahl zwischen Ubuntu LTS und Interim-Releases. Der Wechsel von einer LTS zur nächsten folgt einem eigenen Verfahren, das in dem Upgrade von 24.04 auf 26.04 beschrieben wird.

Ein Detail stellt Serveradministratoren jedes Jahr vor Fragen. Das Ubuntu-Archiv ist in Komponenten aufgeteilt. main wird von Canonical während des gesamten Supportzeitraums gepflegt. universe wird von der Community gepflegt, und die Sicherheitsabdeckung folgt einer anderen Zusage. apt install gibt keinen Hinweis auf diesen Unterschied aus. Ein Befehl zeigt ihn:

apt-cache policy nginx

Eine Repository-Zeile mit /main am Ende bedeutet, dass das Sicherheitsteam von Canonical für dieses Paket zuständig ist. Eine Zeile mit /universe am Ende bedeutet, dass die Community dafür zuständig ist. Prüfen Sie dies bei allem, was aus dem Internet erreichbar ist.

Arch, 2002: Rolling Releases und die Kosten eines Teil-Upgrades

Judd Vinet veröffentlichte Arch 0.1 am 11. März 2002 mit dem von ihm selbst entwickelten Paketmanager pacman und Build-Rezepten in Form einfacher Shell-Skripte. Arch hat überhaupt keine versionierten Releases. Die Installationsmedien sind datierte Snapshots derselben Rolling-Repositories. Ein Rechner, der 2019 installiert und jede Woche aktualisiert wurde, verwendet daher dasselbe Arch wie ein Rechner, der heute installiert wurde. Das AUR (Arch User Repository) enthält von Benutzern beigetragene Build-Rezepte. Dabei handelt es sich nicht um geprüfte Pakete. Vor der Ausführung eines PKGBUILD gehört es daher zur Aufgabe, dessen Inhalt zu lesen.

Rolling Releases haben einen einzigen Fehlermodus, und er wird jedes Mal vom Benutzer selbst verursacht. Wenn Sie ein einzelnes Paket mit pacman -Sy foo installieren, aktualisiert der Befehl zunächst die Paketdatenbank und installiert anschließend eine neue Binärdatei, die gegen neuere Bibliotheken gelinkt ist als die auf dem Datenträger vorhandenen. Programme schlagen dann beispielsweise so fehl:

error while loading shared libraries: libcrypto.so.3: cannot open shared object file: No such file or directory

Der unterstützte Vorgang ist pacman -Syu. Damit werden alle Pakete gemeinsam aktualisiert. Das Projekt veröffentlicht außerdem News-Einträge, in denen vor bestimmten Upgrades auf erforderliche manuelle Eingriffe hingewiesen wird. Wenn Sie das Upgrade ausführen, ohne diese Hinweise zu lesen, kann der Rechner anschließend nicht mehr booten.

Arch ist daher eine schlechte Wahl für einen Server, den Sie längere Zeit unbeaufsichtigt lassen möchten. Ein Rechner, der wöchentlich aktualisiert wird, ist unproblematisch. Bei einem Rechner, den Sie erst ein Jahr später wieder aktualisieren, werden alle übersprungenen manuellen Eingriffe in einem einzigen Durchlauf erforderlich.

Alpine: eine kleine Distribution, die durch Container bekannt wurde

Alpine entstand um 2005 als Fork von LEAF (Linux embedded appliance framework), das seinerseits aus dem Linux Router Project hervorgegangen war. Natanael Copa entwickelte Alpine für Appliances und nicht für Desktop-Systeme. Alpine ersetzt den größten Teil des üblichen Userlands: musl statt der GNU-C-Bibliothek, BusyBox statt der GNU core utilities, OpenRC statt systemd und apk als Paketmanager. Alpine 3.0 war 2014 das Release, mit dem der Wechsel zu musl erfolgte.

Container machten Alpine bekannt. Ein Alpine-Basis-Layer ist nur einen Bruchteil so groß wie eine Debian- oder Ubuntu-Basis. Deshalb wurde Alpine ab 2016 zu einem verbreiteten Basis-Image. Viele Menschen, die Alpine nie selbst installiert hatten, führten es trotzdem täglich aus.

Der Nachteil ist, dass musl nicht glibc ist. Dieser Unterschied führt zu Fehlern, deren Ursache oft nicht offensichtlich ist. Eine gegen glibc gelinkte Binärdatei schlägt unter Alpine mit einer Meldung fehl, die dazu führt, dass nach einer Datei gesucht wird, die bereits vorhanden ist:

sh: ./myapp: not found

Das Programm ist vorhanden. Sein ELF-Interpreter fehlt, weil der Loader von glibc nicht vorhanden ist. Python sorgt regelmäßig für eine weitere Überraschung: Für manylinux erstellte, vorgefertigte Wheels lassen sich unter musl nicht installieren. Deshalb versucht pip, den Quellcode zu kompilieren, und bricht ab, wenn kein Compiler installiert ist. Der musllinux-Wheel-Standard aus dem Jahr 2021 löste dieses Problem für Projekte, die solche Wheels veröffentlichen, aber für keine anderen Projekte.

Als Host-Betriebssystem auf einem VPS lässt sich Alpine mit geringem Platzbedarf installieren und schnell aktualisieren. Gleichzeitig weicht es von dem Pfad ab, den die meisten Dokumentationen voraussetzen. Jede Anleitung, die Sie auffordert, systemctl enable auszuführen, müssen Sie auf rc-update add übertragen.

Das unveränderliche System: atomare Updates und imagebasierte Server

Der neueste Zweig ändert das Update-Modell statt der Paketliste. Ein auf ostree basierendes System hält /usr schreibgeschützt. Ein Update ist ein vollständiger neuer Dateisystembaum, der heruntergeladen, bereitgestellt und beim nächsten Reboot aktiviert wird. Der vorherige Baum bleibt als Boot-Eintrag erhalten. Ein fehlerhaftes Update lässt sich daher rückgängig machen, indem Sie den alten Eintrag booten.

Fedora Silverblue brachte diesen Ansatz 2018 auf den Desktop. Fedora CoreOS brachte ihn 2019 auf Server, nachdem Red Hat CoreOS 2018 übernommen hatte. Flatcar Container Linux führte das ursprüngliche Container Linux fort, als dieses 2020 eingestellt wurde. openSUSE MicroOS erreicht dasselbe Ziel mit btrfs-Snapshots und transactional-update. 2024 fügte Red Hat RHEL einen imagebasierten Modus hinzu, der auf bootc aufbaut. Dabei wird das Betriebssystem als Container-Image ausgeliefert. Eine Maschine wird aktualisiert, indem sie auf einen neuen Tag verwiesen wird. Talos Linux geht am weitesten und entfernt Shell und SSH vollständig. Die Maschine wird über eine API konfiguriert. Es gibt daher keine Anmeldemöglichkeit. NixOS, erstmals 2007 veröffentlicht, verfolgt einen anderen Ansatz. Das gesamte System wird aus einer deklarativen Konfiguration erstellt. Frühere Generationen bleiben bootfähig.

Ihr Provider bietet wahrscheinlich keines dieser Systeme als One-Click-Image an. Diese Systeme sind dafür vorgesehen, beim ersten Boot mit Ignition oder cloud-init konfiguriert zu werden, statt dass ein Administrator Dateien über SSH bearbeitet. Der Vorteil zeigt sich bei vielen identischen Maschinen. In dieser Situation befinden Sie sich, sobald Sie mehrere Linux-Server gleichzeitig verwalten und sicherstellen müssen, dass jeder Server nachweislich mit den anderen übereinstimmt.

Wie lange wird ein Release unterstützt?

Die Release-Politik ist der Teil einer Distribution, mit dem Sie am längsten arbeiten, und sie wird als Anzahl von Jahren veröffentlicht. Hier sind die Zeiträume für 5 aktuelle Server-Releases.

[
  {
    "distro": "Alpine 3.x",
    "standard_years": 2,
    "extended_total_years": 2
  },
  {
    "distro": "Debian 13",
    "standard_years": 3,
    "extended_total_years": 5
  },
  {
    "distro": "Ubuntu 26.04 LTS",
    "standard_years": 5,
    "extended_total_years": 10
  },
  {
    "distro": "AlmaLinux 10",
    "standard_years": 10,
    "extended_total_years": 10
  },
  {
    "distro": "RHEL 10",
    "standard_years": 10,
    "extended_total_years": 13
  }
]

Alpine unterstützt jeden 3.x-Zweig für 2 Jahre. Deshalb eignet sich Alpine besser für ein Container-Image, das Sie häufig neu erstellen, als für einen Host, den Sie unverändert lassen. Das Debian-Sicherheitsteam betreut ein stabiles Release etwa 3 Jahre. Das LTS-Team unterstützt die gängigen Architekturen anschließend insgesamt ungefähr 5 Jahre. Ein Ubuntu LTS bietet Ihnen für Pakete in main 5 Jahre Unterstützung. Ein Ubuntu-Pro-Abonnement verlängert diesen Zeitraum auf 10 Jahre und ist für die private Nutzung auf einer kleinen Anzahl von Maschinen kostenlos. RHEL 10 veröffentlicht einen Supportzeitraum von 10 Jahren. Das kostenpflichtige Add-on für den erweiterten Lebenszyklus verlängert ihn auf 13 Jahre. AlmaLinux 10 entspricht dem RHEL-Zeitraum von 10 Jahren, ohne dass ein Abonnement erforderlich ist. Genau deshalb gibt es die Rebuilds.

Arch ist hier nicht aufgeführt, weil eine Rolling-Distribution kein Release hat, das unterstützt werden müsste. Für Arch ist entscheidend, wie lange Sie eine Maschine unverändert lassen können. Dieser Zeitraum wird in Wochen gemessen.

Warum Ihre VPS-Image-Liste so aussieht

Ein Anbieter stellt die Images bereit, die Kunden namentlich anfordern und die sich unbeaufsichtigt auf seinem Hypervisor installieren lassen. Deshalb beginnt fast jede Liste mit einem Ubuntu LTS und einem stabilen Debian, ergänzt AlmaLinux oder Rocky für Anwender, deren Software für RHEL zertifiziert ist, und führt Alpine, Arch und Fedora weiter unten auf. Wenn Sie wissen, was ein VPS ist und wie das Image auf die Festplatte gelangt, wird das Muster deutlich: Der Anbieter wählt Betriebssysteme aus, die eine unbeaufsichtigte Installation überstehen und länger unterstützt werden, als der durchschnittliche Kunde den Server betreibt.

Die Wahl legt mehr fest als nur einen Paketmanager. Sie bestimmt das Upgrade, das Sie in drei Jahren durchführen werden. Dieses unterscheidet sich je nach Familie grundlegend. Debian und Ubuntu unterstützen direkte Major-Upgrades. Die Red-Hat-Familie führt sie über leapp durch. Bei Arch gibt es kein Upgrade, weil es keine Versionen gibt. Bei Alpine besteht es darin, /etc/apk/repositories zu bearbeiten und apk upgrade --available auszuführen. Die Wahl bestimmt außerdem, welche Software Sie ohne ein Repository eines Drittanbieters installieren können, wer den Patch bereitstellt, wenn ein CVE-Eintrag (Common Vulnerabilities and Exposures) für eine von Ihnen eingesetzte Komponente veröffentlicht wird, und welches Init-System sowie welche C-Bibliothek Ihre künftige Software voraussetzt.

Es gibt noch eine weitere Auswirkung, die leicht unterschätzt wird. Die meisten Anleitungen im Internet gehen von einem Debian- oder einem Red-Hat-Weg aus. Wenn Sie eine andere Familie wählen, müssen Sie Anweisungen während der gesamten Lebensdauer des Systems übertragen. Wählen Sie die Familie, deren Release-Politik dazu passt, wie häufig Sie den Server administrieren möchten, und bleiben Sie dabei. Die Pakete darauf auszutauschen ist einfach. Die Distribution darunter zu wechseln bedeutet, den Server neu aufzubauen.

FAQ

Zu welcher Linux-Distributionsfamilie gehört mein Server?

Führen Sie cat /etc/os-release aus. Das Feld ID nennt die Distribution und ID_LIKE ihre Familie. Ein Ubuntu-System meldet daher ID_LIKE=debian, ein AlmaLinux-System ID_LIKE="rhel centos fedora". Der Paketmanager liefert den zweiten Hinweis. apt und dpkg stehen für die Debian-Familie, dnf und rpm für die Red-Hat-Familie, apk für Alpine und pacman für Arch.

Ist CentOS noch eine kostenlose Version von RHEL?

Nein. CentOS Linux 8, die letzte Neuerstellung unter diesem Namen, wurde am 31 December 2021 eingestellt. CentOS Linux 7 erreichte am 30 June 2024 das Ende seines Lebenszyklus. Das fortbestehende Projekt CentOS Stream ist der Zweig, aus dem die RHEL-Minor-Releases erstellt werden. Daher erhält es Änderungen vor RHEL und nicht danach. AlmaLinux und Rocky Linux haben die frühere Rolle der kostenlosen Neuerstellungen übernommen. Beide bieten einen Zeitraum von zehn Jahren.

Warum enthält Debian stable so alte Versionsnummern?

Die Versionsnummer wird eingefroren, während weiterhin Fehlerbehebungen veröffentlicht werden. Debian übernimmt Sicherheitskorrekturen in die veröffentlichte Version, statt eine neuere Upstream-Version zu importieren. Daher kann ein Paket mit der Versionsangabe 2.4.57-2+deb13u1 eine in der vergangenen Woche veröffentlichte Korrektur enthalten. Das Suffix hinter der Upstream-Version ist die Debian-Revision. apt changelog <package> listet die darin enthaltenen Änderungen auf. Wer die Sicherheit eines Debian-Servers anhand seiner Versionsnummern beurteilt, erhält jedes Mal die falsche Antwort.

Sollte ich eine Rolling Release wie Arch auf einem VPS betreiben?

Nur, wenn Sie das System regelmäßig nach einem festen Zeitplan aktualisieren. Eine Rolling-Release-Distribution setzt voraus, dass jedes System auf den aktuellen Paketsatz gebracht wird. Wenn Sie ein einzelnes Paket mit pacman -Sy foo aktualisieren, bleiben inkompatible Bibliotheken zurück. Dadurch können Fehler wie cannot open shared object file auftreten. Führen Sie pacman -Syu regelmäßig aus. Lesen Sie vor jeder Aktualisierung die News-Seite des Projekts. Dann bleibt das System stabil. Wenn Sie ein Jahr warten, wird das erste Upgrade zum riskanten Schritt.

Was ändert eine unveränderliche oder atomare Distribution tatsächlich?

Sie ändert, wann Aktualisierungen angewendet werden und wie Sie sie rückgängig machen. /usr wird schreibgeschützt eingehängt. Eine Aktualisierung wird als vollständiger neuer Verzeichnisbaum bereitgestellt. Der Wechsel erfolgt beim Reboot. Der vorherige Verzeichnisbaum bleibt als Boot-Eintrag für ein Rollback erhalten. Das System ist dadurch entweder vollständig aktualisiert oder vollständig nicht aktualisiert. Ein teilweise angewendeter Zustand entsteht nicht. Dafür können Sie Software nicht mehr durch Änderungen an Dateien an Ort und Stelle installieren. Anwendungen werden daher in Container oder in geschichtete Pakete verschoben.