Hallo und herzlich willkommen zu meinem Vortrag, Zendors ist tot, lang lebe Zendors, WTF-AQ, häufig gestellte Fragen. Mein Name ist Christian Stankiewicz und ich beschäftige mich mit großer Freude

mit den langweiligen grauen Kisten, die einem dabei helfen, Probleme zu lösen, die man ohne sie gar nicht erst gehabt hätte. Das heißt, genauer gesagt, ich beschäftige mich gerne mit Linux, mit Virtualisierung und auch mit dem Themengebiet der Automatisierung, bin also, wie viele von euch auch, stinkend faul. Und ich bin der Meinung, jedes Linux da draußen

ist auf jeden Fall eine tolle Sache, je mehr Auswahl wir haben, desto besser, außer vielleicht die eine oder andere Ausnahme, sowas wie Henna, Montana, Linux. Das brauche ich persönlich jetzt nicht unbedingt. Und wenn ihr mich auf Twitter finden wollt, da bin ich als stankiewiczdebel zu finden, auf GitHub als stdebel. Und hin und wieder blogge ich auch mal.

Und den Content findet man dann eben auf cstan.io. Aber worum geht es denn heute konkret? Es geht um CentOS, das ist schon mal klar. Aber wir werfen mal einen Blick auf die Agenda. Wir werden uns jetzt nämlich gleich erstmal angucken, was es mit dieser CentOS-Abkündigung so auf sich hat.

Das ist jetzt ja auch schon ein bisschen her. Wir werden das also noch mal ein bisschen näher beleuchten. Da gibt es ja auch viele Mythen und viele falsche Informationen, die lange im Netz kursierten. Da wollen wir so ein bisschen aufklären, worum es da eigentlich konkret geht. Dann schauen wir uns an, was es so aktuelles an neuen Entwicklungen in dem Bereich gibt.

Und dann schauen wir uns ein paar Alternativen an, was man denn statt CentOS so wählen könnte. Und zum Abschluss gucken wir uns noch so ein bisschen an, was ist denn so der Ausblick, wohin könnte die Reise gehen. Also beginnen wir mal mit dem ersten Thema der CentOS-Abkündigung. Worum ging es da konkret?

Da ist es so, letztes Jahr im Dezember 2020, ihr habt es vielleicht über die üblichen Kanäle mitbekommen, wurde vom CentOS-Projekt und von Red Hat gleichermaßen die Einschätzung der CentOS-Distribution, wie wir sie heute kennen, bekannt gegeben. Das heißt, das CentOS 7, das CentOS 8, wie wir es eben kennen, da wurde die Einschätzung bekannt gegeben.

Konkret geht es darum, CentOS 7, dass es ja schon seit einiger Zeit gibt. Das wird wie ursprünglich vereinbart bis 2024 gepflegt. Also der Laufzeitrahmen von CentOS orientiert sich ja auch immer am kommerziellen Red Hat Enterprise Linux. Das ist quasi unverändert.

Das sind also noch einige Jahre, drei Stück, in denen man halt eben da noch das Ganze weiter benutzen kann und auch seine Patches erhält. Allerdings CentOS 8, was danach eben schon erschienen ist, das wird nur noch bis Ende 2021 so gepflegt, wie wir es heute kennen. Ursprünglich war mal geplant, dass das bis Mai 2029 der Fall sein sollte.

Also der Lifecycle wurde halt mal eben um schlappe acht Jahre verkürzt. Das ist natürlich nicht so ganz ohne, weil genau das haben ja immer Anwenderinnen an CentOS so geschätzt, dass man halt eben genau weiß, dass CentOS genauso lange gepflegt wird wie ein Red Hat

und man eben sehr langfristig damit planen konnte. Ja, und als Alternative wurde von beiden Quellen, also sowohl von Red Hat als auch von dem CentOS Projekt, wurde eben der kommerzielle Ableger Red Hat Enterprise Linux beziehungsweise CentOS Stream genannt. Das ist natürlich nicht sonderlich gut in der Community angekommen,

wie ihr euch vorstellen könnt. Und deswegen dauerte es auch nicht lang, bis einzelne Personen sich zu dem Thema sofort gemeldet haben. Zum Beispiel gab es eben auch ein Interview mit dem CentOS Board Mitglied Brian Axelbeard. Und da wurde zum Beispiel gesagt,

es gab keinen nennenswerten Einfluss des CentOS Boards. Also diese Entscheidung wurde im Prinzip getroffen, ohne dass das Board viel dazu sagen konnte. Man sagte allerdings auch, die Verkaufszahlen waren kein Motivator. Nun ist es ja so, dass letztes Jahr Red Hat von IBM übernommen wurde.

Und deswegen war es für viele Leute naheliegend, eben IBM die Schuld für diese Entscheidung zu geben. Fakt ist, wir wissen es nicht und wir werden es sehr wahrscheinlich auch nicht erfahren. Und ich bin auch kein Freund davon, da irgendwelche Verschwörungsmythen oder Theorien jetzt in irgendeiner Art und Weise zu kommentieren oder zu bekräftigen.

Die Aussage, die eben von dem CentOS Projekt kam, war, dass es eben hinsichtlich von Verkaufszahlen keine Motivation gab. Also es würde also diese These, dass das durch IBM veranlasst wurde, eben widerlegen. Mir persönlich ist es auch egal, muss ich ganz ehrlich sagen. Wie gesagt, hier wird es definitiv keine konkrete Aussage geben.

Was aber auf jeden Fall interessant ist, dass man eben das auch nutzen wollte, um CentOS Stream so ein bisschen zu pushen. Ja, also man wollte damit sagen, Leute, ihr könnt ja auch CentOS Stream benutzen. Damit kann man eben die Entwicklungen beschleunigen und für die meisten Leute macht das ohnehin keinen Unterschied, ob man jetzt CentOS oder CentOS Stream verwendet.

Aber dazu kommen wir gleich in der nächsten Folie. Denn CentOS Stream, wer das noch nicht kennt, ist ein neues Projekt, das wurde 2019 eingeführt und ist quasi ein Ableger des CentOS Projekts mit einem Rolling Release Modell. Das heißt, wer das nicht kennt, beim Rolling Release geht es darum,

dass man eben keine konkreten eingefrorenen Versionsstände hat, wie zum Beispiel CentOS 8.3, sondern man verweilt auf einer Hauptversion und es wird kontinuierlich immer geupdated. Also es gibt immer wieder neue Updates und es gibt keinen Zustand, dass etwas eingefroren in einer konkreten Version vorliegt.

Also andere Vertreter dieser Art der Versionierung sind beispielsweise Arch Linux oder eben Open Source Tumbleweed. Hat vielleicht der eine oder die andere schon gehört, das ist ein ähnliches Konzept. Das heißt, wenn wir mal jetzt rein über CentOS und Red Hat nachdenken, denn CentOS war ja auch sehr lange Teil des Red Hat Ökosystems, ist es so, dass sich CentOS Stream

im Prinzip zwischen Fedora und Rell positioniert. Ja, es ist ja so, sehen wir auch gleich noch auf einer der folgenden Grafiken, dass immer zu einem konkreten Fedora Release wird irgendwann mal eine Red Hat Version abgeleitet. Und genau dazwischen positioniert sich eben CentOS Stream. Das bedeutet, CentOS Stream ist quasi das Upstream-Projekt

für das nächste Rell Miner Release. Zum Beispiel, aktuell haben wir ja Rell 8.4. Das heißt, die aktuelle CentOS Stream Version, wie gesagt, eine Version gibt es ja in dem klassischen Sinne nicht, aber wenn ihr jetzt heute CentOS Stream verwenden würdet und euch das installieren würdet, dann wäre das eben der Zustand, der dann in Nahezukunft eben zu Rell 8.5 werden würde.

Und das wurde von der Community ein bisschen falsch aufgefasst, weil es ist natürlich schon ein Release, richtig. Das heißt, es ist somit weniger stabil als eben ein Rell theoretisch, weil es ja eben die nächste Miner Version ist, die noch nicht erschienen ist.

Aber es ist trotzdem stabiler als Fedora, was ja relativ häufig released wird. Das heißt, das Hauptargument, das viele Anwenderinnen hatten, dass es eben heißt, ja, aber das ist ja total instabil, das kann ich ja nicht für meine Umgebung benutzen, ist halt so nicht korrekt, weil es ist kein Beating Edge. Das heißt, wenn wir jetzt mal CentOS Stream mit anderen Rolling-Release-Distributionen vergleichen,

wie beispielsweise einen Arch Linux oder einen OpenSuse Tumbleweed, habe ich meiner Meinung nach eben nicht so ein hohes Aufkommen an Update-Paketen. Also wenn ich Arch oder OpenSuse verwende, kann ich im Prinzip mir jeden Tag ein neues Kernupdate installieren, wenn ich möchte. Das ist bei CentOS Stream jetzt nicht ganz so extrem.

Deswegen, das Argument kann ich persönlich nicht ganz nachvollziehen. Das heißt, für wen ist CentOS Stream im Prinzip gedacht? Im Endeffekt ist es so, dass es für Entwicklungs- und Testzwecke meiner Meinung nach komplett unproblematisch ist. Sondern ungeeignet ist es erst dann, wenn ich wirklich eine Bug-Kompatibilität zu RELL brauche.

Der Vorteil von CentOS war ja immer, es war zum einen eben binär kompatibel. Das heißt, Software, die für RELL gebaut wurde, die funktioniert auch unter CentOS. Das ist auch mit CentOS Stream noch der Fall. Wenn es aber jetzt so ist, dass ich eben eine Software bug-kompatibel testen möchte, das heißt, ich weiß zum Beispiel,

es gibt spezifische Bugs in RELL 8.3 und ich muss die eins zu eins in meinem CentOS nachstellen, dann ist das natürlich nicht unbedingt die Distribution, die ich verwenden kann, weil ich halt eben einen Schritt voraus bin. Und eben der Bug, auf den ich mich referenziere, möglicherweise schon längst als behoben gilt. Um das mal grafisch darzustellen,

haben wir hier eine kleine Zeichnung, die uns zeigen soll, wie jetzt das Zusammenspiel zwischen Fedora, CentOS Stream und RELL eben aussieht. Das heißt, links sehen wir eben den Versionsstrahl von Fedora. Ja, wir sehen zum Beispiel, es gibt Fedora 28. Dann kommt irgendwann N plus eins, die nächste Version.

Und irgendwann ist man eben bei Fedora 34. Das heißt, Fedora Raw Height ist im Prinzip immer die neueste Fedora-Version. Irgendwann wird davon eben zum Beispiel Fedora 28 abgezweigt. Das ist dann quasi die Basis für CentOS Stream 8. Das ist die obere Linie, die wir hier sehen.

Und da ist es so, da gab es dann zu irgendeinem Zeitpunkt, zum Beispiel wurde von dieser Stream-Codebase ein RELL 8.2 abgezweigt. Parallel ging die Entwicklung auf CentOS Stream 8 weiter. Irgendwann wurde auch dieser Code-Zustand eingefroren. Daraus ist dann eben dann RELL 8.3 geworden.

Und so weiter und so weiter. Das heißt, es wird also irgendwann von dem Zustand, als Fedora 28 rauskam, wird eben Stream 8 abgezweigt. Und innerhalb dieser Version, da findet eben die ganze Entwicklung nun als Running Release statt. Und das ist genau das, was ich meine. Das ist kein Bleeding Edge, weil da nicht auf einmal Dinge drin sind,

die erst in Fedora 32 rausgekommen sind. Sondern es ist ja schon ein bisschen abgehangen. Und innerhalb dieser leicht abgehangenen Codebase, da findet eben ein Running Release statt. Ja, das noch mal zur Bekräftigung des Arguments, dass es zwar Running Release, aber kein Bleeding Edge ist. Ja, und irgendwann später, das jetzt hier weiter unten zu sehen,

zum Zeitpunkt von Fedora 34, wurde hier wieder abgezweigt. Das ist eben das, was man CentOS Stream 9 nennt. Das gibt jetzt auch schon als erste Alpha, wenn ich das richtig in Erinnerung habe. Und davon wird dann irgendwann, schätzungsweise irgendwann nächstes Jahr, RHEL 9.0 abgezweigt. Und dann eben nach einigen Monaten RHEL 9.1 und so weiter.

Das heißt, so ist das Zusammenspiel zwischen CentOS Stream, Fedora und RHEL. Aber vielleicht werfen wir auch noch mal einen kurzen Blick auf die Geschichte von CentOS. Das ist nämlich ganz interessant an der Stelle, wie ich finde. Denn da ist es nämlich so, dass 2004 wurde das Projekt von Gregory Kurzer eben ins Leben gerufen.

Und zwar war CentOS ein binärkompatibler Klon von RHEL. Also ein sogenanntes Downstream. Das kam gut an, das kam sogar so gut an, dass ein Jahr später CentOS so populär war, dass es halt eben von Suchmaschinen vor Red Hat Enterprise Linungs angezeigt wurde. Das heißt, wenn ich damals nach RHEL gesucht habe,

war der erste Hit CentOS und der zweite oder dritte Hit, das war dann halt erst die Red Hat Seite. Es ist natürlich aus einer Marketing- und buchaterischen Sicht ein bisschen unklug, weil als Unternehmen man natürlich auch das Interesse hat oder Red Hat hatte das Interesse, eben natürlich auch seine Subscriptions für RHEL zu verkaufen. Das heißt, Red Hat hat dann ganz höflich mal angeklopft beim CentOS-Projekten,

hat gesagt, hier Leute, total cool, dass ihr Open Source macht, dürft ihr ja auch, ist ja alles legitim. Aber wollt ihr nicht vielleicht die Magenzeichen ein bisschen entfernen auf der Webseite, dass wenn man nach Red Hat sucht, man nicht unbedingt CentOS findet. Und das große Problem war, dass zu dem Zeitpunkt gab es in dem CentOS-Projekt einige Leute, die das nicht so ganz nachvollziehen

wollten und Red Hat deswegen getrollt haben. Das heißt, man hat dann die Webseite genommen und da, wo überall Red Hat stand, hat man halt eben PNAELV, also Prominent North American Enterprise Linux Renderer, eingetragen, was relativ eindeutig ja Red Hat darstellen sollte und so ein bisschen eine Verballhornung war.

Das war natürlich nicht so cool. Das heißt, Red Hat hat dann irgendwann Anwälte eben auf das Projekt angesetzt. Und Greg Recurzer hat das nur so am Rande mitbekommen, hat dann gesehen, Moment, hier sind auf einmal Anwälte da und hat sich dann aus dem Projekt herausgezogen, weil er gesagt hat, es macht keinen Sinn, mit den Leuten zu arbeiten.

Er hat mehrfach darauf hingewiesen, dass eben diese Magenzeichen adäquat entfernt werden müssen. Dem ist die Community nicht nachgekommen. Und damit er halt nicht verklagt wird, hat er seine Konsequenzen gezogen und ist da rausgegangen. Das war so die Zeit, wo CentOS eher so ein bisschen seine Tiefen hatte. Also da gab es halt auch durch einige Community-Member,

die da nicht so wohlwollend gestimmt waren, war das nicht so eine gute Zeit für das Projekt. Das hat sich dann aber auch geändert. Zum Beispiel spätestens 2014 ist CentOS nämlich integraler Bestandteil von Red Hat geworden. Das heißt, Red Hat hat eben vier Entwickler angestellt, das CentOS-Projekt und hat damals auch versprochen,

keine drastischen Änderungen an dem Projekt vorzunehmen. Und 2019 hat man dann eben CentOS Stream vorgestellt und 2020, das kennt ihr ja, da haben wir gerade drüber gesprochen. Das ist so grob ein bisschen der Verlauf, wo CentOS herkommt, was sich schon drin so passiert ist und wie das Ganze jetzt quasi endet.

Das finde ich immer ganz interessant, das mal im Hinterkopf zu behalten, um zu verstehen, wo das herkommt. Und generell muss man sagen, seit der Übernahme von Red Hat gab es schon stabilere Prozesse. Also gerade, wenn man mal drüber nachdenkt, immer wenn eine neue RHEL-Version rausgekommen ist, zum Beispiel RHEL 6, da hat es immer eine gewisse Anzahl, Monate oder Wochen gedauert,

bis es dann eben auch das CentOS-Pondor gab. Dazu, dass CentOS dann irgendwann auch Bestandteil von Red Hat war, waren die Prozesse ein bisschen optimierter und es hat nicht mehr so lange gedauert, mit den Paketierungen, mit den Patches hinterherzukommen. Also hat er auch durchaus eine Vorteilung. Kommen wir mal zu den aktuellen Entwicklungen. Was hat sich denn seit Dezember 2020 getan?

Wie schon angedeutet, fand die Community das jetzt nicht sonderlich toll, dass Red Hat und CentOS sich dazu entschieden haben, CentOS einzustellen. Die Kommentare unter den Blogposts, die kamen relativ schnell und in einer relativen Deutlichkeit.

Ich glaube, ihr könnt euch alle vorstellen, wie Meinungsmache im Internet heutzutage funktioniert. Also die volle Breitseite positiven und negativen Feedbacks hagelten auf beide hinab. Red Hat hat dann irgendwann eingelenkt. Das heißt, es gibt die Red Hat Developer Subscription, die gibt es auch schon länger. Das ist jetzt nichts Spezifisches wegen der CentOS-Sache.

Die wurde eben erweitert. Vorher galt die immer für eine einzelne Person und man konnte damit ein Red Hat-System für Testszwecker für sich persönlich registrieren. Die wurde jetzt eben erweitert, sodass man damit bis zu 16 Systeme verwenden kann für Tests, für Entwicklungen und auch ausdrücklich für Produktion

und auch in der Nutzung in einer Cloud-Umgebung. Das heißt, wenn ihr so eine Developer Subscription habt, dann könnt ihr die benutzen, um auf Azure, AWS, Hetzner, was auch immer, euch eben eine RLVM hochzuziehen und da Dinge zu tun. Das bedeutet natürlich, dass ihr keinerlei Support-Anspruch habt. Das heißt, ihr könnt das verwenden,

ihr könnt Updates installieren. Wenn irgendwas nicht funktioniert, dann könnt ihr auch gerne versuchen, in der Red Hat Community im Forum Threads aufzumachen. Aber es gibt natürlich keine Hotline, wo ihr euch melden könnt. Und man braucht eben ein Red Hat-Kundenkonto. Das ist kostenlos, kann man sich einfach registrieren. Ich glaube, man kann sich sogar mit seinem GitHub oder seinem Facebook-Account einloggen.

Und Red Hat hat auch nochmal betont, dass man nicht für Marketing-Zwecke kontaktiert wird. Wir haben sich eingetragen gestört, weil CentOS konnte man ja auch ohne Account benutzen. Und es ist auch in der Regel nur für kleinere Kundinnen anwendbar. Weil es gibt natürlich viele Kunden, die haben wirklich nur eine Handvoll Systeme gehabt,

wo sie eben CentOS darauf betrieben haben. Aber ich kenne auch durchaus Umgebungen mit definitiv mehr als 16 Systemen. Gerade wenn wir mal so an Universitäten und Schulen denken, oder an Forschungszentren. Da gab es oft wirklich sehr große Installationen. Und da sind natürlich 16 Systeme ein bisschen zu kurz gedacht, würde ich jetzt sagen.

Es gab auch eine Petition zu dem Thema. Und die hat innerhalb kurzer Zeit, ich glaube weniger Tage, dann auch 10.000 Unterschriften bekommen. Aber man ist natürlich bei dem Kurs so weit geblieben. Was jetzt allerdings auch noch neu ist, und das wollte ich euch nicht vorenthalten,

ist, es gibt jetzt auch die Red Hat Developer Subscription for Teams. Das bezieht sich jetzt nicht auf eine Einzelperson. Also die eben erwähnte Developer Subscription, die zielt halt auch wieder auf eine natürliche Person ab. Aber die Subscription for Teams, die gilt halt für eine ganze Firma oder für eine ganze Abteilung beispielsweise. Da sind dann bis zu 25.000 Systeme mit abgegolten.

Allerdings ausschließlich für Entwicklungszwecke. Das bedeutet, wenn jetzt ein Kunde eben eine sehr große Entwicklungsumgebung hat, dann könnte er die benutzen und müsste sich keine Rell Subscription erwerben. Um so eine Subscription zu bekommen, muss man die beantragen über einen sogenannten Sales Associates.

Also da gibt es keinen Online-Formular und auch keinen KB-Artikel oder irgendwie sowas, sondern man muss da wirklich an den Ansprechpartner herantreten. Und gegen Aufpreis gibt es halt eben auch Support. Das heißt, erstmal hat man auch keinen Support. Wenn man den haben will, dann kostet das eben extra. Und das große Problem meiner Meinung nach ist,

dass das ein bisschen schwammig formuliert ist, was eine Entwicklung ist. Also das definiert ja jeder Kunde für sich selbst. Und Red Hat hat aber natürlich dann schon eine genauere Vorstellung, was Entwicklung ist. Aber das ist nicht so klar definiert. Also es gibt da so einen FAQ-Artikel zu. Aber da bin ich jetzt persönlich nicht so schlau draus geworden. Also es ist so ein bisschen schwammig formuliert.

Deswegen, glaube ich, bedarf das dann doch längerer Gespräche, bis man sich da irgendwie einigen kann. Und das andere Problem ist ja auch, meiner Meinung nach, ist es natürlich auch wieder nur für Kundinnen anwendbar, die eine reine Entwicklungsumgebung auf CentOS betrieben haben. Das heißt, wenn ich vorher Dinge entwickelt, aber auch getestet habe, dann ist es ja

rein formell keine Entwicklungsumgebung. Und dann ist es eigentlich auch nicht legitim, diese Subscription dafür zu verwenden. Deswegen läuft es da, glaube ich, auf einem individuellen Draht zu Red Hats zu, dass man da einfach mal näher ins Gespräch gehen muss, um halt eben abzuklären, ob das jetzt das, was man selbst betreibt,

wirklich auch in den Augen Red Hats nur eine Entwicklungsumgebung ist. Aber, und das ist ja das Schöne an Open Source Software, wir haben ja immer die Möglichkeit, Dinge zu forken. Das ist auch recht schnell passiert. Also innerhalb weniger Tage gab es schon die ersten Projekte, die sich da angedeutet haben. In dem Blogartikel, der da eben erschienen ist,

auf Seiten von CentOS und Red Hat, war eben eins der ersten Projekte, die sich herausgezeichnet hat, Rocky Linux. Dann gab es auch relativ schnell Alma Linux. Das hieß am Anfang Codename Lennox. Das hat vielleicht der eine oder die andere auch auf Twitter und so weiter gelesen. Und es gibt noch den dritten im Bunde Navy Linux.

Und wir gucken uns jetzt einfach mal die einzelnen Forks an. Und beginnen mal mit Rocky Linux. Rocky Linux ist ein Fork, der von Gregory Kurzer erstellt wurde. Also eben genau derjenige, der damals auch CentOS ins Leben gerufen hat und dann ja doch relativ früh wieder aus dem Projekt ausgeschieden ist.

Rocky Linux ist jetzt hier eine Anspielung auf Rocky Mac Go. Das ist einer der ersten Infrastructure-Member, die damals die ersten CentOS-Bills angestoßen haben, der leider schon verstorben ist. Und deswegen ist das eine nette Umarsch an den Kollegen von damals,

finde ich eine sehr schöne Sache. Rocky Linux ist auch 100% bug-kompatibel mit Red Hat Enterprise-Ledungs. Das heißt, es ist binär und auch bug-kompatibel. Ein 1 zu 1 Replika, wenn man so möchte. Das läuft auf X86 und auch auf AM64-Bit. Also sowohl auf Servern als auch auf kleinen Rechnern wie so einen Raspberry Pi.

Und es gibt eben auch die Rocky Enterprise Software Foundation, RESF. Das ist eine unabhängig gemeinnützige Organisation, die gegründet wurde, die rein spendenfinanziert ist. Und die darf auch laut Linux Foundation offiziell den Namen Linux tragen. Also es hat am Anfang ein bisschen gedauert,

bis das Projekt so ein bisschen technisch auch ins Rollen gekommen ist, was halt eben dahin liegt, dass man eben erstmal Zeit aufwenden musste, um so eine gemeinnützige Organisation zu gründen, Sponsoren zu finden und halt eben auch den Namen Linux bei der Linux Foundation beantragen zu können. Das heißt, was hat man getan?

Es gab zuerst eine Community-Satzung, die erstellt wurde und es wurde eine Struktur geplant, die eben die Probleme verhindern soll, die Xandos am Anfang hatte. Deswegen bin ich auf die Geschichte kurz eingegangen und habe euch erklärt, weswegen Gregory Kurtzer sich da relativ schnell herausziehen musste. Deswegen hat es ein bisschen gedauert, bis sich da auch

mal was getan hat aus technischer Sicht. Es gibt eine Bildinfrastruktur, die unter anderem auf AWS läuft. Und im April diesen Jahres erschien ein Release Candidate auf Basis von RHEL 8.3 und die stabile erste Version, die ist jetzt im Juni erschienen und zwar auf Basis 8.4. Also Rocky Linux 8.4 kann man sich jetzt

herunterladen und kann es verwenden. Dann gibt es noch Alma Linux und Alma Linux ist deswegen prominent, weil sie ein bisschen schneller waren als Rocky Linux. Alma Linux, lateinisch für Seele, ist auch wieder ein RelFork und der kommt von einer Firma, die Cloud Linux ist ein US-amerikanischer

Distributor und auch Hoster. Die haben schon viel Vorerfahrung, auf die sie zurückgreifen können. Die haben nämlich schon mal einen RelFork veröffentlicht, der heißt Cloud Linux OS, passend zum Firmennamen. Und das ist halt eben ein kommerzieller RelFork, das heißt, das ist ein Rel, wo eben nochmal spezielle Anpassungen für das Hosting

Geschäft von Cloud Linux mit drin sind und auch nochmal eine Eigenentwicklung. Es gibt zum Beispiel eine Integration in das Management Panel von Cloud Linux und so weiter. Das heißt, die haben einfach schon eine Bildinfrastruktur gehabt, die haben schon jahrelange Vorkenntnisse gehabt, wie man halt eben so einen Fork hochzieht und das konnten die natürlich auch

direkt am ersten Tag einsetzen. Das heißt, auch Alma Linux ist eben 100% bug-kompatibel mit Rel. Und das war anfangs erstmal nur x86 64-bit. Die haben nämlich das erste Release schon mit 8.3 gehabt, aber jetzt mit 8.4 haben sie auch eine Version für

ARM 64-bit rausgebracht. nun ist es ja so, dass dahinter eine Firma steht, Cloud Linux. Und die haben halt eben angegeben, dass sie jährlich eine Million US-Dollar in die Entwicklung investieren. Und die große Aussage, die sie in einem der Webcasts hatten, war, dass einmal Linux

forever free sein wird. Das muss natürlich jeder für sich selbst so ein bisschen bewerten. Eine ähnliche Aussage gab es ja auch mal von Red Hat seines CentOS, als nämlich das CentOS Projekt integraler Bestandler von Red Hat wurde, hieß es ja auch, keine drastischen Änderungen machen zu wollen. Das heißt, da ist CentOS ein bisschen vorbelastet mit solchen Versprechungen.

Aber man muss sagen, sie liefern, sie haben den ersten Release schon am 30.3. gehabt, haben auch direkt einen Migrationsscript auf GitHub gehabt. Und das Ganze ist jetzt aber auch an eine Community übergeben worden. Das heißt, das ist jetzt nicht so, dass die Firma die vollen Rechte daran hat, sondern es gibt halt eben

Mitarbeiterinnen von Cloud Linux, die an einmal in uns arbeiten. Aber es gibt auch eine Community, wo jeder mitmachen kann. Und da gibt es auch ein Board, wo die Leute aus der Community drin setzen. Also wenn Cloud Linux jetzt das Projekt einstellen wollen würde, dann sollte das ausgeschlossen sein. So zumindest die Aussage

der Firma dahinter. Und der dritte im Bunde ist in dem Kontext eben Navy Linux. Das ist ein eher unbekanntes Projekt. Das wurde von einer Gruppe, die sich Unix Lab nennt, gegründet. Da ist allerdings unklar, wer dahinter steckt. Also da kann man auch nach googeln. Da findet man keine wirklich nennenswerten Informationen. Oder ich

habe mich zu blöd angestellt. Und das ist eben ebenfalls auch ein 1-2-1-Klon von CentOS. Das heißt auch hier wieder Binär- und Backkompatibilität zu Rell ist gegeben. Und das soll vollständig von einer Community gepflegt werden. Wobei wer jetzt diese Community darstellt, das ist relativ intransparent. Bei Rocky und Alma Linux sieht man das. Es gibt

eben einen Forum. Man sieht, wer wo dran arbeitet. Das ist bei Navy Linux nicht der Fall. Und ja, sollen Teams gegründet werden. Derzeit gibt es 40 Core-Mitglieder, die an diesem Projekt arbeiten und circa 80 Slack-User. Aber ist trotzdem nicht so ein bisschen, für mich nicht wirklich greifbar, wer jetzt dahinter steckt.

Und seit Juli gibt es auch eine Non-Profit-Organisation, die eben Navy Foundation heißt. Und da war es am Anfang so. Es gab für 8.3, gab es Pakete, aber kein Installer, also keine ISO, die man sich hätte runterladen können. Aber jetzt im August ist eben das erste stabile Release, Navy Linux

8.4 erschienen. Das gibt es erst mal nur für X86 64-Bit. Aber wenn man sich so ein bisschen in den Mirrors umschaut, dann findet man auch schon teilweise Pakete für ARM 64-Bit und für PowerPC 64-Ditteln. Das heißt, das scheint in irgendeine Art und Weise geplant zu sein.

Man findet aber jetzt im Wiki keine Informationen dazu. Für mich ist die Zukunft ein bisschen fragwürdig, weil ich eben auch nicht weiß, wer dahinter steckt. Das ist alles ein bisschen intransparent. Und was ich auch ein bisschen sonderbar finde, ist, es gibt ja das Apple Repo, das extra Packages für Enterprise Linux. Das, denke ich mal, kennt der eine oder die andere, der sich mit CentOS eben beschäftigt hat.

Und die Plane davon und Fork, der halt eben SELA heißt, also Stable Enterprise Linux Repository. Aber da sind nur sehr wenige Inhalte aktuell vorhanden. Da gibt es zum Beispiel irgendwie spezielle Ceph, Docker, Gluster, Samba und NFS, Ganesha, Paketversionen.

Aber das, was Apple ausmacht und Apple ist wirklich groß, wie ihr vielleicht wisst, da ist noch nichts davon zu sehen. Also ist so ein bisschen schwer zu greifen. Also auch ich habe jetzt keine Namen irgendwo gefunden, keine aktive Community. Auf Twitter reagieren sie meistens relativ schnell. Also habt auch irgendwie

ein paar Mal 404s oder SSL-Fehler gefunden. Da waren die auf Twitter relativ schnell hinterher. Aber es ist für mich einfach ein bisschen schwer zu greifen. Deswegen weiß ich nicht, wie langfristig zukunftsorientiert dieses Projekt ist. Aber der Vollständigkeit haltbar muss es natürlich hier auch genannt werden. Um das mal zu vergleichen,

tabellarisch, habe ich hier mal kurz gegenübergestellt. Rel versus Rocky, Alma und Navy Linux. Rel gibt es für X86, ARM für die Set Series von IBM und für die Power PC Series. Rocky und Alma gibt es für ARM und für X86, Navy nur für X86.

Für Rel, Rocky und Alma Linux gibt es Vagrant Boxes. Das heißt, wenn ihr Infrastructure als Code macht und euch gerne mal eben schnell VMs mit irgendwas hochziehen wollt, könnt ihr da direkt mit loslegen. Für Navy Linux habe ich nichts in der Art gefunden. Und bei den verfügbaren Paketen ist es üblicherweise so, dass Rel eine höhere Paketauswahl

hat. Was daher kommt, dass Rel ja auch aufpreispflichtige Zusatzprodukte hat. Es gibt zum Beispiel Rel Real Time oder es gibt Kernel Live Patching oder es gibt Cluster Stack und was auch immer. Das heißt, da ist eben die Paketauswahl ein bisschen größer. Rocky und Alma Linux sind auf dem gleichen Stand, wie eben auch CentOS das damals war. Das heißt, da fehlen einige

Pakete. Bei Navy Linux sind allerdings ein paar Pakete mehr vorhanden. Wie die zustande kommen, ist mir noch nicht so ganz klar. Ich nehme an, durch diesen Apple Fork, wo man eben verschiedene Versionen dupliziert nochmal ausliefert, dass es daher kommt. Bei Rel gibt es eine unbestimmte Anzahl an Mirror-Servern draußen im Internet.

Die haben ja ein eigenes CDN. Rocky und Alma Linux haben hier mit 90 bis 130 Servern auch eine gute Skalierung. Das heißt, egal wo auf dem Planeten man sich befindet, man hat mit Sicherheit irgendwo einen brauchbaren Mirror. Bei Navy Linux sieht es ein bisschen anders aus. Da hat man nur drei Mirror. Da ist auch die Daunertrate nicht so gut.

Wenn man zu Rel migrieren will, dann könnt ihr das tun von CentOS 7 und 8. Und ab Rel 8.3 könnt ihr auch von einem Oracle Linux migrieren. Bei Rocky geht das nur von CentOS und Alma Linux unterstützt CentOS, Rel, Rocky und Oracle Linux. Also einmal die breite Palette. Navy kann noch gar nichts ergleichen, ist aber in Planung. Es gibt einen Wiki-Artikel

dazu, wie ich gerade die Tage auf Twitter gelesen habe. Aber da wird es vermutlich auch noch ein Script geben. Rel natürlich gibt Support dafür. Rocky Linux ist noch ganz unklar, ob es das irgendwie geben wird über Drittanbieterfirmen. Bei Alma Linux ist es in Diskussion. Da gibt es ja eine Firma, die auch aktiv daran mitarbeitet. Könnte man theoretisch also anbieten.

Bei Navy gibt es keine Aussage. Secure Boot für Rel ist geplant. Bei Rocky gibt es das schon. Alma Linux kann das noch nicht. Und bei Navy Linux gibt es auch noch keine Aussage. Ich sehe auch gerade, hier ist ein Video drin. In Rocky gibt es noch keinen Secure Boot. In Alma Linux gibt es den schon. Das muss ich hier nochmal ergänzen.

Ja, und wenn ihr da hinmigrieren wollt, ist das denkbar einfach. Sowohl von Rocky Linux als auch von Alma Linux gibt es ein einfaches Migrations- Script. Das ist auch ein einfaches Shell-Script. Das findet ihr auf GitHub. Das könnt ihr euch einfach runterladen, könnt's ausführen. Und dann wird halt eben aus eurer CentOS Installation Rocky bzw. Alma Linux.

Viel muss ja im Prinzip auch nicht getan werden. Ja, es werden halt eben ein paar GBG-Keys ausgetauscht. Das Release ändert sich halt eben, weil sich die Distribution ändert. Ein paar Pakete müssen neu installiert werden. Aber im Prinzip ist es ja das gleiche Paket in Anführungsstrichen nur mit einem anderen Branding. Also habe ich mehrfach getestet. Das läuft so 10

Minuten durch. Ihr macht kurz einen Reboot und dann habt ihr eben andere Repos drin, andere Sunning-Keys und ja, eine andere Distribution, die sich aber exakt so verhält, wie das CentOS, was ihr vorher drin hattest. Was aber noch mal interessanter ist, ist die Frage nach der Geschwindigkeit,

nach den Release-Abständen. Da ist nämlich so, Rell 8.4 ist eben im Mai erschienen. Alma Linux 8.4 ist relativ schnell acht Tage später erschienen. Und jetzt haben sie noch die ARM 64-Bit-Version nachgeschoben. Das sei hier der Vollständige halber auch noch mal genannt. Rocket Linux hat ein bisschen länger gebraucht. Über einen Monat

bis sie da die neueste Version am Start hatten, wobei man da auch sagen muss, Rocket Linux hatte wirklich bei null angefangen. Die hatten keine Organisation, keine wirkliche Community dahinter, keine Bildinfrastruktur. Da wird es einfach, glaube ich, die Zukunft zeigen, wie schnell Rocky in Zukunft eben adaptieren kann, wenn jetzt eben Rell 8.5 rauskommt.

Und Navel Linux war da dann doch noch mal deutlich langsamer, was vermutlich auch daran liegt, dass es halt eben nur vier Core Member gibt und bei Rocky und Alma Linux gibt es eine viel größere Teammannschaft dahinter. Das muss man auch ganz klar sagen. Was auch viele Fragen ist, oder das ist den meisten

Anwenderinnen wichtig, wenn sie wechseln, wie schnell sind die jeweiligen Forks? Also wenn ein Rell-Patch rauskommt, dann will ich ja auch möglichst schnell einen Rocky- bzw. Alma Linux-Patch dafür haben. Weil es nutzt mir ja nicht, einen Fork zu benutzen, der im Prinzip das Gleiche ist, wenn ich dafür nur einmal im Monat Updates bekomme. Da habe ich ja nichts mit

gewonnen, dann habe ich ja unter Umständen einen Monat lang eine massive Sicherheitslücke. Und das habe ich mir mal angeschaut über die letzten zweieinhalb Monate, habe da mal eine Auswertung gefahren, vom 1.6. bis zum 17.8. Und habe einfach mal ein bisschen verglichen. Und zwar habe ich mir angeschaut, es gibt ja die Red Hat Security Adversaries, das ist eine Online-Datenbank, wo man genau

einsehen kann, welche Patches, mit welcher Gewichtung rausgekommen sind, welche Pakete, für welche Distribution davon betroffen waren. Und sowohl Rocky Linux als auch Alma Linux haben ähnliche Websites, also auch Online-Datenbanken, wo man genau diese Patch-Informationen für Rocky und Alma Linux sieht.

Nevi Linux fällt da so ein bisschen raus, weil die haben aktuell noch keine Rata-Informationen, die sie bereitstellen. Habe ich aber auch bei denen mal eingekippt und nachgefragt. Ich weiß jetzt nicht, ob es auf der Roadmap steht, aber sie wissen jetzt zumindest, dass das vielleicht was wäre, das man benutzen könnte. Und das, was ich euch jetzt gleich in der Grafik zeige, könnt ihr auch sehr gerne nochmal nachlesen. Das Ganze ist auf GitHub verfügbar.

Die slides werde ich in Nachgang auf der Frostcon-Webseite hochladen. Könnt ihr dann gerne euch angucken. Wir gucken uns mal die Tabelle an, bzw. den Grafen, der sich aus der Tabelle heraus ergeben hat. Das sieht nämlich wie folgt aus. Ich habe hier Rocky und Alma mal verglichen. Unten seht ihr die offiziellen Namen der Patches, wie sie Red Hat vorgibt.

Also RHSA ist Red Hats Security Advisory. Und dann habt ihr hier eine fortlaufende Nummer. Und pro Patch habe ich halt geguckt, wie heißt eben der Patch bei Rocky und AlmaLinux. Die haben dann halt andere Namen. Also dann statt Red Hat Security Advisory heißen die halt Rocky Security Advisory oder AlmaLinux Security Advisory.

Und daraus kann ich ja sehen, ich weiß, wann der Red Hat Patch rausgekommen ist und dann kann ich das korrelieren, wann der Alma und der Rocky Patch rausgekommen ist. Daraus ergibt sich dieser Graph. Und was wir hier sehen, ist, dass hier die Achse zeigt quasi die Differenz an zum Red Hat Datum, wie viele Tage es gedauert

hat. Und da sehen wir AlmaLinux ist wirklich sehr, sehr, sehr, sehr schnell, muss man wirklich sagen. Also das ist in der Regel immer am gleichen Tag. Es gibt hier glaube ich ein paar Meter Daten, die nicht korrekt sind, weil manchmal ist der Alma Patch einen Tag vor dem Red Hat Patch rausgekommen. Das wage ich mal zu bezweifeln, dass das wirklich so stattgefunden hat.

Ich nehme an, da werden einfach die Metainformationen nicht korrekt gepasst haben oder Zeitzonenverschiebung oder was auch immer. Aber ihr seht in aller Regel entweder am gleichen Tag oder hier am Ende, dann halt spätestens am nächsten Tag. Also die sind recht flink, muss man sagen. Bei Rocky sah es am Anfang wirklich nicht so gut aus. Da haben

die Patches teilweise hier 50-40 Tage länger gebraucht. Was glaube ich einfach daherkommt, dass Rocky am Anfang noch keine gescheite Bildinfrastruktur hatte, das Team noch nicht da war, die Parkplans noch nicht vorhanden waren, während der Alma halt eben schon auf die ganzen Vorkenntnisse von Cloud Linux aufbauen konnte.

Das heißt, man sieht es hier, es ist dann besser geworden. Also so ab Mitte, Ende Juli sind die auch recht schnell. Es gibt hier manchmal Ausreiser. Hier war mal ein Patch, der irgendwie acht Tage gebraucht hat, aber normalerweise so zwei, drei Tage später sind die auch da. Was allerdings auffällt, ist, dass hier so ein paar Risse im Grafen drin sind.

Dass hier einfach zwischendrin auch mal Patches fehlen. Dazu kann man sagen, das scheint daran zu liegen. Ich hab diese Tabelle auch mal im Rocky-Liedungsforum gepostet und hab mal gesagt, hier mir ist aufgefallen, da gibt's irgendwie neun Patches, die hat die Alma-Liedungs ausgeliefert, Rocky-Liedungs aber nicht.

Die hab ich hier auch mal aufgeführt. Zum Beispiel einen Firefox-Patch, den es irgendwie gab, oder Ruby-Patches. Dann hat sich herausgestellt, die Patches wurden wohl ausgeliefert. Also man findet diese spezifischen RPM-Paket-Versionen, die diesen Patch ausmachen, auch im FTP oder HTTP-Mirror. Es gab aber nie einen Errater dazu.

Da ist es so, Rocky-Liedungs hat halt ne Pipeline, die sich die Errater-Information von Red Hat Enterprise-Liedungs holt, die Pakete neu kompiliert und da scheinen einfach manche Erraters nicht übernommen worden zu sein. Und es gab auch aber einen Patch, der von Rocky-Liedungs ausgeliefert wurde,

allerdings nicht von Alma-Liedungs. Da scheint es ein ähnliches Problem zu geben. Also da hab ich mich auch mal an Alma-Liedungs gewandt und auch da ist das Paket definitiv im Repo vorhanden. Da scheint einfach irgendwie die Pipeline mit dem Erratern abzuhaben. Also das würde ich jetzt nicht zu sehr

beeindrucken lassen. Aber Fakt ist, Alma liefert einfach sehr, sehr schnell und Rocky kommt jetzt erst an einen Punkt, wo sie auch eine gewisse Geschwindigkeit haben, aber tendenziell ist Alma noch mal einen kleinen Tick schneller. Das muss man auf jeden Fall anmerken. Aber wie sieht es denn aus, wenn man jetzt sagt, okay, interessiert mich alles nicht. Ich hab keinerlei Vertrauen

mehr in Red Hat-artige Distros. Das könnte noch mal passieren. Ich will jetzt was anderes machen. Das ist vollkommen valide. Die Auswahl habt ihr. Es gibt sehr viele Linux-Distros. Eine davon, und das wäre die naheliegendste, wäre eben Oracle Linux. Die gibt seit 2006. Ist auch ein Fork von Rell, ein kommerzieller quasi, weil er von Oracle eben kommt.

Der kann kostenlos verwendet werden. Man kann ihn allerdings auch mit Support haben. Dann kostet das eben Geld. Und Oracle Linux bietet optional auch einen Linux-Körner mit speziellen Oracle-Anpassungen. Das heißt, wenn ihr halt eine Oracle-Datenbank habt, dann gibt es da einen Körner, der da nochmal ein bisschen optimiert drauf ist und dann läuft das Produkt vielleicht ein bisschen besser

drauf. Es gibt Migrationsscripts auf GitHub. Da könnt ihr von CentOS 6 bis 8 auf Oracle Linux migrieren. Allerdings nicht mit CentOS Stream. Das funktioniert so nicht. Vorteil dabei wäre, es ist binär-kompatibel. Ist die gleiche Codebase. Ist auch mal an den Rell als Codebase gewesen. Das heißt,

der Migrationsaufwand dürfte für euch tendenziell dann geringer sein. Nachteil ist, das Ganze gibt es aktuell nur für X86 64-Bit und ARM 64-Bit. Während es Rell und CentOS auch für PowerPC eben gibt. Und ansonsten ist meiner persönlichen Meinung nach die Zukunft ein bisschen fragwürdig, weil der Hersteller jetzt nicht

unbedingt damit aufgefallen ist, ein sonderlich großes Interesse in Open-Source-Software und Open-Source-Kultur zu haben. Wenn wir mal an OpenSolaris denken, an Java, an OpenOffice, da ist da schon ein Muster, das sich irgendwie abzeichnet. Ich will natürlich hier nix in den Mund legen,

aber ich würde mir wünschen, dass es diesmal vielleicht besser läuft mit Oracle Linux als mit den anderen Tools. Ansonsten gibt es auch noch die Möglichkeit, OpenSource zu verwenden. Das ist auch eine Lieblingsdistribution, die von einer Community gepflegt wird. Und zwar ist es auch so, es gibt

einen Bordausschuss dieses Projekts und da sind sechs Leute drin. Zwei davon gehören auch zu SUSE. Das heißt, das sind SUSE-Angestellte. Aber die anderen vier gehören eben nicht zu SUSE. Das heißt, die Community hat halt einfach einen größeren Einfluss als die Firma, die das so ein bisschen mit-subventioniert.

Und das ist eben ein kommerzieller SUSE-Linux- Enterprise-Server. Davon gibt es zwei Editionen. Es gibt eben einmal OpenSource Leap. Das ist quasi die stabile Version und ist jetzt auch das Upstream zu SUSE-Linux-Enterprise. Das heißt, vorher war die Aussage nur so

zu 90% zutreffend, aber jetzt mit dem neuen OpenSource Leap 15.3 bzw SUSE-Linux-Enterprise 15sp3 ist es so, dass der Prozess auch wirklich vereinheitlicht wurde. Das heißt, auch die Infrastruktur, die genutzt wird, das ist auch teilweise die gleiche. Und das ist auch so, dass ich in OpenSUSE Pakete

konsumiere, die wirklich aus dem SUSE-Linux-Enterprise kommen, zum Beispiel. Dann gibt es noch das OpenSUSE Tumbleweed. Das ist eben ein Rolling Release. Das ist die Entwicklerversion. Die hatte ich auch eingehend schon mal kurz erwähnt. Das heißt, wenn ich Bleeding Edge haben will, dann ist eben OpenSUSE Tumbleweed das Tool, was ich oder die Distro, die ich benutzen

sollte. Und wenn ich irgendwann mal in OpenSUSE Leap habe, dann kann ich auch zu Slash migrieren und das wird auch vom Support abgedeckt. Das ist eine ganz feine Sache, wie ich finde. Hat den Vorteil, es ist das gleiche Paketformat, also auch OpenSUSE verwendet RPM-Pakete, wie eben Rell und Centos auch. Und ich persönlich finde die Community

ganz interessant, weil sie wirklich aktiv arbeitet und die Community auch einen guten Job macht und auch jeder da wirklich willkommen ist. Nachteil ist halt, das ist eine andere Distribution. Also gerade, wenn man noch nie mit SUSE gearbeitet hat und dann auf einmal mit so Dingen konfrontiert wird wie JAST, das ist schon eine gewisse Umgewöhnung, die da stattfinden muss. Das will ich gar nicht beschönigen

jetzt. Das ist schon was anderes. Klar, die ganzen Kommandozahlen-Tools arbeiten natürlich größtenteils gleich, aber man muss sich erst mal umgewöhnen. Was viele Leute auch anprangern, ist, dass es relativ kurze Wartungszeiten bietet. Das heißt, wenn jetzt ein OpenSUSE rauskommt, zum Beispiel OpenSUSE Leap 15.3, dann wird das für

18 Monate mit Patches versorgt. Denn einmal im Jahr kommt ein minor Release raus. Das heißt, das nächste wäre dann jetzt zum Beispiel OpenSUSE 15.4, das eben für nächstes Jahr erwartet wird. Und sobald so ein Release draußen ist, dann wird das aktuelle alte Release, also eben jetzt in dem Fall 3, wenn 4

rauskäme, das wird noch für 6 Monate weiter unterstützt. Und ihr habt dann 6 Monate Zeit rüber zu migrieren. Das gilt natürlich nicht für die Enterprise-Version. Also wenn man Slash verwendet, dann sind da die Zeitabstände doch nochmal anders. Man kann sich auch nochmal extra Support reinkaufen, sodass man mehr Zeit hat als 6 Monate.

Aber wir reden ja hier gerade über einen potenziellen Nachfolger oder eine Ablöse von CentOS. Das heißt, rein aus CentOS Sicht, wenn ich kein Geld in die Hand nehme und OpenSUSE Leap verwende, habe ich 6 Monate Zeit. Je nachdem, wie groß meine Landschaft ist, ist das vielleicht zu kurz. Das heißt natürlich auch in Summe, ich muss häufiger Upgrades fahren. Weil ich muss

eben einmal im Jahr idealerweise alle meine Systeme auf die neuen Service Pack upgraden. Könnte also auch nicht Ihnen gefallen. Dann gibt es noch Ubuntu und ich denke, das kennen die meisten von euch. Ubuntu ist eine von einer Community gepflegte Linux-Distribution, die gibt es seit 2004,

basiert auf dem Debian-Paket-Format, teilt auch viel mit Debian und ist nicht ohne Grund die beliebteste Distribution im Hosting, im Public Cloud oder im Container- Bereich. Das heißt, wenn man irgendwo ein Hosting-Angebot annimmt oder in der Public Cloud

sich vor allem zusammenklickt, dann ist Ubuntu meistens das, was die Leute am meisten verwenden. Und wenn ich mir irgendwo ein Container-Image runterlade, dann ist es auch häufig so, dass die zum Großteil auf Ubuntu basieren. Hat seine Vor- und Nachteile, aber wir wollen jetzt hier keine Grundsatzdiskussion über den Bau von Container-Images führen.

Fakt ist, das ist eine sehr beliebte Distribution. Und es gibt eben pro Jahr immer zwei Releases, nämlich die Punkt 04 und die Punkt 10 Releases, die halt eben im April und im Oktober erscheinen. Die werden in der Regel neun Monate unterstützt. Und danach gibt es eben das nächste Release. Die Ausnahme bilden

die sogenannten Long-Term-Support-Releases. Die kommen alle zwei Jahre im April raus. Das heißt, jedes zweite Punkt 04 Release ist ein sogenanntes Long-Term-Support-Release. Das wird fünf Jahre lang mit Patches versorgt. Das heißt, das wäre dann das, was man verwenden wollen würde in einer professionellen Umgebung, wo man nicht alle neun Monate

sich die Maschinen neu hochziehen möchte. Bei Zendos hatten wir ja zehn Jahre. Das heißt, ein Argument, das häufig kommt, ja, aber bei Ubuntu habe ich ja nur fünf Jahre. Warum soll ich Ubuntu benutzen? Das ist so nicht ganz korrekt. Also, ja, es sind erst mal kostenlos fünf Jahre. Aber es gibt eben auch das Extended Security Maintenance, kurz ESM.

Und ab Ubuntu 1804 kann man da quasi weitere fünf Jahre dazu bekommen. Und dann kommt man auch wieder auf zehn Jahre. Bei SUSE und Red Hat kriegt man halt standardmäßig 10 und gegen extra Münze bis zu 13. Hier wären es dann halt mit extra Münze bis zu 10. Ist halt ein Argument, aber

muss man sich halt überlegen, ob das Sinn ergibt für einen persönlich. Was auf jeden Fall interessant ist, weil viele Leute, die Zendos betrieben haben, haben das ja gemacht, weil sie eine Testumgebung haben und Kosten sparen wollten, weil sie nicht noch Red Hat Subscriptions für ihre Testumgebung kaufen wollten. Und Ubuntu ist da bedeutend günstiger als Rell und Sles. Also wer schon mal so Rell

oder Sles Subscriptions gekauft hat, der weiß, dass man da doch ein bisschen Geld in die Hand nehmen muss. Da ist auch relevant, wie viele Systeme, mit wieviel CPUs ich da betreibe. Und da sind wirklich die Preise überschaubar mit zum Beispiel 24-7-Support. Da zahle ich irgendwie pro Host 1500 US-Dollar und kann

beliebig viele VMs drauf betreiben. Das wäre bei Red Hat und SUSE um ein Vielfaches teurer. Das ist auf jeden Fall, muss man so sagen, ist auf jeden Fall ein Fakt. Vorteil bei Ubuntu wäre, ist natürlich kostenlos nutzbar. Gegen einen Aufpreis kann ich es auch bis zu zehn Jahre lang benutzen. Nachteil, wenn man von Zendos

kommt, das ist ein anderes Paketsystem und eine andere Distribution. Ich muss mich da definitiv umgewöhnen. Ich habe keine RPMs mehr, sondern Debian-Pakete. Wenn ich einen Dienst installiere, dann wird ja nach der Installation auch automatisch gestartet und aktiviert, was eben bei einem Red Hat-artigen System niemals passieren würde. Da muss ich mich schon ein bisschen umgewöhnen wollen, wenn ich halt eben sonst immer

Zendos benutzt habe. Das heißt, wenn ich dahin migrieren will, dann muss ich auf jeden Fall irgendeine Art der Automatisierung verwenden, wenn ich eine größere Anzahl an Systemen habe, sei es jetzt Puppets, Solstack, Ansible, Chef, was auch immer. Ansonsten wird das, glaube ich, wirklich ein sehr zeitaufwändiges Unterfangen.

Was man so ein bisschen als Nachteil ansehen kann, das ist so ein ganzes Blödsinn, das müsst ihr für euch selbst bewerten. Der Hersteller Canonical treibt neue Ideen natürlich auch immer aggressiv voran. Das heißt zum Beispiel Unity hat Canonical im Alleingang gemacht. Die ganze x mehr, mehr-Sache haben sie auch im Alleingang umgesetzt, haben versucht, Leute da mit rein zu ziehen, die da

nicht interessiert dran waren. Snap ist auch wieder eine Eigenentwicklung, die nur im Ubuntu Ökosystem irgendwie Verwendung findet. Damals gab es eine Amazon Desktop Suche, die von heut auf einfach im Unity Desktop drin war. Das kann Vorteil sein, kann auch Nachteil sein. Das müsst ihr für euch selbst bewerten. Deswegen sei hier das aber auch der

Vollständigkeit halber erwähnt. Die Frage ist jetzt nur, wohin geht die Reise? Was ist der Ausblick? Also was ist so das Lessons Learned? Was sollte man nehmen, was sollte man nicht nehmen? Und da ist es so, im Prinzip habt ihr natürlich mehrere Optionen, die erst mal in Betracht kommen. Also wenn

ihr noch auf CentOS 7 seid, habt ihr erst mal gar keinen Stress, weil der CentOS 7 Support, der endet ja erst 2024. Das heißt, da habt ihr noch drei Jahre Zeit euch damit auseinanderzusetzen. Ob man eine andere Distribution verwendet, ob man einen der CentOS Forks benutzt, da bleibt euch noch genügend Zeit. Wenn man jetzt natürlich relativ schnell war und auch direkt

seine Systeme auf CentOS 8 migriert hat, das mir auch passiert ist, dann ist es natürlich unschön, weil dann müsst ihr jetzt bis Ende diesen Jahres natürlich irgendwie eine Lösung für euch finden. Und da würde ich den Leuten nicht unbedingt zustimmen, dass CentOS Stream keine Alternative sein kann. CentOS Stream kann sehr wohl eine sehr valide Option sein,

weil CentOS Stream ist wirklich stabiler, als die meisten Leute denken. Es ist zwar Rolling Release, aber es ist kein Beating Edge, wie zum Beispiel Arch Linux oder OpenSuse Tumbleweed. Das heißt, ja, es ist nicht so, dass wenn ihr CentOS Stream einsetzt, eure ganzen Applikationen nicht mehr funktionieren und eure Systeme alle drei Tage abstürzen. So

wird das nicht sein, weil es ja doch deutlich abgehangen ist. Wir haben das ja in der Grafik eingehends gesehen. Das heißt, da würde ich so ein bisschen sagen, einfach mal ausprobieren. Also nicht so viel auf CentOS Stream rumparken, einfach mal testen. Die Community war da relativ ablehnend eingestellt. Ich kann das nicht ganz nachvollziehen, muss ich

sagen. Problematisch ist es nur dann, wenn ihr eine Bug-Kompatibilität zurell braucht. Also weil ihr zum Beispiel eine Software entwickelt, die wirklich zum genauen Versionsstand bei den und den Bugs das und das tun soll. Dann ist natürlich CentOS Stream nicht unbedingt die richtige Wahl. Das heißt, wenn das der Fall sein sollte, dann würde ich

tendenziell mir einmal Linux oder Rocky Linux einfach mal angucken und schauen, ob ich das benutzen möchte, ob das Sinn ergibt. Und wenn man jetzt sich in seinen Grundmantifesten erschüttert sieht und jetzt nicht mehr auf Red Hat-artige Systeme vertrauen will, dann kann man natürlich auch eine andere Distribution nehmen. Aber dann muss man schon, muss einem klar

sein, dass es einen bedeutend höheren Aufwand darstellen sollte. Und diese klassische Antwort, was man jetzt machen soll, die gibt es nicht. Das heißt, hier gibt es wieder die klassische Beraterantwort, it depends. Ich persönlich würde gucken, würde mir mal die Forks anschauen, würde überlegen, ob Stream eine Option für mich wäre.

Und ich glaube, da hat man schon gute Optionen, die man einfach benutzen kann und hat da nicht allzu viel Aufwand mit. Wenn man wechseln will, die Optionen sind da, in mannigfaltige Ausprägungen gibt es genügend in der Community. Auch das wäre möglich. Gut, dann habe ich zum Abschluss für euch noch ein paar Links.

Zum Beispiel einmal die Webseite von Alma Linux, von Rocky Linux und auch von Navy Linux. Ganz interessant fand ich auch ein Podcast von changelog.com. Das ist ein Online-Format, wo wöchentlich Podcasts über die Linux Open Source und Entwicklungsecke veröffentlicht werden. Und die haben vor einigen Monaten mal ein sehr langes Interview. Ich glaube, es waren zwei oder

zweieinhalb Stunden mit Gregory Kerzer geführt, wo auch über die Geschichte gesprochen wurde und wie jetzt Rocky eben beginnt. Das fand ich total spannend. Einfach mal ein bisschen mehr über das Projekt zu erfahren von demjenigen, der es ursprünglich auch mal gegründet hat. Das heißt, wenn ihr mal zwei Stunden

Langeweile habt und mit euch nichts anzufangen wisst, ist das auf jeden Fall ein spannendes Thema. Kann man mal reinhören. Und bei meinem Arbeitgeber der SVA haben wir auch einen Podcast über CentOS und denkbare Alternativen veröffentlicht vor ein paar Monaten und haben da auch ein bisschen drüber gesprochen, was ist passiert, wohin geht die Reise, was sind denkbare

Optionen. Das heißt, da könnt ihr, wenn ihr wollt, auch gerne einmal reinhören, wenn es euch interessiert. Und ansonsten wäre ich jetzt auch durch und würde mich für eure Aufmerksamkeit bedanken. Und wenn ihr Fragen habt, dann dürft ihr die sehr gerne jetzt im Chat posten. Dann versuche ich, die zu beantworten. Und

ihr könnt die natürlich auch sehr gerne im Nachgang über Twitter oder Mail dürft ihr auch gerne noch stellen. So, da kommt auch schon das erste Feedback. Vielen Dank.

Die Frage ist, was ich persönlich von Debian halte. Ich persönlich mag Debian sehr. Es war tatsächlich, also Ubuntu war so die erste Lieblingsdistribution, die ich selbst verwendet habe längere Zeit. Und hab dann auch natürlich Debian eingesetzt. Und ich find Debian super. Also, was viele Leute hier immer an Debian kritisieren, ist, dass es

deutlich abgehangen ist. Das ist korrekt. Dafür ist Debian sehr stabil. Also, wenn ich Server einsetze, ist Debian eine total valide Option meiner Meinung nach. Auf dem Desktop würde ich es jetzt vermutlich eher nicht einsetzen, weil dadurch, dass die Software und die Kern-Version insbesondere immer ein bisschen abgehangen sind, sieht es gerade mit

neuer Hardware immer ein bisschen schwierig aus. Aber für Server oder Appliances oder sonst was ist Debian super und setzt sich auch tatsächlich häufig ein, weil es auch ein bisschen einen kleineren Footprint hat. Also, gerade wenn man sich mal so eine Mini-VM oder so einen Raspberry Pi betreibt, da ist halt Debian eine ganze Ecke schlanker als so ein Centos, muss man

ganz ehrlich sagen. Also, großer Freund von, finde ich super. Da gibt's auch Leute, die Debian auf dem Desktop und auf dem Thinkpad verwenden. Gibt's natürlich auch. Also, ich denke auch, das kann man nicht so generell sagen. Klar, wenn ich jetzt das neueste Thinkpad habe,

mit der elften Generation Intel CPU, mit eingebauter GPU, dann muss ich vielleicht ein bisschen basteln, aber wenn man nicht speeding Edge hat, dann ist das bestimmt Debian auch eine gute Wahl. Ich selbst habe hier Ubuntu auf dem Laptop mit einem Custom Curl und fahre damit auch sehr, sehr gut.

Gut, weitere Fragen scheint es nicht zu geben. Bei doch, da kommt noch eine rein. Mit RHEL 8 haben wir Butter FS verloren. Oracle Linux scheint das ja weiterhin unterstützen

zu wollen. Gibt es Aussagen, wie die anderen damit umgehen? Das ist wirklich ein spannendes Thema, weil Butter FS, finde ich persönlich, ist eine sehr spannende Sache und ist auch wichtig, das anzubieten. Also, SUSE waren ja die ersten oder eine der ersten Distros, die das mit reingenommen haben, oder eigentlich die erste Enterprise-Distro, die es mit reingenommen hat.

Und Red Hat hat sich dagegen entschieden. Also, mit RHEL 7 ist das rausgeschmissen worden. Man hat jetzt aber wohl erkannt, also, Red Hat bietet erst mal nur XFS an oder eben X4. Die haben auch mit Stratis eine eigene Erweiterung für das XFS-Filesystem, aber die ist natürlich auch von der Feature-Sicht betrachtet

nicht so gut wie Butter FS. Und Gerüchtung zufolge soll sich das mit RHEL 9 eben ändern. Das heißt, da müsste man mal in CentOS 9 reingucken, das gibt es schon als Alpha, ob das da wieder mit reinkommt. Wie es bei Oracle aussieht, weiß ich offen gesprochen nicht. Bei Ubuntu macht es sich stark für ZFS.

Also, man kann auch, wenn ich es richtig in Erinnerung habe, Ubuntu mit ZFS betreiben und kann da auch Support für bekommen. Also, ZFS ist ja ein Datalysystem, das eher aus der Solaris-Ecke kommt, das man auch im BSD-Umfeld hat. Aber es ist nicht in Linux enthalten, weil es die Lizenz nicht zulässt. Also, Oracle hat da eine Lizenz gewählt, die nicht kompatibel mit der

Lizenz des Linux-Currents ist. Deswegen hat sich zum Beispiel eines Torpels sehr stark dagegen ausgesprochen. Was ich aus einer rechtlichen Sicht nachvollziehen kann, finde ich es schade, weil ZFS eigentlich das Datalysystem schlecht hin ist, meiner Meinung nach. Das heißt, Ubuntu kannst du mit ZFS benutzen. Wie es da mit ButterFS aussieht, weiß ich nicht.

Von daher, ich bin mal gespannt, was sich mit RHEL 9 tut. Weiß ich nicht, ob dir das weiter hilft. Aber da muss man mal gucken.

Ich glaube, dann sind wir mit den Fragen durch. Genau, wenn keiner weitere Fragen hat.

Chat habe ich jetzt auch nichts gesehen, denke ich war es das, oder? Ja, sieht so aus. Da möchte ich noch mal sagen, vielen Dank für die Aufmerksamkeit. Danke für das tolle Feedback und die Fragen. Hat mir sehr viel Spaß gemacht. Und ich wünsche euch natürlich noch viel Spaß mit den anderen Vorträgen der Froscon.

Vielleicht sehen wir uns ja bei einem weiteren Vortrag. Vielen Dank.