La notizia che Linux 7.3 eliminerà i driver per vecchie schede Silicon Graphics (SGI) potrebbe sembrare il solito sfoltimento di hardware ormai archeologico. Ma il contesto in cui matura è tutto fuorché ordinario. Da un lato, la motivazione ufficiale parla di "preoccupazioni di sicurezza": codice non manutenuto che diventa superficie d'attacco. Dall'altro, la manutenzione stessa del kernel è oggi sotto pressione per un fenomeno inedito: il rumore generato dagli agenti di coding basati su LLM, che inondano le mailing list di patch di bassa qualità o irrilevanti. I driver SGI sono l'ultimo esempio di una potatura che non dipende solo dall'obsolescenza tecnica, ma da una ridefinizione strutturale di ciò che il kernel può sostenere.

Il primo ordine di conseguenze è chiaro: chi utilizza ancora hardware SGI in ambienti di produzione on-premise—tipicamente laboratori, sistemi industriali o infrastrutture di calcolo legacy—dovrà scegliere se congelare il kernel, esporsi a vulnerabilità note o migrare a hardware più recente. Ma è il secondo ordine a essere più rivelatore. La comunità dei maintainer sta reagendo alla valanga di contributi generati automaticamente restringendo la propria tolleranza verso tutto il codice che non ha un custode attivo. Non conta più solo se un driver "funziona": se non c'è qualcuno che lo verifica e lo aggiorna con costanza, viene etichettato come rischio e rimosso. L'AI non è solo uno strumento per scrivere codice migliore; sta indirettamente innalzando lo standard di ciò che resta nel kernel, accelerando il declino di qualsiasi componente non presidiata.

Questo crea un paradosso per le organizzazioni che fanno della sovranità dei dati e del controllo on-premise un pilastro operativo. Da sempre il fascino di Linux risiede nella capacità di far rivivere hardware datato, riducendo i costi di sostituzione e garantendo cicli di vita estesi. Se il kernel diventa più aggressivo nel rimuovere codice, l'effetto a lungo termine è una spinta verso l'hardware più recente, con benefici evidenti per i produttori di silicio ma costi nascosti per chi pianifica ammortamenti su 10-15 anni. È un segnale strutturale: il software libero non è immune dalla pressione di un ecosistema che, spinto dall'AI, premia la manutenibilità istantanea rispetto alla stabilità di lungo periodo.

C'è poi la questione della fiducia. I maintainer sono sempre più sommersi da patch che sembrano sensate ma nascono da un prompt piuttosto che da una reale comprensione del sottosistema. Il rischio di "hallucination" tecniche è alto, e il tempo speso a filtrare rumore si somma a quello già scarso per gestire il codice storico. La rimozione dei driver SGI—giustificata da vulnerabilità reali o potenziali—potrebbe diventare una leva più facile da azionare quando il backlog di revisione è intasato da contributi sintetici. Non è un atto ostile, ma una conseguenza sistemica: meno occhi umani disponibili, meno spazio per ciò che non è immediatamente verificabile.

Per chi valuta deployment on-premise, lo scenario impone qualche riflessione. Mantenere fork del kernel con driver critici diventa più probabile, ma porta con sé l'onere della manutenzione indipendente. Oppure si accelera la migrazione verso hardware più moderno, magari con schede acceleratrici per LLM, spostando il problema su un diverso ciclo di aggiornamento. Non esistono risposte semplici, ma il caso SGI mostra che il kernel non è più un museo inerte del passato: è un ecosistema sotto stress, dove le decisioni di oggi sono plasmate da forze—come l'AI generativa—che fino a ieri non facevano parte dell'equazione.