Linus Torvalds rompe il tabù: l’IA nel kernel Linux si farà. Intanto, ecco Wayland 1.26

🐧 Novità principali

• Torvalds sostiene l’uso volontario dell’IA nella revisione del kernel quando gli strumenti producono risultati tecnici misurabili e verificabili.
• Sashiko segnala bug nelle patch attraverso commenti, senza modificare autonomamente il codice o prendere decisioni al posto dei maintainer.
• Wayland 1.26 aggiorna puntatore, rimozione dei global, gestione dei socket e debug, mentre Weston 16 corregge perdite di memoria e regressioni DRM.

Linus Torvalds interviene con decisione nel dibattito sull’impiego dell’intelligenza artificiale nella revisione delle patch del kernel Linux, respingendo l’idea di imporre al progetto una posizione pregiudizialmente contraria agli strumenti basati su LLM. Il confronto nasce attorno a Sashiko, sistema volontario di code review automatizzata capace di analizzare le patch in più fasi e segnalare possibili difetti attraverso commenti. Parallelamente, il 16 luglio 2026 arriva Wayland 1.26, release che perfeziona il protocollo grafico con nuove primitive per puntatore, global e socket, accompagnata da Weston 16, aggiornamento dell’implementazione di riferimento.

Torvalds considera l’IA uno strumento e non una battaglia ideologica

La posizione di Torvalds emerge durante una discussione sulla mailing list del kernel dedicata all’integrazione di Sashiko nel processo di revisione. Il maintainer principale ha chiarito che Linux non aderirà a una linea anti-IA e che gli sviluppatori contrari restano liberi di non utilizzare questi strumenti o, secondo la logica dell’open source, di creare un fork. Il punto centrale non riguarda l’accettazione automatica di codice generato, ma la possibilità di impiegare sistemi capaci di individuare problemi prima del merge. Torvalds tratta l’IA come qualsiasi altro strumento di analisi: deve essere valutata sulla base dei risultati, dei falsi positivi e della capacità di migliorare la qualità del codice. La posizione segna una distinzione rispetto ad altri progetti che hanno introdotto limiti generali per timori legati a copyright, provenienza del codice o qualità dei contributi. Nel kernel, invece, la priorità resta la revisione tecnica. Torvalds aveva già affrontato gli effetti indesiderati dell’automazione quando modificò la gestione dei report di sicurezza Linux dopo l’aumento delle segnalazioni duplicate generate dall’IA, mostrando un approccio pragmatico: apertura agli strumenti utili, ma nessuna tolleranza per rumore, risultati non verificati o carico aggiuntivo imposto ai maintainer.

Sashiko segnala i bug senza modificare autonomamente le patch

Sashiko, sviluppato da Roman Gushchin, opera come sistema opt-in di revisione multi-stage e pubblica osservazioni sotto forma di commenti. Non applica modifiche, non approva patch e non sostituisce il giudizio dei maintainer. Secondo i dati discussi sulla mailing list, il tool individua il 53,6% dei bug presenti nelle patch analizzate, mantenendo i falsi positivi entro il 20%. Il valore più rilevante consiste nella capacità di identificare problemi sfuggiti a precedenti revisioni umane, offrendo un ulteriore livello di controllo prima dell’integrazione nel kernel. Laurent Pinchart aveva proposto di sottoporre l’output alle linee guida del Software Freedom Conservancy sul codice generato dall’IA, ma Gushchin ha osservato che trattare ogni segnalazione come contributo generativo da sottoporre a un processo separato avrebbe ridotto l’utilità pratica del sistema. La distinzione è importante: Sashiko non produce necessariamente porzioni di codice da incorporare, ma formula osservazioni tecniche che uno sviluppatore deve verificare. Il modello ricorda gli analizzatori statici, i fuzzer e i test automatici, pur utilizzando tecniche differenti. La responsabilità finale resta umana, e ogni commento deve essere valutato in relazione all’architettura, alle convenzioni e al contesto della patch.

Il kernel accetta l’innovazione ma pretende risultati verificabili

La difesa dell’IA non equivale a un’autorizzazione indiscriminata a inviare patch generate automaticamente. Il kernel Linux mantiene requisiti rigorosi su attribuzione, responsabilità, revisione e qualità. Un contributore deve comprendere ciò che propone, essere in grado di motivarlo e rispondere alle osservazioni dei maintainer. Gli strumenti AI possono aiutare a individuare errori di memoria, condizioni limite, incoerenze nelle API o regressioni, ma non eliminano la necessità di test, benchmark e conoscenza del sottosistema. Torvalds sostiene che l’intelligenza naturale non sia infallibile e che un sistema automatico non debba essere perfetto per risultare utile: deve semplicemente migliorare il processo in casi concreti. Questa impostazione contrasta con il divieto scelto da alcuni progetti, come emerso nel confronto tra Linux 7.0 e la posizione anti-AI adottata da Xubuntu. Per i contributori, il messaggio è chiaro: l’uso dell’IA rimane accettabile quando non scarica lavoro inutile sulla comunità e produce segnalazioni tecnicamente fondate.

Wayland 1.26 introduce nuove primitive per puntatore e global

Sul versante grafico, Wayland 1.26 arriva quattro mesi dopo la versione 1.25 e introduce l’evento wl_pointer.warp, che consente al compositore di notificare una nuova posizione del puntatore senza rappresentarla come un movimento effettuato fisicamente dall’utente. La distinzione permette di gestire meglio riposizionamenti automatici, funzioni di accessibilità, sessioni remote e altri scenari nei quali il cursore cambia coordinate per decisione del sistema. La release aggiunge inoltre wl_fixes.ack_global_remove, richiesta progettata per coordinare la rimozione dei global ed evitare race condition tra server e client. Un global rappresenta un’interfaccia esposta dal compositore attraverso il registry; quando viene rimosso mentre il client sta ancora elaborando eventi correlati, possono verificarsi comportamenti non deterministici. Il nuovo meccanismo consente di confermare esplicitamente la gestione dell’evento, rendendo più robusta la sincronizzazione. Questi interventi proseguono il percorso descritto nella guida all’architettura Wayland e al superamento dei limiti di X11, dove sicurezza, isolamento e controllo del compositore rappresentano i principi strutturali del protocollo.

Socket rimovibili e timestamp più leggibili aiutano gli sviluppatori

La funzione wl_display_remove_socket_fd permette di rimuovere un file descriptor precedentemente registrato con wl_display_add_socket_fd, offrendo ai server un controllo più preciso sulla gestione dinamica dei socket. La novità può risultare utile nei compositori avviati in ambienti complessi, nei sistemi embedded, nei test automatizzati e nelle configurazioni che creano o disattivano endpoint Wayland durante l’esecuzione. Wayland 1.26 aggiorna inoltre i timestamp di WAYLAND_DEBUG al formato HH:MM:ss.xxxxxx, facilitando il confronto tra i messaggi del protocollo e i log prodotti da kernel, systemd, driver grafici o applicazioni. Il cambiamento appare marginale per l’utente finale, ma riduce il tempo necessario per ricostruire problemi di input, rendering e sincronizzazione. La release include anche chiarimenti nella documentazione e correzioni che riducono ambiguità per gli sviluppatori di client e compositori. Il progetto mantiene così una strategia incrementale: invece di alterare continuamente il protocollo principale, introduce primitive specifiche e compatibili con l’infrastruttura esistente. Un percorso già visibile con Wayland 1.24 e le nuove API destinate agli ambienti GNOME e Linux.

Weston 16 corregge perdite di memoria e problemi del backend DRM

Insieme al protocollo è stato pubblicato Weston 16, il compositore di riferimento utilizzato per validare implementazioni, backend e nuove funzionalità Wayland. La release corregge una perdita di memoria in drm_process_layoutput, un errore nell’inizializzazione del backend DRM in drm_pending_state_apply_sync e una leak nella stringa di descrizione creata da gl_shader_scope_new_subscription. Sebbene Weston non rappresenti il desktop utilizzato direttamente dalla maggior parte degli utenti, conserva un ruolo importante per sviluppatori, produttori hardware e sistemi embedded. Offre un ambiente controllato nel quale verificare il comportamento del protocollo, testare backend grafici e riprodurre problemi senza la complessità di un desktop completo come GNOME o KDE Plasma. Le correzioni sul backend DRM migliorano soprattutto l’affidabilità nei sistemi che comunicano direttamente con il sottosistema grafico del kernel, mentre gli interventi sulle allocazioni evitano consumi progressivi durante sessioni o test prolungati.

Linux evolve tra revisione automatizzata e maturità del desktop moderno

La posizione di Torvalds e il rilascio di Wayland 1.26 riguardano livelli diversi dell’ecosistema, ma condividono un approccio pragmatico. Nel kernel, un nuovo strumento viene giudicato in base alla capacità di trovare bug senza interferire con responsabilità e processo di revisione. Nel desktop, il protocollo grafico evolve attraverso correzioni circoscritte che migliorano affidabilità, debug e controllo delle risorse. Per le distribuzioni, Wayland 1.26 arriverà progressivamente attraverso i repository, mentre compositori e toolkit potranno adottare le nuove API in base ai propri cicli di sviluppo. Per i maintainer del kernel, Sashiko resta un supporto opzionale e non un revisore autonomo. Linux continua quindi ad assorbire tecnologie nuove senza rinunciare ai propri criteri fondamentali: codice verificabile, responsabilità dei contributori, interoperabilità e miglioramenti tecnici misurabili.