Red Hat brengt RHEL 9-bèta uit als eerste CentOS-downstreamrelease

Red Hat heeft RHEL 9 als bèta uitgebracht, de eerste versie van Red Hat Enterprise Linux die gebaseerd is op CentOS Stream. Die draait op Linux-kernel 5.14 en bevat veel nieuwe securityfeatures.

Red Hat Enterprise Linux 9 Beta is nu voor iedereen te downloaden. Gebruikers hoeven zich voor het eerst niet meer specifiek op te geven om een bètabuild te downloaden. RHEL9 is de eerste volledige release van de distro die is gebaseerd op CentOS Stream. De ontwikkelaars van CentOS gaven vorig jaar het OS niet meer als een rebuild van RHEL uit te brengen, maar als als een upstream-branch van Red Hat Enterprise Linux. CentOS 8 was de laatste rebuild van RHEL, specifiek RHEL 8. De nieuwe bètabuild is de eerste release die is voortgekomen uit CentOS Stream.

De bèta van RHEL 9 draait op Linux-kernel 5.14 op x86_64- en aarch64-systemen. Ook zou het mogelijk moeten zijn de distro op Apples M1-processor te draaien. In het OS zitten onder andere nieuwe versies van compilers zoals Go en Rust, Python 3.9 en GNU C-library glibc 2.3.4. De GCC-compiler is bijgewerkt naar versie 11 waardoor programmeurs C++ 17 als standaardtaal kunnen gebruiken.

Er zitten verschillende securityfuncties in, zoals Smart Card-ondersteuning en de integratie van OpenSSL 3. Ook is Link Time Optimization toegevoegd, waarmee packages kleiner worden en sneller compileren.

Veel gebruikers van CentOS waren niet blij met de wijzigingen die Red Hat doorvoerde. Daarop werden verschillende CentOS-alternatieven gebouwd, waaronder AlmaLinux en Rocky Linux.

Reacties (27)

[Yarisken]

Vaarwel centos, welkom rocky

[bonyuri]

Of Alma

[WhiteDog]

Week geleden mijn CentOS 8.4 omgezet naar Rocky Linux, duurde een half uurtje, kan het iedereen aanraden.

[DDX]

En ik maar denken dat de centos stream gewoon een ongoing iets was.
Maar nee centos stream 8 is er nu naast centos stream 9 en er is geen 'dnf update' die een 'upgrade' doet.

Logica om centos 8 dan eol te maken en mensen te 'verplichten' om over te stappen naar centos steam mis ik dus even.

[rbr320]

Logica om centos 8 dan eol te maken en mensen te 'verplichten' om over te stappen naar centos steam mis ik dus even.

Daar zit dezelfde logica achter als dat RHELX EOL wordt en men geacht wordt over te stappen op RHELX+1.

Red Hat wil met de stappen die het afgelopen jaar zijn gezet CentOS meer betrekken bij het RHEL ecosysteem. CentOS was in principe altijd een gratis downstream variant van RHEL, volledig "binary compatible". Dat was mooi voor de mensen die de stabiliteit van RHEL wilden of bijvoorbeeld software van een derde partij wilden gebruiken waar die derde partij RHEL ondersteunt, zonder een betaald contract af te sluiten met Red Hat. Logischerwijs was dit voor Red Hat een minder goede deal, zij deden het werk om RHEL te voorzien van een nieuwe, stabiele (minor) release en de CentOS gebruikers profiteerden daarvan. Daarom heeft Red Hat nu besloten om CentOS de upstream te maken voor RHEL. Dat betekend dat het werk dat Red Hat verricht om de software te updaten nog steeds in CentOS verschijnt, maar wat Red Hat daar nu voor terug krijgt is dat CentOS Stream gebruikers de nieuwe code eerst in de praktijk testen voordat dit in de volgende minor release van RHEL terecht komt. CentOS Stream is dus min of meer een rolling release, je krijg de updates die in de volgende minor release van RHEL komen direct zodra ze door de interne tests van Red Hat heen zijn.

Eens in de zoveel tijd neem Red Hat de nieuwe ontwikkelingen in de open source wereld, specifiek die in Fedora, en bouwt daar een nieuwe major versie van RHEL mee. Dit was altijd al zo, het enige dat er nu wordt gewijzigd is dat ze eerst een nieuwe versie van CentOS Stream uit zullen brengen dat fungeert als testbed voor de komende release van RHEL.

Je snapt dat de mensen die jarenlang feitelijk gratis gebruik hebben gemaakt van RHEL door CentOS te installeren niet zo blij zijn geworden van al deze wijzigingen, maar voor Red Hat is dit gewoon een manier om in business te blijven.

[Reactie gewijzigd door rbr320 op 22 juli 2024 19:02]

[Berlinetta]

Ik denk dat de vork iets anders in de steel dan dat je illustreert.

Maarja, nu moet ik even met een onderbouwing komen... brb

[BartOtten]

4 uur later…

[Berlinetta]

Gelukkig heb ik dit soort dingen ook bij zogenaamde gevorderde ICTers, ging er vanuit dat men het wel door had.

[rbr320]

Nou ja, net als waarschijnlijk @BartOtten ben ik nog steeds benieuwd welke dingen ik volgens jou bij het verkeerde eind heb. Ik heb toevallig recent een online seminar van Red Hat bijgewoond waar de verhouding tussen RHEL en CentOS ongeveer zo uit de doeken werd gedaan als dat ik het beschreven heb, maar misschien dat ik bepaalde dingen niet helemaal goed heb begrepen of verkeerd heb verstaan want ik was tijdens het praatje gewoon aan het werk. Dus ik ben benieuwd naar jouw inzichten.

[AntonNus]

Het model van een OS op een fysieke machien jarenlang te lopen updaten met backports en de bijkomende rot is in de moderne enterprise wereld passe.

Bijna wat recent en in de toekomst gebouwd wordt is gevirtualiseerd met vm's en containers. Allemaal gemanaged met moderne tooling. Dat is waar IBM en Red Hat al jaren mee bezig zijn.

Je deployed een nieuw RHEL virtualisatie host op je server, je spawnt wat VM's en containers. Applicatie deploy, automated testing, wat vrutten en debuggen en je gooit de boel om van de oude naar de nieuwe omgeving.

Daarom die kortere support cycles en wordt er geen extra tijd en moeite gestoken in een upgrade mechanisme.

Gezien CentOS de upstream van RHEL is geworden geld daar hetzelfde. In de oude situatie was dat hetzelfde geweest omdat de downstream van RHEL op het zelfde uit zal komen.

Kan het alleen maar toejuichen, hoe vaak ik wel niet zelf heb moeten frutten om een nieuwere versie van iets aan de praat te krijgen, recente hardware werkend te krijgen.

De tijd gaat steeds sneller en iedereen is met linux vrij om voor een andere distro te kiezen die aan het tradionele model vast wil houden

[eborn]

Hoeveel partijen zullen ook hun update management voor containers op orde hebben? Het is heel erg leuk dat containers code + applicaties + libraries combineren, zodat je een stabiele werkomgeving kunt creëren voor je applicaties. Maar dat betekent wel dat je dit ook up-to-date moet houden door periodiek je container bij te werken. Helemaal als je gebruikmaakt van andere base images kan dat nog wel eens een uitdaging worden.

[Ernie_W]

Inderdaad. Laatste een ernstig lek in Apache proxy mod. Maar die versie werd alleen nog gebruikt in bleeding edge distros en.. een hele berg containers.

[divvid]

Een container is geen toverwoord en kan zo lek als een mandje zijn. Wat voor code haal je in huis met repo x,y,z in je container? Als ik naar een willekeurige pipeline kijk zitten daar zomaar 15-30 containers in met allerlei smaken distros. Gelukkig draaien wij geen mission critical zaken, maar auditing wordt zo wel een dingetje (oh nee, dat willen ze natuurlijk juist, want daar wordt aan verdiend)

[AntonNus]

Een container is geen toverwoord en kan zo lek als een mandje zijn. Wat voor code haal je in huis met repo x,y,z in je container? Als ik naar een willekeurige pipeline kijk zitten daar zomaar 15-30 containers in met allerlei smaken distros. Gelukkig draaien wij geen mission critical zaken, maar auditing wordt zo wel een dingetje (oh nee, dat willen ze natuurlijk juist, want daar wordt aan verdiend)

Zelf ben ik inderdaad niet zo fan van containers maar de wereld waar Red Hat aan levert wel, repo's kan je af vangen met Red Hat Satellite, die doet ook container livecycle.

[Thc_Nbl]

Ik gebruikt gewoon Debian. klaar ben je. je wilt nooit meer anders...

[divvid]

geen idee waarom je een min krijgt, want je hebt een punt. RH is bezig een rookgordijn aan te leggen rondom CentOS. Ook wij zitten er serieus over na te denken naar Alma te gaan...Nieuwe club, moet zich eerst nog 'bewijzen' (niet in kennis, maar wel in stabiliteit van de community over lange tijd) en als je dan toch bezig bent en je halve community op U/D zit, dan kan het wel eens logisch zijn om naar een debian based omgeving te gaan.

[RonaldHeirbaut]

Hier net zo. Was altijd wel redelijk fan van Centos maar ben er vanaf gestapt toen ze met die rolling-release kwamen. Of dat wat te maken heeft met de overname door IBM weet ik niet. Maar ik zag de logica niet. Daarna overgestapt op Debian (had wel eens aan Debian geroken maar vond het niks), even wennen dat het hier en daar net even anders is maar wil nu niet anders meer. Erg stabiel en zelfs upgrades van Debian 10 naar Debian 11 zijn appeltje-eitje.
Maar nu kan je wel naar Redhat9 maar dat is Centos upstream oid? Misschien ben ik te dom maar ik snap het niet.

[FreshMaker]

Vanuit de andere kant ...
Thuisgebruiker met wat kleine projectjes

Ga je zoeken op internet, komt "iedereen" aan met ubuntu (server)
Dus daar ga je dan, vol goede wil de boel optuigen, en gebruiken.
De problemen die ik tegenkwam, waren door wat zoekwerk redelijk vlot opgelost.

Sinds dik anderhalf jaar naar Debian overgestapt, omdat er in ubuntu steeds meer 'handige' dingen worden geïntroduceerd die ik niet wil, en je weer moet verwijderen achteraf.
Debian is 'lekker' slank ( zelfs sudo moet nog worden geïnstalleerd )

[geeMc]

Vasthouden aan een distributie "omdat" is ook niet handig. Ik ben fan van Debian voor bepaalde zaken, maar RHEL werkt voor andere zaken weer beter net als dat Ubuntu Server ook weer use-cases heeft. Alles maar op een enkele distributie willen doen onder het mom van uniformiteit (die je prima kunt bouwen met goede server orchestration met puppet/ansible/chef/whatever met verschillende distributies) is een domme zet naar mijn mening. Uiteindelijk kan een goede beheerder met elke distributie wel uit de voeten, maar het is ook compleet onnodig om tijd te investeren in iets dat een ander al voor je heeft gedaan.

Ik heb zeker wel momenten dat ik anders dan Debian wil. Toegegeven, de laatste twee jaar wel steeds minder, maar vooral de slechte transitie naar systemd in Jessie met al die backwards compatible sysvinit scripts in combinatie met de zwaar outdated packages in een periode waar veel nieuwe dingen uitkomen (apache, php, mysql, libvirt bijvoorbeeld) was dramatisch te noemen. Debian is - net als elke andere distributie - niet heilig.

[Ernie_W]

Wij hebben SELinux op enforcing op onze RHEL productie VMs. Laatste keer dat we naar SELinux op andere distributies keken werden we daar niet echt blij van. En down-ported security patches van RHEL zijn ook prettig met al die projecten die een jaar of 2 moeten draaien zonder dat er resources zijn voor onderhoud.

[geeMc]

Natuurlijk zullen er bij bepaalde bedrijfseisen of inrichtingen geldige redenen kunnen zijn om bij een enkele distributie te blijven en ik had mezelf wellicht wat duidelijker moeten maken. Mijn verhaal gaat ook alleen op voor situaties waarbij je die vrijheid hebt. Ik ben het met je eens dat als je aan bijvoorbeeld SElinux vast zit, het vervelend is om verschillende distributies te ondersteunen. Ik herken me in je verhaal over SElinux op andere distributies.

Maar het neemt niet weg dat het een vervelende beperking kan zijn die je alsnog extra werk kan geven.

[Reactie gewijzigd door geeMc op 22 juli 2024 19:02]

[Frame164]

Een paar product units bij ons hadden ook wat producten op Debian gebaseerd. Totdat er een technisch probleem was en de support te kort schoot. Toen maar herontwikkeld op basis van RHEL met bijbehorende support.

[nvaert1986]

Een typefoutje: Linux-lernel 5.14 <- kernel

[Xm0ur3r]

Geachte Redactie

[FreshMaker]

alles komt goed

plan: Tweakers zoekt een eindredacteur

[TheVivaldi]

Spel- en tikfoutjes - en dus *geen* andere foutjes - deel 45

[beerse]

Nu de RedHat EnterpriseLinux gebruik gaan maken van openbare beta's hoop ik dat Tweakers deze releases ook bij de software-downloads gaat opnemen. En dan mogelijk ook bij de software-prise-watch.