AlmaLinux 9.3, la prima release che non rispetta i tempi di RHEL e che farà capire quanto funziona la compatibilità ABI

7

Il progetto AlmaLinux non dorme mai. Mentre i responsabili della promozione sono impegnati alle conferenze e stanno organizzando il primo evento AlmaLinux-centrico a Tokio, che si svolgerà il prossimo 9 dicembre, gli sviluppatori hanno annunciato la disponibilità della versione 9.3 di AlmaLinux, la quale ha una particolarità: è la prima ad uscire in tempi indiretti rispetto alla controparte redhattiana.

La distribuzione AlmaLinux, come abbiamo lungamente raccontato negli scorsi mesi seguenti la decisione da parte di Red Hat di sospendere la pubblicazione dei sorgenti RPM relativi a Red Hat Enterprise Linux, ha deciso di scegliere una strada diversa rispetto alle “concorrenti” che fanno parte del progetto OpenELA e che continuano ad essere dei cloni 1:1 di RHEL. Questa strada è la garanzia della sola compatibilità ABI (Application Binary Interface).

La release 9.3 di AlmaLinux è infatti la prima a non esser stata rilasciata immediatamente dopo l’uscita di RHEL 9.3, a conferma del fatto che le cose, oggi, sono gestite in maniera diversa. Due anni esatti fa infatti pubblicavamo l’articolo “48 ore dopo RHEL 8.5 ecco arrivare AlmaLinux 8.5, e con ELevate migrare è ormai un attimo!“, ma da allora come sappiamo di cose ne sono cambiate moltissime.

Seguì poco dopo la scelta di Red Hat su cui ogni clone ha poi fatto le proprie considerazioni, che per AlmaLinux, secondo Benny Vasquez (dirigente del progetto), hanno portato a queste conclusioni raccontate a FossForce:

Red Hat has made very clear what they want from us and how they’re willing to work with us. Attempting to subvert them in the way that they want us to work with them is only going to cause, from my perspective, insecurity in my community. I don’t want to try and pick a fight and have the community have to deal with the instability that comes with that. That’s why we ultimately ended up going ABI instead of trying to continue to be one-for-one with RHEL.

Red Hat ha chiarito [dopo l’annuncio] cosa vuole e come è disposta a lavorare con noi. Tentare di sovvertirli nel modo in cui vogliono che lavoriamo con loro causerà solo, dal mio punto di vista, insicurezza nella mia community. Non voglio provare a litigare e costringere la community a dover affrontare l’instabilità che ne deriva. Ecco perché alla fine abbiamo optato per ABI invece di provare a continuare a essere uno a uno con RHEL.

Le riflessioni di Vasquez continuano poi a proposito della non partecipazione ad OpenELA:

We haven’t needed to go to them for any of the updates at this point, if there’s a change in what Red Hat’s doing in the future, we might change how we’re doing things. But right now, there’s no reason for us to go to OpenELA.

Non abbiamo bisogno di rivolgerci a loro [ai pacchetti sorgenti generati da OpenELA] per nessuno degli aggiornamenti a questo punto, se ci sarà un cambiamento in ciò che Red Hat farà in futuro, potremmo cambiare il modo in cui stiamo facendo le cose. Ma in questo momento non c’è motivo per noi di andare a OpenELA.

Che si tratti di una scelta “politica”, per rimanere in buoni rapporti con Red Hat, o di altro, rimane il fatto che l’anima di Alma (scusate il gioco di parole) al momento rimane libera e indipendente:

One of the things we continue to see from our users is they like that the approach we’re taking lends itself to longevity and stability, we’re not going to have to shift every two years because something crazy changed. We’re focused on something that will be the long term solution. This is one of the things that I’ve really had to hammer home with folks, especially from outside the organization.

Una delle cose che continuiamo a vedere dai nostri utenti è che a loro piace l’approccio che stiamo adottando, che si presta alla longevità ed alla stabilità, senza dover cambiare ogni due anni perché è successo qualcosa di pazzesco. Siamo concentrati su qualcosa che sarà una soluzione a lungo termine. Questa è una delle cose su cui ho dovuto insistere maggiormente con le persone, soprattutto al di fuori dell’organizzazione.

AlmaLinux 9.3 in questo senso è quindi la capostipite del nuovo corso, a cui si aggregherà nel breve anche la prossima release del ramo 8. È bene poi chiarire come questo “disallineamento” di date sia al momento assestato su una settimana, quindi niente di trascendentale, trattandosi queste di distribuzioni di classe enterprise che di certo non prevedono presso i datacenter cicli di update quotidiani.

Da sempre appassionato del mondo open-source e di Linux nel 2009 ho fondato il portale Mia Mamma Usa Linux! per condividere articoli, notizie ed in generale tutto quello che riguarda il mondo del pinguino, con particolare attenzione alle tematiche di interoperabilità, HA e cloud.
E, sì, mia mamma usa Linux dal 2009.

7 risposte a “AlmaLinux 9.3, la prima release che non rispetta i tempi di RHEL e che farà capire quanto funziona la compatibilità ABI”

  1. Avatar Black_Codec

    Si son basati su centos e dicono “non cambia nulla”… Uhm…

  2. Avatar Raoul Scarazzini

    Potresti estendere il tuo commento?

  3. Avatar Black_Codec

    Ad oggi CentOS Stream non è allineata con la release di RHEL, basare i propri repository sulla versione presente su CentOS significa disallineare rispetto a una RHEL, è il motivo per cui è nata OpenELA.
    “Continuously delivered distro that tracks just ahead of Red Hat Enterprise Linux (RHEL) development, positioned as a midstream between Fedora Linux and RHEL. For anyone interested in participating and collaborating in the RHEL ecosystem, CentOS Stream is your reliable platform for innovation.”
    Cioè sono loro stessi a dirti “siamo una via di mezzo tra Fedora e RHEL”, quindi dire agli utenti AlmaLinux non cambia nulla è errato perché effettivamente cambia molto rispetto a una rhel e rispetto a essere “allineati a RHEL”.

  4. Avatar Raoul Scarazzini

    Adesso quello che volevi dire si è compreso con chiarezza e capisco il tuo punto di vista, però metto sul piatto due considerazioni essenziali:

    1. Le patch ed ogni tipo di feature che deve arrivare in RHEL (produzione) passa obbligatoriamente da CentOS Stream, ed è raro se non impossibile che una patch che passa da lì non finisca in RHEL. questo perché, a quanto mi risulta, l’approccio Red Hat è sempre stato “upstream first”, quindi quant’anche ci dovesse essere un problema con una patch, la sua risoluzione passerebbe sempre e comunque da CentOS Stream. Quindi la differenza la fa solo il comparto QA, che è il valore aggiunto di RHEL, che è ciò per cui Red Hat si fa legittimamente pagare. In questo senso, certamente, la scelta è degli utenti. Però ribadisco: ciò che finisce in RHEL passa da CentOS Stream, pertanto agganciarsi a quel treno significa essere allineati (presto o tardi).

    2. Rispetto alle “concorrenti” OpenELA la scelta di Alma è coraggiosa e corretta, tant’è che come si scrive nell’articolo è presumibile che sia una scelta “politica” per non inimicarsi Red Hat. Fossi un utente finale apprezzerei certamente di più un progetto simile, rispetto agli altri. Ma mi rendo conto essere una questione prevalentemente filosofica.

  5. Avatar Black_Codec

    Il punto 1 non è assolutamente vero, ci sono molte differenze tra centos stream e rhel, ti faccio un esempio pratico le patch di sicurezza 8.6 e 8.7 sono certo (perché i sorgenti erano ancora disponibili) che non provengono dal flusso stream. Ti posso anche dire che la 9.2 non era dal flusso stream perché centos stava già 2 release più avanti e quelle sottoversioni neanche le ha viste.
    Invalidando il punto 1 viene snaturato anche il punto 2, scelta politica o non il punto è che openEla prova a impostare un repository comune dove chiunque può partecipare e contribuire secondo le classiche modalità (non è un aur per capirci) mentre quello che sta facendo AlmaLinux è basarsi su Centos stream che sarà la base della nuova Rhel10 non della 9.x…

  6. Avatar Raoul Scarazzini

    Non starò qui ad insistere, ma da definizione data da Red Hat stessa (https://www.redhat.com/en/topics/linux/what-is-centos-stream) CentOS Stream è la versione upstream di RHEL. Significa che quanto c’è in RHEL è prima passato da Stream. Da sempre, e ne sono stato testimone quando lavoravo come Principal Software Engineer in Red Hat nel gruppo HA di OpenStack, la filosofia è Upstream first. Se c’è in RHEL, c’è in CentOS Stream. Poi potrebbe non esser sempre vero il contrario, ma è raro.

  7. Avatar Black_Codec

    Il link inviato non porta da nessuna parte, io non ho mai detto che se c’è in rhel non c’è in centos stream ma ho detto una cosa assai diversa… E per quanto possa crederti faccio fatica a darti ragione quando la stessa rhel ti dice che non sono la stessa cosa
    https://www.redhat.com/en/resources/centos-stream-checklist

Lascia un commento

Il tuo indirizzo email non sarà pubblicato. I campi obbligatori sono contrassegnati *