Il supporto a lungo termine per il kernel Linux verrà ridotto poiché la manutenzione continua a essere sotto sforzo
Long-term support for the Linux kernel will be reduced due to ongoing maintenance issues.
BILBAO, Spagna: Al Open Source Summit Europe, Jonathan Corbett, sviluppatore del kernel Linux ed editore esecutivo di Linux Weekly News, ha aggiornato tutti sulle novità del kernel Linux e su quale sarà la sua direzione.
Ecco una grande modifica in arrivo: il supporto a lungo termine (LTS) per i kernel Linux verrà ridotto da sei a due anni.
Attualmente, ci sono sei kernel Linux LTS — 6.1, 5.15, 5.10, 5.4, 4.19 e 4.14. Con il processo attuale, il kernel 4.14 verrà sostituito nel gennaio 2024 e verrà aggiunto un nuovo kernel. In futuro, però, quando il kernel 4.14 e i due successivi verranno rimossi, non verranno sostituiti.
Inoltre: Vuoi un’alternativa elegante e user-friendly a Windows? Prova Manjaro 23.0 con KDE Plasma
Perché? Semplice, ha spiegato Corbett: “Non ha davvero senso mantenerli per così tanto tempo perché le persone non li utilizzano.” Sono d’accordo. Anche se sono sicuro che ci sia ancora qualcuno che utilizza il kernel 4.14 in un sistema Linux di produzione, non possono essere molti.
- Hai vinto, Google la mia esperienza nell’aggiornare lo spazio...
- Intel inserisce trucchi per risparmiare batteria nel suo processore...
- Guarda la Champions League di calcio Livestream AC Milan vs. Newcas...
Un’altra ragione, e un problema molto più grande rispetto alla semplice manutenzione LTS, secondo Corbett, è che i manutentori del codice Linux si stanno esaurendo. Non è che i programmatori siano un problema. Le ultime versioni di Linux hanno coinvolto in media oltre 2.000 programmatori — inclusi circa 200 nuovi sviluppatori che si uniscono — che lavorano su ogni rilascio. Tuttavia, i manutentori — le persone che verificano se il codice è adatto e funziona correttamente — sono un’altra questione.
I manutentori affrontano numerose difficoltà nel svolgere il loro lavoro. Difficoltà numero uno: molti manutentori non vengono pagati per la manutenzione. Effettuano la manutenzione del codice oltre al loro lavoro quotidiano. Inoltre, devono far fronte a una crescente richiesta di tempo — a causa di una carenza di personale e dell’uso di fuzzers per individuare bug. Sebbene i fuzzers siano utili, scoprono anche troppi bug minori, ognuno dei quali deve essere esaminato e poi scartato dai manutentori.
Il risultato? Per citare Josef Bacik, sviluppatore del file system del kernel Linux e manutentore: “I manutentori si stanno esaurendo perché i manutentori non possono essere scalati”. Ha aggiunto Darrick Wong, un altro manutentore senior del kernel Linux: “Questo non può continuare. Abbiamo bisogno di aiuto.”
Come possono ottenere aiuto? Beh, per prima cosa, Corbett suggerisce ai manutentori di parlare con i loro datori di lavoro per essere pagati per il loro lavoro di manutenzione. Come ha osservato Wong, “La maggior parte dei miei amici lavora per piccole aziende, organizzazioni non profit e governi locali. Segnalano gli stessi problemi di sovraccarico di lavoro, paura pervasiva e rabbia e difficoltà nel comprendere e adattarsi a nuove idee che osservo anche qui. Vedono la connessione diretta tra la mancanza di ricavi e risorse della loro organizzazione. Non capiscono perché diavolo succede la stessa cosa a me e ai miei colleghi quando lavoriamo per aziende che fanno miliardi di dollari.”
È una buona domanda. Le aziende devono capire che devono contribuire a Linux se vogliono continuare a beneficiarne.
Inoltre: Perché non più persone utilizzano Linux desktop? Ho una teoria che potrebbe non piacervi
Un problema correlato: Linux sta ora adottando Rust come esperimento. Sebbene questa sia una buona notizia in molti modi — Rust rimuove intere classi di errori a cui il linguaggio principale di Linux, C, è vulnerabile — presenta anche problemi per i manutentori. Dopotutto, se un manutentore ha passato 30 anni a lavorare in C, chiedergli di diventare un esperto di Rust è un grande impegno.
Inoltre, Rust è ancora in evoluzione. Sono necessarie molte patch di Rust per far funzionare correttamente il linguaggio a un livello profondo in Linux. Ciò comporta anche la necessità di molto codice di collegamento per far collaborare Rust e Linux in modo efficace.
Ci sono anche alcuni sviluppatori del kernel Linux che non amano Rust. Come ha detto uno di loro: “Ci sono alcune parti [di Linux] ben progettate e scritte che non hanno avuto problemi di sicurezza della memoria per molti anni. È offensivo presentare questo come un miglioramento rispetto a ciò che è stato raggiunto da coloro che hanno svolto tutto questo duro lavoro.”
Anche così, Corbett crede che il punto di decisione – se Rust diventerà una parte mainstream del kernel – si avvicini presto. Quel giorno arriverà, ha notato, “quando uniremo la prima funzione di cui gli utenti dipendono”.
Inoltre: Come Google sta usando Rust per ridurre le vulnerabilità di sicurezza della memoria in Android
Quel giorno è vicino: Tre importanti nuove aggiunte basate su Rust al codice del kernel Linux sono in arrivo, ha detto Corbett. Queste sono un’implementazione del PuzzleFS, un server di filesystem Plan9 a lettura/scrittura; e – quello che farà più notizia – il driver della GPU Apple M1. Infatti, i primi driver Linux OpenGL ES 3.1 conformi sono ora disponibili per le GPU Apple M1 e M2, arrivati alla fine di agosto 2023. Con lavori del genere ben avviati, Corbett sarebbe molto sorpreso se Rust non diventasse permanentemente parte di Linux.
Un altro argomento di cui si parla ultimamente è come le modifiche apportate da Red Hat alla licenza di Red Hat Enterprise Linux (RHEL) abbiano provocato la creazione di fork di RHEL da parte di Oracle, SUSE e CIQ con l’Open Enterprise Linux Association (OpenELA). Tralasciando le complicazioni commerciali e di licenza che hanno portato a questa lotta, ci sono anche preoccupazioni per il kernel Linux.
Queste preoccupazioni ruotano attorno alla domanda: quale kernel dovresti utilizzare per la tua distribuzione Linux? Ci sono due scelte reali: 1) Eseguire l’ultima versione stabile del kernel o 2) Eseguire un kernel vecchio con correzioni backportate. Quest’ultimo è ciò che Red Hat e gli altri distributori di Linux enterprise tendono a fare.
Quest’ultimo porta anche a kernel specifici dei fornitori. E sebbene ciò offra stabilità, allontana queste distribuzioni dal supporto della comunità e le rende dipendenti da fornitori specifici. È questa ultima conseguenza – che ha portato AlmaLinux e Rocky Linux a creare le proprie versioni di CentOS (il clone gratuito di RHEL di Red Hat) dopo che Red Hat ha chiuso CentOS a favore di CentOS Stream – che ha scatenato il conflitto tra Red Hat e OpenELA. Quello che OpenELA vuole è un clone di RHEL, che utilizza il kernel patchato più vecchio di RHEL. Restate sintonizzati per ulteriori sviluppi mentre questo conflitto continua a bruciare.
Inoltre: La mia idea per una nuova distribuzione Linux adatta ai principianti
D’altra parte, Corbett ha osservato, Android “ha fatto molto in modo da ottenere questa immagine del kernel generico e si è basato su aggiornamenti stabili. Questo perché hanno scoperto che ciò aiuta a migliorare la sicurezza di Android. Hanno scoperto che la grande maggioranza dei problemi di sicurezza viene divulgata nel kernel e/o risolta nei kernel di Android prima che vengano divulgati perché sono già stati incorporati prima che qualcuno sapesse che si trattava effettivamente di bug correlati alla sicurezza”.
Questo è un altro problema di cui gli sviluppatori del kernel Linux sono dolorosamente consapevoli. Come ha spiegato Corbett:
“Uno degli aspetti interessanti dello sviluppo del kernel è che praticamente qualsiasi cosa può essere un bug di sicurezza. E non si sa davvero che lo sia finché qualcuno non trova un modo per sfruttarlo in qualche modo. Quindi moltissime correzioni vengono effettuate e non vengono contrassegnate come correzioni di sicurezza. Non perché la comunità del kernel stia cercando di nascondere le correzioni di sicurezza. Voglio dire, a volte c’è un po’ di furbizia che va avanti lì che personalmente non mi piace. Ma nella maggior parte dei casi, la verità è che nessuno sa che questo bug è un bug di sicurezza. È solo in seguito che qualcuno se ne accorge. E quindi l’unico modo per proteggersi da questo tipo di bug è applicare tutte le correzioni”
Ecco perché Corbett, e chiunque conosca davvero Linux, consiglia che se stai creando una distribuzione Linux, includi sempre tutte le patch. Per kernel più vecchi, come il 4.14, possono essere fino a 26.799 commit. Ma se provi a selezionare e scegliere quali patch utilizzare, sicuramente aprirai le porte a falle di sicurezza.
Infine, Corbett ha osservato che Scott McNealy, ex CEO di Sun, ha una volta detto: “L’open source è gratuito come un cucciolo è gratuito”. McNealy aveva ragione. Usare open source e Linux è facile. Pagare per la formazione necessaria per evitare pasticci sul pavimento della cucina, quello è più difficile.
.
