Con il consueto messaggio di rilascio pubblicato sulla mailing list del Kernel Linux, Linus Torvalds ha annunciato l’uscita di Linux 6.9, l’ultima release del pinguino.

A figurare tra le novità più rilevanti di questa release ci sono:

• Il supporto Rust per le architetture AArch64 (quindi ARM64), per cui tra l’altro Torvalds indica di avere macchine arm64 che sono state fornite da Ampere, e quindi in questo senso più possibilità di testare quel tipo specifico di architettura.
• Il supporto per il meccanismo FRED di Intel, che sta per Flexible Return and Event Delivery, tecnologia piuttosto avveniristica di gestione del flusso degli eventi nei processori descritta nel dettaglio sul sito di Intel.
• Il supporto per AMD SNP ossia il Secure Nested Paging, anche qui una funzionalità avanzata per la gestione della memoria di virtual machine in maniera protetta, per cui esiste un whitepaper molto esaustivo sull’argomento.
• Un nuovo Device Mapper chiamato dm-vdo, il cui acronimo sta per Virtual Data Optimizer ed il cui scopo è quello di rendere più efficiente la deduplicazione a livello di block device, la compressione ed il thin provisioning.

Miglioramenti sono presenti anche per quanto riguarda l’ambito della compilazione e l’accesso ai dati.

Da notare come questa versione sarà supportata per non più di un paio di mesi, ed il papà di Linux si sta già occupando della versione 6.10, che avrà una data di release intorno al settembre 2024.

Ci sono già diverse discussioni in corso in merito al futuro del Kernel, una delle quali raccontata da Phoronix, a proposito delle mitigazioni relative a quelli che vengono definiti come overflow (e underflow) aritmetici.

Kees Cook, uno degli ingegneri per la sicurezza del Kernel Linux, ha lavorato con Google per capire come gestire meglio questi problemi imprevisti all’interno del codice sorgente C del kernel Linux.

Tra le complicate riflessioni proposte c’è quella di rendere Linux più sicuro attraverso quelli che vengono definiti come dei “sanitizer” che dovrebbero gestire in maniera automatica questo genere di problematiche.

La parte più “divertente” è come sempre la risposta alla proposta da parte del, mai come in questo caso, Dittatore Benevolo, il quale è tutt’altro che entusiasta della proposta e chiude con una riflessione che ben identifica quello che è il suo approccio a tutti gli ausili che dovrebbero facilitare la vita degli sviluppatori:

And no, the answer is ABSOLUTELY NOT to add cognitive load on kernel developers by adding yet more random helper types and/or functions.

We already expect a lot of kernel developers. We should not add on to that burden because of your pet project.

Put another way: I’m putting the onus on YOU to make sure your pet project is the “Yogi Bear” of pet projects – smarter than the average bear.

As long as you are approaching this from a “this puts the onus on others”, YOU are the problem.

Be the solution, not the problem.

Linus

E no, la risposta è ASSOLUTAMENTE NO all’aggiunta di un carico cognitivo agli sviluppatori del kernel aggiungendo ancora più tipi e/o funzioni di helper casuali.

Ci aspettiamo già molto dagli sviluppatori di kernel. Non dovremmo aggiungere questo peso a causa del tuo progetto preferito.

Detto in altro modo: mi sto assumendo l’onere di assicurarmi che il tuo progetto per animali domestici sia l’”Orsetto Yogi” dei progetti per animali domestici: più intelligente dell’orso medio.

Finché ti avvicini a questo dal punto di vista “questo mette l’onere sugli altri”, *TU* sei il problema.

Sii la soluzione, non il problema.

Linus

E questa è solo la chiusura di una serie enorme di indicazioni tecniche per cui la soluzione proposta non accende l’entusiasmo del creatore di Linux il quale, lo ricordiamo se ce ne fosse bisogno, ha diritto di veto su qualsiasi integrazione alla sua creatura.

E voi che pensavate come lavorare con il vostro capo attuale fosse complicato!