Eerste stabiele bèta van RHEL-alternatief Rocky Linux komt uit

De Rocky Enterprise Software Foundation heeft de eerste versie van Rocky Linux 8.3 uitgebracht. Die distro moet een alternatief worden voor Red Hat Enterprise Linux, nadat Red Hat vorig jaar stopte met de ontwikkeling van CentOS.

De ontwikkelaars laten weten dat de eerste stabiele bèta van Rocky Linux 8.3 uit is. Het gaat om Release Candidate 1 die geschikt is voor x86_64- en voor aarch64-architecturen. De makers waarschuwen dat de bèta nog niet geschikt is voor productie. Eerder al zeiden de makers ergens tussen maart en mei hun eerste release te willen uitbrengen. Het BaseOS van Rocky Linux kan inmiddels worden gedownload.

Rocky Linux is een alternatief voor CentOS. Ontwikkelaar Red Hat stopte in december met rebuilds van RHEL toen het team zich alleen nog op CentOS Stream wilde richten. Inmiddels is RHEL wel beschikbaar voor verschillende klanten, maar dat is voor veel ontwikkelaars niet genoeg. Rocky Linux moet dat gat vullen; de makers noemen het een besturingssysteem dat 'honderd procent bug-voor-bug compatibel is' met CentOS.

De distro gaat daarom releases uitbrengen op dezelfde manier als CentOS dat deed. Dat is als een 'downstream build', waarbij patches en updates pas worden uitgerold nadat een distributeur dat heeft gedaan. Dat is anders dan CentOS Stream, de nieuwe werkwijze waarbij het werkt als upstream ontwikkelplatform van RHEL en dus al experimenteert met updates voordat die in RHEL's stabiele releases komen. Rocky is niet het enige alternatief voor RHEL: eerder kwam al AlmaLinux OS van Cloudlinux uit die datzelfde deed.

Een van de hoofdontwikkelaars van het besturingssysteem is Gregory Kurtzer, de oprichter van CentOS. Het project wordt verder gesteund door onder andere Amazon Web Services en GitLab.

Reacties (77)

[Onno]

Ontwikkelaar Red Hat stopte in december met RHEL toen het team zich alleen nog op CentOS wilde richten.

Eh, Red Hat is niet met RHEL gestopt, alleen willen ze CentOS geen rebuild van RHEL meer laten zijn.

[teek2]

Ik denk dat @TijsZonderH het veranderd heeft van stoppen met Red Hat naar stoppen met Centos ("nadat Red Hat vorig jaar stopte met de ontwikkeling van CentOS"), maar helaas, ook dat klopt niet. Centos is nu een Rolling release die een soort preview is van RHEL. Dit is om de community de tijd te geven feedback te geven op de volgende versie van RHEL. De intentie is wel om Centos van hoge kwaliteit te laten zijn. En ook al gebruiken ze de term "Rolling release", het is minder "Rolling" en minder "Bleeding Edge" dan Arch bijvoorbeeld.

Er is te veel over gezegd om hier allemaal samen te vatten en de situatie is complex met soms gebrekkige communicatie, dus ik snap wel dat er soms fouten in de rapportage sluipen. Hoe dan ook, zelf ben ik van mening dat er best plaats is voor distro's als Rocky en Alma, maar dat voor veel klagende mensen de nieuwe Centos best een goed alternatief is voor de oude Centos, zo is het idee dat je beta tester bent met Centos bijv onterecht, imho.

Edit: Nog een kleine opmerking: 'honderd procent bug-voor-bug compatibel is' met CentOS.": Dan bedoel je het oude Centos, want Centos bestaat nog, alleen is het ontwikkelmodel veranderd.

[Reactie gewijzigd door teek2 op 22 juli 2024 15:28]

[Gitano]

Denk dat de schrijver nog niet helemaal wakker was inderdaad :-) RHEL stopt niet.

[HollowGamer]

Waarom schuift de Linux Enterprise markt niet (helemaal) over naar containers? Met zaken als Docker en flatpak kan je als developer toch zelf bepalen welke versie(s) je (naast elkaar) draait?

CentOS gaat nu zo te lezen meer over naar Debian unstable en Rocky Linux is als het ware Debian. In beide gevallen blijft het in mijn ogen Linux, enkel de inrichting is wat anders.

[DrPoncho]

Docker is niet de heilige graal, met zat nadelen (helaas), om over de overhead nog niet te spreken.

Ontopic: artikelen staat inderdaad vol fouten over RHEL/CentOS

[Reactie gewijzigd door DrPoncho op 22 juli 2024 15:28]

[3raser]

Zo vaak RHEL typen is ook lastig. Dan slipt er wel eens een "REHL" doorheen.

[redfox314]

Die containers draaien ook in een OS. Iemand moet die draaien.

[HollowGamer]

Klopt, maar zelfs een bleeding edge zou nog die containers kunnen draaien. Op Arch Linux (bleeding edge) draai ik ook gewoon Docker en kan je ook zaken als flatpak gebruiken. Zolang de kernel/Hypervisor het ondersteunt, draait het zover ik weet op vrijwel elk OS.

Toegegeven dat je die basis het liefst stabiel wilt hebben op productie, maar daarvoor heb je genoeg alternatieven voor Rocky OS voor.

[Hatsikki]

Klopt voor de teams/bedrijven die enkel containers willen gebruiken kunnen daarvoor RedHat OpenShift (vroeger CoreOS) gebruiken.

[Blokker_1999]

Omdat containers ook niet heilig zijn. Eenvoudig voor deployment maar minder leuk als er gaten in dependencies zitten bijvoorbeeld.

Stel er duikt een nieuw, ernstig lek op in OpenSSL, zonder containers is het voldoende dat je distributie het oplost om heel je systeem weer veilig te krijgen, met containers moet je wachten tot voor elke containerized app er updates zijn voor je weer helemaal veilig bent.

[Hellboy!]

Daarom zorg je er ook voor dat je een registry hebt die kan scannen en andere tooling hebt om draaiende containers te scannen.

Containers die niet veilig zijn mogen niet meer runnen.

[Verwijderd]

Heb je een voorbeeld van zulke tooling?

[bzzzt]

Docker heeft zelf een 'docker scan' commando wat gebruik maakt van de Snyk tooling, maar er zijn aardig wat partijen die hiervoor tools aanbieden volgens Google

[Verwijderd]

Nice, docker scan kende ik nog niet (ik ben docker aan het leren). Wel fantastisch dat ze vulnerability en dependancy scanning ingebouwd hebben.

[Clueless]

Hier zou je een kort lijstje kunnen vinden van tooling: Geekflare - Container Security Scanners

[Verwijderd]

Thanks! Ik had Harbor en Falco al een keer langs zien komen maar de overige kende ik nog niet. Ik ga er mee experimenteren!

[Hellboy!]

Stackrox bijv. Is nu van redhat. Wist registry. Je kan bijv ook afdwingen dat alleen signed container images kan draaien. Ook moet je ervoor zorgen dat niet iedereen zomaar externe registies kan bereiken of zomaar containers kan draaien.

Kortom een Enterprise grade k8s omgeving komt nog wel wat bij kijken.

[Verwijderd]

Kortom een Enterprise grade k8s omgeving komt nog wel wat bij kijken.
Dat is de uitdaging

Het gaat bij mij om een thuisnetwerk maar met alle diensten die ik ondertussen draai wil ik wel meer inzicht in de containers. En het is gewoon leuk om de verschillende oplossingen te proberen!

[supersnathan94]

met containers moet je wachten tot voor elke containerized app er updates zijn voor je weer helemaal veilig bent.

Hoezo wachten? Je kunt in principe binnen het bouwen van je image patches draaien.

[bzzzt]

Niet als je een applicatie als docker image krijgt en alleen gebruikt. Dan ben je dus erg afhankelijk van de developer.

[supersnathan94]

Jawel hoor. Kun je gewoon overheen patchen door die als “FROM” source te gebruiken. Als het echt een groot issue is, heb je die optie altijd nog.

[bzzzt]

Moet je wel voldoende kennis hebben van de distributie die voor dat image gebruikt is. En weten hoe je die secure maakt. En waarschijnlijk gaat je leverancier niet akkoord met support op zelf aangepaste images.

[supersnathan94]

Dat is echt een heel vergezochte use case om eerlijk te zijn. Als je leverancier daar moeilijk over gaat doen, dan heb je ws niet goed genoeg duidelijk weten te krijgen waarom ze nog geen nieuwe versie hebben uitgebracht. Dit is niet iets waar je maanden op gaat zitten wachten. Een patch als dit gebruik je bij een kritieke bug waardoor je snel een tijdelijke oplossing hebt. Als de fabrikant een fix heeft zet je die neer. Tada klaar.

Dergelijke situaties heb je hopelijk hoogstens een sprint op productie staan. Gewoon omdat bijvoorbeed het risico op een datalek hoger is dan het niet hebben van volledige support.

[bzzzt]

Het gaat er niet om dat ik het niet zou doen, maar dat sommige bedrijven niet de juiste mensen, kennis of processen hebben omdat alles uitbesteed is aan een ontwikkelpartij (waarmee soms niet de juiste afspraken gemaakt zijn).
Vooral in de 'enterprise software' wereld komen dat soort brakke situaties vaker voor dan je zou willen.

[supersnathan94]

Het gaat er niet om dat ik het niet zou doen, maar dat sommige bedrijven niet de juiste mensen, kennis of processen hebben

Dat zal best, maar die gaan dan ook niet een patch uitvoeren op een server ergens.

[To_Tall]

Dat is toch niet anders dan met andere applicaties?
Als een stukje software neem bv OpenSSL in een applicatie zit verwerkt. Dan moet je ook wachten tot de ontwikelaar de software heeft aangepast..

Daarnaast kan je natuurlijk containers zelf bouwen en aanpassen.. exec is niet voor niets om aanpassingen in de container te kunnen doen.. Moet alleen OpenSSL aangepast worden kan je ook het Image zelf aanpassen..

Probleem is denk ik meer de kennis die noodzakelijk is. Als je niet weet hoe je zelf docker Images moet maken/aanpassen. Dan wordt het lastig om bv een lek in OpenSSL te dichten.

[Verwijderd]

Het is inderdaad niet veel anders dan met normale applicaites. Daar zitten namelijk ook genoeg zaken in die niet van derde partijen komen (zoals libraries). Ik zie dit vaak met e-mail functionaliteit of LDAP clients. Niet lang geleden zelfs nog een LDAP client moet debuggen uit 1995.

Developers moeten tegenwoordig ook meer security voeren, zij zijn verantwoordelijk voor de veiligheid van hun applicaties. Of dat nu in docker draait of niet...
Ik zou zelfs docker prefereren gezien ze er dan niet omheen kunnen dat ze een update verplichting hebben.

[hackerhater]

Ligt eraan met applicaties.
Hebben ze de library in de applicatie meegebakken dan ja ben je van de ontwikkelaar afhankelijk.
Linken ze naar de systeem-library is het OS updaten genoeg.

[HollowGamer]

Ik vind dat altijd zo'n moeilijke discussie. OpenSSL is opzicht redelijk stabiel en backwards compatible*, die containers kan je toch prima opnieuw builden met de laatste OpenSSL versie en vervolgens deployen?

Als je kijkt naar iets als PHP, dan vind ik dat meer breaking. De ene heeft versie X nodig, de andere versie X (dot releases nog niet meegenomen). Een package manager kan daar moeilijker mee omgaan of gebruikt namen als php7 voor die specifieke versie. Maar je kan nog verder gaan met Python, node, etc. Met een container lost je die dep misverstanden wel eenvoudiger op, zeker als je op een systeem meerdere versies naast elkaar moet/wilt draaien.

Dan heb ik zaken als sandboxing nog weggelaten, dat is ook mogelijk met iets als flatpak.

[Reactie gewijzigd door HollowGamer op 22 juli 2024 15:28]

[NielsFL]

In debian/ubuntu wordt ook de minor versie genummerd in de packagenaam waardoor je prima 7.3 en 7.4 naast elkaar kunt draaien.

Hetzelfde kun je natuurlijk bij elke andere package doen die mogelijk een conflict veroorzaakt.

[batjes]

OpenSSL is niet vrij van exploits of bugs.
nieuws: OpenSSL dicht kwetsbaarheid die denial-of-serviceaanval mogelijk maakte

Je kan op Linux zonder al te veel moeite prima meerdere PHP versies naast elkaar hebben draaien, daar is ook geen docker (oid) noodzaak voor.

[HollowGamer]

Het voordeel is juist dat dit eenvoudiger zou kunnen. Je kunt bijvoorbeeld een Docker image maken met PHP7 en de andere met PHP8. Je hoeft dan op het OS niets te doen, enkel de images onderling te koppelen aan de juist container. Mocht je vervolgens die PHP7 container niet meer nodig hebben, dan gooi je deze eenvoudig weg.

Ik heb heel lang PHP versies naast elkaar gedraaid op één systeem, maar naar verloop van tijd wordt het echt een dep zooi als je bijvoorbeeld ook nog legacy code hebt.

[MrDrako]

Niet elke docker is in beheer van de organisatie die er gebruik van maakt. Stel je bent klant van bedrijf X, en X levert en beheert de docker, ben je dus afhankelijk van de leverancier voordat een potentieel lek gepatched is. Wij hebben bijvoorbeeld +-1000 windows servers, en slechts een klein tiental linux servers.Die linux servers zijn in beheer bij een externe partij, die netjes met tools als puppet de boel inricht/onderhoud. Maar komen er dan 3 of 4 externe partijen met een docker ipv een volledige linux machine, staat onze beheerpartij ineens buitenspel, en zijn we afhankelijk van die externe partijen dat zij tijdig hun dockers patchen. En nee, dat is niet zo vanzelfsprekend. Zeker bij grote partijen in de zorg niet. Je zal je verbazen hoe belaberd hun zijn met het bijhouden van zelfs eenvoudige windows updates.

[HollowGamer]

Maar zou het voor jullie dan niet eenvoudiger worden? Je kunt die Docker images toch offline halen of isoleren van een ander systeem? In het ergste geval bieden jullie zelf Docker images aan en/of doen jullie het beheer ervan.

[Verwijderd]

Vaak steken leveranciers hun handen omhoog als er een security update nodig is. Het probleem zit hem vooral in het feit dat er geen onveilige applicaties aangeschaft mogen worden en dat de leverancier niet gedwongen wordt de applicatie adequaat te updaten. Dit is vaak niet het geval met deze problemen als gevolg.

Systeembeheer moet dan direct de applicatie teruggeven of weigeren te beheren. Dat kunnen ze immers zelf niet.

[Reactie gewijzigd door Verwijderd op 22 juli 2024 15:28]

[BeosBeing]

Ik vind dat altijd zo'n moeilijke discussie. OpenSSL is opzicht redelijk stabiel en backwards compatible*, die containers kan je toch prima opnieuw builden met de laatste OpenSSL versie en vervolgens deployen?

Dat het prima kan, wilt nog niet betekenen dat dit ook automatisch door de makers van die containers gedaan wordt. Lees hieronder de reactie van @MrDrako maar.

Ook met Windows is dat nu juist één van de grootste problemen. De software-maker is gestopt, maar jij bent voor je bedrijfsvoering wel afhankelijk van die software.

[Reactie gewijzigd door BeosBeing op 22 juli 2024 15:28]

[decide1000]

Fedora doet dat al. De kernel is gevirtualiseerd.

Docker is echter niet veilig genoeg. Podman is een veel veiliger en compatibel alternatief.
Nog veiliger (en sneller) is jails (FreeBsd).

[Reactie gewijzigd door decide1000 op 22 juli 2024 15:28]

[coolkil]

Gevirtualiseerde Kernel? Is dat niet gewoon een virtuele machine dan? in de vm kan je uiteraard alsnog weer Docker/podman met eventueel een orchestrator draaien. (zoals dit in veel cloud omgevingen gebeurdt)

[wica]

Fedora doet dat al. De kernel is gevirtualiseerd.

En waar draait deze virtuale kernel?

[FreezeXJ]

There is no cloud, it's just someone elses computer (running Linux... meestal een eigen smaakje van de hoster)...
En nee, virtualisatie is inderdaad niet het antwoord op alles, en zelfs dan wil ik een heel stabiel OS eronder, zoals vroegah CentOS, en hopelijk straks Rocky.

Ondertussen is CentOS 7 gewoon prima, en nog een beste tijd supported, dus de nood is alleen hoog bij snelle overstappers.

[ctrl-tab]

welk base image gebruik je dan voor je containers, en welk os draai je op je docker hosts?

[HollowGamer]

Dan kan iedere distro zijn, Rocky OS is niet de enige (stable) die deze kan draaien, zowel op als de container zelf.

[i-chat]

ik weet niet hoe jij centos met debian wilt vergelijken,

CentOS was vroeger een opensource versie van Red Hat Enterprise Linux (RHEL) ongeveer zoals Android, een opensource versie is van Google Adroid, of Chromium een opensource versie van Google Chrome.
De meeste, zo niet (bijna) alle, onderdelen van RHEL zaten wel in CentOS en (een deel van de) rest was prima te vervangen door Opensource alternatieven. waardoor centOS dus nagenoeg gratis RHEL was.
Het moge duidelijk zijn dat dat voor RedHat niet heel prettig werken was, waardoor ze de uiteindelijk CentOS een beetje wilde killen voor professioneel gebruik. Nu het meer weg heeft van een /unstable/ versie kunnen hobbyisten en kleine bedrijfjes nog prima gebruik blijven maken en bugs blijven raporteren maar zullen bedrijf kritische systemen vaker moeten overstappen naar RHEL-paid version.

Maar dan loop je ineens tegen de limieten van GPL en zijn virale karakter aan; hoeveel je ergens ook in investeert, er zullen altijd meer mensen misbruik maken, dan gebruik...
In dat opzicht is er ook wel één substantieel probleem met licenties als GPL. Je mag als gebruiker namelijk de code pakken, (kleine) wijzigingen aanbrengen en het in gebruik nemen, en je hoeft het met niemand te delen zolang je de software ook niet deelt.

Je mag het eindresultaat zelfs beschikbaar maken (denk aan webhosting services) zolang ze maak op jouw servers draait zonder dat er ooit iemand anders profijt van heeft. Het is een soort van nog een wonder dat je de firmware van apparaten tegenwoordig beschikbaar moet stellen als je gebruik maakt van GPL maar zelfs dan alleen nog de gebruikte onderdelen (en dus niet al je code),

Een groot nadeel is dat GPL geen Share or Pay model kent. iedereen heeft toegang tot de code, en als je daartoe in staat bent kun je dus gratis een versie compileren en gebruiken
Het zou voor iedereen beter zijn als er dus een non-comercial-for-free clausule in alle opensource software zou worden opgenomen zodat je gewoon licentie-gelden betaald om het te mogen gebruiken, van dat licentiegeld kunnen (andere) bedrijven bijvoorbeeld weer verder-ontwikkelen aan de code, of bugs pletten. Je zou dan bijvoorbeeld aan een soort 'belasting' kunnen denken die dan vervolgens als een soort subsidiepot kan worden besteed aan opensource projecten. Bedrijven die code 'doneren' krijgen bij gebruik dus in weze even hard hun belasting weer terug maar bedrijven die dat niet doen gaan niet langer kunnen/mogen freeloaden op het werk van anderen.

Probleem daarbij is dat zoiets in 'real world' waarschijnlijk net zo min gaat werken als hoe GPL nu werkt.

Cheaters gonna cheat,
Fakers gonna Fake
Freebies gonna Freebie.

[Reactie gewijzigd door i-chat op 22 juli 2024 15:28]

[HollowGamer]

Kun je een voorbeeld noemen van iets dat nu niet (meer) beschikbaar is van tools/stuff op CentOS?

Ik snap Red Hat wel, het is een bedrijf dat uiteindelijk geld moet verdienen en met alles 'gratis' weggeven verdien je uiteindelijk niet veel. Ze hebben het ook vooral van support, voor webhosters zou paid support dus ook interessant kunnen zijn. Zoals gezegd bestaan er ook genoeg alternatieven distros die hetzelfde willen doen als CentOS.

Verder vind ik je reactie wel een beetje overdreven, RockyOS gaat gewoon verder op de basis van RHEL en als zij dit verder willen blijven ondersteunen is het toch prima? Gebruikers kunnen daar op overstappen of kiezen voor RHEL.

[Reactie gewijzigd door HollowGamer op 22 juli 2024 15:28]

[moredruid]

Ten eerste: (security) patches lopen bij CentOS achter RH aan. Heb je een internet-facing server dan zou dit al voldoende argument moeten zijn.

Verder zijn er vanuit RHEL een aantal management pakketten beschikbaar, voornamelijk om dingen te stroomlijnen voor beheerders.
Een paar voorbeelden RH <> Centos
- RH Satellite server <> Spacewalk/Katello
- RH Cluster Suite <> Linux-HA
- RH Virtualization manager/KVM <> oVirt/KVM
- RH Openshift <> Docker/Kubernetes

En je krijgt natuurlijk toegang tot hun support site en support staff (allemaal minimaal RHCE level).

[Dorank]

Het zou voor iedereen beter zijn als er dus een non-comercial-for-free clausule in alle opensource software zou worden opgenomen zodat je gewoon licentie-gelden betaald om het te mogen gebruiken, van dat licentiegeld kunnen (andere) bedrijven bijvoorbeeld weer verder-ontwikkelen aan de code, of bugs pletten.

Fijn dat jij dat even gaat beslissen. De GPL bestaat al jaren en heeft al jaren success met waarvoor het ontworpen is: opensource open source houden na aanpassingen. Ben je het er niet mee eens, dan gebruik je het niet. Er zijn voldoende andere licenses op de markt of je verzint er gewoon zelf een.

Je kan bij GPL software alsnog aan de/alle developers vragen om de code onder andere voorwaarden dan de GPL te mogen gebruiken/verspreiden.

[Mars Warrior]

Bedrijven doen dat wel, maar dat kost nogal wat tijd.

De omschakeling van bijv. Linux clusters naar Kubernetes is niet zomaar gedaan in een jaartje.

Maar als dat gebeurt dan heb je RHEL niet meer nodig, immers het OS is niet relevant meer voor docker containers, of beter gezegd containerd.

Vandaar ook de inspanningen van Red Hat in container OSsen en podman.

[coolkil]

Dit gebeurt al. Dat staat alleen los van de Centos en Rhel discussie. Redhat doet hier vrolijk aan mee met CoreOS https://www.openshift.com/learn/coreos/ wat de basis is van hun Kubernetes platform genaamd Openshift.

Echter zijn er ook nog genoeg dingen die bedrijven nog niet in containers willen doen. Daarvoor is een stabiel basis OS toch wel van belang Centos en Rhel zijn toch wel de marktleiders op dit gebied.

[Il Duce]

Wil je SAP of Oracle in een container gaan draaien, zonder vendor support?

[davekok]

Dat gaat ook wel gebeuren maar niet met Docker. Eerder met Podman of iets dergelijks. Direct ondersteunt vanuit systemd om OCI containers aan te maken en te draaien. Het zal alleen duren voor het er allemaal doorheen is.

[The_Big_Easy]

De 3e alinea moet even aangepast worden lijkt me, daar worden CentOS en RHEL door elkaar gehaald. De ontwikkeling van RHEL is zeer zeker niet gestopt maar die van CentOS wel

[King4589]

Niet alleen de 3e, de eerste en tweede ook al

[The_Big_Easy]

Idd . Volgens mij heeft de auteur van het artikel wel de klok horen luiden maar wist hij niet waar de klepel hing. Van de CentOS Wiki page:

CentOS is a Linux distribution that provides a free, community-supported computing platform functionally compatible with its upstream source, Red Hat Enterprise Linux (RHEL).
...
In December 2020, Red Hat unilaterally terminated CentOS development. Red Hat will however continue to support the related rolling release distro, CentOS Stream. As a response, CentOS founder, Gregory Kurtzer, created the Rocky Linux project as a successor to the original mission of CentOS

[Hobbit13]

Denk dat het hele artikel maar even offline moet. Er is nu geen touw aan vast te knopen.

Wat is de relatie tussen RedHat en Rocky Linux? Krijg je hiermee een legale vrij te gebruiken versie van security patches die op de REL zijn uitgebracht door RedHat?

[HollowGamer]

Dit komt vaak voor doordat artikelen worden vertaald en vervolgens de hele context erbij wegvalt of wordt herschreven.

Zo te zien heb je wel gelijk en gebruik Rocky RHEL als hun basis, en vullen ze dus het gat op wat CentOS achterlaat.

[Heidistein]

Ja. Net als CentOS vroeger. Maar toen nam redhat dat project onder haar paraplu, en dat was prima. Toen kocht IBM de rode hoed (mogelijk irrelevant, wel frappant), toen besloot redhat om wat fratsen met CentOS uit te halen.

Ik begrijp het ook nog wel, overigens. Vind het voor sommige servers niet erg, voor anderen zeer onwenselijk...

[Herax10NL]

x86_64- en voor aarch64-architecturen

Ik ben wel benieuwd of men ook nog met een ARM versie komt, daar kan ik nog niets over vinden (of ik zoek met m'n ogen dicht )

[matthijsln]

aarch64 is de 64-bit ARM versie

[snoopdoge90]

Hahah ben je ook aan het typen met je ogen dicht ? Maar even serieus, aarch64 is de build target voor de ARM 64 bit.

[Herax10NL]

Ik had nog geen koffie gehad

[vrieske]

De titel heeft het over een 'stabiele bèta' terwijl er in het artikel staat 'De makers waarschuwen dat de bèta nog niet geschikt is voor productie'.

Titel is dus niet echt handig geformuleerd.

[w1ckedlunat1c]

Een beta kan toch prima stabiel zijn maar nog niet gereed voor productie?

[ocf81]

8.3 om de match met RHEL releases aan te geven?

[lenwar]

Hoe verhoudt, of gaat Rocky Linux zich verhouden tot Alma Linux (dat ook 100% compatibel is met RHEL)?

[bzzzt]

Waarschijnlijk net als vroeger toen je 2 RHEL rebuilds (CentOS en Scientific Linux) had...

[lenwar]

Ik moet nu even graven in m'n geheugen, maar SL was toch niet gegarandeerd binary compatible? Die hadden toch een andere kernel, waar CentOS wel gegarandeerd binary compatible was.

[hackerhater]

Het zou mij persoonlijk niet verwonderen als over een tijdje die 2 gaan mergen.

[rob12424]

Dit was eigenlijk wel een beetje te verwachten. Wat ik mij nu weer afvraag: waarom gaan die 2 alternatieven niet samen?

Overigens het grappige is: vroeger had je ook al chrootjails waar containers eigenlijk van afgeleid zijn. Maar waren ze voor veel mensen moeilijker te maken.

Tegenwoordig heb je containers en dat is bijna de heilige graal en vollop gebruikt. Waren Chrootjails zo onbekend of hoe zit dit?

[Creesch]

Moeten applicatie ontwikkelaars weer ergens mee rekening houden.

Niet op de titel van een bericht reageren maar op de inhoud. Van het artikel zelf namelijk:

de makers noemen het een besturingssysteem dat 'honderd procent bug-voor-bug compatibel is' met CentOS.

En aangezien CentOS weer gelijk is aan RHEL valt dat rekening houden met reuze mee.

[Caviatjuh]

Dit is niet weer een extra distributie en heeft ook nog eens niets te maken met Linux op de desktop. CentOS viel weg, en in dat gat is gewoon een andere gestapt. Het doel van deze (twee) distributies is niet om weer een ander smaakje toe te voegen, maar om volledig compatible te zijn met RHEL. Ik geloof ook dat je om van CentOS naar Rocky te switchen alleen een script gedraaid hoeft te worden om de branding en de repositories te veranderen (maar ik draai geen RH achtigen, dus pin me er niet op vast).

[No_Identity]

Dat is correct. In ieder geval voor AlmaLinux werkt dat prima. Rocky Linux heeft inderdaad hetzelfde idee. Het is inderdaad een kwestie van de repositories aanpassen, de redhat-release package aanpassen en klaar. Werkt prima :-)

[bzzzt]

Hoewel je RHEL prima op een desktop of laptop kan draaien is de primaire markt gewoon die voor servers (vandaar ook de sponsoring van AWS voor Rocky Linux).

De reden dat Linux minder geschikt is voor consumenten heeft niets te maken met een server distributie meer of minder. Overigens is dat ook niet meer helemaal waar: wel eens met een Chromebook gewerkt?

[Arrogant]

Dit is precies waarom Linux nooit voor gewone consumenten zal worden op desktops en laptops.

Gewone consumenten hebben liever dat Microsoft, Apple of Google voor ze bepaalt hoe ze hun systemen mogen gebruiken in plaats van zelf hierin te beslissen.

[leonbong]

Nee 1 af (centos) 2 bij (rocky Linux, almalinux)