Markus Glantz, einer meiner Kollegen bei Red Hat, hat vor einigen Monaten einen sehr guten Artikel verfasst auf Linkedin auf diesen wir uns hier stützen bzw. teilweise übersetzen. Der Link zum Original Artikel (English) findet ihr unten auf dieser Beitragsseite.
2021 haben wir die Open Source Welt durch eine nicht immer ganz gelungene Kommunikation verunsichert wenn es zu unserem Flagschiff RHEL (Red Hat Enterprise Linux) kommt.
Lasst uns kurz betrachten wie die Dinge funktionieren in der Welt der Linux-Entwicklung.
Wichtig auch, bevor wir uns mit dem Entwicklungs-Flow befassen müssen wir zunächst ein grundlegendes Missverständnis ausräumen. Welches wäre, dass einige Linux-Distributionen nicht kontinuierlich sind. ALLE Linux Distributions sind kontinuierlich, es gibt keine V1, V2, V3,…. ect.
Wie Markus Glantz es korrekt dargestellt hat, es gibt keine statischen Boxen wie oben zu sehen, es gibt EINE Linux Distribution die kontinuierlich durch tausende von Open Source Projekten weiterentwickelt wird.
Wie man in der Zeichnung oben gut erkennen kann werden die Komponenten von Linux-Distributionen als inkrementelle Updates veröffentlicht. Diese bauen immer auf den zuvor erstellten Veränderungen auf. Daran ändert sich grundsätzlich nie etwas und ist Teil unseres Entwicklungsmodells. Die Art und Weise wie eine Linux-Distribution diese kontinuierlichen Änderungen veröffentlicht (Wie Red Hat z.B. in RHEL) macht sie in keinster Weise nicht weniger kontinuierlich.
Oben im Bild „Fedora Development“ seht ihr gut wie die Fedora-Entwicklung funktioniert. Der Entwicklungszweig links heißt „Fedora Rawhide“. Aus diesem entstehen alle paar Monate die stabilen Fedora-Zweige. I.d.R liegen 6 Monate dazwischen. Dies geschieht in einer „kontinuierlichen Bewegung“. Wir haben also „keine“ separaten Versionsboxen wie das oft in Closed Code Projekten und Betriebssystemen der Fall ist. Es sind tatsächlich immer nur Updates & Upgrades zu den Vorgängerversionen.
Wenn wir das nun mit der Entwicklung von RHEL vergleichen stellen wir fest das es keine Unterscheidungen gibt zum Upstream Modell. Auch unser RHEL baut immer auf die Vorgängerversion auf, egal ob es sich um eine Minor Version, oder um eine Major Version handelt.
Red Hat Enterprise Linux Release Cycle
- Kontinuierliche Entwicklung
- Neue Major Releases alle paar Jahre (~ 3 Jahre)
- Neue Minor Releases alle paar Monate (~ 6 Monate)
Fedora, CentOS, RHEL – der alte Weg bis 2021
Die ehemalige Entwicklung von RHEL sehen wir unten im Bild. Zu einem bestimmten Zeitpunkt wurde ein Fork von Fedora Rawhide abgezweigt, der zu einer stabilen Fedora-Version wurde. Daraus wurde dann die nächste RHEL Major Version.
Die Repositories die den RHEL-Code enthielten waren hier nach dem forken erstmal nur für Red Hat zugänglich. Wir veröffentlichten allerdings den Quellcode. Zunächst taten wir das auf ftp.redhat.com und später dann (2021 – 2023) auf git.centos.org.
Dieser Code wurde dann verwendet um verschiedene Linux-Distributionen auf Basis von Red Hat Enterprise Linux zu erstellen. Darunter CentOS Linux, Rocky Linux und AlmaLinux. Die Idee war das jeder der Downstream Rebuilder seine Bug Reports an den CentOS Stream reportet und dort dann die tatsächliche Innovation passiert, so das jeder profitiert, egal ob Community Linux Varianten oder Enterprise Linux Varianten. Leider blieb es bei dieser Idee. Die Realität sah anderes aus.
Idee:
Realität:
Dann, da scheinbar die meisten einfach nur kostenlos Bier trinken wollten, trafen wir die Entscheidung die weitere Veröffentlichung von RHEL Source Code auf CentOS.org einzustellen (Ab Juni 2023). Das heißt auch wir als Red Hat entwickeln direkt im CentOS Stream (bereits seit 2021) mit. Dort ist der Source Code natürlich verfügbar und dort hat dann jeder Downstream Rebuilder die Möglichkeit zu kontributieren und Linux innovativ mit zu gestalten. Der RHEL Code selber ist im übrigen für Kunden ind Partner mit Red Hat Account weiter frei verfügbar.
Ein weiter entscheidender Grund sich von diesem System zu verabschieden war übrigens, das es sehr schwierig für Partner und Kunden war sich direkt am RHEL Entwicklungsprozess zu beteiligen. Heißt Kunden oder Development Partner von CentOS Linux oder RHEL wussten nie wirklich wo sie kontributieren konnten (Für Partner gab es z.B. private RHEL Repos). Dies hatte zur Folge dass die CentOS Linux-Community eher passiv wurde anstatt zu einer florierenden Open-Source-Community zusammen zu wachsen die Lösungen für gemeinsame Herausforderungen beiträgt. Das bereitete uns viele Jahre Kopfzerbrechen und es war somit sehr schwierig Binär Kompatible zu sein.
Auf Art und Weise die wir dann schließlich im Juni 2023 eingeführt haben aufgrund der oben beschriebenen Herausforderungen (Alle entwickeln im CentOS Stream) kann nun dass gesamte Enterprise Linux Eco System wirklich profitieren und arbeitet gemeinsam in einem Code Respository.
Ecosystem ab 2023
Die Sorgen war dann – ist RHEL Binär Kompatibel zu CentOS Stream?
Ja es ist! Red Hat Enterprise Linux und CentOS Stream nutzen denselben Entwicklungsprozess, haben das gleich ABI (Application Binary Interface) und es wird binär kompatible Software entwickelt die beide Systeme gleichermaßen betreffen.
Der wohl größte Unterschied zwischen beiden besteht darin dass Software sofort für CentOS Stream released wird während Sie für RHEL dann im z-realeases oder im nächsten Minor release für RHEL verfügbar ist. Entscheidend ist hier das wirklich jedes kleinste ‚bit‘ auch in RHEL einfließt Somit ist RHEL zu 100% Binary Kompatibel zu CentSO Stream.
Oben im Bild wird beschrieben dass der Quellcode der zum Erstellen von CentOS Stream und RHEL verwendet wird derselbe ist. Dieser Code wird synchron in die Gates von CentOS Stream und RHEL eingespeist. Wichtig ist hier, das um den Test zu bestehen, beide Gates den Test parallel bestehen müssen, das für CentOS Stream und das für RHEL.
Dadurch wird technisch sichergestellt dass CentOS Stream ABI-/binärkompatibel mit RHEL ist und dass Software die einmal in CentOS Stream released wurde auch unverändert in RHEL vorhanden ist.
Quellen:
The secret behind Fedora, CentOS and RHEL
The problem with Rocky Linux and free beer
Du muss angemeldet sein, um einen Kommentar zu veröffentlichen.