Rocky Linux 9 met nieuw build-systeem is verschenen

The Rocky Linux Project heeft versie 9 van de distro uitgebracht. De versie genaamd Blue Onyx is de eerste volledige versie van een stabiele RHEL-distro, die als vervanger geldt van CentOS. De makers raden aan een verse installatie uit te voeren.

De nieuwe distro is gebaseerd op Red Hat Enterprise Linux 9, dat in mei werd aangekondigd. Rocky Linux 9 is een alternatief voor CentOS. Het kostte volgens de makers langer dan verwacht om de distributie uit te brengen omdat er een compleet nieuw build-systeem werd gebruikt. De makers gebruiken daarvoor Peridot. Dat is een build-systeem dat door The Rocky Linux Project is ontwikkeld. Peridot is open source beschikbaar en werkt op x86_64-, aarch64-, s390x- en ppc64le-architecturen. De makers zeggen dat ze van Koji zijn afgestapt dat in Rocky Linux 8.4 nog werd gebruikt. Voor RL 9 zouden de makers liever een architectuur kiezen die meer cloudgericht is.

Het project voor Rocky Linux werd vorig jaar opgezet uit onvrede over de koers van Red Hat. Dat stopte eind 2020 met rebuilds van Red Hat Enterprise Linux en ging zich alleen nog op CentOS Stream richten. Rocky Linux is daar een alternatief voor. Een eerste stabiele bèta kwam vorig jaar in mei uit en een maand later volgde de eerste stabiele definitieve versie, Rocky Linux 8.4. Nu is Rocky Linux 9 de eerste grote nieuwe versie van de distro.

Behalve de switch naar Peridot zijn er ook veel andere dingen aangepast in de distro. Zo is de beveiliging verbeterd door nieuwe versies van OpenSSL en OpenSSH te implementeren en SHA-1 uit te faseren. Op netwerkgebied is iptables vervangen door nftables en zijn er nieuwe virtualisatiemogelijkheden toegevoegd. Zo kunnen bestanden makkelijker uitgewisseld worden tussen de host en de vm via virtiofs en is er ondersteuning voor virtual trusted platform modules. De makers waarschuwen dat upgraden vanaf Rocky Linux 8.6 technisch mogelijk is, maar niet is aan te raden.

Door Tijs Hofmans

Nieuwscoördinator

19-07-2022 • 10:32

47

Reacties (47)

47
47
13
3
0
32
Wijzig sortering
Niet vergeten, je kan nu tot 16 servers draaien met redhat zelf , gratis, met een individuele developers licentie.

https://developers.redhat...-enterprise-linux#general

Support is uiteraard niet inbegrepen ! Kan wel handig zijn voor mensen die thuis een paar vm's hebben draaien.
Je moet wel elk jaar verlengen en dit niet vergeten want dit gaat niet automatisch.
Doorlooptijd voor verlengen is een paar dagen.
Mijn ervaring is dat het verlengen gewoon via de developer site gaat en enkele minuten duurt. Gebruik het ondertussen thuis al een behoorlijke tijd naar volle tevredenheid. Het blijft wat mij betreft toch wel de meest stabiele distro voor het draaien van een server thuis (en betaald op het werk).
Ik gebruik liever een Rhel clone waarbij ik niet vast zit aan die irritante subscription-manager en gewoon repos kan gebruiken zonder subscriptie.
Welke clones zijn de beste ?
Volgens mij zijn op dit moment deze drie de beste opties:
- Rocky Linux
- Alma Linux
- Springdale Linux
De laatste word door een kleiner team bij gehouden dus gaat de updates wel wat trager dus daarom is het logischer om voor Rocky of Alma Linux te kiezen als je een Rhel clone wil gebruiken.
Oracle Linux is één van de beste Linux distro's die RHEL compatibel is momenteel.
Veel mensen kijken hem over het hoofd of kennen hem niet, maar hij is erg goed:
https://www.trustradius.com/products/oracle-linux/reviews
https://computingforgeeks...-vs-rhel-vs-oracle-linux/
The only Linux distribution with zero downtime automated patching for kernel, hypervisor and critical user-space libraries.
Oracle Linux is ook sneller dan gebruikelijk, stabiel en veilig.

Ik weet niet goed waarom hij niet meer populariteit heeft. Een aantal mensen haten Oracle voor hun licensing models en voor hun salespeople. Maar Oracle heeft de laatste 20 jaar erg weinig gedaan als je het vergelijkt met de negatieve zaken die Microsoft/Apple/Google bijna dagelijks doen.

Voor zover ik weet is Oracle ook in andere gebieden ondergewaardeerd: https://www.reddit.com/r/...ier_better_than_what_ive/
Oracle is nog steeds een bedrijf dat niet te vertrouwen is. Je hebt zeker nog nooit met ze te maken gehad.
Bijvoorbeeld het betaald maken van Java, dat was ook eerst gratis en is nog maar een paar jaar geleden gebeurd.
Er zijn bedrijven die hierdoor EUR 100000'en moesten betalen omdat de applicatie leverancier op dat moment nog geen OpenJDK ondersteunde.
En Oracle Database op een virtuele server, bijv. VMware. Het is nog steeds zo dat als je dat doet je licenties moet betalen voor alle CPU's in de gehele farm. Dus niet alleen voor de CPU's van de VM en zelfs ook niet voor de CPU's van de VMware host waarop de Oracle VM draait maar voor alle CPU's van alle VMware hosts in de gehele farm. En als je site recovery manager gebruikt ook nog voor alle CPU's van de VMware hosts in de DR site.
Dat is gewoon oplichterij en denk maar niet dat je er onderuit komt want de Oracle juridische afdeling zit al klaar.
Veel mensen worden liever niet (meer) opgelicht en laten Oracle links liggen. Dat lijkt mij nogal logisch.

[Reactie gewijzigd door zalazar op 22 juli 2024 14:14]

Ik vermoed dat je over de commerciële ondersteuning praat want voor Java te gebruiken heb je toch nooit moeten betalen? Wat is er zo verschillend hieraan als je het vergelijkt met de volgende zaken:

- Adobe vraagt een redelijke maandelijkse som voor Photoshop, die na een paar jaren al meteen erg hoog oploopt als je de som maakt, terwijl je GIMP/Krita gratis kunt gebruiken en deze apps algemeen gezien niet slechter zijn. Krita is zelfs beter voor digitaal schilderen dan Photoshop..

- Microsoft vraagt al altijd geld voor Excel hoewel Gnumeric meer functies biedt, stabieler, sneller en gebruiksvriendelijker is, en ook exactere resultaten oplevert. Weet je hoeveel perfecte alternatieven er voor MS Word bestaan? Je hebt WPS Office, ONLYOFFICE, LibreOffice, AbiWord, Calligra, Emacs Org Mode, etc die allemaal volledig gratis zijn.

- Als je ziet wat Apple met zijn app store doet, hoeveel onnodige kosten hebben mensen hierdoor al gemaakt? Gewoon om een deftige photo viewer (een basis applicatie) te vinden mag je op Apple een uur zoeken vooraleer je iets deftig gevonden hebt dat je niet via de app store dient te installeren. Heel veel gratis open-source apps zoals darktable en RawTherapee zijn niet zo stabiel op macOS zoals ze op Linux/BSD systemen zijn. Waardoor Apple gebruikers denken dat deze apps 'niet goed zijn' en massaal hoge kosten zitten te maken voor zaken waar Linux/BSD gebruikers zo goed als nooit geld aan spenderen. Apple heeft zijn monopolie positie met de app store ook flink misbruikt, en hierdor hebben ze veel meer geld binnengekregen dan wat Oracle via zijn Java subscripties gekregen heeft.

Dus ik praat niet goed wat Oracle hier doet, maar ik zie niet het minste verschil met Microsoft/Google/Apple/Adobe, enzovoort.

Voor zover ik weet is MySQL al altijd gratis geweest, en is dit niet een Oracle product?

Oracle Linux is ook al altijd een gratis product geweest sinds 2006, niet?

Welke gelijkaardige grote projecten doen Microsoft en Apple waar ze geen geld voor vragen?
Het scenario met de Oracle JDK is als volgt:
1) Sun roept dat het altijd gratis is
2) Oracle koopt Sun en roept dat er niets zal veranderen voor de gebruiker
3) Oracle verandert de licentie
4) Oracle doet een audit bij zijn database klanten (want dat mogen ze van de licentie), en sturen een factuurtje voor de Java installaties die ze tegenkomen

Zowel Microsoft als Oracle maken de licentie structuur zo slecht inzichtelijk dat een significant gedeelte van de inkomsten komt uit "enforcement" bij te goeder trouw handelende klanten. En dat vind ik een zeer verontrustende conclusie.
Ik heb dan nog steeds het gevoel dat Oracle de minst erge van de Amerikaanse big tech bedrijven is. Laat me enkele voorbeelden geven die ik erger vind dan wat Oracle hier gedaan heeft:

Apple
Batterygate: A Complete History of Apple Throttling iPhones https://www.ifixit.com/News/11208/batterygate-timeline
Apple fined $12M by Russian regulator over App Store monopoly abuse https://www.theverge.com/...rsky-parental-control-app
Apple Sued Over Apple Pay, Accused of Antitrust Violations https://www.bloomberg.com...rust-violations#xj4y7vzkg
EU Agrees With Spotify: Apple Is Abusing Its App Store Monopoly https://www.fool.com/inve...le-is-abusing-its-app-st/
Apple, Google, Facebook and Amazon abused monopoly power, House report says https://www.cnet.com/tech...-power-house-report-says/
Apple knew a supplier was using child labor but took 3 years to fully cut ties, despite the company's promises to hold itself to the 'highest standards,' report says https://www.businessinsid...ts-2020-12?op=1&r=US&IR=T

Facebook
Facebook to pay $90 million to settle data privacy lawsuit https://www.washingtontim...ttle-data-privacy-lawsui/
Amazon sues 10,000 Facebook Group admins for offering fake reviews https://www.theregister.c.../amazon_facebook_reviews/
Facebook far too consumed by greed to make itself less harmful to society, whistleblower tells https://www.theregister.c...ok_whisteblower_congress/
Facebook harms children and weakens democracy: ex-employee https://www.bbc.com/news/world-us-canada-58805965

Microsoft
Both Microsoft and its Founder Have a Poor History of Sexual Misconduct Allegations https://www.amglaw.com/bl...l-misconduct-allegations/
MICROSOFT IS TIED TO HUNDREDS OF MILLIONS OF DOLLARS IN FOREIGN BRIBES, WHISTLEBLOWER ALLEGES https://www.theverge.com/...whistleblower-contracting
Activision Blizzard Sued by California Over Sexual Harassment, Unequal Pay in ‘Pervasive Frat Boy’ Culture https://variety.com/2021/...t-unequal-pay-1235025376/
Microsoft Cloud Executive Leaves After Allegations of Verbal Abuse https://www.bloomberg.com...legations-of-verbal-abuse
Microsoft Execs Accused Of “Verbal Abuse And Sexual Harassment" In New Report https://www.thegamer.com/...al-harassment-new-report/
Amazon and Microsoft employees caught up in sex trafficking sting https://www.engadget.com/...AEJVTqvJ5ub24WiypvBK58PtP
User locked out of Microsoft account by MFA bug, complains of customer-hostile support https://www.theregister.c..._locked_out_of_microsoft/

Google
Google is de grootste verklaring voor de populairteit van Python. Google heeft bvb een erg lange hand in de educatieve sector en bepaalt dus voor een groot deel wat IT studenten aanleren. Python is één van de allertraagste programmeertalen die er bestaan en die wordt nu gebruikt voor energieverslindende taken als AI, deep learning, data science, web development, system administration, video/audio scripting, etc. Je hebt zoiets als carbon offsets, als Google zijn werkelijke offsets zou mogen betalen voor de extra emissies die veroorzaakt zijn als gevolg van het feit dat ze Python zo populair gemaakt hebben, dan gaat Google meteen failliet.
Google haalt zijn grootste inkomsten uit het gedrag om mensen op alle websites te bestoken met advertenties, en zorgen er ook voor dat je zonder ad blocker geen youtube meer kunt kijken zonder om de haverklap een advertentie te krijgen. Dit vind ik veel ergerlijker dan alles wat Oracle al gedaan heeft.
Google faces $5 billion lawsuit in U.S. for tracking 'private' internet use https://www.nbcnews.com/t...nternet-browsing-n1222676
Google faces a major multi-state antitrust lawsuit over Google Play fees https://techcrunch.com/20...8k-6sJBBih4fg_-TUHJQ6hKFK

Dit is maar een beknopt lijstje van zaken waar deze bedrijven mee bezig zijn, dus ik zou het punt willen maken dat Oracle zich het best gedragen heeft van de grote Amerikaanse tech bedrijven.
Wat betreft Java, nee daar gaat het helaas niet over.
Het staat hier vrij goed uitgelegd: https://upperedge.com/ora...se-licensing-affects-you/
Kijk ook even naar de post van d3burt

Ik ben het met je eens dat nogal wat grote bedrijven hetzelfde doen. Alleen de manier waarop het licentie model van Oracle werkt bij het gebruik van software op virtuele servers gaat veel te ver. Bij IBM heb je bijv. de mogelijkheid om ILMT te implementeren zodat je alleen voor de CPU's van de VM betaald (sub-capacity ipv full capacity). En full capacity is alleen voor de CPU's van de onderliggende host.

Oracle Linux is volgens mij ook altijd gratis geweest. Maar het zou me niet verbazen als hier iets achter zit. Red Hat en Oracle liggen al jaren met elkaar in de clinch.

MySQL Commuity is inderdaad gratis maar de varianten zoals Standard en Enterprise niet. Zelf kies ik altijd voor MariaDB.

[Reactie gewijzigd door zalazar op 22 juli 2024 14:14]

Ze proberen geld te maken op alle manieren dat ze kunnen. En ze zijn dus geen fans van zaken die gratis zijn. Maar dit is bij Microsoft en Apple niet anders.

VirtualBox is ook van Oracle en is één van de beste gratis virtualisatie apps die er bestaan. Dus je kunt zeggen dat ze met VirtualBox, Oracle Linux en MySQL drie grote softwareprojecten ondersteunen die volledig gratis zijn en die ook erg goed zijn.

Het ding dat ik het meest spijtig vind is wat ze met Solaris en OpenSolaris gedaan hebben. Dit waren twee van de beste systemen op dat moment, en ze zouden nog steeds de beste systemen zijn in 2022 als Oracle er niet was geweest.

In jouw geval zou ik voor PostgreSQL + FreeBSD + ZFS kiezen aangezien dit hogere prestaties en betrouwbaarheid geeft. Je gaat twee keer prestaties winnen:
1. PostgreSQL vs MariaDB Performance comparison https://calmitchell.tech/...resql-mariadb-performance
2. PostgreSQL benchmark on FreeBSD, CentOS, Ubuntu Debian and openSUSE https://redbyte.eu/en/blo...s-ubuntu-debian-opensuse/

PostgreSQL heeft verder ook meer features dan MariaDB.
Helemaal mee eens. Ze zijn nu 'chill' omdat ze weinig macht hebben in de linux markt, maar ik zou het niet vertrouwen.

Er is trouwens ook een ander alternatief to RHEL/CentOS: SLES, en de gratis openSUSE LEAP wat erop is gebaseerd. Gebruik het al jaren op mijn server, heerlijk stabiel, en op de desktop heb je tumbleweed, een rolling release dus niet dat gedoe met elke 6 maanden updaten.
Heb ik ook jaren gedaan voordat het developer programma bestond, is ook niets mis mee naar mijn mening. De afgeleiden distros zijn minimaal even stabiel (of stabieler omdat deze de laatste patches een tikkeltje later krijgen).

Wel is het zo dat de major release upgrades (en in mindere mate minors) soms wat tijd op zich laten wachten. Ik gebruikte RHEL9 in mei al. Rocky is nu pas aan de beurt. Alma was al weer een behoorlijk stuk sneller.

Laatste punt om nog voor RHEL te gaan. De security fixes heb je als eerste, die worden nou eenmaal eerst bij de bron uitgegeven (iets dat ik zelf wel fijn vind om bij te hebben).
Ik ben nadat bekend was dat CentOS end of life ging december 2021 mijn systemen over gezet naar Springdale Linux 8 zonder migratie script of zo. Daarna to Rocky Linux 8 beschikbaar was heb ik het migratie script gebruik om al mijn systemen over te zetten naar Rocky Linux 8. Dus als er eentje onder uit gaat is het makkelijk zat om weer over te sappen naar de volgende Rhel clone.

Ik werk dagelijks met Rhel en heb genoeg met subscription-manager te maken en ook Satellite, ik ben echt blij dat ik op mijn eigen systemen mee hoef te werken. De twee enige twee dingen die je wel krijgt met een developer subscription is snellere updates en het mooie rode kleurtje en rode hoed logotjes van redhat geinstalleerd waarbij een Rhel clone dat andere kleuren en logo's zijn. Waarom ben jij eigenlijk voor van een Rhel clone naar een Rhel developers subscription gegaan?

[Reactie gewijzigd door Hydranet op 22 juli 2024 14:14]

Je kan helemaal niet 'verlengen'.
You can't renew your subscription, but you can re-register
https://developers.redhat...per-program-subscription#
Je moet een "Request subscription renewal" doen. Dit valt bij mij onder "verlengen"
Output is: Thank you. Your request has been received. A member of the Red Hat Renewals team will contact your organization shortly to assist you with this and any other subscriptions you would like to renew.
Ik draai mijn hele setup op Debian en Ubuntu dus ik heb geen ervaring met de CentOS-kant van Linux.

Ik vraag me eigenlijk af: wat is precies het voordeel van een betaalde Linuxvariant zonder support? Wat biedt Redhat boven Ubuntu Server of Debian Stable?
Een voordeel kan zijn dat Red Hat een lange en voorspelbare ondersteuningsperiode heeft. Een versie van Red Hat Enterprise Linux krijgt standaard 10 jaar lang ondersteuning, tegenover 5 jaar voor een Ubuntu Server LTS versie. In beide gevallen kan je daarna nog betaald de ondersteuning verlengen. Debian Stable wordt ondersteunend tot de volgende stabiele versie uit komt en die is klaar wanneer het klaar is. Voor veel bedrijven is dat veel te onvoorspelbaar.

Daarnaast wordt RHEL, naast Suse, gezien als een industriestandaard voor Linux. Veel commerciële software die op Linux draait wordt dan ook geleverd met installatie-instructies voor RHEL en de garantie dat het op een bepaalde versie van RHEL goed zal blijven werken omdat hierop getest wordt.

Voor thuisgebruik zou ik eigenlijk geen voordelen kunnen noemen van RHEL ten opzichte van Ubuntu of Debian. Sterker nog, ik denk dat er buiten de enterprise markt voor veel software veel betere bronnen te vinden zijn voor Debian gebaseerde distributies dan voor RHEL. Wel kan het handig zijn om in je homelab te experimenteren met RHEL als je er voor je werk bekend mee wilt raken. Daarvoor is een developer subscription waarmee je 16 RHEL installaties mag doen zonder ondersteuning uitermate geschikt.
Geen ervaring mee, maar ik kan me voorstellen dat bugs die je tegenkomt sneller opgelost worden dan in een gratis variant, omdat anders hun betaalde klanten er ook last van krijgen.
Je betaald bij Red Hat voor de ondersteuning, maar de software is nog steeds open source. Bugs die worden opgelost in open source code zijn dan ook direct beschikbaar voor alle Linux distributies, betaald of niet. Mijn ervaring is dan ook niet dat Red Hat sneller met fixes komt dan andere distributies, wel komen belangrijke fixes voor kritieke problemen zoals bijvoorbeeld Spectre en Meltdown vaak bij ontwikkelaars van Red Hat vandaan.

Dat gezegd hebbende, de betaalde ondersteuning van Red Hat is erg goed in mijn ervaring, ik heb tot nu toe nog nooit meegemaakt dat ze niet een oplossing wisten voor complexe problemen in een omgeving met RHEL systemen.
Je bedoeld Red Hat? Je betaald daar juist voor de support.
Cent-OS was juist de gratis variant zonder support.

[Reactie gewijzigd door hackerhater op 22 juli 2024 14:14]

Ik denk dat @GertMenkel vooral doelt op de RHEL developer subscription waarmee je gratis 16 RHEL installaties mag doen, ook voor productiedoeleinden, maar dan zonder ondersteuning.
Ik zou zeggen dat je feitelijk hetzelfde kan met Debian based, maar RHEL is wel wat meer ready voor grotere enterprise omgeving.

En daar komt dan ook de support om de hoek kijken. Inschrijven, aanmelden, maar dan krijg je ook hulp als je ergens vastloopt. Bij Ubuntu kan je alles anoniem downloaden en installeren.

Dat gezegd doet Ubuntu het best lekker met LTS releases, je kán tot 10 jaar support krijgen. Maar dan is wel weer een 'advantage subsscription" nodig. RHEL kan dit echter nog rekken tot 12 jaar.

sja, verder...heb je andere repositories, package managers, SELinux vs AppArmor security.

Maar als je puur op droge functionaliteit kijkt, kun je exact hetzelfde voorelkaar krijgen op RHEL als Ubuntu
Je mag deze licentie in de meeste gevallen niet op je werk gebruiken indien deze server niet allemaal voor jezelf zijn (en dan nog is het de vraag of je het nog zou mogen).
The Red Hat Developer Subscription for Individuals is still only available to individuals, not organizations or teams, and is designed for personal servers, home labs, and small open source communities.

[Reactie gewijzigd door MetalfanBlackness op 22 juli 2024 14:14]

Nee voor thuis he. Corporate gebruik je dan rocky of alma !
Wat is eigenlijk de reden dat mensen dit uberhaupt willen draaien? Mijn ervaring is dat als ik CentOS kreeg ik dus ook 20 jaar terug in de tijd moest kwa features.
Stabiliteit vooral, als je dingen als je email server of een backup server erop draait wil je dat hij altijd stabiel en bereikbaar is, dus niet een update die de boel platgooit als je even niet oplet.
Je gebruikt dat niet als desktop maar als een stabiele server !
Ze claimen zelf "designed to be 100% bug-for-bug compatible with Red Hat Enterprise Linux", maar als ze nu een ander build systeem gebruiken kan dat toch niet meer waar zijn?

En als je een niet-enterprise red-hat achtige linux wil gebruiken is almalinux dan niet een logischere keuze? Die is binary compatibel, dan lijkt me het verschil vele malen kleiner.
Ik zie niet waarom niet, ze compileren nog altijd de broncode van Red Hat 9, met dezelfde compiler. En zijn dus binair compatibel, ik zie daar geen onderscheid met Almalinux.
In hoeverre is het reproducible?
Ik weet niet wat je met reproduceerbaar bedoeld, maar ik ben momenteel software aan het testen op RH9. Red Hat en CentOS al getest, Alma nog niet en Rocky ook nog niet (want het was nog niet uit). Dus wellicht weer ik binnenkort meer.
O.a. dat de build deterministic is. Zie https://reproducible-builds.org/

Bij ons gebruiken ze Docker containers hiervoor, ben zelf meer voorstander van NixOS of Nixpkgs. Maar als niet iedereen switcht heb je daar geen zak aan...
Waarom maakt het uit?

Er is geen bedrijf met een klein beetje verstand of toekomst visie die een willekeurige distro zal gebruiken zonder eerst eens goed te kijken of er voldoende (betaalde) support voor is en of de nodige software die zij willen gebruiken er ook op kan draaien.

Dit soort distro's zijn leuke niche producten voor een hobby clubje en een paar fanatieke autisten die alles zelf kunnen doen en het allemaal beter weten. Uiteindelijk is het ten doden opgeschreven simpel weg omdat zonder commerciele support een distro nooit groter zal worden dan leuk voor de hobby en het klein en kleine midden bedrijf. Ieder een beetje groter bedrijf gebruikt commercieel ondersteunde distro's omdat ze het bedrijf nu eenmaal niet in de handen van een hobbyisten clubje kunnen leggen.

Een ander build systeem zegt helemaal niets, zo lang de compiler en de compiler settings het zelfde zijn is het enige echte verschil de manier waarop de code en artifacts op de juiste plek worden gezet en hoe de orchestration daarom heen werkt. Denk aan de keuze voor CI/CD tool... Een Jenkins pipeline of een Shipable pipeline maakt echt geen verschil, alles in shell of toch een python script maakt niets uit het eind resultaat is 100% het zelfde.
Natuurlijk zal de een makkelijker zijn om mee te werken dan de ander en kun je een eindeloze discussie voeren welke keuze de juiste is. Ik kan je uit ervaring vertellen dat het echt niets uit maakt en dat het belangrijkste is dat het systeem doet wat jij nodig hebt en flexibel genoeg is om ook in de toekomst (voor zo ver je dat kunt inschatten natuurlijk) je de mogelijkheden te bieden om de builds te maken zo als jij wil.

Ik kan met 10 verschillende build systemen op 10 verschillende manieren 100 identieke builds maken, die 100% binary compatible zijn. Het enige dat van belang is is dat het build systeem bijvoorbeeld de juiste output genereert. Een slack message als een bepaald punt is bereikt in de build, test resultaten die naar een ander systeem worden verstuurd. De mogelijkheid om de build automatisch de artifacts in een andere repo te laten plaatsen als ze aan bepaalde criteria voldoen (succesvolle tests bijvoorbeeld). Misschien wil ik wel de mogelijkheid hebben om als een dependency build faalt de laatst succesvolle build van die dependency te gebruiken (kan handig zijn als je bijvoorbeeld de nieuwe SSH tools wil testen en totaal niets geeft om die mogelijk nieuwe versie van netcat die ook in deze build wordt verwacht)

Er zijn eindeloos veel redenen om van build systeem te wisselen of om build systeem A boven build systeem B te verkiezen. En allemaal zijn het hele goede reden, maar uiteindelijk is het aller belangrijkste het resultaat en in dit specifieke geval dat het resultaat 100% gelijk is aan de RetHat Enterprise Linux build. Alle andere toeters en bellen zijn niet belangrijk als je die 100% compatibility niet kunt beloven en dat is vaak veel makkelijker dan het misschien klinkt als je van build systeem veranderd.
Ik denk dat je onderschat hoeveel CentOS servers er tot voor kort actief waren. Veelal kochten bedrijven een licentie voor hun Productie servers en gebruikten ze dan CentOS voor hun develop en test omgevingen. Ook veel webhosting bedrijven gebruikten vroeger CentOS.

Ik run Rocky Linux 8 op mijn Cloud servertje en dat is rock solid qua stabiliteit.
Denk ook aan grote rekenclusters, paar master en service nodes met RHEL voor support, alle computenodes met CentOS/Scientific Linux/"RHEL respin of choice"
Zo draaien er honderden, zo niet duizenden HPC installaties. En een enkel cluster heeft al gauw honderden nodes. Op ISC2022 weer genoeg gezien en gehoord.
Voor HPC omgevingen, nodes zijn eigenlijk allemaal gelijk op software niveau, en als er variatie is dan is dat een set van een paar honderd van deze nodes een paar honderd van die andere nodes en enkele tientallen van dit soort nodes. Een verandering van OS is een stuk minder lastig omdat als het op een node goed werkt je het makkelijk naar de andere nodes uit kunt rollen. Testen is dan ook relatief simpel omdat zelfs in de grootste clusters je maar een paar verschillende nodes hoeft te testen en vervolgens alle andere gelijke nodes kunt overzetten.

Compatibiliteit is belangrijk maar de keuze voor een specifieke distro een stuk minder omdat er relatief weinig software is die er op moet werken en het meer gaat om hoe veel het OS de software/hardware in de weg zit dan dat het gaat om compatibiliteit met duizenden verschillende software pakketten die over de afgelopen 30 a 40 jaar of zo geschreven zijn.

Natuurlijk wil je ook bij een HPC cluster je downtime zo klein mogelijk houden maar een compute note op een ander OS laten draaien en eens kijken hoe goed die node presteert is vrij eenvoudig. In een enterprise serverfarm waar je veel al misschien net aan een high level idee hebt wat 60% van de hardware doet is dat een heel ander verhaal. (die 60% is een reeel aantal gebaseerd op de grote internationale bedrijven waar ik gewerkt heb gedurende de afgelopen 25 jaar).

Van de kleine hoeveelheid interactie die ik met HPC clusters gehad heb heb ik de indruk dat dit een stuk minder rommelig is dan de gemiddelde enterprise server farm. Iets wat een OS switch heel erg veel makkelijker maakt.
Node performance test je zelden over een enkele node maar vaak juist over een set nodes om zo de interconnects ook mee te nemen in de benchmarking.
Verschillende versies van OFED, MPI implementaties ed kunnen soms voor verrassende verschillen zorgen. En niet iedere OFED versie werkt met ieder OS/kernel...
Bij MPI zijn er dan ook nog, OFED afhankelijk, tig parameters te testen.
Een switch van OS of zelfs OS minor release is dan ook vaak een proces van maanden met een gigantische boom aan tests die je afwerkt voor je zeker weet dat het productie-waardig is.

De switch CentOS 8.2 -> Rocky 8.6 voor een paar midsize HPC clusters heeft so far bijna een half manjaar gekost. De switch van Scientific Linux 7.9 naar CentOS 8.2 in 2020 naar schatting 2-3 manjaar vanwege benodigde code changes.
Dat is een zelfde argument als ik draai een eigen mail server en ik heb nooit een outage of een probleem met het ding. Tot je een half miljoen accounts opzet en tienduizenden mails per seconde ontvangt en verstuurt... dan op eens is het een heel ander verhaal...

Dat een product goed werkt in een hobby omgeving zegt heel erg weinig over een productie omgeving.

Ik weet heel erg goed dat er erg veel CentOS was maar ik weet ook dat er steeds minder CentOS is in productie omgevingen en dat men druk bezig is met plannen voor het vervangen van CentOS in de dev/test omgevingen.

Een grote organisatie heeft zomaar maanden of zelfs jaren nodig om zo'n operatie uit te voeren. Een van mijn vorige werkgevers besloot de dev/test hardware met 10% te reduceren en schakelde ~300.000 servers uit. Als zo'n organisatie besluit dat er een ander OS gebruikt moet worden dan is dat niet een verhaal van een paar weekjes knutselen dat is een project van een paar jaar...
Alleen al de keuze maken voor een andere distro is een project van maanden omdat men er zeker van wil zijn dat alles echt werkt, compatible is en dat het waarschijnlijk is dat de beheerders van de distro niet op eens een andere koers gaan varen waardoor de compatibiliteit verloren gaat. De kosten van het opnieuw bouwen van miljoenen servers, en het installeren van software die niet zelden ouder is dan de meeste engineers die er aan werken en dus niet zo maar opnieuw te compileren laat staan dat er een ansible/chef/puppet/etc script is om het te installeren is zo extreem hoog dat een overstap naar een ander OS vaak niet heel realistisch is tot men er echt zeker van is dat het de juiste keuze is voor de (hele) lange termijn.
Ik denk dan ook dat RedHat een flink aantal extra licenties zal verkopen omdat de grote bedrijven tot de conclusie komen dat ze weinig anders kunnen doen. Zo veel geld investeren en gokken dat het hobby clubje dat de nieuwe distro bouwt er nog vele jaren mee door zal gaan de compatibiliteit zal behouden en niet besluit dat A of B een goede reden is om dingen "beter" te doen dan RedHat zal heel erg moeilijk zijn om te verkopen binnen de grote organisaties.

Voor kleine bedrijven is dat een heel ander verhaal ze hebben veel minder servers, nog veel minder legacy systemen waar eigenlijk niemand meer precies van weet hoe ze werken zij kunnen dus veel makkelijker zulke risico's nemen omdat de kosten relatief klein zijn in zulke gevallen.
Ik denk niet dat het build systeem andere binaries maakt, alleen de manier waarop de developers er mee omgaan. Ze kunnen eenvoudigweg niet 100% compatibility claimen als dat niet het geval zou zijn.

De discussie of Alma of Rocky een betere of logischere keuze zou zijn is echt een kan wormen opentrekken. Daar zit zoveel achter, inclusief oud zeer van mensen die zich verraden voelen door de oud centos-oprichter, en aan de andere kant staan veel mensen die vinden dat Alma te commercieel is. En dan is er nog de groep die vindt dat CentOS goed genoeg is. Ik denk niet dat er een goeie of slechte keuze is, doe iene-miene-mutte en kies er een uit. Het is wat mij betreft allemaal lood om oud ijzer.
Niet 100% meer nee, maar het build systeem is natuurlijk maar 1 component van een linux distributie.
Ik kom nog wel eens software tegen, die vooral voor RHEL systemen gemaakt zijn of voornamelijk documentatie aanwezig is voor RHEL achtige systemen.

Niet elke ontwikkelaar heeft zin om voor verschillende distro's packages uit te brengen.

Ja, deze software draaid meestal goed op een debian of ubuntu. Maar is meestal iets meer werk.
Ik vraag me even af, die laatste alinea zijn dat wijzigingen bovenop de RHEL 9 release, of is dat neergedruppeld uit RHEL 9 en staat dat hier alleen volledigheidshalve gemeld als generieke verbeteringen in het OS, onafhankelijk van RL of AL?
Dat laatste. Het betreft de verbeteringen aan Red Hat Enterprise Linux 9 ten opzichte van versie 8.
Wel jammer dat een upgrade afgeraden wordt. Ik snap het wel, met al deze wijzigingen, maar 1 van de redenen dat ik Rocky ben gaan gebruiken is om voor lange tijd een stabiele omgeving te hebben.
Mijn VM's opnieuw installeren is niet zo'n probleem, maar om van de nieuwe mogelijkheden gebruik te kunnen maken zal ik mijn HyperVisor, welke ook Rocky draait, ook opnieuw moeten installeren.

Op dit item kan niet meer gereageerd worden.