Perché Red Hat ha ucciso CentOS rimpiazzandola con CentOS Stream
di Riccardo Robecchi pubblicata il 30 Gennaio 2021, alle 10:31 nel canale DeviceCentOS è morta e molti hanno attribuito la colpa a IBM o alla volontà di Red Hat di ottenere maggiori contratti. Ma Brian Exelbierd, membro del direttivo di CentOS, spiega che le cose non stanno così
A inizio dicembre Red Hat ha fatto un annuncio che ha scombussolato molti equilibri nel mondo Linux, dismettendo completamente CentOS nella sua versione "storica" e trasformando la distribuzione nel luogo dove sperimentare i cambiamenti che finiscono in Red Hat Enterprise Linux (RHEL). Questo cambiamento è stato visto con estremo sospetto dalla comunità, che ha ipotizzato l'intervento di IBM (proprietaria di Red Hat) o la volontà dell'azienda di vendere più contratti. In un'intervista con The Register, Brian Exelbierd, membro del direttivo di CentOS, fa chiarezza sulla vicenda e spiega che si tratta di una questione di investimenti e di rapporto con la comunità.
La fine di CentOS è una questione di investimenti e rapporto con la comunità
"Red Hat partecipa in molti progetti e comunità open source. Red hat sponsorizza alcuni progetti e comunità open source. CentOS è un progetto sponsorizzato, noi siamo l'agente di finanziamento e siamo anche un contributore importante. Abbiamo imparato che le comunità open source vanno bene se sono indipendenti, quindi lasciamo che i direttivi dirigano. [Ma] il direttivo di CentOS non può decidere cosa fanno le squadre di ingegneri di Red Hat." Queste le parole di Exelbierd, che spiega come la decisione di eliminare CentOS nella sua incarnazione classica sia derivata da una scelta di Red Hat nell'allocazione delle risorse.
"Red Hat ci ha detto che avrebbe apportato cambiamenti fondamentali nel modo in cui avrebbero diretto i finanziamenti. Quindi siamo andati dal progetto CentOS e gli abbiamo detto che Red Hat avrebbe fatto ciò. Crediamo che ci siano delle conseguenze... e il risultato finale è stato una decisione presa dal progetto", afferma Exelbierd. Come sappiamo, il risultato è stato la fine di CentOS per come l'abbiamo conosciuto per 16 anni.
Secondo Exelbierd, uno dei problemi di CentOS era la mancanza di interazione con una larga fetta degli utenti, fatta di persone che "non chiamavano mai, non scrivevano mai, non interagiscono con noi". L'assenza di riscontri impediva a Red Hat e al direttivo di CentOS di capire le esigenze di questa base di utenti e, di conseguenza, di capire quale direzione prendere. C'era anche un'assenza di contributi, con la maggioranza degli utenti che non sosteneva il progetto né finanziariamente né con del codice.
Al contrario, CentOS Stream rappresenta un'occasione per Red Hat per introdurre i cambiamenti che andranno poi in RHEL e ricevere quindi il feedback necessario per capire come orientare tali modifiche e quali problemi eventualmente queste causino. "CentOS Stream è critica", dice Exelbierd. "Soddisfa esigenze molto specifiche per noi. Abbiamo spiegato la nostra posizione e comunicato che avremmo spostato i nostri contributi ingegneristici, in alcuni casi il tempo dedicato dalle persone... Vogliamo che diate loro la vostra attenzione [del direttivo di CentOS] perché, a seconda di quello che deciderete di fare, ci sono potenziali problemi di responsabilità che potrebbero risultarne, quindi vogliamo essere sicuri che abbiate un piano."
Per offrire un controbilanciamento a questo cambiamento, Red Hat ha introdotto la possibilità di usare RHEL gratuitamente fino a 16 server. Exelbierd fa però presente che ci saranno delle limitazioni relativamente alla definizione di "server": "Stiamo lavorando su delle FAQ con tutti i dettagli, inclusi cose come core e altre componenti. Un supercomputer in cantina non è l'utilizzo per cui abbiamo pensato questo programma. L'intenzione è comunque di non mettere limitazioni significative sul caso d'uso o sull'hardware." Maggiori informazioni dovrebbero arrivare nel corso dei prossimi giorni.
L'aspetto che emerge chiaramente è dunque che CentOS non era più sostenibile da parte di Red Hat, che ha deciso di staccare la spina. Non si può però non notare come sebbene ci siano motivazioni valide dietro questa decisione, la comunicazione della stessa sia stata gestita in maniera imperfetta, con l'annuncio di un cambiamento imponente che non è stato controbilanciato sul momento da un'alternativa. Proprio questo errore di comunicazione ha scatenato i problemi nella comunità cui assistiamo ancora oggi. Una lezione per il futuro?
20 Commenti
Gli autori dei commenti, e non la redazione, sono responsabili dei contenuti da loro inseriti - infoavesse RedHat/IBM parlato chiaro fin da subito sarebbe stato tutto più semplice, come al solito.
Sarà un pregiudizio mio, ma l’impressione è che Centos Stream sia soltanto una RHEL “insider edition”, laddove invece CentosX sai che è production ready.
Da capire bene le limitazioni d’utilizzo della RHEL in versione gratuita, magari è tutto un fuoco di paglia.
Io fortunatamente ho tutte le installazioni nella mia rete di casa su CentOS7 e quindi non sono stato toccato da questa scure che ha colpito CentOS 8, ma al termine del supporto difficilmente passerò a CentOS Stream e se questo ragionamento lo faccio io che ho soltanto qualche macchina virtuale, figuriamoci ambienti più complessi.
Articolo
E poi dicono che sono i videogiochi ad avere continui richiami alla violenza...
Poi se serve il titolo acchiappa clic... "Esclusivo! Top! Solo qui le foto del massacro di CentOS! Tutti gli scabrosi dettagli in cronaca! 11111"
Io fortunatamente ho tutte le installazioni nella mia rete di casa su CentOS7 e quindi non sono stato toccato da questa scure che ha colpito CentOS 8, ma al termine del supporto difficilmente passerò a CentOS Stream e se questo ragionamento lo faccio io che ho soltanto qualche macchina virtuale, figuriamoci ambienti più complessi.
Questa cosa non è scritta da nessuna parte nell'intervista originale
https://www.theregister.com/2021/01/26/killing_centos/
E sapete perché? Perché nessuno può contribuire al codice di CentOS (non Stream) perché è un clone di RHEL! Non è che potevi diventare package maintainer
Ho 4 macchine virtuali deployate su vultr, tutte usano ubuntu 20.04.
Su una ho un server di git (gitea), su un altra ho un applicazione node.js connessa con cloudflare, su una ho un db redis, mentre l'ultima la uso per sperimentare
Ho messo Ubuntu 20.04 perche` avevo Ubuntu su un desktop qualche anno fa, e ho anche pensato che avere deployato uno dei sistemi operativi piu` diffusi mi avrebbe portato a trovare info e documentazione in rete piu` facilmente.
Nessuna di queste macchine mi ha mai dato alcun problema di stabilita` o performance.
Anzi, sono rimasto estremamente colpito.
Ho fatto qualche benchmark (7zip, numeri primi, sysbench, cose simili) e sono rimasto estremamente colpito. La performance di queste cpu e` compresa tra il 10 e il 25% del mio pc desktop.
Con la differenza che solo con quello che ho pagato la mia mobo pago quasi 2 anni di questa macchina virtuale (pago circa 7 euro al mese per ogni vm).
Sono andato fuori tema, in ogni caso mi chiedo quali sarebbero queste garanzie in piu` che RHEL mi dovrebbe dare in termini di stabilita` visto che di problemi lato os non ne ho mai visti.
Ho 4 macchine virtuali deployate su vultr, tutte usano ubuntu 20.04.
Su una ho un server di git (gitea), su un altra ho un applicazione node.js connessa con cloudflare, su una ho un db redis, mentre l'ultima la uso per sperimentare
Ho messo Ubuntu 20.04 perche` avevo Ubuntu su un desktop qualche anno fa, e ho anche pensato che avere deployato uno dei sistemi operativi piu` diffusi mi avrebbe portato a trovare info e documentazione in rete piu` facilmente.
Nessuna di queste macchine mi ha mai dato alcun problema di stabilita` o performance.
Anzi, sono rimasto estremamente colpito.
Ho fatto qualche benchmark (7zip, numeri primi, sysbench, cose simili) e sono rimasto estremamente colpito. La performance di queste cpu e` compresa tra il 10 e il 25% del mio pc desktop.
Con la differenza che solo con quello che ho pagato la mia mobo pago quasi 2 anni di questa macchina virtuale (pago circa 7 euro al mese per ogni vm).
Sono andato fuori tema, in ogni caso mi chiedo quali sarebbero queste garanzie in piu` che RHEL mi dovrebbe dare in termini di stabilita` visto che di problemi lato os non ne ho mai visti.
Trovi le informazioni qui
https://www.redhat.com/it/topics/li...nterprise-linux
tuttavia penso che nel tuo caso non ti serva una RHEL, è più per ambienti critici dovela probabilità di avere eventuali problemi deve essere ridotta al minimo.
Nel tuo caso potresti usare benissimo Fedora o CentOS Stream
https://www.redhat.com/it/topics/li...nterprise-linux
tuttavia penso che nel tuo caso non ti serva una RHEL, è più per ambienti critici dovela probabilità di avere eventuali problemi deve essere ridotta al minimo.
Nel tuo caso potresti usare benissimo Fedora o CentOS Stream
Ma perche`, che ha ubuntu che non va?
Vul, Ubuntu non ha niente che non va.
Come hai detto tu, hai una manciata di VM che ti gestisci direttamente, sono stabili, assolvono allo scopo.
Che altro serve? Niente.
Io sono in una situazione simile alla tua con delle CentOS7 ed una Centos8. Ho scelto quelle giusto perché usando già le Fedora per altre cose, le CentOS/RHEL sono quasi identiche. Per praticità dunque.
RHEL offre tutta una serie di pacchetti di funzionalità già preconfezionati per tanti scenari d'utilizzo, documentazione molto approfondita, consulenti certificati in tutto il mondo, precise API unificate e documentate per ogni aspetto del sistema ad altri mille servizi
Per dire, hai un'applicativo cloud based multi-tentant. hai bisogno di organizzare un sistema per offrire dei runtime per deploy serverless in java e java-mini-vm, autoscaling, autosharding, message brokers, single sign-on, role based access e monitoraggio real-time di tutto quanto. dietro c'è tutta una galassia di pod kubernetes disseminati da qualche parte che devono coordinarsi altrettanto per fare scaling, sharding ecc. da un'altra parte ancora hai una batteria di DB per vari ambienti a cui le cloud functions ed i microservizi deployati nei pod di prima devono puntare al volo e di cui devono risolver correttamente le connection string. E magari questi DB hanno ridondanza solo in europa, quindi in asia ed america hai bisogno pure di coordinare degli edge server ultra carrozzati con una replica in redis delle tabelle principali così da velocizzare il tutto. e magari la decisione di cosa replicare su redis è in capo ad un sistema di machine learning su altri ulteriori server in .Net e python.
nel frattempo hai pure 4000 dipendenti, email, sedi, vpn, stampanti, messaggistica, gestione documentale ecc. da far funzionare.
e mettiamoci pure che l'azienda ha un team di sviluppo interno, quindi c'è bisogno anche di tutta una CI/CD integrata con la topologia di rete interna.
Presi singolarmente i problemi da risolvere non sono niente di particolarmente esotico, ma organizzare tutto da zero, minimizzare costi e garantirsi flessibilità futura sono questioni tutto fuor che banali.
è qui che RHEL fa la sua partita.
non è niente che non si possa fare con profitto basandosi su ubuntu, su qualsiasi altro linux, o su windows server.
anzi, in tanti vanno proprio di ubuntu/centos o windows se la complessità non giustifica quel baraccone di RHEL (alla fine RHEL costa abbastanza caro).
personalmente, l'unica grande critica che ho per RHEL è che è troppo java-centrico. per il resto il lavoro fatto con kubernetes ed openshift è notevole
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".