Geschichte der Linux-Distributionen und ihre Abstammung

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 die Hardware. Danach endet seine Aufgabe. 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 Gesamtheit an Entscheidungen plus die Gruppe von Menschen, die sich anschließend dauerhaft darum kümmert.

Sie besteht aus fünf Teilen. Ändert man einen davon, erhält man eine andere Distribution, selbst wenn die meisten Binärdateien identisch sind:

• 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 dafür zuständige Installationswerkzeug.
• Eine Release-Policy: Was darf sich ändern, wie häufig geschieht das, und wie lange wird jedes Release gepflegt?
• Menschen: Paketbetreuer, ein Security-Team und eine zuständige Person, die reagiert, 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 steht. Das sollten Sie beim Vergleich von Linux und FreeBSD als Serverplattformen berücksichtigen. Bei FreeBSD werden Kernel und Basis-Userland von einem Projekt entwickelt und gemeinsam veröffentlicht. Unter Linux stammen diese Bestandteile von getrennten Upstream-Projekten. Die Distribution sorgt dafür, dass sie zusammenpassen.

Eine Geschichte der Linux-Distributionen in drei Familien

Aus drei Projekten, die 1993 und 1994 gestartet wurden, entstanden Familien: Slackware, Debian und Red Hat. Fast jedes Image in einem VPS-Kontrollpanel gehört heute zu einer dieser Familien oder ist ein Abkömmling davon. Ein Abkömmling übernimmt das Paketformat, die Dateistruktur und meist auch die Release-Gewohnheiten. Deshalb wirkt eine Debian-Derivatdistribution weiterhin wie Debian, wenn die Markenbezeichnung entfernt wurde.

Die unabhängigen Distributionen verdienen eine eigene Zeile, weil sie von keiner anderen Distribution abgezweigt 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. Die Gründe dafür hatten 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 enthielt den Kernel und die GNU-Tools (GNU's not Unix) in zwei Disketten-Images sowie ein menügesteuertes Installationsprogramm. Der Grund dafür war, dass die manuelle Einrichtung einen ganzen Arbeitstag dauerte.

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

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

Patrick Volkerding veröffentlichte Slackware 1.00 am 16. Juli 1993. Die Distribution basierte auf SLS und beseitigte dessen Fehler. Slackware wird weiterhin gepflegt und ist damit die älteste noch bestehende Linux-Distribution.

Ein Slackware-Paket ist ein komprimiertes tar-Archiv mit einem Installationsskript. Eine Auflösung von Abhängigkeiten gibt es nicht. Es wird nicht geprüft, ob die von einem neuen Paket benötigte Bibliothek bereits auf dem Datenträger vorhanden ist. Diese einzelne Entscheidung prägte alle weiteren Aspekte. Wenn das Werkzeug Abhängigkeiten nicht auflösen kann, muss die ausgelieferte Paketsammlung von vornherein konsistent sein. Deshalb erscheinen neue Versionen selten und mit konservativen Änderungen. Slackware 15.0 erschien im Februar 2022, sechs Jahre nach 14.2.

Die Familie ist klein. Die ersten SUSE-Versionen aus der Mitte der 1990er-Jahre basierten auf Slackware. Später ging das Projekt mit YaST und anschließend mit dem RPM-Paketformat einen eigenen Weg. Dieser letzte Punkt sorgt häufig für Verwirrung. SUSE und openSUSE verwenden RPM-Pakete und sind keine Derivate von Red Hat. Das Format verbreitete sich. 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 Namen seiner Partnerin Debra mit seinem eigenen zusammen. Das Debian-Manifest folgte im Januar 1994 und legte die Bedingungen fest: Diese Distribution sollte offen von Freiwilligen gepflegt werden, nicht von einem Unternehmen.

Debian hielt die Bedingungen anschließend schriftlich fest. Der Debian Social Contract und die DFSG (Debian free software guidelines) wurden im Juli 1997 verabschiedet, und die DFSG bildete 1998 die Grundlage der Open Source Definition. Ein Dokument, das klären sollte, was in eine Distribution gehört, definierte damit letztlich 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 aufwendige Suche installiert werden konnte.

Die Werkzeuge sind das andere Erbe. 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, ist die Ebene, die ermittelt, was zusätzlich und in welcher Reihenfolge abgerufen werden muss. Jeder apt-Befehl in jeder Debian-Ableitung geht auf diese Arbeit zurück.

Der Release-Prozess 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, sofern es auf den Release-Architekturen gebaut wurde und keinen neuen release-kritischen Fehler eingeführt hat. Anschließend wird testing eingefroren, das Release-Team bereinigt die verbleibenden Probleme, und stable wird veröffentlicht, sobald die Fehlerliste kurz genug ist. Nicht zu einem festen Datum. Deshalb wirkt Debian stable alt und verhält sich zuverlässig: Die Versionsnummern bleiben beim Freeze unverändert, während Sicherheitskorrekturen in diese Versionen zurückportiert werden.

Auch die Governance ist schriftlich festgelegt, mit einem gewählten Projektleiter und bindenden allgemeinen Resolutionen. Im Jahr 2014 bestimmte dieses Verfahren systemd zum standardmäßigen Init-System. Diejenigen, die damit nicht einverstanden waren, forkierten Devuan, das 2017 sein erstes Release veröffentlichte. Die größeren Ableitungen sind Ubuntu, Raspberry Pi OS, Proxmox VE, Kali und Linux Mint.

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

Marc Ewing veröffentlichte das erste Red Hat Linux ungefähr zu Halloween 1994. Das Unternehmen von Bob Young kaufte es 1995. Gemeinsam gründeten sie das erste Linux-Unternehmen, 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, gegen die die meiste Unternehmenssoftware zertifiziert wird, seither Eigentum von IBM.

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

Red Hat Linux 9 aus dem Jahr 2003 war die letzte Version der ursprünglichen Produktlinie. Das Unternehmen teilte sie in zwei Teile: Fedora Core 1 im November 2003 als schnelle Community-Version und RHEL (Red Hat Enterprise Linux), das 2002 als Advanced Server 2.1 begonnen hatte, als langsame kostenpflichtige Version. Der Grund ist eindeutig. Ein Produkt kann nicht zugleich die Plattform sein, auf der neue Versionen erprobt werden, und die Plattform, die eine Bank zehn Jahre lang unverändert betreibt. Die beiden Hälften sind miteinander verbunden: Eine RHEL-Hauptversion wird aus einer Fedora-Version 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 in beiden Distributionen.

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. CentOS wurde für ein Jahrzehnt 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 wird, also acht Jahre früher als ursprünglich veröffentlicht. Der Name sollte als CentOS Stream weiterbestehen. Stream ist kein Rebuild. Es ist der Zweig, aus dem die RHEL-Minor-Releases erstellt werden. Daher liegt Stream vor RHEL und nicht dahinter. Für einen Server, den Sie jahrelang betreiben möchten, 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 an allen Stellen außer CentOS Stream und seinem 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, ohne dass garantiert wird, dass die Fehlerlisten vollständig übereinstimmen. Oracle, SUSE und CIQ gründeten später in diesem Jahr OpenELA, um gemeinsam genutzte Quellen zu veröffentlichen.

Wenn die Image-Liste eines Anbieters weiterhin CentOS aufführt, klären Sie vor der Verwendung, welche Variante 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 RHEL folgt und ein Zeitfenster von zehn Jahren bietet.

Ubuntu, 2004: ein Snapshot von Debian unstable nach Kalender

Ubuntu 4.10 wurde am 20. Oktober 2004 mit finanzieller Unterstützung von Mark Shuttleworth veröffentlicht. Die Beziehung zu Debian ist technisch und nicht emotional. 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 pflegt Ubuntu eigene Änderungen. Viele Ubuntu-Pakete bestehen aus dem Debian-Paket plus einem Delta. Im Changelog ist angegeben, um welches Delta es sich handelt.

Die andere Hälfte ist der Kalender. Debian veröffentlicht eine Version, wenn sie fertig 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-Version (Long Term Support). Das ist gemeint, wenn ein Anbieter Ubuntu ohne weiteren Zusatz aufführt. Welche der beiden Varianten auf einen Server gehört, ist das zentrale Thema von der Entscheidung zwischen Ubuntu LTS und Interim-Versionen. Der Wechsel von einer LTS-Version zur nächsten folgt einem eigenen Verfahren, das in dem Upgrade von 24.04 auf 26.04 beschrieben wird.

Ein Detail fällt Serveradministratoren jedes Jahr auf. 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. 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 zuständig ist. Prüfen Sie dies für alles, 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 einem selbst entwickelten Paketmanager, pacman, und Build-Rezepten in Form einfacher Shell-Skripte. Bei Arch gibt es überhaupt keine versionierten Releases. Die Installationsmedien sind datierte Snapshots derselben Rolling-Repositories. Daher läuft auf einem Rechner, der 2019 installiert und jede Woche aktualisiert wurde, dasselbe Arch wie auf einem Rechner, der heute installiert wurde. Das AUR (Arch User Repository) enthält von Benutzern beigesteuerte Build-Rezepte. Es handelt sich um Rezepte, nicht um geprüfte Pakete. Daher gehört es zur Aufgabe, einen PKGBUILD vor der Ausführung zu lesen.

Rolling Releases haben einen Fehlermodus, der jedes Mal selbst verursacht wird. Die Installation eines einzelnen Pakets mit pacman -Sy foo aktualisiert die Paketdatenbank und installiert anschließend eine neue Binärdatei, die gegen neuere Bibliotheken gelinkt ist als die auf dem System 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 wird alles gemeinsam aktualisiert. Das Projekt veröffentlicht außerdem News-Einträge, in denen vor bestimmten Upgrades auf erforderliche manuelle Eingriffe hingewiesen wird. Wird das Upgrade ausgeführt, ohne diese Hinweise zu lesen, kann ein System entstehen, das nicht mehr bootet.

Damit ist Arch eine schlechte Wahl für einen Server, den Sie unbeaufsichtigt lassen möchten. Ein Rechner, der wöchentlich aktualisiert wird, ist unproblematisch. Ein Rechner, der erst ein Jahr später wieder aktualisiert wird, präsentiert Ihnen alle übersprungenen manuellen Eingriffe in einem einzigen Durchlauf.

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 Desktops. Die Distribution ersetzt den Groß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 auf musl umgestellt wurde.

Container machten Alpine populär. Eine Alpine-Basisschicht ist nur einen kleinen Bruchteil so groß wie eine Debian- oder Ubuntu-Basisschicht. Deshalb wurde Alpine ab 2016 zu einem häufig verwendeten Basis-Image. Viele Menschen, die Alpine nie installiert hatten, führten es täglich aus.

Der Nachteil ist, dass musl nicht glibc ist. Der Unterschied zeigt sich in Fehlern, die keinen offensichtlichen Zusammenhang haben. Ein gegen glibc gelinktes Binary 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. Daher wechselt pip zur Kompilierung aus dem Quellcode und bricht ab, wenn kein Compiler installiert ist. Der musllinux-Wheel-Standard von 2021 löste dieses Problem für Projekte, die solche Wheels veröffentlichen, aber für keine anderen.

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

Das unveränderliche System: atomare Updates und imagebasierte Server

Der neueste Zweig ändert das Update-Modell und nicht die Paketliste. Ein ostree-basiertes 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 dieses Modell 2018 auf den Desktop. Fedora CoreOS brachte es 2019 auf Server, nachdem Red Hat CoreOS 2018 gekauft hatte. Flatcar Container Linux führte das ursprüngliche Container Linux fort, als dieses 2020 eingestellt wurde. openSUSE MicroOS erreicht dasselbe über btrfs-Snapshots und transactional-update. 2024 fügte Red Hat RHEL einen imagebasierten Modus hinzu, der auf bootc basiert. 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 nichts, woran Sie sich anmelden können. 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 über Ignition oder cloud-init konfiguriert zu werden, statt dass ein Administrator Dateien über SSH bearbeitet. Sie lohnen sich bei vielen identischen Maschinen. Das ist die Situation, in der Sie sich befinden, sobald Sie mehrere Linux-Server gleichzeitig verwalten und nachweisen müssen, dass jeder Server mit den anderen übereinstimmt.

Wie lange wird ein Release unterstützt?

Die Release-Policy ist der Teil einer Distribution, mit dem Sie am längsten arbeiten. Sie wird in Jahren angegeben. Hier sind die Supportzeiträ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 2 Jahre lang. 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-Security-Team unterstützt ein Stable-Release etwa 3 Jahre lang. Anschließend betreut das LTS-Team die gängigen Architekturen insgesamt ungefähr 5 Jahre. Ein Ubuntu LTS bietet 5 Jahre Support für Pakete in main. Ein Ubuntu-Pro-Abonnement verlängert diesen Zeitraum auf 10 Jahre. Für die private Nutzung auf wenigen Rechnern ist es kostenlos. RHEL 10 bietet 10 Jahre Support. Das kostenpflichtige Add-on Extended Life Cycle Support verlängert diesen Zeitraum auf 13 Jahre. AlmaLinux 10 übernimmt das RHEL-Zeitfenster von 10 Jahren vollständig ohne Abonnement. Genau dafür gibt es die Rebuilds.

Arch hat hier keinen Eintrag, weil eine Rolling Distribution kein Release mit festem Supportzeitraum hat. Für Arch ist entscheidend, wie lange Sie einen Rechner 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 Systeme, deren Software gegen 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, welches Upgrade Sie in drei Jahren durchführen werden, und diese unterscheiden sich je nach Familie vollständig. Debian und Ubuntu unterstützen In-Place-Upgrades auf neue Hauptversionen. Die Red-Hat-Familie führt sie über leapp durch. Arch benötigt 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 zusätzliches Drittanbieter-Repository 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 im Internet veröffentlichten Anleitungen setzen einen Pfad aus der Debian-Familie oder der Red-Hat-Familie voraus. Wenn Sie sich für eine andere Familie entscheiden, müssen Sie daher während der gesamten Lebensdauer des Systems Anleitungen übertragen. Wählen Sie die Familie, deren Release-Politik dazu passt, wie häufig Sie den Server administrativ anfassen möchten, und bleiben Sie dabei. Die Pakete auf dieser Basis zu ändern, ist einfach. Die Distribution darunter zu wechseln, bedeutet, das System 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 deren Familie. Ein Ubuntu-System meldet daher ID_LIKE=debian, ein AlmaLinux-System ID_LIKE="rhel centos fedora". Auch der Paketmanager gibt einen 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 seiner Lebensdauer. Das fortbestehende Projekt CentOS Stream ist der Zweig, aus dem die Minor-Releases von RHEL erstellt werden. Daher erhält es Änderungen vor RHEL und nicht danach. Die kostenlosen Neuerstellungen, die diese frühere Rolle übernommen haben, sind AlmaLinux und Rocky Linux. Beide bieten einen Zeitraum von zehn Jahren.

Warum enthält Debian stable so alte Versionsnummern?

Weil die Versionsnummer eingefroren wird, während weiterhin Fehlerbehebungen bereitgestellt werden. Debian übernimmt Sicherheits-Patches in die veröffentlichte Version, statt ein neueres Upstream-Release zu importieren. Ein Paket mit der Versionsangabe 2.4.57-2+deb13u1 kann daher eine in der vergangenen Woche veröffentlichte Fehlerbehebung enthalten. Das Suffix nach der Upstream-Version ist die Debian-Revision. apt changelog <package> listet auf, welche Änderungen darin enthalten sind. Die Sicherheit eines Debian-Servers anhand seiner Versionsnummern zu beurteilen, führt jedes Mal zu einer falschen Einschätzung.

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

Nur, wenn Sie sie nach einem festen Zeitplan aktualisieren. Eine Rolling-Release-Distribution setzt voraus, dass jedes System auf den aktuellen Paketsatz gebracht wird. Eine Aktualisierung einzelner Pakete mit pacman -Sy foo führt daher zu nicht zusammenpassenden Bibliotheken und Fehlern wie cannot open shared object file. Führen Sie pacman -Syu regelmäßig aus und lesen Sie vor jedem Durchlauf die News-Seite des Projekts. Dann bleibt das System stabil. Lassen Sie es ein Jahr lang unverändert, wird das erste Upgrade zum riskanten Schritt.

Was ändert eine immutable 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 im laufenden System installieren. Anwendungen werden daher in Container oder Layer-Pakete verschoben.