Torvalds rilascia Linux 6.16, le novità del kernel da 38 milioni di righe di codice

Linux 6.16 è stato rilasciato in versione stabile con importanti novità come il supporto ai driver Nouveau per GPU NVIDIA Hopper e Blackwell, ottimizzazioni prestazionali e preparativi per Intel APX. Il prossimo ciclo di sviluppo, Linux 6.17, potrebbe subire ritardi a causa degli impegni personali di Linus Torvalds.
di Manolo De Agostini pubblicata il 28 Luglio 2025, alle 13:01 nel canale Sistemi OperativiLinux
Il kernel Linux 6.16 è stato ufficialmente rilasciato da Linus Torvalds il 27 luglio tramite il consueto annuncio sulla Linux Kernel Mailing List (LKML). Dopo una settimana di test definita "tranquilla", senza bug critici o imprevisti, la nuova versione è stata taggata e pubblicata come da programma, senza necessità di un'ottava versione RC.
Linux 6.16 porta con sé una vasta gamma di miglioramenti, che spaziano dal supporto hardware all'ottimizzazione delle prestazioni, con importanti evoluzioni nel campo della sicurezza e del networking.
Sul fronte GPU, spicca l'integrazione di driver open-source Nouveau per le architetture NVIDIA Hopper e Blackwell, segnando un passo in avanti per chi utilizza schede grafiche NVIDIA in ambienti completamente open. Non manca il consueto aggiornamento per dispositivi AMD, Intel e ARM, insieme al supporto per hardware consumer come il mouse Apple Magic Mouse 2 (versione USB-C), controller ByoWave Proteus, OneXPlayer, Acer Nitro NGR200 e miglioramenti per l'ASUS ROG Ally.
Tra le modifiche di rilievo, anche il supporto migliorato per USB audio offloading, capace di mantenere lo streaming audio attivo anche durante lo sleep del sistema, con impatto positivo sull'autonomia nei dispositivi portatili.
Linux 6.16 introduce OpenVPN DCO (Data Channel Offload), che sposta le operazioni critiche del canale dati nel kernel per un notevole aumento delle prestazioni, soprattutto nei trasferimenti di grandi dimensioni. Altra novità significativa è il supporto per la trasmissione zero-copy da memoria GPU alla rete, utile in ambiti data-intensive come calcolo scientifico e AI.
Una delle innovazioni più strutturali è l'abilitazione universale delle tabelle di paginazione a cinque livelli. Questa modifica espande l'indirizzamento della memoria fino a 128PB, preparando il kernel alle future esigenze di workload ad alta intensità, come AI e machine learning.
In ambito sicurezza e virtualizzazione, arriva il supporto per le Intel Trust Domain Extensions (TDX), che permettono l'isolamento crittografico della memoria per le VM eseguite in ambienti KVM. Inoltre, viene introdotto l'uso delle chiavi di cifratura protette da hardware, già presenti su Android, ora disponibili anche per Linux desktop e server.
Il kernel introduce importanti progressi anche nei file system. In particolare: Ext4 beneficia di un aumento fino al 37% della velocità nelle operazioni sequenziali grazie al supporto ai large folio, XFS implementa scritture atomiche per una maggiore integrità, FUSE aumenta il buffer di lettura directory migliorando le performance e Bcachefs può posticipare le operazioni di rebalance se il sistema è alimentato a batteria.
Il kernel Linux 6.16 rappresenta anche un'evoluzione dimensionale: 38,4 milioni di righe di codice su oltre 78.000 file, secondo le metriche dello strumento cloc. Una crescita costante che riflette l'espansione del supporto a nuove piattaforme e casi d'uso.
Torvalds ha già avvisato la comunità che il ciclo di sviluppo di Linux 6.17 potrebbe essere meno lineare. Durante il mese di agosto sarà impegnato in viaggi tra Stati Uniti e Finlandia per eventi familiari, aumentando potenzialmente il rischio di ritardi. L'obiettivo è comunque quello di mantenere un rilascio regolare, ma non si escludono ritardi o l'aggiunta di ulteriori release candidate.
Linux 6.17 sarà di particolare importanza in quanto sarà il kernel predefinito di Ubuntu 25.10 ed è previsto anche su Fedora 43, entrambe in uscita a fine 2025.
7 Commenti
Gli autori dei commenti, e non la redazione, sono responsabili dei contenuti da loro inseriti - infoVolete farmi credere che lo sviluppo di linux si blocca se a Torvalds viene la cacarella? Non ci credo neanche se lo vedo che sia l'unico a poter fare le pull request e le merge sul progetto, manco stessimo nella vecchia unione sovietica
Beh, Linux è un marchio registrato di Linus Torvalds. Questo dovrebbe suggerire qualcosa
Volete farmi credere che lo sviluppo di linux si blocca se a Torvalds viene la cacarella? Non ci credo neanche se lo vedo che sia l'unico a poter fare le pull request e le merge sul progetto, manco stessimo nella vecchia unione sovietica
è lui che ha sempre voluta il controllo sul progetto
Volete farmi credere che lo sviluppo di linux si blocca se a Torvalds viene la cacarella? Non ci credo neanche se lo vedo che sia l'unico a poter fare le pull request e le merge sul progetto, manco stessimo nella vecchia unione sovietica
Si, il dittatore benevolo decide le sorti del kernel.
Volete farmi credere che lo sviluppo di linux si blocca se a Torvalds viene la cacarella? Non ci credo neanche se lo vedo che sia l'unico a poter fare le pull request e le merge sul progetto, manco stessimo nella vecchia unione sovietica
e manco lo vedrai perché non ci sono ACL o sistemi tanto evoluti stile GitHub sul repo. c'è solo un git server puro, PR e mailing list.
tutti i merge li ha fatti esclusivamente Torvalds da anni, tranno una piccola parentesi anni fa quando delegò Andrew Morton. C'è un main repo di cui lui è l'unico con merge grants e tutta una serie di repo downstream organizzati stile patch flow, con ciascuno un solo maintainer che invia periodicamente PR a Torvalds con le email inline di Git.
più a valle ancora poi ogni "modulo" si organizza un po' come meglio crede, tanti fanno GitFlow o trunk based dev per i collaboratori abituali, mentre chiedono fork e patch per i commit in arrivo al di fuori del team.
le PR può aprirle chiunque, ma comunque mainline e gli altri alberi secondari principali filtrano via tutto, troppo rumore sennò.
Per le questioni urgenti si scrive sulla ML, si forka e si pubblica un patch
è così da sempre, le uniche due "modifiche" sono state il passaggio a Git anni fa da BitKeeper, ed il passaggio a BitKeeper dai tarball pubblicati su mailing list ancor prima
organizzazione molto rigida ed accademica, ma se non si è beccato ancora dei fork in faccia di quelli brutti evidentemente il modello benevolent dictator è adeguato per il progetto
Se non c'è nessuno che comanda (e controlla), sarebbe un continuo frignare tra primedonne...
Il kernel è suo, è giusto che decida (finché è in grado di farlo).
tutti i merge li ha fatti esclusivamente Torvalds da anni, tranno una piccola parentesi anni fa quando delegò Andrew Morton. C'è un main repo di cui lui è l'unico con merge grants e tutta una serie di repo downstream organizzati stile patch flow, con ciascuno un solo maintainer che invia periodicamente PR a Torvalds con le email inline di Git.
più a valle ancora poi ogni "modulo" si organizza un po' come meglio crede, tanti fanno GitFlow o trunk based dev per i collaboratori abituali, mentre chiedono fork e patch per i commit in arrivo al di fuori del team.
le PR può aprirle chiunque, ma comunque mainline e gli altri alberi secondari principali filtrano via tutto, troppo rumore sennò.
Per le questioni urgenti si scrive sulla ML, si forka e si pubblica un patch
è così da sempre, le uniche due "modifiche" sono state il passaggio a Git anni fa da BitKeeper, ed il passaggio a BitKeeper dai tarball pubblicati su mailing list ancor prima
organizzazione molto rigida ed accademica, ma se non si è beccato ancora dei fork in faccia di quelli brutti evidentemente il modello benevolent dictator è adeguato per il progetto
Affascinante come possa funzionare (e mi sembra funzioni bene, a quanto posso capire).
Conosci questo perché contribuisci o hai letto qualcosa a riguardo?
By(t)e
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".