Nel mondo Linux enterprise, pochi nomi hanno plasmato l’ecosistema tanto quanto Red Hat Enterprise Linux (RHEL) e derivate. Per oltre vent’anni, RHEL ha stabilito gli standard di stabilità, sicurezza e compatibilità binaria per server e cloud, diventando sinonimo di Linux “enterprise-grade”. Tuttavia, non tutti possono o vogliono pagare un abbonamento RHEL. Qui entrano in gioco distro come CentOS, CentOS Stream, AlmaLinux e Rocky Linux, ciascuna con un approccio diverso: alcune puntano a replicare fedelmente RHEL, altre offrono patch aggiuntive e supporto a hardware più ampio, altre ancora sono orientate agli sviluppatori che vogliono sperimentare le novità prima della release ufficiale.
In questo nostro articolo esploriamo la storia, l’architettura tecnica, le differenze di governance e le controversie tra queste distribuzioni, chiarendo quando e perché usarle, sia in ambienti enterprise sia in contesti di sviluppo e test.
Le origini: Red Hat e la nascita di RHEL
Red Hat, fondata nel 1993, fu una delle prime aziende a trasformare Linux in una piattaforma commerciale. La distribuzione Red Hat Linux, rilasciata negli anni ’90, si rivolse sia agli utenti domestici che alle imprese. Tuttavia, con la crescita del mercato enterprise, nel 2002 l’azienda decise di segmentare la propria offerta:
- Fedora come progetto comunitario e innovativo (upstream: sviluppo rapido e sperimentale).
- RHEL (Red Hat Enterprise Linux) come sistema stabile, certificato e con supporto a pagamento (ciclo di vita di circa 10 anni).
Il cuore di RHEL si basa su un principio fondamentale: stabilità, prevedibilità e certificazioni hardware/software, elementi essenziali per data center e infrastrutture mission-critical.
CentOS: il clone gratuito di RHEL
Nel 2004 nacque CentOS (Community ENTerprise Operating System), un progetto che ricompilava i pacchetti SRPM (Source RPM) di RHEL, rimuovendo i marchi Red Hat ma mantenendo una compatibilità binaria quasi perfetta.
Il progetto si distingueva per la sua compatibilità bug-for-bug con RHEL, ovvero non introduceva patch indipendenti, ma replicava esattamente i pacchetti di RHEL.
Il ciclo di vita di CentOS era allineato a quello di RHEL, ma senza supporto ufficiale. A colmare il “gap” c’era una comunità di utenti che crebbe in modo esponenziale, tanto che CentOS divenne per oltre un decennio la scelta privilegiata per chi desiderava la solidità di RHEL senza i costi di licenza, trovando impiego massiccio in Web hosting, HPC e ambienti di test.
Il “cataclisma” CentOS Stream
A dicembre 2020, Red Hat annunciò la fine di CentOS Linux “classico” e l’introduzione di CentOS Stream come sostituto.
Diversamente rispetto a CentOS, CentOS Stream (come suggerisce il nome) si basa su una rolling-release upstream di RHEL “minor”, che riceve aggiornamenti prima della release ufficiale di RHEL, fungendo da “preview” continua.
I pacchetti software sono quindi aggiornati continuamente: nuove versioni dei pacchetti, patch di sicurezza e bugfix arrivano man mano che sono testati e approvati. CentOS Stream è upstream rispetto alle minor release di RHEL perché i pacchetti e le correzioni arrivano nella distribuzione prima che le “sottoversioni” di RHEL siano ufficialmente rilasciate. In pratica, come accennato in precedenza, CentOS Stream è costantemente un “anteprima stabile” delle future minor release di RHEL.
Questo approccio ha evidentemente creato frustrazione in molti utenti, perché con la fine di CentOS Linux, Red Hat ha eliminato la possibilità di utilizzare una distribuzione stabile, con aggiornamenti congelati fino alla release successiva, senza affrontare i costi di licenza. Fedora esiste come progetto upstream e sperimentale, ma non è progettata per l’uso enterprise mission-critical, quindi non può sostituire direttamente CentOS come clone gratuito di RHEL.
In generale, molti utenti enterprise percepirono CentOS Stream come meno stabile e inadatto a server produttivi.
La diaspora: AlmaLinux e Rocky Linux
La decisione di Red Hat di interrompere il progetto CentOS Linux spinse la comunità a cercare alternative pienamente compatibili con RHEL. Da qui nacquero due progetti principali: AlmaLinux e Rocky Linux.
Avviato nel 2021 da CloudLinux Inc., azienda con esperienza decennale in ambienti enterprise, la distro AlmaLinux (download) è governata da una fondazione no-profit (AlmaLinux OS Foundation).
Il progetto poggia in questo caso sulla ricompilazione dai sorgenti CentOS Stream, con l’obiettivo di mantenere compatibilità binaria con RHEL. AlmaLinux introduce miglioramenti opzionali: patch di sicurezza indipendenti, supporto per hardware non coperto da RHEL, funzionalità aggiuntive (ad esempio kernel alternativi).
Anche Rocky Linux nasce nel 2021 per volontà di Gregory Kurtzer, co-fondatore di CentOS. La distribuzione (download) è gestita dalla RESF (Rocky Enterprise Software Foundation), con governance ibrida (community e sponsor).
In questo caso l’approccio è diverso: Rocky Linux opta per una ricostruzione downstream bug-for-bug di RHEL, senza aggiungere patch o funzionalità indipendenti. La filosofia è quella di essere una copia il più fedele possibile a RHEL, senza deviazioni.
Per quanto riguarda il ciclo di vita, sia AlmaLinux che Rocky Linux seguono pedissequamente quello di RHEL.
AlmaLinux vs Rocky Linux: differenze tecniche e filosofiche
Caratteristica | AlmaLinux | Rocky Linux |
---|---|---|
Modello di sviluppo | Fork di RHEL basato su CentOS Stream; aggiunge patch extra e supporto hardware non coperto da RHEL | Ricostruzione downstream RHEL pura; massimo allineamento “bug-for-bug” con RHEL, senza patch indipendenti |
Target utenti | Server enterprise self-supported, cloud, container, workstation enterprise | Server enterprise, ambienti legacy, container; utenti che vogliono compatibilità totale con RHEL |
Governance | AlmaLinux OS Foundation: organizzazione no-profit 501(c)(6), decisioni della comunità | Rocky Enterprise Software Foundation (RESF): Public Benefit Corporation, governance comunitaria guidata dal fondatore |
Valore aggiunto | Patching aggiuntivo, correzioni bug/patch di sicurezza non presenti in RHEL, supporto hardware esteso | Compatibilità bug-for-bug con RHEL; nessuna modifica o patch aggiuntiva |
Stabilità | Alta, leggermente più flessibile grazie a patch e supporto hardware extra | Massima stabilità rispetto a RHEL, anche se più conservativa |
Ruolo filosofico | Community-driven con valore aggiunto; flessibilità e correzioni proattive | Community-driven puro; fedeltà totale a RHEL, filosofia minimalista senza modifiche proprie |
Governance, autonomia e scelte della comunità
AlmaLinux è stato percepito come più “aperto” e innovativo, ma con legami commerciali con CloudLinux Inc. Tuttavia, AlmaLinux OS Foundation è formalmente costituita come organizzazione senza scopo di lucro negli USA, sotto la classificazione 501(c)(6), come indicato in tabella. Questa scelta è comune per le associazioni commerciali e di interesse professionale.
Rocky Linux, pur essendo dichiaratamente community-driven, è stata oggetto di dibattiti sulla reale autonomia rispetto al fondatore e agli sponsor.
Purtuttavia, la distribuzione è gestita da RESF, che è un’organizzazione senza scopo di lucro (Public Benefit Corporation). Gregory Kurtzer è stato il co-fondatore di CentOS e ha un ruolo di leadership, ma all’atto pratico la governance è formalmente strutturata come fondazione, con board e membri della comunità, non come azienda privata classica. CIQ è un’azienda commerciale fondata da Kurtzer che fornisce supporto e servizi per Rocky Linux, ma non “possiede” legalmente la distribuzione.
Alla fine, oltre alle preferenze filosofiche e alla fiducia nella governance, chi cercava valore aggiunto e patch rapide ha preferito AlmaLinux; chi voleva fedeltà totale a RHEL ha scelto Rocky Linux.
Target reale di distribuzioni come RHEL, CentOS Stream, AlmaLinux e Rocky Linux
RHEL ha il nome “enterprise” nel suo acronimo. Ma AlmaLinux e Rocky Linux non sono “enterprise” nel senso stretto.
Molte aziende medio-piccole, provider cloud, sviluppatori e sistemisti le usano anche su server domestici, VPS e ambienti di test. La scelta dipende più da stabilità, compatibilità e gestione del ciclo di vita che dal solo “target enterprise”.
RHEL rimane la scelta privilegiata per le aziende, i data center e i cloud provider che gestiscono sistemi mission-critical, server certificati e applicazioni enterprise, grazie al supporto ufficiale, agli SLA (Service Level Agreement) e alle certificazioni hardware/software.
Esiste anche una versione gratuita di RHEL per sviluppatori che consente di gestire fino a 16 macchine senza costi di licenza, ma nelle implementazioni di produzione critica il supporto a pagamento diventa fondamentale, specialmente in settori regolamentati come finanza, sanità e Pubblica Amministrazione.
Le alternative a RHEL
CentOS Linux, fino alla sua interruzione nel 2020, era la soluzione ideale per utenti e aziende che volevano una clone gratuita e stabile di RHEL, perfetta per server di produzione, hosting o ambienti di test, mantenendo la piena compatibilità con RHEL senza costi aggiuntivi. Con l’avvento di CentOS Stream, il modello è cambiato: questa distribuzione si colloca “upstream” rispetto alle minor release di RHEL e adotta, come abbiamo visto, un ciclo rolling-release, aggiornando pacchetti e patch man mano che vengono testati.
Così CentOS Stream è adatta per team DevOps, sviluppatori e chi deve testare applicazioni o container prima della release ufficiale, ma meno indicata per ambienti enterprise critici dove la stabilità assoluta è un requisito.
Distribuzioni come AlmaLinux e Rocky Linux sono nate per colmare il vuoto lasciato dalla fine di CentOS Linux tradizionale, offrendo alternative gratuite con piena compatibilità RHEL.
AlmaLinux aggiunge valore attraverso patch supplementari, supporto a hardware non coperto da RHEL e correzioni di bug, rendendola flessibile e adatta a server enterprise, cloud, container e workstation aziendali. Rocky Linux, invece, si concentra sulla fedeltà assoluta a RHEL, garantendo una ricostruzione downstream “bug-for-bug” senza alcuna modifica aggiuntiva, ideale per chi desidera un clone gratuito e stabile di RHEL, in particolare per ambienti legacy o container enterprise certificati.