La manutenzione di un kernel monolitico come Linux è un atto di equilibrio continuo: integrare nuove funzionalità senza appesantire il codice con componenti che nessuno usa più. Con la versione 7.2, gli sviluppatori hanno affondato il bisturi in un driver che affonda le radici in un’epoca preistorica dell’informatica: il supporto per PROFIBUS, il bus di campo nato nell’automazione industriale degli anni Novanta. Il codice incriminato era stato importato da SCO Unix nel 1998 e, da allora, non aveva più ricevuto aggiornamenti significativi. Nessun utente attivo è stato identificato sulle versioni moderne del kernel, e così il driver è finito nel tritacarte insieme ad altri due componenti obsoleti eliminati nel sottosistema char/misc.

Una tecnicia che ha fatto la storia dell’industria

PROFIBUS (Process Field Bus) è un protocollo di comunicazione seriale standardizzato a livello internazionale, ampiamente utilizzato per collegare sensori, attuatori e controllori logici programmabili (PLC) nelle fabbriche. Sviluppato alla fine degli anni Ottanta e ratificato come standard EN 50170, ha dominato per decenni gli impianti manifatturieri. La sua presenza nel kernel Linux era un retaggio di quando il sistema open source iniziava a essere adottato come alternativa embedded anche nell’industria pesante. Ma il driver specifico in questione, quello per schede di rete PROFIBUS, è rimasto fermo al codice di oltre venticinque anni fa, incapace di adattarsi alle moderne interfacce del kernel e senza sviluppatori disposti a mantenerlo.

Pulizia necessaria per la salute del kernel

La comunità Linux ha meccanismi ben rodati per decidere l’obsolescenza: un driver senza manutenzione, privo di utenti noti che utilizzano rami attuali del kernel, viene contrassegnato per la rimozione dopo un periodo di preavviso. Il caso di PROFIBUS è emblematico perché coniuga due fattori: codice vecchissimo e nessun segnale di vita dal mondo reale. Non si tratta di un capriccio, ma di una misura di igiene che riduce la superficie d’attacco (codice non controllato può nascondere vulnerabilità latenti) e alleggerisce il lavoro dei maintainer, che devono garantire la compatibilità con le nuove versioni del kernel. Ogni riga di codice rimossa è una riga che non va testata, revisionata e adattata a cambiamenti architetturali.

Cosa significa per chi gestisce macchine on-premise

Nei contesti industriali e negli ambienti on-premise, dove spesso sopravvivono macchine con una decade o più di servizio, l’eliminazione di driver legacy può creare attriti. Chi ancora utilizza hardware PROFIBUS su Linux si trova di fronte a un bivio: restare ancorato a kernel datati (magari customizzati), isolare la macchina dalla rete, o migrare a soluzioni più recenti come PROFINET. È il tipico trade-off tra stabilità operativa e aggiornamento tecnicico che ogni responsabile infrastruttura conosce. Da un lato c’è il costo e il rischio di toccare un sistema che funziona, dall’altro la necessità di ricevere patch di sicurezza e poter aggiornare il sistema operativo. La notizia della rimozione, pur passando inosservata ai più, è un campanello d’allarme per chi pianifica la longevità dei propri impianti: monitorare il supporto upstream dei driver usati non è un optional.

L’evoluzione del kernel e le lezioni per l’on-prem

Linux 7.2 non sarà ricordato per questa singola epurazione, ma ogni potatura contribuisce a mantenere il kernel sano e longevo. Per il mondo on-premise — non solo industriale ma anche data center privati, edge computing e ambienti air-gapped — il messaggio è chiaro: le dipendenze da componenti hardware orfani di manutenzione sono un debito tecnico che prima o poi va saldato. Chi valuta deployment locali dovrebbe includere nel Total Cost of Ownership anche il rischio di abbandono dei driver, scegliendo hardware con supporto upstream attivo e timeline di manutenzione note. Allo stesso modo, per chi eredita infrastrutture esistenti, conviene eseguire audit periodici delle componenti kernel utilizzate, sfruttando strumenti di analisi della configurazione per individuare moduli a rischio. Non si tratta solo di sicurezza: è una strategia di sovranità tecnicica, dove la capacità di aggiornare e controllare lo stack software dipende anche dalla vivacità del supporto della comunità.

La rimozione del driver PROFIBUS è una piccola nota nelle lunghe release notes del kernel, ma racconta una storia più grande: la disciplina open source sa quando è il momento di voltare pagina, anche a costo di lasciare indietro qualche pezzo di archeologia informatica. Per chi costruisce il futuro dell’IT on-premise, è un promemoria a non dare nulla per scontato.