Il Kernel Linux è emblematicamente forse il progetto open-source per eccellenza, ed in quanto tale ognuno può modificarlo, integrarlo e scegliere di mantenerlo a seconda delle proprie disponibilità ed esigenze.
In virtù di questo, potrà sembrare banale ricordarlo, ma non esiste un Kernel Linux unico. Se è vero che le release sono cadenziate e gestite da Linus Torvalds in persona (pochi giorni fa abbiamo raccontato del rilascio della versione 6.10) quello che poi arriva nelle distribuzioni che sono disponibili nei vari progetti, siano esse istanze nel cloud o file .iso scaricati per installazioni locali, sono essenzialmente ciò che la distribuzione sceglie di adottare e manutenere.
Per essere chiari: la versione 5.15 del Kernel Linux distribuita con Red Hat Enterprise Linux 9 potrebbe essere molto, molto diversa dalla versione 5.16 che invece è parte di Ubuntu 22.04. Questo perché ciascuna organizzazione sceglie di includere determinate patch, effettuare il backport di altro materiale e quindi sebbene nominalmente molto vicine, quelle due release potrebbero avere sostanziali differenze.
Tutto questo lungo preambolo per raccontare due notizie che riguardano proprio l’adozione personalizzata del Kernel Linux da parte di due importanti aziende.
La prima è Oracle che, come racconta The Register, ha deciso di iniziare a sperimentare le build UEK-next. Si tratta infatti di una release del Kernel introdotta ad aprile creata secondo il principio della CI (Continuous Integration). La questione è interessante per diversi aspetti, ma il più importante è il cambio di paradigma: infatti se tutte le big scelgono release stabili, Long Term Support, che quindi hanno una certa maturità, UEK-next segue invece l’upstream, in un ciclo che è riassunto in questa immagine:
Come mostra lo schema, gli utilizzatori di questa versione potrebbero avere il Kernel 6.10, appena rilasciato, in tempi davvero brevissimi.
Di tutt’altro avviso è invece Google che, come racconta Android Authority, ha deciso invece di sobbarcarsi il peso del mantenimento dei Kernel LTS, che come ricorderete era stato ridotto da sei a tre anni, in modo da gestire i quattro anni di mantenimento mancanti all’interno di un fork.
La scelta come intuibile riguarda da vicino i sistemi Android, i quali forse per la connotazione che hanno (principalmente gli smartphone) hanno necessità di una gestione del ciclo di vita piuttosto diversa da quella di un server standard.
Tra Oracle e Google due esempi diametralmente opposti di gestione del Kernel, i cui benefici vanno valutati insieme ai rischi annessi in termini di stabilità.
La catena di CI per la produzione dei pacchetti Kernel ci si aspetta che effettui ogni tipo di controllo di stabilità, ma va detto allo stesso tempo come tutte le vulnerabilità del passato avessero riguardato anche Kernel considerati affidabili, pertanto “LTS” non vuol dire “sicuro”, così come “upstream” non vuol dire “bacato”.
Vale poi la pena ricordare in chiusura un aspetto molto importante della gestione dei numeri di release del Kernel Linux, ossia che questi non hanno un senso logico, l’ultima major release della serie 5 non ha differenze sensibili in termini di evoluzione rispetto alla prima della serie 6.
Questo perché Linus Torvalds ha da sempre utilizzato un approccio molto preciso nel passare da una release all’altra: quello casuale.
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.
English (US)