Mit einer Woche Abstand zur RHEL-10-Veröffentlichung bringt AlmaLinux OS 10 frischen Wind in die Enterprise-Linux-Welt. Die neue Version mit dem Spitznamen „Purple Lion“ setzt auf Kernel 6.12 und verspricht vollständige Kompatibilität mit Red Hat Enterprise Linux. Ein Highlight: Frame Pointers sind nun standardmäßig aktiviert. Das erlaubt bessere Systemanalyse in Echtzeit. Auch ältere Hardware profitiert, denn […]
Seit einigen Jahren ist CentOS kein produktionstauglicher RHEL-Klon mehr. Wer RHEL produktiv nutzen will, aber nicht dafür bezahlen kann, hat die Qual der Wahl: zwischen AlmaLinux, CentOS Stream (nicht für Langzeitnutzung), Oracle Linux, RHEL via Developer Subscription und Rocky Linux. Ich bin ein wenig zufällig im AlmaLinux-Lager gelandet und habe damit über mehrere Jahre, vor allem im Unterricht, ausgezeichnete Erfahrungen gemacht.
Nach diversen Tests mit der Beta-Version läuft AlmaLinux 10 jetzt nativ auf meinem Mini-PC (AMD 8745H), außerdem die aarch64-Variante in einer virtuellen Maschine auf meinem Mac. Dieser Artikel stellt die neue Version AlmaLinux 10 vor, die am 27. Mai 2025 freigegeben wurde, genau eine Woche nach dem Release von RHEL 10. Die meisten Informationen in diesem Artikel gelten auch für RHEL 10 sowie für die restlichen Klone. Oft beziehe ich mich daher im Text auf RHEL (Red Hat Enterprise Linux), also das zugrundeliegende Original. Es gibt aber auch ein paar feine Unterschiede zwischen dem Original und seinen Klonen.
AlmaLinux 10 mit Gnome Desktop
Ich habe vor, diesen Artikel in den nächsten Wochen zu aktualisieren, wenn ich mehr Erfahrungen mit AlmaLinux 10 gemacht habe und es zu Rocky Linux 10 und Oracle Linux 10 weitere Informationen gibt.
Update 8.6.2025: Der MySQL-Server ist per Default weiterhin offen wie ein Scheunentor.
Update 16.6.2025: Zu Rocky Linux 10 gibt es jetzt auch Release Notes.
Update 16.6.2025: Postfix und BDB vs LMDB
Update 27.6.2025: Oracle Linux 10 ist auch verfügbar, ich habe am Ende des Artikels Links zum Oracle-Blog und zu den Release Notes eingebaut
Red Hat hat mit RHEL 10 den X.org-Server aus den Paketquellen entfernt. RHEL setzt damit voll auf Wayland. (Mit XWayland gibt es für X-Client-Programme eine Kompatibilitätsschicht.) Weil RHEL und seine Klone zumeist im Server-Betrieb und ohne grafische Benutzeroberfläche laufen, ist der Abschied von X.org selten ein großes Problem. Einschränkungen können sich aber im Desktop-Betrieb ergeben, vor allem wenn statt Gnome ein anderes Desktop-System eingesetzt werden soll.
Eine Menge wichtiger Desktop-Programme sind aus den regulären Paketquellen verschwunden, unter anderem Gimp und LibreOffice. RHEL empfiehlt, die Programme bei Bedarf aus Flathub zu installieren. Davon abgesehen ist aber kein Wechsel hin zu Flatpaks zu bemerken. flatpak list ist nach einer Desktop-Installation leer.
In der Vergangenheit haben RHEL & Co. von wichtigen Software-Produkten parallel unterschiedliche Versionen ausgeliefert. Dabei setzte RHEL auf das Kommando dnf module. Beispielsweise stellte RHEL 9 Mitte 2025 die PHP-Versionen 8.1, 8.2 und 8.3 zur Auswahl (siehe dnf module list php).
Anscheinend sollen auch in RHEL 10 unterschiedliche Versionen (»AppStreams«) angeboten werden — allerdings nicht mehr in Form von dnf-Modulen. Wie der neue Mechanismus aussieht, habe ich nach dem Studium der Release Notes allerdings nicht verstanden.
Administration und Logging
Wie schon in den vergangenen Versionen setzt RHEL zur Administration auf Cockpit. Die Weboberfläche ist per Default aktiv, nicht durch eine Firewall geschützt und über Port 9090 erreichbar.
Zur Webadministration ist »Cockpit« auf Port 9090 vorgesehen
Bei einer Desktop-Installation sind standardmäßig rsyslog und das Journal installiert. rsyslog protokolliert wie eh und je in Textdateien in /var/log. Das Journal führt dagegen keine persistente Speicherung durch. Die Logging-Dateien landen in einem temporären Dateisystem in /run/log/journal und verschwinden mit jedem Reboot wieder. Wenn Sie ein dauerhaftes Journal wünschen, führen Sie die folgenden Kommandos aus:
Unbegreiflicherweise ist MySQL — jetzt in Version 8.4 — auch in RHEL 10 per Default so konfiguriert, dass jeder Benutzer mit mysql -u root ohne Passwort volle MySQL-Administrationsrechte erhält. Bei Ubuntu erhält per Default nur sudo mysql Admin-Rechte, und bei MariaDB (egal, ob unter Debian, Fedora, RHEL oder Ubuntu) gilt die gleiche Regel. Warum also nicht auch bei RHEL und MySQL?
Wie dem auch sei, das Problem ist nicht neu. Führen Sie also unmittelbar nach der Installation von mysql-server das Kommando mysql_secure_installation aus! Entscheidend ist dabei die Einstellung einen root-Passworts für MySQL.
sudo mysql_secure_installation
Would you like to setup VALIDATE PASSWORD component? y
There are three levels of password validation policy:
LOW Length >= 8
MEDIUM Length >= 8, numeric, mixed case, and special characters
STRONG Length >= 8, numeric, mixed case, special characters,
dictionary file
Please enter 0 = LOW, 1 = MEDIUM and 2 = STRONG: 1
Please set the password for root here.
New password: ************
Re-enter new password: ************
Disallow root login remotely? y
Remove test database and access to it? y
Reload privilege tables now? y
Postfix und BDB versus LMDB
RHEL 10 liefert den Mail-Server Postfix in der Version 3.8 aus. Bei früheren RHEL-Versionen hat Postfix Berkeley Datenbanken (BDB) zur Speicherung von Konfigurationstabellen verwendet. Mit RHEL 10 wird allerdings die libdbd-Bibliotheken aufgrund von Lizenzproblemen nicht mehr mitgeliefert. Postfix verwendet jetzt per Default LMDB-Datenbanken:
So weit, so gut. Ich bin beim Versuch, einen Postfix-Server einzurichten, allerdings über die Datei /etc/aliases gestolpert. Bisher was es notwendig, nach jeder Änderung in dieser Datei die entsprechende BDB-Datenbank aliases.db mit dem Kommando newaliases neu zu generieren. Genau dieser Hinweis steht auch in der von RHEL ausgelieferten Beispieldatei /etc/aliases. Und erstaunlicherweise funktioniert das Kommando auch unter RHEL 10. newaliases ist über fünf Links mit /usr/sbin/smtpctl aus dem Paket opensmtpd verbunden und scheint weiterhin BDB-Funktionen zu enthalten, Lizenzsorgen hin oder her.
Das Problem ist allerdings, dass Postfix /etc/aliases.db ignoriert und sich stattdessen darüber beklagt, dass es /etc/aliases.lmdb nicht gibt.
journalctl -u postfix
... postfix/smtpd[56492]: error: open database /etc/aliases.lmdb: No such file or directory
Ich habe eine Weile gebraucht, bis ich einen Weg gefunden habe, aliases.lmdb zu erzeugen. Das richtige Kommando, das newaliases ersetzt, sieht jetzt so aus:
postalias /etc/aliases
Virtualisierung
Red Hat enthält die üblichen qemu/kvm-Pakete als Basis für den Betrieb virtueller Maschinen. Die Steuerung kann wahlweise auf Kommandoebene (virsh) oder mit der Weboberfläche Cockpit erfolgen.
Das wesentlich komfortablere Programm virt-manager hat Red Hat schon vor Jahren als obsolet bezeichnet, und ich hatte Angst, das Programm wäre mit Version 10 endgültig verschwunden. Aber überraschenderweise gibt es das Paket weiterhin im CodeReady-Builder-Repository:
crb enable
dnf install virt-manager
virt-manager ist aus meiner Sicht die einfachste Oberfläche, um virtuelle Maschinen auf der Basis von QEMU/KVM zu verwalten. Red Hat empfiehlt stattdessen Cockpit (dnf install cockpit-machines), aber dieses Zusatzmodul zur Weboberfläche Cockpit hat mich bisher nicht überzeugen können. Für die Enterprise-Virtualisierung gibt es natürlich auch OpenShift und OpenStack, aber für kleine Lösungen schießen diese Angebote über das Ziel hinaus.
Bereits in RHEL 9 hat Red Hat die Unterstützung für Spice (Simple Protocol for Independent Computing Environments) eingestellt (siehe auch dieses Bugzilla-Ticket). Spice wurde/wird von virt-manager als bevorzugtes Protokoll zur Übertragung des grafischen Desktops verwendet. Die Alternative ist VNC.
Abweichend von RHEL wird Spice von AlmaLinux weiter unterstützt (siehe Release Notes).
EPEL (Extra Packages for Enterprise Linux)
Zu den ersten Aktionen in RHEL 10 oder einem Klon gehört die Aktivierung der EPEL-Paketquelle. In AlmaLinux gelingt das einfach mit dnf install epel-release. Es wird empfohlen, zusammen mit EPEL auch die gerade erwähnte CRB-Paketquelle zu aktivieren.
Die EPEL-10-Paketquelle ist mit schon gut gefüllt. dnf repository-packages epel list | wc -l meldet über 17.000 Pakete! Ein paar Pakete habe ich dennoch vermisst:
google-authenticator fehlt noch, ist aber in EPEL 10.1 für Fedora schon enthalten, wird also hoffentlich auch für RHEL10 & Klone bald verfügbar sein.
joe fehlt ebenfalls. Ich installiere dieses Editor-Paket gerne, weil es jmacs zur Verfügung stellt, eine minimale Emacs-Variante. Ich bin vorerst auf mg umgestiegen, es entspricht meinen Ansprüchen ebenfalls. (Ich bin kein vi-Fan, und nano ist mir ein bisschen zu minimalistisch. Den »richtigen« Emacs brauche ich aber auch nicht, um zwei Zeilen in /etc/hosts zu ändern.)
AlmaLinux versus Original (RHEL)
Im Wesentlichen verwendet AlmaLinux den gleichen Quellcode wie RHEL und ist zu diesem vollständig kompatibel. Es gibt aber ein paar feine Unterschiede:
Seit RHEL den Zugang zum Quellcodes für die Updates erschwert hat (siehe Ärger für Red-Hat-Klone und Red Hat und die Parasiten), greift AlmaLinux auch auf den Upstream-Quellcode einzelner Projekte zu, führt Bugfixes/Sicherheits-Updates zum Teil früher durch als RHEL und besteht nicht mehr auf eine vollständige Bit-für-Bit- und Bug-für-Bug-Kompatibilität. Im Detail ist diese Strategie und das Ausmaß der Kompatibilität hier dokumentiert.
Red Hat hat RHEL 10 für x86_v3 kompiliert, unterstützt damit nur relativ moderne Intel- und AMD-CPUs. Deswegen läuft RHEL 10 auf älteren Computern nicht mehr! Alma Linux macht es ebenso, bietet aber darüber hinaus eine v2-Variante an und unterstützt damit auch ältere Hardware. Die Mikroarchitektur-Unterschiede zwischen v2 und v3 sind z.B. in der Wikipedia sowie auf infotechys.com beschrieben. Das v2-Angebot umfasst auch die EPEL-Paketquelle.
Der Verzicht auf Bit-für-Bit-Kompatibilität gibt AlmaLinux die Möglichkeit, sich in einigen Details vom Original abzuheben. Das betrifft unter anderem die Unterstützung von Frame Pointers als Debugging-Hilfe sowie die fortgesetzte Unterstützung des Protokolls Spice,
AlmaLinux vs RockyLinux + Oracle Linux
In der Vergangenheit waren alle Klone praktisch gleich. Nun gut, Oracle hat immer einen eigenen »unbreakable« Kernel angeboten, aber davon abgesehen war das gesamte Paketangebot Bit für Bit kompatibel zum Original, kompiliert aus den gleichen Quellen. Die Extrapakete aus der EPEL-Quelle sind sowieso für das Original und seine Klone ident.
Seit Red Hat 2023 den Zugriff auf den Source-Code aller Updates eingeschränkt bzw. deutlich weniger unbequemer gemacht hat, haben sich AlmaLinux auf der einen und Rocky Linux und Oracle Linux auf der anderen Seite ein wenig auseinander entwickelt. AlmaLinux hat den Anspruch auf Bit-für-Bit-Kompatibilität aufgegeben (siehe oben). Rocky Linux und Oracle Linux beziehen den Quellcode für Updates hingegen nun aus anderen öffentlichen Quellen, unter anderem aus Cloud- und Container-Systemen (Quelle).
RHEL Developer
Für Entwickler macht Red Hat mit dem Red Hat Developer eigentlich ein attraktives Angebot. Nach einer Registrierung gibt es 16 freie Lizenzen für Tests und Entwicklungsarbeit. Ich habe einen entsprechenden Account, habe RHEL 10 installiert und registriert, bin aber dennoch nicht in der Lage, die Paketquellen zu aktivieren. Vielleicht bin ich zu blöd, vielleicht wird RHEL 10 noch nicht unterstützt (diesbezüglich fehlt klare Dokumentation) — ich weiß es nicht. Ich habe es ein paar Stunden probiert, und ich werde es in ein paar Wochen wieder versuchen. Vorerst fehlt mir dazu aber die Zeit und der Nerv.
AlmaLinux entstand neben Rocky Linux nach der Abkündigung von CentOS durch Red Hat im Dezember 2020. AlmaLinux weicht mittlerweile von den 1:1 Clones von RHEL ab und nutzt CentOS Stream als Basis.
Innerhalb weniger Tage nach der Veröffentlichung von RHEL 9.5 stehen nun auch Rocky Linux 9.5 und AlmaLinux 9.5 als neue stabile Versionen bereit. Beide Distributionen bringen zahlreiche Verbesserungen und neue Funktionen mit, die Entwickler, Administratoren und Unternehmen gleichermaßen ansprechen. Rocky Linux 9.5 „Blue Onyx“ Rocky Linux 9.5 führt zahlreiche Neuerungen ein, darunter: Zudem wurden die […]
AlmaLinux, eine kostenlose, von der Community getragene Enterprise-Linux-Distribution, ist seit über drei Jahren im Microsoft Azure Marketplace verfügbar. Durch die jüngste Anerkennung zählt AlmaLinux nun jedoch offiziell zu den empfohlenen Optionen auf Azure und reiht sich damit neben bekannten Namen wie Ubuntu, Red Hat Enterprise Linux und SUSE Enterprise Linux ein. Benny Vasquez, Vorsitzender des […]
AlmaLinux entstand neben Rocky Linux nach der Abkündigung von CentOS durch Red Hat im Dezember 2020. AlmaLinux weicht mittlerweile von den 1:1 Clones von RHEL ab und nutzt CentOS Stream als Basis.
Red Hat hat vorgeschlagen, dass Kunden, die über das bevorstehende Lebensende von CentOS 7 besorgt sind, möglicherweise über seinen Insights-Dienst auf Red Hat Enterprise Linux (RHEL) migrieren möchten. Der Support für CentOS Linux 7 endet am 30. Juni 2024. Eine Entscheidung, die Red Hat Ende 2020 getroffen hat. Jetzt ist die IBM-Tochter besorgt über das...
Mit der Veröffentlichung der Version 9.3 geht AlmaLinux seinen kürzlich beschlossenen Weg weg vom 1:1-RHEL-Klon und hin zur Kompatibilität zu Red Hat Enterprise Linux.
AlmaLinux hatte sich, anders als der Verbund aus Suse, Oracle und Rocky Linux dazu entschlossen, nach der Umwidmung von CentOS zum Upstream von Red Hat Enterprise Linux und der erschwerten Zugänge zu den Quellcodes lediglich Kompatibilität mit RHEL anzustreben.
Das biete diverse Vorteile, hatte das AlmaLinux-Team verlautbart. So lasse sich das neue Synergy Repository für alle möglichen Pakete nutzen, die noch nicht in RHEL vorhanden seien, aber von einem Mitglied der AlmaLinux Community für die Gemeinschaft angefordert wurden.
Das nun veröffentliche AlmaLinux 9.3 alias Shamrock Pampas Cat kommt mit dem Kernel 5.14.0-362.8.1.el9_3 und GCC 11.4.1. Das Team verspricht mit AlmaLinux 9.3 mehr Flexibilität und Zuverlässigkeit sowie Sicherheit in hybriden Umgebungen. Mit dieser Version werde zudem die Automatisierung und das Systemmanagement weiter vereinfacht. Verbesserungen an der Web-Konsole würden Verwaltungsaufgaben erleichtern. Darüber hinaus können Benutzer Health Check-Aktionen für Podman-Container und vsock-Geräte in virtuellen Maschinen konfigurieren.
Die Ankündigung verlinkt die diversen Images zum Download.
AlmaLinux verabschiedet sich mit Version 9.3 davon, ein reiner RHEL-Klon zu sein. Das neue Entwicklungsmodell eröffnet auch Perspektiven für die Zukunft.
Die Open Enterprise Linux Association hat ihre Ankündigung umgesetzt und stellt Repositories mit dem Quellcode von RHEL zum Nachbau für jedermann bereit.
AlmaLinux geht einen eigenen Weg, um weiterhin eine mit RHL ABI-kompatible Distribution herausgeben zu können. Trotz Mehrarbeit sehen die Entwickler auch Vorteile.
CIQ, Oracle und SUSE haben vor wenigen Wochen die Gründung der Open Enterprise Linux Association (OpenELA) angekündigt, um RHEL-basierte Distributionen zu unterstützen. Die Entscheidung von Red Hat, den Zugang zu seinem Quellcode einzuschränken, ist eines der wichtigsten und zeitgleich negativen Ereignissen, aus der Open-Source-Welt in diesem Jahr. Diese Nachricht polarisierte und löste einen Sturm an...
CIQ, Oracle und SUSE haben vor wenigen Wochen die Gründung der Open Enterprise Linux Association (OpenELA) angekündigt, um RHEL-basierte Distributionen zu unterstützen. Die Entscheidung von Red Hat, den Zugang zu seinem Quellcode einzuschränken, ist eines der wichtigsten und zeitgleich negativen Ereignissen, aus der Open-Source-Welt in diesem Jahr. Diese Nachricht polarisierte und löste einen Sturm an...
AlmaLinux sucht seinen eigenen Weg aus dem Dilemma, dass Red Hat mit seiner Entscheidung schuf, die Quellen für RHEL nicht mehr öffentlich zugänglich zu machen.
Dass Red Hat angekündigt hat, keinen Quellcode für Downstream-Klone bereitzustellen, damit diese 1:1-Binärkopien von Red Hat Enterprise Linux (RHEL) erstellen können, hat bei den betroffenen AlmaLinux und Rocky Linux und auch Oracle Linux für Aufregung gesorgt. AlmaLinux werde das Ziel, aufgeben, 1:1 kompatibel mit RHEL zu sein, teilt die hinter der Distribution stehende Foundation nun mit.
Man werde aber weiterhin versuchen, eine unternehmenstaugliche, langfristige Linux-Distribution zu entwickeln, die auf die Bedürfnisse der Community abgestimmt und – soweit möglich – ABI-kompatibel mit RHEL sei, berichtet Benny Vasquez, Chair of the Board der AlmaLinux OS Foundation aus der Vorstandsitzung.
Für den typischen Nutzer bedeute dies kaum eine Änderung, schreibt Vasquez weiter. Red Hat-kompatible Anwendungen würden weiterhin auf AlmaLinux OS laufen können, und AlmaLinux-Installationen würden weiterhin rechtzeitig Sicherheitsupdates erhalten. Die bemerkenswerteste potentielle Auswirkung der Änderung sei, dass AlmaLinux nicht mehr an die Linie der “Bug-for-Bug-Kompatibilität” mit Red Hat gebunden sei. Damit könne man Fehlerbehebungen außerhalb von Red Hats Veröffentlichungszyklus akzeptieren. können. Das bedeute zwar, dass einige AlmaLinux OS Nutzer auf Fehler stoßen können, die nicht in Red Hat enthalten sind, auf der anderen Seite könnten sie aber auch von früheren Bugfixes profitieren, die bei Red Hat noch nicht aufgenommen worden seien.
In den Entwicklungs- und Build-Prozessen werde sich einiges ändern. Eines der ersten Dinge seien Kommentare in den Patches einfügen werden, die einen Link zum Ursprung des Patches enthalten. Diese Änderung sei aus mehreren Gründen hilfreich, diene aber insbesondere dem Ziel Transparenz zu schaffen.
Zudem werde man jeden, der Fehler in AlmaLinux OS meldet, darum bitten, das Problem auch in CentOS Stream zu testen und zu replizieren, damit AlmaLInux seine Energie darauf konzentrieren könne, das Problem an der richtigen Stelle zu beheben.
Man wolle auch klarstellen, dass man weiterhin Upstream-Beiträge zu Fedora und CentOS Stream und zum größeren Enterprise-Linux-Ökosystem leisten werde, so wie es seit der Gründung der Foundation geschehen sei.
Das Linux-System BlendOS kann Pakete aus mehreren anderen Distributionen installieren und verwalten. Die neue Version 3 jongliert auch Nix-Pakete und erlaubt nahtlose Updates im Hintergrund.
Bei einer Systemaktualisierung lädt BlendOS v3 zunächst das komplette Basissystem herunter. Da ein Differenzabbild mit Zsync zum Einsatz kommt, soll der Download nur zwischen 10 und 100 MByte umfassen. Beim nächsten Neustart tauscht die Distribution das Root-Dateisystem gegen die aktualisierte Fassung aus. Die vom Nutzer bereits installierten Pakete bleiben dabei unangetastet. BlendOS v3 geht damit den Weg von anderen „unzerstörbaren“ Distributionen wie Fedora Silverblue.
Ab sofort genügt ein Doppelklick auf ein DEB-, RPM-, pkg.tar.zst- der APK-Paket, um die darin enthaltene Software zu installieren. Android-Apps unterstützen allerdings derzeit nur die BlendOS-Varianten mit Plasma- oder Gnome-Desktop.
BlendOS v3 führt mit „user“ und „system“ zwei neue Kommandozeilenbefehle ein. Letztgenanntes dient dazu, Pakete direkt auf dem Host-System zu installieren. Dazu bedient sich „system“ bei den Arch-Linux-Repositories.
Darüber hinaus hilft „system“ bei der Wahl des Desktops: BlendOS v3 unterstützt sieben Desktop-Umgebungen, zwischen denen man schnell mit dem Kommandozeilenbefehl „system track“ wechselt. Die Entwickler rufen zudem Anwender auf, weitere Desktops vorzuschlagen. Dazu müssen sie lediglich eine einfach aufgebaute Konfigurationsdatei erstellen und auf GitHub per Pull-Request einreichen.
Das Tool „user“ ersetzt das alte „blend“-Kommando. Unter anderem kann es Container starten und diese auf ein anderes BlendOS-System verschieben. In Containern erlaubt sind jetzt Arch Linux, AlmaLinux 9, Crystal Linux, Debian, Fedora 38, Kali Linux (in der Rolling-Variante), Neurodebian Bookworm, Rocky Linux, Ubuntu 22.04 und Ubuntu 23.04.
Konfigurationsdateien und Container lassen sich über eine YAML-Datei beschreiben und so auf mehreren Systemen reproduzieren. Das genaue Vorgehen beschreibt ein Eintrag in der Knowledge Base.
Wir sprechen über Red Hat und SUSE und die dazugehörigen Meldungen der letzten Tage und Wochen. Was die jüngsten Entscheidungen bedeuten und welche Reichweite das haben könnte. All das gibts im Podcast.
Im Hause Red Hat scheint man es nicht mehr so gerne zu sehen, dass alle binärkompatiblen Klone von der eigenen Arbeit kostenlos profitieren. Anders als bei CentOS Stream könnten sich Klone wie AlmaLinux oder RockyLinux künftig mit erschwerten Bedingungen konfrontiert sehen. Denn für CentOS Stream kündigen sich Änderungen an, die den Zugirff auf den RHEL-Quellcode...
Der Coup von Red Hat, die Sourcen für RHEL nicht mehr öffentlich bereitzustellen, wird Gewinner und Verlierer haben. Die Verlierer stehen fest, wer wird gewinnen?
Die Einstellung des Git-Repos mit den RHEL-Quellen (siehe auch Ärger für Red-Hat-Klone) hat im Netz erwartungsgemäß für hitzige Diskussionen gesorgt. Ein wenig irritiert haben mich die Kommentare auf lwn.net, eigentlich der seriösesten Linux-News-Quelle: Dort wurden AlmaLinux, Rocky Linux und speziell Oracle von manchen Autoren als »Parasiten« bezeichnet.
Nun ist es unbestritten, dass die Zusammenstellung einer Distribution wie RHEL mit richtig viel Arbeit verbunden ist. Noch viel mehr Mühe bereitet es, das Software-Angebot über 10 Jahre zu warten und auch bei veralteter Software Sicherheits-Patches rückzuportieren. (Python 2.7 ist ein klassisches Beispiel.)
Wenn nun die RHEL-Klone die Quellen einfach kopieren und daraus ein kostenloses Produkt machen (oder, wie im Falle von Oracle, wahlweise kostenlos oder kostenpflichtig mit Support), ist das noch fair? Ist die Bezeichnung »Parasiten« womöglich zutreffend?
Anmerkung: Dieser Artikel wurde zwischen 23.6. und 24.6.2023 mehrfach aktualisiert.
Open Source ist keine Einbahnstrasse
ABER: Linux ist Open-Source-Software. Und das gilt nicht nur für den Kernel, das gilt auch für alle weitere Komponenten: Apache, NGINX, PHP, PostgreSQL, Samba, Postfix, Java, die Bash, der C-Compiler, Python, GRUB usw. Ich könnte hier vermutlich 1000 Open-Source-Komponenten aufzählen, die in RHEL zum Einsatz kommen. Ja, Red Hat arbeitet intensiv an manchen Open-Source-Projekten mit (dem Kernel, systemd, Gnome usw.) und unterstützt viele weitere finanziell. Von anderen Projekten profitiert es, ohne etwas zurückzugeben.
Dazu noch eine Anmerkung aus meiner beruflichen Praxis: Red Hat hat mit Podman ein Konkurrenzprodukt zu Docker geschaffen. Beide Programme stehen unter Open-Source-Lizenzen, beide halten sich an den öffentlichen OCI-Standard und beide funktionieren großartig. In der Presse genießt Docker aber einen zweifelhaften Ruf, weil es versucht, Geld zu verdienen. (Gerade c’t und iX bzw. einige Heise-Autoren sind sehr Docker-kritisch eingestellt.) Übersehen wird dabei: Die Firma Docker betreibt — mit beträchtlichem finanziellem Aufwand — den Docker Hub, die weltweit größte Quelle von Container-Images. Red Hat betreibt zwar auch Registries für ein paar eigene Software-Projekte, aber davon abgesehen gilt: Wer Podman anwendet, bezieht in aller Regel die Images vom Docker Hub (also von docker.io) und verursacht so weitere Kosten für Docker. Red Hat und Podman sind hier also Nutznießer einer Infrastruktur, die von einer anderen Firma geschaffen wurde. (Und ja, das ist Open Source. Das bessere Angebot wird sich langfristig durchsetzen.)
Das Open-Source-Modell funktioniert dann am besten, wenn Einsatz/Aufwand und Nutzen einigermaßen fair verteilt sind. Das Linux-Ökosystem als Ganzes profitiert von erfolgreichen Open-Source-Firmen, und Red Hat war ohne Zweifel die erfolgreichste. (Seit 2018 ist Red Hat Teil von IBM.) Red Hat wiederum profitiert vom riesigen Angebot exzellent gewarteter Open-Source-Software.
Wenn nun umgekehrt kleine Entwickler, Organisationen ohne riesige Finanzmittel, Schulen usw. RHEL-kompatible Software über den Umweg von AlmaLinux, Rocky Linux und Co. kostenfrei nutzen dürfen, erscheint mir das fair. Wiederum profitieren alle, letztlich sogar Red Hat bzw. IBM, weil ihre Software von vielen Anwendern genutzt und getestet wird, weil Studenten die Administration von RHEL-kompatiblen Systemen lernen (und nicht etwas die von Debian oder Ubuntu) usw.
Ohne Not in den Shit Storm
Der Schritt von Red Hat, die Quellen zu RHEL (soweit es GPL-technisch überhaupt möglich ist) zu kappen, wäre verständlich, wenn man sich um die finanzielle Stabilität von Red Hat Sorgen machen müsste. Aber soweit man den Finanzberichten trauen kann, ist das nicht der Fall. IBM hat 2018 Red Hat für 34 Mrd. Dollar gekauft. Damals machte Red Hat 2,9 Mrd Dollar Umsatz und 259 Mil. Dollar Gewinn (Quelle). Seither werden keine eigenen Red-Hat-Zahlen mehr veröffentlicht, aber die Red-Hat-Sparte innerhalb von IBM hat sich offenbar prächtig weiterentwickelt (Quelle). Red Hat kämpft also nicht um sein finanzielles Überleben. Eher ist es wohl die Gier (IBMs?), aus einem gut gehenden Geschäft noch mehr rauszuholen. Auch wenn dabei die Fairness auf der Strecke bleibt.
Und eines muss man schon sagen: Das Timing ist bösartig, ein freundlicheres Wort fällt mir nicht ein. Sowohl die Kommunikation über das CentOS-Ende (Ende 2020) als auch der Stopp der Veröffentlichung der RHEL-Quellen unter git.centos.org (Juni 2023) erfolgte jeweils äußerst kurzfristig mitten im Release-Zyklus. Es ist beabsichtigt, die Anwender von (damals) CentOS und (heute) AlmaLinux, Rocky Linux, Oracle Linux ganz bewusst zu verunsichern und vor den Kopf zu stoßen.
fosspost.org hat die Aktion Red Hat als Schuss ins Knie bezeichnet. Mir erscheint diese Einschätzung zutreffend. Ansible-Entwickler Jeff Geerling fragt: »Are you dumb?« und überlegt, ob er sich überhaupt noch die Mühe machen soll, RHEL zu unterstützen (also z.B. Fehlermeldungen zu bearbeiten, die sich auf RHEL beziehen).
Als Red Hat das CentOS-Projekt in seiner bisherigen Form stoppte, hatte ich Sorgen um die freie Verfügbarkeit von RHEL-Klonen. Dann erlebte das Konzept in Form von AlmaLinux und Rocky Linux eine Wiedergeburt und funktioniert heute besser denn je. Womöglich wird sich dieses Spiel wiederholen. An den Regeln der GNU Public Licence geht auch für Red Hat/IBM kein Weg vorbei. Sicher ist aber schon jetzt: Red Hat (IBM) verliert in der Open-Source-Community gerade massiv Reputation und Gunst.
Anmelden
Mit einer Woche Abstand zur RHEL-10-Veröffentlichung bringt AlmaLinux OS 10 frischen Wind in die Enterprise-Linux-Welt. Die neue Version mit dem Spitznamen „Purple Lion“ setzt auf Kernel 6.12 und verspricht vollständige Kompatibilität mit Red Hat Enterprise Linux. Ein Highlight: Frame Pointers sind nun standardmäßig aktiviert. Das erlaubt bessere Systemanalyse in Echtzeit. Auch ältere Hardware profitiert, denn […]
