Nel ciclo di sviluppo di Linux 7.3, le modifiche a char/misc approdate questa settimana raccontano due storie diverse. La prima è prevedibile: il solito ricambio di driver IIO e gli aggiornamenti ai driver Google Binder. La seconda è più rivelatrice: il kernel continua a eliminare driver hardware datati, l'ultimo dei quali è un vecchio driver IBM che si aggiunge ai driver SGI ritenuti insicuri. Dietro la pulizia c'è una pressione nuova: l'eccesso di segnalazioni di bug e patch generate da LLM.

Il punto non è solo che quei driver sono obsoleti o senza utenti attivi sul kernel mainline. È che il costo di mantenerli sta cambiando. Ogni driver morto che resta nell'albero diventa un bersaglio per correzioni automatiche di bassa qualità, costringendo i maintainer a spendere tempo per distinguere contributi utili da rumore. In questo contesto, la rimozione diventa razionale: meno codice non aggiornato, meno superficie da revisionare, meno segnalazioni spurie da gestire.

Per chi gestisce infrastrutture on-premise con cicli di vita lunghi, questo è un segnale strutturale. Il supporto mainline non è una garanzia statica: è un processo con soglie di attenzione che cambiano. Se un'azienda ha ancora in produzione macchine con driver IBM o SGI di quella generazione, la rimozione dal kernel mainline significa che dovrà mantenere patch fuori dall'albero, pagare un supporto esteso o migrare prima del previsto. In tutti i casi il TCO sale, e la scelta di restare su hardware datato diventa più costosa.

C'è anche una questione di fiducia. Le patch generate da LLM non sono necessariamente errate; molte sono plausibili ma banali, altre richiedono contesto che un modello non possiede. Per i manutentori di driver obsoleti, il volume di contributi deboli è un costo nascosto che non appare in nessun changelog. L'effetto di secondo ordine è che la selezione del codice da mantenere non dipende più solo dall'utilità tecnica, ma anche dalla quantità di rumore che quel codice attrae. I driver con pochi utenti e molte segnalazioni automatiche diventano i primi candidati all'eliminazione.

Chi ci guadagna? I maintainer, che riducono il carico di revisione; i venditori di hardware più recente, che vedono accelerare l'obsolescenza; e chi usa solo componenti moderni. Chi ci perde? Gli operatori di laboratori, impianti industriali o centri di ricerca con apparecchi legacy, e le comunità che mantengono varianti di nicchia del kernel. Il messaggio strutturale è che l'automazione generativa, applicata alla manutenzione del software, può paradossalmente aumentare il lavoro umano invece di ridurlo, perché il costo di triage supera il beneficio della quantità.

Per chi pianifica deployment on-premise con orizzonti di cinque o dieci anni, questo episodio ricorda che il software di sistema non è un costo una tantum. È un impegno continuo di manutenzione, e le decisioni su quale hardware e quale kernel adottare andrebbero valutate anche in base alla probabilità che il supporto upstream sopravviva all'obsolescenza. AI-RADAR offre su /llm-onpremise un framework analitico per confrontare i trade-off tra manutenzione autonoma e dipendenza dai canali upstream, senza ridurre tutto alla sola convenienza immediata.