Tutte le volte che Linus Torvalds ha blastato la community Linux

Linus Torvalds, creatore del kernel Linux, è una delle figure più iconiche del panorama informatico moderno. Oltre ad essere l’architetto di uno dei progetti open source più influenti della storia, Torvalds è anche noto per il suo carattere tagliente e per la franchezza brutale con cui si è spesso rivolto alla community. Dai thread infuocati sulle mailing list a dichiarazioni pubbliche che hanno fatto scalpore, Torvalds ha “blastato” — ossia criticato duramente, a volte con sarcasmo, a volte con rabbia — collaboratori, aziende e decisioni progettuali in più di un’occasione.

In questo articolo analizzeremo i casi più eclatanti in cui Linus ha messo a ferro e fuoco la community, ma anche il contesto tecnico dietro le sue invettive, cosa lo ha spinto a reagire in quel modo e come il progetto Linux ne è uscito, nel bene o nel male.

Il “f*** you” a NVIDIA: l’esempio della frustrazione per l’hardware closed-source

Dopo anni e anni, a giugno 2025 Bill Gates e Linus Torvalds si sono incontrati e hanno cenato insieme. In passato, però, il clima non era così gioviale.

Nel 2012, ad esempio, durante un evento organizzato dall’Università di Aalto, uno studente chiese a Torvalds perché i driver NVIDIA su Linux non funzionassero correttamente. La sua risposta fu un inequivocabile e ormai indimenticabile “NVIDIA, f*** you!”, accompagnato dal dito medio.

Torvalds accusava NVIDIA di non collaborare con la community Linux, preferendo soluzioni binarie closed-source, come il modulo proprietario nvidia.ko, rifiutandosi di lavorare su nouveau, driver open source. Questo andava contro la filosofia di Linux di interoperabilità e trasparenza del kernel-space.

Anni dopo, NVIDIA ha iniziato a pubblicare versioni open source dei suoi moduli kernel, ma all’epoca dei fatti la situazione aveva fatto letteralmente inalberare Torvalds. In particolare, a maggio 2022, NVIDIA ha iniziato a cambiare approccio, rilasciando i primi moduli kernel GPU open source (driver R515) con doppia licenza GPL e MIT, inizialmente per GPU da datacenter e con supporto sperimentale per GeForce e Workstation.

Da allora, la società di Jensen Huang ha lavorato per estendere la compatibilità e migliorare le prestazioni dei moduli open source, raggiungendo nel 2024-2025 un livello tale da poterli consigliare come soluzione principale per molte GPU recenti. Con il driver R560, NVIDIA ha annunciato la completa transizione ai moduli kernel open source per le GPU Turing, Ampere, Ada Lovelace, Hopper e per le piattaforme avanzate come Grace Hopper e Blackwell.

La questione dei driver binari (proprietari)

Torvalds ha sempre difeso con forza la libertà di usare codice proprietario, pur preferendo le soluzioni open source. Questo lo ha messo in rotta con i puristi della Free Software Foundation (FSF), compreso Richard Stallman.

Nel 2006, a chi lo accusava di “favorire il software non libero” rispose che egli non si occupava delle “guerre di religione”. A lui interessavano le cose pratiche, ad esempio il fatto che una scheda WiFi funzionasse correttamente su Linux. Già dieci anni prima, per mettere da parte sua fine alla polemica sull’uso del termine GNU/Linux, Torvalds sosteneva come non gli interessasse la nomenclatura, finché si dà credito a chi lo merita.

Torvalds ha spiegato che accetta moduli binari quando questi non derivano da lavoro specifico sul kernel Linux, ma sono portati da altri sistemi: in questi casi non si può richiedere la licenza GPL. Tuttavia, non supporta moduli binari che sono chiaramente derivati dal kernel, per i quali la GPL si applica pienamente

Anche se non si tratta di un “blast” diretto, quella di Torvalds fu una posizione che infuocò il dibattito sulla filosofia GNU vs Linux, che ancora oggi divide la community.

GCC e gli insulti agli sviluppatori del compilatore

Nel 2012, Torvalds criticò pesantemente un cambiamento introdotto in GCC (il compilatore usato per costruire il kernel), definendo alcune modifiche “idiote” e “totalmente inutili”.

Linus criticava soprattutto i comportamenti del compilatore che rompevano funzionalità usate nel kernel Linux, come la gestione dei bitfield e il modello di memoria. Così, Torvalds ha  dichiarato pubblicamente di voler considerare l’uso di Clang/LLVM come alternativa, per migliorare la modularizzazione e la portabilità del kernel.

Systemd: un’accoglienza glaciale

All’introduzione di systemd, init system adottato da molte distribuzioni, Torvalds non si è opposto frontalmente, ma ha manifestato profonde perplessità.

Le critiche di Torvalds riguardavano soprattutto l’approccio monolitico del progetto systemd, in contrasto con la tradizione UNIX di “doing one thing well”. Inoltre, lamentava l’intrusività di systemd nel ciclo di boot, nel logging (journald) e nella gestione degli utenti e sessioni, considerandolo un “tentativo di reimplementare l’intero userspace“.

In più occasioni, Torvalds ha criticato l’approccio del team Systemd come “invasivo” e “arrogante”. Per tutta risposta, Lennart Poettering – ideatore di Systemd – ha risposto accusando Torvalds di avere un comportamento “cattivo” e di essere un cattivo esempio per la comunità open source, sottolineando come l’atteggiamento aggressivo di Torvalds abbia addirittura contribuito a un clima di odio e minacce personali nei suoi confronti. Poettering ha messo in relazione questo clima con il modo in cui Torvalds e il suo gruppo di sviluppatori gestivano la comunicazione, caratterizzata da linguaggio duro e mancanza di moderazione.

Torvalds, da parte sua, ha mostrato poco interesse per i problemi personali di Poettering e ha difeso il proprio stile diretto e a volte rude come efficace per la gestione della comunità di sviluppo. In un altro articolo abbiamo visto, ad esempio, quante parolacce ci sono nel sorgente del kernel Linux.

L’attacco a Kay Sievers

Nel 2014, Linus Torvalds ha espresso una dura critica pubblica a Kay Sievers, uno dei principali sviluppatori di systemd, a causa di un problema tecnico legato all’uso del parametro di avvio “debug”. Sievers aveva suggerito ai sviluppatori del kernel di non usare il termine generico “debug” perché systemd e il kernel Linux usavano entrambi quella parola chiave, causando un eccesso di messaggi di log che potevano impedire il boot del sistema.

Torvalds si è infuriato perché Sievers non aveva corretto il problema nel suo codice, costringendo il kernel a dover aggirare il problema. In un messaggio sulla mailing list del kernel, Torvalds non le ha mandate a dire e ha aggiunto che non avrebbe accettato ulteriori patch da Sievers finché non avesse modificato il suo comportamento.

Le “merge window” e gli sviluppatori negligenti (secondo Torvalds)

Ogni versione del kernel Linux ha una “merge window” di due settimane subito dopo una release stabile, durante la quale Torvalds e “i suoi” accettano nuovi commit ossia proposte di nuove correzioni. Torvalds ha spesso criticato gli sviluppatori che inviano patch fuori tempo massimo o con modifiche non testate.

Nel 2013, ad esempio, il “re pinguino” attaccò lo sviluppatore Mauro Carvalho Chehab sostenendo che non avesse neppure testato una patch da lui inviata. Torvalds rimproverò Chehab per non aver appreso la “prima regola della manutenzione del kernel“, ovvero che il kernel non deve rompere lo spazio utente con codice “totalmente scadente“. Dopo aver rincarato la dose, Torvalds concluse che Chehab avrebbe dovuto “correggere il suo approccio alla programmazione del kernel“.

Torvalds è estremamente attento alla qualità del codice e all’integrità del kernel. Non tollera commit mal formattati, con regressioni o con documentazione assente. Lavorare nel kernel richiede una disciplina da ingegnere di sistema di basso livello.

Una situazione molto simile si è venuta a creare a inizio giugno 2025 quando Torvalds ha reagito con toni accesi a una serie di commit sbagliati sul kernel Linux. “Questo è inaccettabile!“, ha tuonato contro Kees Cook (area sicurezza e mitigazioni). Successivamente si è potuto verificare che il problema è scaturito da un meccanismo di scripting difettoso.

GNOME 3: “un disastro” per l’usabilità

Torvalds non è stato tenero nemmeno con gli sviluppatori del desktop environment GNOME, in particolare rispetto alla release 3.0.

L’inventore del kernel Linux criticava la rimozione di funzionalità considerate essenziali per l’uso quotidiano, l’abbandono del paradigma desktop tradizionale, e la mancanza di personalizzazione. Tornò temporaneamente a Xfce per protesta. Alcune distribuzioni mantennero GNOME 2 o passarono a MATE. Negli anni, GNOME è migliorato, ma la spaccatura ha lasciato il segno.

Safe language, safe code? Blast, poi parzialmente corretto, per i sostenitori di Rust

Con l’introduzione sperimentale di codice in linguaggio Rust nel kernel Linux a partire dal 2022, alcuni membri della community hanno enfatizzato i benefici della sicurezza della memoria.

Torvalds ha inviato un’osservazione sferzante sostenendo di fatto che egli non è contrario a Rust nel kernel, ma si oppone alla narrativa secondo cui C sarebbe intrinsecamente insicuro. Per l’informatico finlandese, il problema è la mancanza di rigore nella scrittura e revisione del codice, non il linguaggio in sé.

Rust è stato quindi integrato con cautela nel kernel del pinguino. La posizione di Torvalds ha inizialmente raffreddato l’entusiasmo di alcuni “Rust evangelist”, ma ha stabilito un chiaro perimetro: Rust nel kernel va bene, purché si mantenga la compatibilità, la leggibilità e la manutenzione del codice nel lungo termine.

A febbraio 2025, Torvalds ha detto che il codice Rust va inserito nel kernel Linux, invitando a farla finita con le polemiche. Nonostante le resistenze di alcuni sviluppatori, Torvalds batte forte i pugni sul tavolo e insiste: il supporto a Rust non è facoltativo. Il linguaggio, grazie alle sue garanzie in termini di sicurezza della memoria, promette di prevenire bug comuni nei driver, anche se l’integrazione con C comporta nuove sfide tecniche. Il dibattito resta acceso, ma la direzione è chiara: Rust sarà sempre più parte del futuro del kernel.

L’esplosione del 2018 e la “pausa per imparare l’empatia”

Nel 2018, Torvalds annunciò una pausa dal mantenimento del kernel per “lavorare sul modo con cui interagisce con le persone“, dopo anni di linguaggio violento e, spesso, attacchi personali. Il numero uno di Linux riconobbe che il suo approccio, seppur efficace per garantire rigore tecnico, era spesso dannoso per la collaborazione. La riflessione portò all’adozione di un nuovo Code of Conduct nel progetto Linux.

Quel momento segnò una svolta culturale: pur mantenendo il rigore tecnico, in seno al kernel Linux si adottò un linguaggio più professionale e meno aggressivo. Torvalds tornò al timone della sua “creature” dopo poche settimane, visibilmente più misurato.

Gli attacchi a Intel per Meltdown e Spectre

Nel 2018, a seguito della scoperta delle vulnerabilità Meltdown e Spectre, Linus fu durissimo con Intel, colpevole — secondo lui — di aver ignorato la sicurezza per anni.

In una discussione sulla gestione delle patch per mitigare gli attacchi side-channel nei processori, Torvalds definì le patch di Intel come “COMPLETE AND UTTER GARBAGE” (completamente e assolutamente spazzatura) e le accusò di fare “cose letteralmente folli” (“literally insane things“).

Torvalds criticò in particolare il fatto che Intel avesse reso opzionale l’attivazione della mitigazione a livello di boot, cosa che a suo avviso non aveva senso dato che la vulnerabilità era grave, e che alcune parti delle patch fossero ridondanti rispetto a soluzioni già esistenti come la tecnica “retpoline” di Google. Inoltre, Torvalds si domandò se Intel avesse intenzione di rendere queste soluzioni una caratteristica architetturale permanente, definendo tale idea “una follia” e invitando gli ingegneri Intel a parlarne con i loro manager.

Questa uscita provocò un terremoto mediatico, ma anche una maggiore pressione su Intel per risolvere seriamente il problema. In generale, comunque, Torvalds ha espresso molte riserve (per usare un eufemismo) quando alcuni sviluppatori proponevano patch che, secondo lui, degradavano le prestazioni in nome della sicurezza.

Con ciò, Torvalds non intendeva ovviamente minimizzare gli aspetti legati alla sicurezza, ma rifiutava l’idea di implementare ogni mitigazione senza un’analisi costi-benefici.

Torvalds contro i livelli di microarchitettura: il kernel non ha bisogno di astrazioni arbitrarie

A dicembre 2024, con un nuovo intervento diretto e senza mezzi termini, Linus Torvalds ha criticato duramente una proposta per il kernel Linux che prevedeva l’adozione di livelli di microarchitettura (come v1, v2, v3…) per classificare le capacità dei processori x86-64. Secondo Torvalds, tale classificazione — introdotta dal mondo user-space e in particolare dalla glibc — non ha alcuna utilità pratica per il kernel e rischia solo di introdurre confusione.

A suo avviso, è più corretto e robusto basarsi sui bit CPUID, che descrivono in modo preciso e tecnico le reali funzionalità della CPU. L’approccio proposto, per Torvalds, non solo è superfluo ma persino dannoso, perché complica inutilmente un sistema già ben funzionante.

L’inventore del kernel Linux ha ricordato inoltre che molte ottimizzazioni pensate per vecchie architetture non sono più rilevanti, suggerendo di puntare a build generiche e flessibili, evitando così scelte obsolete.

DRM: “quel codice è disgustoso!”

Il 29 marzo 2025, Torvalds ha criticato aspramente il codice hdrtest introdotto nel sottosistema DRM del kernel 6.15. Perdendo ancora una volta la pazienza, ha definito le modifiche disgustose e inutili in quanto rallentavano le compilazioni e lasciavano un’infinità di file temporanei.

Nonostante avesse già sollevato il problema in passato, il codice non è stato modificato: di conseguenza, Torvalds ha marcato hdrtest come “broken“, escludendolo temporaneamente dalla compilazione standard.

Nel contesto del kernel Linux, DRM non ha nulla a che vedere con il Digital Rights Management (gestione dei diritti digitali). Si riferisce invece al sottosistema per la gestione dell’accesso diretto all’hardware grafico, come GPU e display controller; all’accelerazione hardware di grafica 2D/3D; alla gestione della memoria video; alla sincronizzazione delle immagini a schermo; alla comunicazione tra kernel e user space per operazioni grafiche avanzate.

DRM fornisce un’interfaccia standard e sicura per i driver grafici, ed è la base tecnica su cui si appoggiano Mesa (implementazione open source di OpenGL/Vulkan), Wayland e X11, KMS (Kernel Mode Setting) per gestire le risoluzioni e i monitor direttamente dal kernel.

Conclusioni

Linus Torvalds ha incarnato, sin dagli albori di Linux, una visione del software fondata sull’efficienza, la qualità del codice e una comunicazione priva di filtri. I suoi “blast” non sono semplici sfoghi emotivi, ma atti di difesa verso l’integrità di un progetto che oggi alimenta miliardi di dispositivi.

Se da un lato il suo stile ha generato tensioni, attriti personali e polemiche pubbliche, dall’altro ha spesso portato a riflessioni tecniche necessarie e a cambiamenti concreti. Nel tempo, la community ha imparato – spesso a caro prezzo – che dietro ogni invettiva di Torvalds si cela quasi sempre una motivazione tecnica fondata. Il suo approccio resta divisivo, ma è anche uno degli elementi che ha reso Linux ciò che è oggi: un ecosistema robusto, pragmatico e in costante evoluzione.