Le alternative a CentOS procedono: Rocky Linux lancia la prima release candidate, AlmaLinux dispone del supporto a pagamento
di Riccardo Robecchi pubblicata il 17 Maggio 2021, alle 18:51 nel canale Device
Dopo l'annuncio della dismissione di CentOS da parte di Red Hat, due principali eredi sono comparsi: Rocky Linux, che è ora alla prima release candidate, e AlmaLinux, che ha recentemente lanciato il supporto a pagamento
Il panorama delle distribuzioni Linux è cambiato all'improvviso lo scorso dicembre, quando Red Hat ha annunciato la dismissione di CentOS per lasciare spazio a CentOS Stream. Questa decisione ha creato un vuoto che viene ora colmato da due distribuzioni: Rocky Linux, guidata dalla comunità, e AlmaLinux, nata invece da CloudLinux. Entrambe le distribuzioni sono arrivate ora a importanti passaggi nel proprio sviluppo: Rocky Linux è giunta alla prima release candidate, mentre AlmaLinux ha visto l'arrivo del supporto a pagamento.
Gli eredi di CentOS, Rocky Linux e AlmaLinux, evolvono
Rocky Linux è stata fondata da uno dei contributori originali di CentOS e sta proseguendo nel suo percorso verso il primo rilascio stabile. La distribuzione ha annunciato il rilascio della prima release candidate, ovvero uno stadio successivo alla beta in cui dovrebbero essere presenti solo bug la cui correzione è triviale. Se non vengono rilevati bug importanti in questa fase si procede al rilascio della versione definitiva, che verrà considerata stabile e pronta all'uso in ambienti di produzione.
Come CentOS, Rocky Linux punta a essere una versione compatibile al 100% con Red Hat Enterprise Linux (RHEL), con gli stessi bug e le stesse patch. L'obiettivo è quello di fornire un'alternativa gratuita a RHEL che sia sfruttabile da appassionati, tecnici e piccole imprese che non hanno le possibilità economiche per ottenere una licenza di RHEL. Ciò è reso possibile dal fatto che RHEL è rilasciato sotto licenza GPL e, pertanto, ne sono rilasciati anche i sorgenti: a patto di sostituire i marchi di Red Hat, è possibile ricompilare tali sorgenti per ottenere un sistema operativo identico a RHEL.
AlmaLinux, di contro, è già arrivata alla prima versione considerata stabile (basata su RHEL 8.3) e ha di recente visto l'introduzione del supporto commerciale: in questo modo non solo le aziende possono sostenere lo sviluppo della distribuzione, ma anche ottenere supporto diretto da esperti e accordi sulle tempistiche per fornire le patch. AlmaLinux diventa quindi per molti versi un concorrente diretto di RHEL, che si sostiene proprio grazie al fatto che Red Hat richiede il pagamento del supporto. AlmaLinux non divulga dettagli sui costi nella pagina dedicata e rimanda a discussioni private questo tema.
Il mondo delle alternative a RHEL è più vivo rispetto a prima, ma rimane da vedere se una distribuzione prenderà il sopravvento e, in caso positivo, quale: sia Rocky Linux che AlmaLinux sono supportate da nomi di grosso calibro, dunque c'è la speranza nella comunità che entrambi i progetti si rivelino longevi.
LG TONE Free T90S: gli auricolari con la disinfezione UV cambiano forma
Kindle Paperwhite 2024: l'ereader di riferimento si rinnova ancora
Recensione LEGO Horizon Adventures: un'avventura costruita per emozionare 
La navicella cargo Tianzhou-8 ha effettuato il docking con la stazione spaziale cinese Tiangong
Impulse Space svilupperà il motore Deneb e ha comprato tre lanci su SpaceX Falcon 9
Studio ESA: un razzo spaziale di grandi dimensioni è ''possibile in linea di principio''
11 Commenti
Gli autori dei commenti, e non la redazione, sono responsabili dei contenuti da loro inseriti - infoChe senso ha passare a ubuntu, a sto punto usa Debian. Io, oltre BSD, monto solo Debian ormai sui server e non ho mai avuto problemi. Gli RPM meno li vedo meglio sto.
Tornando a CentOS io francamente ho passato a CentOS 8 Stream alcune delle macchine su cui avevo già installato la 8.
Capisco l'indignazione per come RedHat ha gestito la cosa, e la provo io stesso, però trovo che dal punto di vista tecnico su questa faccenda si siano fatte considerazioni troppo precipitose e senza una reale valutazione costi/benefici.
Da molte parti si è fatta passare l'idea che CentOS Stream sia una distribuzione instabile o rischiosa dal punto di vista dell'affidabilità, il che è oggettivamente falso.
Parliamoci chiaro ragazzi, da sempre c'è gente che installa Fedora o Debian Sid, e onestamente non ho mai visto gente strapparsi i capelli per questo o servizi cascare come pere per l'instabilità dell'OS...
Se colossi come Facebook o Twitter hanno deciso di sostenere pesantemente CentOS Stream per i propri datacenter significa che poi così instabile non dovrebbe essere...
Diamo il giusto peso alle cose, condivido l'indignazione per le scelte di RedHat e trovo che dal punto di vista etico sia stata una mossa molto molto discutibile, però da qui a un fuggi fuggi generale ce ne passa, specialmente per chi ha pesantemente investito in conoscenze su distribuzioni derivate da RedHat.
Mi son fermato dopo questa frase.
Chi installa fedora o Debian Sid in produzione merita solo di essere licenziato senza possibilità di appello
E' innegabile che RH si sia sparata da sola nei @@ col cambio. C'è poco altro da dire.
Chi installa fedora o Debian Sid in produzione merita solo di essere licenziato senza possibilità di appello
E credimi, ne ho avute (e ne ho ancora ahimè
Poi chiaro, parlo di sistemi su cui devono girare dei servizi, per cui che Gnome o il tal servizio per l'audio posizionale siano instabili non mi interessa, perchè comunque sulla macchina a cui mi riferisco non installerò nemmeno quella roba.
Chiaramente prima di installare Fedora o Debian Sid ci sono millemila alternative considerate più adatte, però il mio post era solo per dire che se si devono far girare dei servizi anche quelle distribuzioni "bleeding edge" non crashano ogni due per tre, tutt'altro, idem CentOS Stream (che sappiamo bene non essere "bleeding edge"
Tra l'altro a me spesso capita di trovare server su cui è stata installato CentOS o Rhel, o Ubuntu LTS, e va benissimo... poi però per far partire il tal servizio o per soddisfarne le dipendenze puntualmente ci sono package presi dai repository yum o apt più sconosciuti o controversi, o che cmq sono tutt'altro che "conservativi".
E spesso questo è inevitabile perchè cmq i package di quelle distro sono estremamente obsoleti e oggettivamente insicuri, ok ci sono anche repo alternativi ufficiali (o pseudo-ufficiali) con release più recenti dei package, e credo siamo tutti d'accordo nel considerarle alternative valide... però vedi che già ci siamo allontanati parecchio da quell'alone mistico di "stabilità" per cui si è scelto la tal distribuzione?
Lasciami aggiungere un'ultima cosa, ricordiamoci che 99 volte su 100 i problemi nascono sempre da criticità applicative, eccezioni non gestite, codice scritto a "membro di segugio", logica applicativa grossolana o architettura pensata male (tutte cose che spesso non nascono da incapacità di chi le ha realizzate, ma dalle pessime condizioni in cui costui è stato messo a lavorare, scarsità di risorse, tempo insufficiente, specifiche e obbiettivi che cambiano in corso d'opera etc etc...
Non ho scritto il contrario. Nel momento in cui il supporto scade e non ci sono aggiornamenti di sicurezza, la macchina va rifatta. Spesso non viene fatto perché i sistemisti sono pagati a cottimo ed il cummenda di turno non vuole sganciare soldi "perché tanto funziona, perché toccarlo?"
Chiaramente prima di installare Fedora o Debian Sid ci sono millemila alternative considerate più adatte, però il mio post era solo per dire che se si devono far girare dei servizi anche quelle distribuzioni "bleeding edge" non crashano ogni due per tre, tutt'altro, idem CentOS Stream (che sappiamo bene non essere "bleeding edge"
Non aggiorni l'OS di un server ogni 6 mesi rifacendo la macchina proprio perché non vuoi dover ritestare gli applicativi su uno stack software (OS+libs) differente. Usando Centos stream, uno yum update in pratica ti installa le nightly builds di RH, sei veramente così entusiasta di fare la cavia in ambienti di produzione?
Poi quando tutto sarà containerizzato e l'host sarà solo un "lancia container", allora questo discorso sarà superato. Purtroppo non è ancora così.
E spesso questo è inevitabile perchè cmq i package di quelle distro sono estremamente obsoleti e oggettivamente insicuri, ok ci sono anche repo alternativi ufficiali (o pseudo-ufficiali) con release più recenti dei package, e credo siamo tutti d'accordo nel considerarle alternative valide... però vedi che già ci siamo allontanati parecchio da quell'alone mistico di "stabilità" per cui si è scelto la tal distribuzione?
Repo sconosciuti e controversi === peracottaro. Se hai bisogno di lib molto diverse per i tuoi servizi o ospiti servizi eterogenei sullo stesso server, vai di virtualizzazione/containerizzazione oppure di compilazione statica delle lib.
Come dici, non è solo il sistema operativo, ma è anche il set di dipendenze a corredo.
Ti dico cosa ho visto spesso in giro: server con versione di ubuntu non LTS, server con fedora non aggiornati e non aggiornabili pena applicativi che si spaccano. In quel caso, non avendo OS stabile e supporto per anni, sei fottuto e ti tocca rifare la macchina e metter mano agli applicativi.
Centos Streams va avanti con rolling release e gli aggiornamenti sono le nightly builds di RH.
1. Puoi trovarti in situazioni dove gli aggiornamenti ti spaccano gli applicativi installati e ti tocca capire cosa ha spaccato cosa e perché e fare rollback degli update.
2. Tu sei veramente tranquillo sapendo che sul server ci finiscono delle nightly builds? Ok che sono NB di RH, ma cavolo, son sempre NB.
Insomma, come non userei mai una Ubuntu non LTS o una Fedora, non installerei mai CentOS Stream su un server. Discorso diverso sul desktop personale dove, anche se si spaccasse qualcosa dopo un aggiornamento, potrei velocemente fare rollback senza far andare down servizi esposti.
Devi effettuare il login per poter commentare
Se non sei ancora registrato, puoi farlo attraverso questo form.
Se sei già registrato e loggato nel sito, puoi inserire il tuo commento.
Si tenga presente quanto letto nel regolamento, nel rispetto del "quieto vivere".