© Evgeniy Shkolenko / 123RF.com

Red Hat schockierte Ende 2020 die Community mit der Ankündigung, CentOS als ständige Distribution einzustellen. Mit AlmaLinux und Rocky Linux stehen zwei mögliche Nachfolger in den Startlöchern.

Die Welt der Linux-Distributionen hat sich in den vergangenen Jahrzehnten stark verändert. Das hat unter anderem etwas damit zu tun, dass Linux seit den frühen 2000-ern in den Rechenzentren stetig an Bedeutung gewonnen hat. Freilich war damit auch eine deutliche Professionalisierung verbunden.

Viele Unternehmen entscheiden sich heute zwar für Linux, aber nur in Verbindung mit Support-Verträgen eines Herstellers, der im Falle eines Falles (technische) Verantwortung übernimmt. Andere Unternehmen sind eher auf der klassischen Linux-Schiene unterwegs, die Support innerhalb der Community sucht und die eigenen Systeme auf Basis eines freien Systems wie Ubuntu oder Debian GNU/Linux konzipiert. Momentan teilt sich der Markt in klare Lager auf.

Weil verlässliche Zahlen fehlen, lassen sich die Anteile von Ubuntu, Debian, Suse Linux Enterprise Server (SLES), Red Hat Enterprise Linux (RHEL) und vielen anderen Distributionen am Markt nicht genau beziffern. Alle verfügbaren Statistiken deuten jedoch darauf hin, dass Ubuntu als Debian-Derivat die größte Verbreitung genießt, gefolgt vom Elter Debian. Auf Platz 3 sehen die Statistiker einhellig CentOS, noch vor dessen “Profi-Version” RHEL.

Diese Aufteilung ist freilich kein Zufall. Ubuntu fußt noch immer auf Debian, auch wenn die Unterschiede kontinuierlich wachsen. Ein geübter Debian-Admin kann ein Ubuntu-System schon deshalb unter Kontrolle bringen und halten, weil ihm dieselben Werkzeuge zur Verfügung stehen und die meisten Programme ihre Konfigurationsdatei an denselben Stellen ablegen. Wer aus der Debian-Welt kommt, der muss sich unter CentOS oder RHEL an sehr viel mehr Neues gewöhnen als bei Ubuntu.

Die Bruchlinie der Admin-Gunst verläuft damit faktisch noch immer an der gleichen Stelle wie bereits vor Jahrzehnten – was der Bauer nicht kennt, frisst er nicht. Wenn Admins die Wahl zwischen “ihrem” System und dem der Konkurrenz haben, entscheiden sie sich für das, was ihnen vertraut ist.

CentOS spielte bis Anfang Dezember 2020 in diesem Theater eine wichtige Rolle. Wer aus der Red-Hat-Welt kam, aber Linux ohne Support der roten Hüte nutzen wollte, konnte nicht zu RHEL greifen: Updates gibt es dafür nur mit gültiger Subskription. Wer schon einmal mit »subscription-manager« auf der Shell zu tun hatte, der weiß: In Sachen Lizenzen hört bei Red Hat der Spaß auf.

Bei CentOS war das anders: Hier bekam der Admin ein zu 100 Prozent binär- und Bug-kompatibles Pendant zu Red Hat, für das Updates frei verfügbar waren. Lediglich auf Support verzichteten die Admins – was vielen leichter fiel, als man glaubt. Der kommerzielle Support fast aller Linux-Distributoren genießt nicht unbedingt den Ruf, stets qualitativ hochwertig oder grundsätzlich nützlich zu sein.

Aus und vorbei

Der 8. Dezember 2020 dürfte für Admins, die ein Red-Hat-Basis-System wollen, ohne für Support zu zahlen, jedenfalls als schwarzer Tag in die Geschichte eingehen. An jenem Tag verkündete das CentOS-Projekt einen fundamentalen Wechsel in der Art und Weise, wie es arbeitet. Ab Ende 2021 gibt es CentOS nicht mehr als Klon von Red Hat Enterprise Linux. Stattdessen fungiert CentOS dann als Entwicklungsplattform für RHEL, und zwar auf Grundlage eines Rolling-Release-Modells.

Dazu muss man wissen: CentOS gehörte seit der offiziellen Übernahme 2005 zu Red Hat – schon das ist vielen Admins gar nicht bewusst. Ein kleines Team bei Red Hat nahm sich im Wesentlichen die jeweils aktuelle Version von RHEL vor, ersetzte darin die Red-Hat-Grafiken durch CentOS-Grafiken, entfernte RHEL-Spezifika wie den Subscription-Manager und bot das Ganze schließlich als eigenes ISO-Image zum Download an. Die Idee hinter CentOS war stets vollständige Binärkompatibilität zu RHEL, was zum Teil absurde Züge annahm. Fehler in CentOS korrigierten die Entwickler auch dann nicht, wenn es bereits Fixes gab, bis die Fehlerkorrekturen auch ihren Weg in RHEL gefunden hatten.

Dass Red Hat CentOS früher oder später den Stecker ziehen würde, hatte man in der Szene schon lange befürchtet. Schließlich konkurriert CentOS nicht nur direkt mit RHEL, sondern verursacht Red Hat obendrein auch noch Aufwand. Nicht allzu lange nach der Übernahme von Red Hat durch IBM war es nun schließlich soweit.

Für Admins, die CentOS als zentrale Komponente ihrer IT-Landschaft betreiben, sind die Neuigkeiten katastrophal: Sie hatten damit gerechnet, CentOS 8 über Jahre nutzen und dann zeitnah auf CentOS 9 aktualisieren zu können. Nun sehen sie sich einer Situation gegenüber, in der es ab Ende 2021 gar keine Updates mehr für das eigene System gibt.

Red Hat verhält sich hier also ausgesprochen unsportlich, denn ein einziges Jahr Vorbereitungszeit ist nicht sonderlich viel für Admins, die einerseits ihr Setup einmal auf links drehen müssen und andererseits ja auch andere alltägliche Aufgaben haben.

Das Rennen um die Nachfolge

Wer sich in der Open-Source-Szene ein bisschen auskennt, der weiß: Die Community nimmt Aktionen wie die von Red Hat als feindselig wahr und goutiert sie nicht nur nicht, sondern reagiert in der Regel auch produktiv-trotzig. Zu den immer wieder angeführten Vorteilen von Open-Source-Software zählt ja gerade der Umstand, dass man nicht vom Wohl und Wehe eines einzelnen Anbieters abhängt.

So kam, was kommen musste: Nur wenige Tage nach Red Hats Ankündigung brachten sich gleich mehrere potenzielle CentOS-Nachfolger ins Gespräch. AlmaLinux, das kurz vorher noch Lenix hieß, erhebt ebenso Anspruch auf das CentOS-Erbe wie Rocky Linux. Letzteres hat sich eigens als Stiftung gegründet, um die Entwicklung eines RHEL-Klons künftig nicht mehr von einzelnen Anbietern abhängig zu machen. Viel mehr als erste Ankündigungen und Betas gibt es von beiden Projekten bisher nicht – theoretisch könnte dieser Artikel an dieser Stelle also zu Ende sein.

Praktisch bieten der Wegfall von CentOS und das Auftauchen mehrerer Alternativen aber die einmalige Gelegenheit für einen Blick hinter die Kulissen: Wie viel Aufwand verursacht es tatsächlich, den Klon einer Linux-Distribution zu pflegen? Welche Infrastruktur muss ein Anbieter schaffen, um diese Aufgabe zu stemmen? Welche Punkte gilt es zu beachten, an die im ersten Moment möglicherweise noch niemand denkt?

Alte Bekannte

Nicht alles ist bei AlmaLinux so neu, wie es im ersten Moment scheint. Die Firma hinter der Distribution etwa entpuppt sich als alter Bekannter: CloudLinux zählt zu den größeren Hosting-Providern, die mit Linux-Servern ihr Geld verdienen. Vermutlich setzen nicht eben wenige Kunden bei CloudLinux auf CentOS, und so bedroht der Wegfall der Distribution indirekt auch das Geschäft des Unternehmens.

Das dürfte den Ausschlag dafür gegeben haben, dass CloudLinux schon wenige Tage nach der Verkündung des CentOS-Endes vorpreschte und einen neuen CentOS-Klon ankündigte, der ursprünglich Lenix heißen sollte. Mitte Januar 2021 entschied man jedoch, das Produkt in AlmaLinux umzubenennen. Alma bezieht sich auf das lateinische Wort für ernähren oder säugen, wie es etwa auch im Kontext der Alma Mater für Universitäten zum Einsatz kommt. AlmaLinux, so die Idee, schafft die Grundlage für das Wohlergehen des Workloads, der auf Alma-Systemen gehostet ist.

In einem auf Youtube veröffentlichten Interview ließ CloudLinux-Chef Igor Seletskiy dann auch keinen Zweifel an den Ambitionen der neuen Distribution. AlmaLinux soll CentOS nahtlos ersetzen und Nutzern auch einen Upgrade-Pfad bieten, um von aktuellen CentOS-Setups auf AlmaLinux umzusatteln. Vorgehen will AlmaLinux dabei im Prinzip exakt so, wie die Nutzer es schon von CentOS kennen: AlmaLinux soll hundertprozentig kompatibel zu RHEL sein, inklusive der berüchtigten Bug-Kompatibilität.

Viel zu tun

Was Außenstehende oft unterschätzen, holt die Entwickler von AlmaLinux gerade brachial ein: Die Komplexität, die das Klonen einer großen Linux-Distribution mit sich bringt.

Bestehende Pakete herunterladen, Logos austauschen und eine ISO-Datei bauen – diese Arbeitsschritte fallen zwar auch an. Doch um sie überhaupt vollziehen zu können, bedarf es schon einiger Infrastruktur. Das Bauen von ISO-Abbildern etwa kann der einzelne Entwickler kaum sinnvoll auf seinem Desktop erledigen, und schon gar nicht, wenn mehrere Maintainer die Arbeit kollaborativ erledigen müssen.

Hier hat CloudLinux freilich den Vorteil, bereits eine Hosting-Plattform mit skalierbarem Speicher zu betreiben, auf der sich Systeme für das Hosten der neuen Distribution schnell starten lassen. Obendrein hängt die CloudLinux-Umgebung über eine dicke Leitung am Internet, der Download der Pakete von bestehenden CentOS-Spiegeln geht also flott.

Für den Bau AlmaLinux-spezifischer Pakete haben die CloudLinux-Leute zudem mehrere separate VMs abgestellt. Auf denen packen sie künftig die RPMs aus und wieder ein, aus denen sie Red-Hat-spezifische Details wie Logos entfernen müssen.

Mehrarbeit verursacht auch der Installer: Wie ein simpler Vergleich von CentOS und RHEL zeigt, ist er selbst gebrandet, sodass die Entwickler auch hier am Original von RHEL Modifikationen vornehmen müssen.

Infrastruktur drumherum

Darüber hinaus machen die CloudLinux-Leute aktuell die Erfahrung, dass eine Distribution nicht nur jene Dienste benötigt, die das Erstellen der ISO-Images voraussetzt. Neben der dafür nötigen Hardware bereitet man gerade reichlich Infrastruktur vor, um AlmaLinux sinnvoll unterstützen zu können.

Eine eigene Website [1] ist seit Ende Januar unter online, eine Github-Organisation gibt es mittlerweile ebenfalls [2]. Hier will CloudLinux die Tools und Werkzeuge veröffentlichen, die im Hintergrund für den reibungslosen Betrieb der AlmaLinux-Infrastruktur sorgen. Zu Redaktionsschluss gab es noch nicht viel zu sehen, laut CloudLinux auch deshalb, weil man erst “fertig” sein möchte – was auch immer das bedeuten mag.

Da AlmaLinux nicht auf existierende Ressourcen bei Red Hat zurückgreifen kann, braucht es zudem einen eigenen Bugtracker, eigene Mailing-Listen und auch eine eigene Chain of Trust für das Signieren von Paketen. Zur Erinnerung: Schon seit einiger Zeit ist bei Red Hat die gesamte Kette der Paketinstallation digital signiert. Versucht man, ein nicht signiertes Paket zu installieren, schlägt Rpm Alarm und fragt mehrfach nach. Die Schlüssel zum Signieren der Pakete auszutauschen, ist keine große Kunst. Mehr Arbeit macht es, Werkzeuge wie Rpm so anzupassen, dass sie Signaturen mit den neuen Schlüsseln auch tatsächlich akzeptieren.

Nicht zuletzt wird AlmaLinux einige Ressourcen in Form von Manpower verschlingen. Security-Updates seitens RHEL müssen die Entwickler künftig etwa zumindest im Hinblick auf RHEL-spezifische Details wie Logos untersuchen. AlmaLinux braucht ferner ein eigenes Sicherheitsteam, das Aktualisierungen verfolgt und nötigenfalls Security-Advisories für die eigenen Nutzer veröffentlicht.

Spieglein, Spieglein …

CentOS kann auf ein verzweigtes Netzwerk von Spiegelservern zurückgreifen, um seine Distribution unters Volk zu bringen. CloudLinux arbeitet laut eigener Aussage an einem ähnlichen Spiegelnetz für AlmaLinux. Naturgemäß dürfte es aber eine Weile dauern, bis so viele Alma-Download-Server zur Verfügung stehen wie jetzt für CentOS.

Daneben werden die Storage-Anforderungen für AlmaLinux-Spiegel auch nicht ganz ohne sein. Zwar plant die Distribution mit x86_64 als erster und Hauptarchitektur, ARM kündigt sich am Horizont aber schon schemenhaft als weitere Architektur an, die die Entwickler laut eigener Aussage ebenfalls unterstützen wollen. Ohne leistungsstarkes Spiegelnetz lässt sich das kaum leisten.

Eine eigene Toolchain

Zu guter Letzt braucht es Software, um die genannten Dienste sinnvoll zusammenzuhalten. Die Systeme, auf denen Komponenten für AlmaLinux selbst laufen, automatisieren die Entwickler etwa mittels Ansible. Pakete für AlmaLinux werden, wie der Zeitgeist es vorschreibt, automatisch in einer CI/CD-Pipeline entstehen, die laut Entwickler-Statements auf Jenkins und Packer setzt.

Jeder einzelne Arbeitsschritt dieser Aufgaben wäre an und für sich nicht sehr aufwendig. Doch Kleinvieh macht auch Mist, und am Ende sind es Kleinigkeiten, die viel Zeit verschlingen. Wer etwa will, dass das Hochladen eines Pakets automatisch einen Bug im Bug-System schließt, braucht entsprechende Integration, die man schlechtestenfalls mühsam von Hand entwickeln muss.

Wo die Reise hingeht

Bei Redaktionsschluss gab es bereits eine AlmaLinux-Version (Abbildung 1), die Sie auch auf der DELUG-DVD dieser Ausgabe finden. Sie erlaubt schon eine Installation und liefert einen guten Indikator dafür, dass die verschiedenen Räder bei AlmaLinux im Hintergrund bereits recht sauber ineinander greifen.

Abbildung 1: Eine erste Beta-Version von AlmaLinux steht auf der Website des Projekts bereits zur Verfügung.

Es bleibt zu hoffen, dass bald auch eine als stabil deklarierte Version folgt: Die Admins, die sonst mit ihren CentOS-Systemen ab Ende 2021 in Sachen Updates, Bugfixes und Sicherheitskorrekturen auf dem Trockenen sitzen würden, brauchen etwas Zeit für die Migration auf eine andere Distribution – auch wenn diese als Drop-in-Replacement auftritt.

Community-Governance

Obgleich CloudLinux mit Igor Seletskiy als Hauptsponsor für AlmaLinux auftritt, soll die Distribution der Community gehören und auch von dieser verwaltet werden. CloudLinux hat hier ganz offensichtlich das Anliegen, nicht als kommerzieller Anbieter eines RHEL-Klons am Markt zu agieren, sondern die Community einen Teil der Arbeit miterledigen zu lassen. Das setzt allerdings entsprechende Strukturen voraus. Entsprechend plant CloudLinux, ein Governance Board einzuführen, das nach aktuellem Stand der Dinge die letzte Instanz bei Fragen rund um AlmaLinux sein soll.

Ob und wann die AlmaLinux-Community sich zumindest zum Teil von CloudLinux abnabelt, scheint derzeit völlig offen. In seiner ersten Instanz soll das Governance Board von AlmaLinux durch CloudLinux eingesetzt werden – wohl vorrangig, weil es eine organisierte Alma-Community noch nicht gibt. Ob und wann Wahlen für das Board stattfinden, wer dann unter welchen Umständen zur Wahl steht, und was das Governance-Board letztlich wirklich leisten soll, lässt sich derzeit nicht zuverlässig prognostizieren.

Rocky Linux als Stiftung

Praktisch die gesamten bis hierhin beschriebenen Arbeiten hat das Rocky-Linux-Projekt in ähnlicher oder identischer Weise in den vergangenen Wochen ebenfalls hinter sich gebracht. Rocky Linux [3] legt sogar noch mehr Wert auf die Arbeit im Kontext der Community. Es kommuniziert, anders als AlmaLinux, von Anfang an nicht über Reddit, sondern über eine eigene Website.

Dort findet sich auch die Community-Timeline, in der das Projekt über weitere Schritte informiert. Laut der dortigen Statements waren Ende Januar 2021 die Infrastruktur für den Bau von Paketen und das Anlegen von Disk-Images fertig. Bis Ende Februar sollte das Rocky-Linux-Paketverzeichnis an den Start gehen, und für Ende März war der erste Release-Kandidat von Rocky Linux angekündigt.

Auch die Rocky-Linux-Entwickler machen also die Erfahrung, dass das Klonen von RHEL mehr Arbeit macht, als man im ersten Moment glauben könnte. Darüber hinaus muss auch Rocky Linux einiges an Geld in das Bereitstellen von Infrastruktur investieren. Teile der Daten hostet das Projekt momentan auf AWS; Gespräche mit anderen Anbietern laufen aber bereits. Sie zielen auch darauf ab, zumindest zum Teil gesponsort zu werden.

Transparenter als AlmaLinux macht Rocky Linux zudem die Liste der Aufgaben, die zu einzelnen Themengebieten wie Anaconda (dem Red-Hat-Installer) oder Sicherheitsaktualisierungen anfallen. Das geschieht nicht nur aus PR-Gründen: Tatsächlich rekrutieren die Mitglieder des Projekts sich vorrangig aus der Community, und die Mitarbeit von Freiwilligen dürfte für den Fortbestand des Projekts essenziell sein. Da hat es AlmaLinux mit einer Truppe von bezahlten Entwicklern etwas leichter. Einen echten Nachteil stellt das aber wohl nicht dar: Rocky Linux wäre schließlich nicht die erste Distribution, die ausschließlich von Freiwilligen gepflegt und betreut wird.

Um die Freiwilligen zu koordinieren, bietet Rocky Linux Zugriff auf eine eigene Instanz [4] des Instant-Messaging-Diensts Mattermost an (Abbildung 2). Dort hat jeder Interessierte die Möglichkeit, sich einen Account zuzulegen und unmittelbar in Kontakt mit anderen möglichen Projektmitgliedern zu treten.

Abbildung 2: Rocky Linux bindet die Community im Augenblick stärker ein, als es bei AlmaLinux der Fall ist, etwa durch eine eigene Mattermost-Instanz.

Zumindest im Moment scheint Rocky Linux damit ein etwas zugänglicheres Projekt als AlmaLinux zu sein. Ob beide Projekte langfristig nebeneinander existieren können, irgendwann gemeinsame Sache machen oder eines der beiden (oder gar beide) untergeht, muss sich noch herausstellen. Absehbar war bei Redaktionsschluss immerhin schon, dass auch ein Rocky-Linux-Release zeitnah zur Verfügung stehen sollte: Für eine erste Beta peilten die Entwickler Ende März 2021 an.

Die Zukunft

Das relative abrupte Ende von CentOS als Linux-Distribution bietet auch Gelegenheit, sich mit dem Sinn und Unsinn großer Distributionen im Jahr 2021 etwas genauer zu befassen. Spitzzüngig könnte man RHEL als Profisystem etikettieren und CentOS als Bastlerwerkzeug abtun, doch das greift viel zu kurz.

Es mag durchaus sein, dass vor allem solche Administratoren CentOS bevorzugen, die ein relativ flexibles System mit vielen Stellschrauben brauchen, ohne sich gleich mit dem Hersteller ins Bett zu legen. Allerdings hat sich in den vergangenen Jahren die Art und Weise fundamental geändert, wie Linux in vielen Unternehmen zum Einsatz kommt – aus mehreren Gründen.

Einerseits begreifen mittlerweile die meisten Admins, dass Automation eine absolute Grundvoraussetzung für Firmen ist, um heute in Sachen IT erfolgreich zu sein. Die beinharten Bastlerinstallationen, bei denen man händisch ein Betriebssystem installiert, manuell ein Apache darüber bügelt und schließlich Owncloud mittels dessen Installer ausrollt, gehören inzwischen in den meisten Firmen der Vergangenheit an.

Um die Installation von Servern kümmern sich stattdessen Automationskonzepte und Systeme für Lifecycle-Management; Pakete installiert Ansible. Das bedeutet unter anderem auch, dass Admins mit den Systemen selbst immer weniger in Kontakt kommen. Ob Dpkg oder Rpm die Pakete verwaltet, spielt keinerlei Rolle, wenn der Administrator Befehle auf den Systemen ohnehin nur noch per Ansible ausführt.

Andererseits haben sich viele Admins längst daran gewöhnt, Anwendungen in Form von Containern auszurollen. Pakete kommen entsprechend vielerorts gar nicht mehr im früher üblichen Umfang zum Einsatz. Das erleichtert die Wartung und auch Updates.

Container bieten Erleichterungen

Statt eines ausgewachsenen Linux-Systems mit Hunderten Paketen braucht ein in Container-Form ausgerolltes MariaDB bloß noch eine Laufzeitumgebung wie Docker oder Podman, einen Linux-Kernel und ein paar Helferlein. Steht ein MySQL-Update an, stoppt der Admin die alte Datenbank und hängt ihr Daten-Volume an den neuen Container an, den er dann startet – fertig. Wie die Installation von Paketen lässt sich obendrein auch dieser Vorgang vortrefflich automatisieren.

Red Hat entwickelt die eigene Enterprise-Distribution seit Jahren in exakt diese Richtung. RHEL dient heute als Fundament für ein ganzes Füllhorn verschiedener Produkte, die vom Grundsystem allesamt nicht viel mehr brauchen als dessen grundlegendste Funktionen. Suse als zweiter großer Enterprise-Distributor schlägt derzeit exakt denselben Weg ein. Ubuntu befindet sich seit Jahren auf dem nämlichen Trip, auch wenn das eigens für diesen Zweck gebaute Paketformat Snap bei den Admins nicht wirklich verfangen will.

So oder so ist der Weg klar: Die Linux-Distribution per se verliert auch in den kommenden Jahren weiter an Gewicht, während zusätzliche Produkte immer bedeutender werden, die auf der Kernfunktionalität des Systems fußen.

Das Ende von RHEL?

Überspitzt ausgedrückt: Für RHEL ist heute wichtiger, dass es Container aus OpenShift, Red Hat Ceph Storage oder Red Hat OpenStack ausführen kann, als dass sich ein General-Purpose-Linux-System damit betreiben lässt (Abbildung 3). Wohl auch vor diesem Hintergrund wurde Red Hat der Aufwand zu groß, CentOS weiter zu pflegen.

Abbildung 3: Quo Vadis, Linux? Braucht man Enterprise-Distributionen nur noch als Container-Vehikel, stellt sich die Frage, ob sie überhaupt noch in der bekannten Form nötig sind.

Es lässt sich nicht einmal komplett ausschließen, dass Red Hat sein Enterprise Linux als Produkt irgendwann ganz aufgibt. Die Pflege verschiedener riesiger Programme (MariaDB, PostgreSQL, Apache, etc.) für verschiedene Versionen der Distribution – einige davon ein Jahrzehnt alt – frisst unglaublich viele Ressourcen.

Längst liefern Projekte wie MySQL oder PostgreSQL ihre Datenbanken aber auch in Container-Form. Ein und derselbe PostgreSQL-Container lässt sich auf RHEL 7, RHEL 8 oder auch RHEL 34 betreiben, solange die Laufzeitumgebung für Container auf dem jeweiligen System mitspielt. RHCOS (Red Hat Core OS) steht als möglicher RHEL-Erbe bereits in den Startlöchern.

Im Rahmen einer Container-First-Strategie, wie sie Red Hat seit Jahren erkennbar fährt, wäre der Schritt nur konsequent, RHEL durch RHCOS zu ersetzen. Und er wäre nicht weniger als eine Revolution: Er würde den geliebten Software-Museen, die offiziell meist Long-Term-Support-Release heißen, die Grundlage entziehen.

Spätestens das wäre dann wohl auch das unvermeidliche Ende von Alternativen wie AlmaLinux und Rocky Linux, denn es ist gewaltige Manpower nötig, um Pakete nicht nur aus RHEL in eine andere Distribution zu übernehmen, sondern sie komplett selbst zu bauen.

Sie sollten sich jedenfalls nicht darauf verlassen, dass Ihnen bis 2029 ein System mit RHEL-Kompatibilität zur Verfügung steht, wie es bei CentOS geplant war. Wie immer gilt: Nichts in der IT ist steter als der Wandel. (jcb/jlu)