Storia del kernel Linux: le decisioni che durano

La storia in breve del kernel Linux

La storia del kernel Linux va dalla versione 0.01 del settembre 1991 alla serie 7.x, avviata oggi sui server. L’elenco delle release è la parte meno interessante. Un numero ridotto di decisioni ne ha definito la struttura e ciascuna produce ancora conseguenze su una macchina che noleggi oggi pomeriggio. Il motivo per cui nel 1991 fosse necessario un nuovo kernel appartiene a una storia più ampia di Unix, delle licenze AT&T e della causa legale che bloccò BSD.

Le date e i numeri di versione riportati qui provengono da kernel.org e dalla cronologia delle release pubblicata dal progetto. Situazione aggiornata ad agosto 2026: la versione 7.0 è arrivata il 12 aprile 2026, la 7.1 il 14 giugno 2026 e la 7.2 è disponibile come release candidate.

Perché la scelta della GPL nel 1992 conta ancora

La versione 0.01 è stata pubblicata il 17 settembre 1991 con una licenza scritta dallo stesso Torvalds. La licenza richiedeva la distribuzione del codice sorgente e aggiungeva una clausola ancora più importante: "Non è possibile distribuire questo software a pagamento, nemmeno addebitando i costi di gestione." Nel 1991 il software veniva distribuito su floppy disk, e copiare e spedire floppy disk aveva un costo. Questa clausola rendeva impossibile una distribuzione commerciale di Linux.

Torvalds cambiò licenza. Il passaggio alla GNU General Public License (GPL) fu annunciato nelle note di rilascio della versione 0.12 nel gennaio 1992 ed entrò in vigore il 1 febbraio 1992. La versione 0.95, pubblicata nel marzo 1992, fu la prima release distribuita con questa licenza. Ogni attività commerciale costruita in seguito su Linux si basa su questo cambiamento.

Il kernel è distribuito esclusivamente con GPL version 2 e non è mai passato alla versione 3. Nel 2007 Torvalds rifiutò il passaggio, soprattutto a causa della regola anti-tivoisation della GPLv3, che impone a un dispositivo che distribuisce codice GPL di accettare anche una copia modificata dello stesso codice. Considerava l'hardware bloccato una scelta commerciale del produttore. Nel 2017 gli sviluppatori del kernel pubblicarono il Kernel Enforcement Statement, che riprende comunque un elemento della GPLv3: chi corregge una violazione dopo essere stato informato conserva la licenza, invece di perderla definitivamente alla prima violazione.

Su un server ne derivano due conseguenze. Il binario del kernel avviato dal sistema garantisce il diritto di ottenere il codice sorgente corrispondente, quindi nessuno può fornirti un kernel Linux che non puoi esaminare o ricompilare. Inoltre, l'avviso di copyright del kernel specifica che la licenza non copre i programmi utente che usano i servizi del kernel tramite le normali system call. Per questo database proprietari e agenti di monitoraggio vengono distribuiti per Linux senza violare la licenza. Una licenza permissiva crea la pressione opposta, e comprendere questa differenza è utile prima di scegliere una piattaforma: consulta Linux e FreeBSD come piattaforme server.

Perché il kernel monolitico ha prevalso nella pratica

Il 29 gennaio 1992, Andrew Tanenbaum pubblicò nel newsgroup comp.os.minix un messaggio intitolato "LINUX is obsolete". Sosteneva due tesi. I kernel monolitici, in cui driver e filesystem vengono eseguiti nello stesso spazio di indirizzi privilegiato, erano un'architettura degli anni 1970. I microkernel, in cui questi componenti vengono eseguiti come processi ordinari, erano il futuro. Inoltre Linux era strettamente legato a Intel 386 e quindi non sarebbe mai stato portabile su altre architetture.

La tesi sulla portabilità fu smentita dai porting. La versione 1.2, nel marzo 1995, aggiunse Alpha, SPARC e MIPS. La versione 2.0, nel giugno 1996, aggiunse un porting a 64 bit per Alpha.

La tesi progettuale fu affrontata con un compromesso. Linux non diventò mai un microkernel. Furono introdotti i moduli caricabili del kernel: file oggetto che si inseriscono in un kernel in esecuzione e si rimuovono successivamente, così un driver può essere distribuito separatamente dal binario del kernel.

lsmod | head
modinfo virtio_net | head -5

lsmod elenca ciò che è caricato in questo momento. modinfo stampa il file da cui proviene il modulo e i parametri che accetta. Su un server virtuale, gran parte del supporto per disco e rete è costituito da moduli. Per questo una singola immagine del kernel può avviarsi su hardware che non ha mai rilevato. Il kernel segnala soltanto la presenza del nuovo hardware. Un demone in user space decide quale modulo caricare e quale nome assegnare al dispositivo. È così che la gestione dei dispositivi è entrata nel sistema init e anche uno dei motivi per cui systemd è diventato difficile da evitare.

I moduli offrirono questa flessibilità senza il costo associato alla progettazione dei microkernel. Isolare un driver in un processo separato richiede un context switch e l'invio di un messaggio a ogni chiamata. Nel 1992 questo costo era elevato.

Il costo che Linux ha mantenuto è quello da considerare nella pianificazione: un modulo viene eseguito con privilegi completi del kernel. Un modulo difettoso può quindi arrestare l'intera macchina, invece di compromettere un solo processo. Il problema è particolarmente evidente con i moduli out-of-tree. Un driver del fornitore che non fa parte del mainline deve essere ricompilato per ogni nuovo kernel. È questo che DKMS fa durante un upgrade. Se la compilazione non riesce, dopo il riavvio il dispositivo semplicemente non è disponibile.

Perché SMP ha richiesto quindici anni

Linux 2.0, rilasciato nel giugno 1996, è stato il primo kernel a supportare il multiprocessing simmetrico (SMP), cioè l'esecuzione dello stesso kernel su più CPU. La prima implementazione usava un unico lock, il big kernel lock (BKL), quindi un solo processore alla volta poteva eseguire codice del kernel. Una seconda CPU apportava quindi vantaggi ai carichi di lavoro che eseguivano calcoli nello spazio utente, ma incideva molto poco sui carichi costituiti da system call, perché queste venivano accodate dietro lo stesso lock.

La rimozione di quel lock ha richiesto quindici anni. Gli ultimi punti in cui veniva usato sono stati convertiti al locking fine-grained, soprattutto da Arnd Bergmann, e il BKL è stato eliminato in 2.6.39, rilasciato il 18 maggio 2011. Anche lo scheduler si è evoluto con la stessa lentezza: lo scheduler O(1) in 2.6.0, il Completely Fair Scheduler (CFS) a partire da 2.6.23 nel 2007 e EEVDF, che ha sostituito CFS nella versione 6.6 nell'ottobre 2023.

Questo lavoro spiega perché oggi un piano con 4 vCPU sia del tutto normale. Indica anche un limite importante da conoscere. Su un server virtuale condiviso, il kernel pianifica l'esecuzione dei thread e l'hypervisor pianifica l'esecuzione del kernel. Esegui top e leggi il campo %st. Lo steal time è il tempo di CPU che il kernel era pronto a utilizzare, ma che l'host ha assegnato a un altro guest; nessuna ottimizzazione all'interno del kernel può recuperarlo.

Perché la serie 2.6 ha cambiato il modo in cui viene compilato il kernel

Prima della 2.6, i numeri di versione erano organizzati in coppie. Un secondo numero pari indicava una serie stabile (2.4), mentre un numero dispari indicava una serie di sviluppo (2.5). La versione 2.4 è stata rilasciata il 4 gennaio 2001 e la 2.6 il 17 dicembre 2003, quindi gli utenti hanno atteso quasi tre anni per la serie stabile successiva. Le distribuzioni non potevano aspettare e quindi facevano il backport delle modifiche. Due vendor che distribuivano entrambi la versione "2.4" potevano fornire kernel distanti tra loro migliaia di patch.

La separazione è stata abbandonata dopo la 2.6. Ora il mainline apre una merge window di circa due settimane, integra il nuovo lavoro, quindi pubblica release candidate finché il codice non si stabilizza e rilascia una nuova versione ogni 9-10 settimane, secondo la cadenza ancora documentata su kernel.org. L'altra metà del modello è arrivata il 4 marzo 2005 con il primo rilascio dello stable tree: un aggiornamento che conteneva solo correzioni per la versione 2.6.11, mantenuto da Greg Kroah-Hartman e Chris Wright. Lo stable tree integra le correzioni e rifiuta le funzionalità.

Una conseguenza è che il numero di versione ha smesso di essere una garanzia. Le versioni 3.0, 4.0, 5.0 e 7.0 non sono riscritture complete. Torvalds incrementa il primo numero quando il secondo cresce abbastanza da infastidirlo; per questo la versione 7.0 ha seguito la 6.19 nell'aprile 2026. Per un server conta quale ramo segue la distribuzione e se quel ramo riceve ancora correzioni.

Come la crisi di BitKeeper ha portato alla nascita di git nell'aprile 2005

A partire da febbraio 2002, il kernel fu sviluppato in BitKeeper, un sistema proprietario di controllo versione distribuito dell'azienda BitMover di Larry McVoy, iniziando dalla serie 2.5. BitMover concesse agli sviluppatori del kernel una licenza gratuita, ma a determinate condizioni: non si poteva lavorare a uno strumento di controllo versione concorrente e non si poteva effettuare il reverse engineering di BitKeeper. Molti sviluppatori non apprezzavano il fatto di sviluppare un kernel libero con uno strumento il cui codice non potevano esaminare.

La collaborazione si interruppe nell'aprile 2005, dopo che Andrew Tridgell dimostrò un programma in grado di comunicare con i repository BitKeeper. BitMover lo considerò reverse engineering e ritirò la licenza gratuita. Il kernel rimase senza sistema di controllo versione nel pieno di un ciclo di sviluppo.

Il lavoro su git iniziò il 3 aprile 2005. Torvalds lo annunciò il 6 aprile. Il 7 aprile git era già self-hosting, cioè la sua cronologia veniva già mantenuta in git. Il primo merge di più branch fu eseguito il 18 aprile. Nel giugno 2005, git gestì la release di 2.6.12. Poco dopo Torvalds affidò la manutenzione a Junio Hamano e tornò a occuparsi del kernel.

Il design derivò direttamente dal problema: migliaia di contributori e maintainer che eseguono il pull gli uni dagli altri attraverso una rete di cui nessuno si fida. Ogni oggetto è denominato tramite l'hash del proprio contenuto, quindi la modifica di un solo byte nella cronologia precedente cambia il nome di ogni commit successivo. Per questo un clone costituisce una prova, non una dichiarazione. Ogni pipeline di deploy, ogni repository di configurazione, l'hosting del codice su cui esegue il push la maggior parte dei team e il server git che puoi gestire autonomamente sono nati da una disputa sulla licenza riguardante un kernel.

Cosa garantisce il modello LTS e cosa invece non garantisce

Non si esegue una release mainline. Una release mainline viene sostituita dopo 9-10 settimane. Il ramo stable riceve correzioni per alcune settimane dopo ogni release. I rami longterm, generalmente indicati come LTS, ricevono correzioni per anni. Sono questi i rami su cui si basano le distribuzioni.

La versione 2.6.32, rilasciata a dicembre 2009, ha dimostrato la validità del modello. RHEL 6, Debian 6, SUSE Linux Enterprise 11 SP1 e Ubuntu 10.04 LTS la includevano nei propri rilasci. Il ramo è stato mantenuto fino a febbraio 2016, oltre sei anni dopo la sua pubblicazione. Red Hat si è spinta oltre e ha mantenuto il proprio kernel basato su 2.6.32 con backport autonomi fino alla fine di RHEL 6 nel 2020. Riprodurre gratuitamente quel decennio di supporto è il motivo per cui è esistito CentOS e Rocky Linux e AlmaLinux lo hanno sostituito.

La durata del supporto è cambiata più di una volta. Inizialmente era di due anni, poi è diventata di sei anni per alcuni rami. Nel 2023 i maintainer di stable hanno riportato la durata predefinita a due anni, perché il backporting nei rami più vecchi richiede tempo ai maintainer e i rami obsoleti ricevono pochi test reali. Il 25 febbraio 2026 Greg Kroah-Hartman ha pubblicato nuovamente proiezioni più lunghe, dopo aver discusso con le aziende che dipendono da questi rami. Il framework attuale prevede una durata compresa tra tre e sei anni.

[
  {
    "kernel": "5.10",
    "released": "2020-12-13",
    "eol_projected": "Dec 2026",
    "maintained_for": 6.0
  },
  {
    "kernel": "5.15",
    "released": "2021-10-31",
    "eol_projected": "Dec 2026",
    "maintained_for": 5.1
  },
  {
    "kernel": "6.1",
    "released": "2022-12-11",
    "eol_projected": "Dec 2027",
    "maintained_for": 5.0
  },
  {
    "kernel": "6.6",
    "released": "2023-10-29",
    "eol_projected": "Dec 2027",
    "maintained_for": 4.2
  },
  {
    "kernel": "6.12",
    "released": "2024-11-17",
    "eol_projected": "Dec 2028",
    "maintained_for": 4.1
  },
  {
    "kernel": "6.18",
    "released": "2025-11-30",
    "eol_projected": "Dec 2028",
    "maintained_for": 3.1
  }
]

kernel.org elenca 6 rami longterm ad agosto 2026. Il più vecchio, 5.10, avrà ricevuto correzioni per 6.0 anni quando terminerà in Dec 2026. Il più recente, 6.18, dovrebbe restare in uso fino a Dec 2028, per un totale di 3.1 anni di correzioni.

Considerate queste date come una durata minima, non come un impegno contrattuale. Le proiezioni per 6.6 e 6.12 sono state entrambe estese a febbraio 2026, ma un ramo che nessuno utilizza può essere eliminato. In genere è la distribuzione a scegliere per voi: Debian 13 include 6.12 e Ubuntu 26.04 LTS include 7.0. Questa differenza costituisce il contenuto pratico di la scelta tra LTS e release intermedia su un server ed è ciò che cambia realmente sotto il sistema quando si esegue l'upgrade da Ubuntu 24.04 a 26.04.

Da qui deriva un possibile equivoco. uname -r su Ubuntu 24.04 stampa qualcosa come 6.8.0-51-generic. Il valore indica una base upstream a cui si aggiungono i backport della distribuzione. Il numero mostra quindi da quale ramo è iniziato il kernel, non quali correzioni contiene. Gli scanner che valutano un kernel in base alla stringa della versione generano falsi allarmi proprio per questo motivo sui kernel delle distribuzioni.

Cosa sta discutendo il kernel in questo momento

Sono in corso due discussioni, entrambe incentrate su chi debba svolgere il lavoro.

Rust è entrato nell'infrastruttura del kernel con la versione 6.1, nel dicembre 2022. Nella versione 7.0 è stata rimossa l'etichetta sperimentale. I linguaggi principali del kernel sono quindi C, assembly e Rust, e la compilazione non richiede più un compilatore nightly. La controversia riguarda la manutenzione. Un maintainer del codice C che modifica un'interfaccia può rompere i binding Rust che non conosce. La discussione riguarda chi debba occuparsi di correggerli.

La seconda discussione riguarda i contributi generati con l'AI. Sasha Levin ha proposto una policy nel luglio 2025, dopo che un numero crescente di patch assistite da strumenti automatici aveva raggiunto le mailing list. Il documento è stato inserito il 23 dicembre 2025 nella documentazione dei processi del kernel, all'indirizzo docs.kernel.org/process/coding-assistants.html. Un agente AI non deve aggiungere un tag Signed-off-by, perché quella riga certifica il Developer Certificate of Origin (DCO) e solo una persona può rilasciare tale certificazione. L'assistenza viene dichiarata con un tag Assisted-by:, modificato da Co-developed-by: durante la revisione perché uno strumento non è un autore. Il codice generato deve essere compatibile con GPL-2.0-only. La persona che invia la patch la revisiona e ne assume la responsabilità.

La pressione alla base della policy riguarda il tempo necessario per la revisione. Generare una patch richiede pochi secondi, mentre revisionarla può occupare un intero pomeriggio del maintainer. Un tag non elimina questo squilibrio. Mantiene però la provenienza del codice: la cronologia continua a registrare chi ha firmato ogni modifica. È proprio questa la proprietà che il DCO è stato introdotto per tutelare nel 2004.

Cosa significa questa storia per il server che noleggi

• La licenza spiega perché puoi leggere e ricompilare il kernel avviato dal provider e perché il software proprietario continua a funzionare su di esso.
• Il design monolitico spiega perché un bug in un driver riavvia l'intera macchina e perché un modulo esterno all'albero dei sorgenti deve essere ricompilato a ogni aggiornamento del kernel.
• Il modello di rilascio spiega perché il numero di versione fornisce poche informazioni, mentre il ramo e la relativa data di fine del supporto indicano quasi tutto.
• Il tipo di virtualizzazione determina ciò che puoi fare: con KVM avvii il tuo kernel e carichi i moduli, mentre nella virtualizzazione basata su container, che condivide il kernel dell'host, uname -r mostra la versione dell'host, modprobe non riesce e diversi sysctl sono di sola lettura.

FAQ

Perché il kernel Linux è ancora GPLv2 e non GPLv3?

Torvalds ha escluso GPLv3 nel 2007, soprattutto a causa del requisito anti-tivoisation, che impone a un dispositivo che distribuisce codice GPL di accettare anche una versione modificata dello stesso codice. Considera l'hardware bloccato una scelta commerciale del produttore. Anche il relicensing è quasi impossibile nella pratica, perché il copyright del kernel appartiene a migliaia di contributori e non esiste un accordo di cessione a cui fare riferimento. Il kernel è disponibile esclusivamente con GPL-2.0-only, quindi il codice offerto soltanto con GPLv3 non può essere integrato.

Il kernel Linux è monolitico o microkernel?

È monolitico, con moduli caricabili. I driver e i filesystem vengono eseguiti nello spazio degli indirizzi del kernel e lsmod mostra quelli caricati in questo momento. Da un lato questo garantisce prestazioni elevate, dall'altro amplia il raggio d'azione dei guasti: un modulo difettoso può mandare in panic l'intera macchina, mentre un microkernel perderebbe un solo processo. Il modello si è parzialmente evoluto dal 1992, grazie ai filesystem FUSE nello spazio utente e ai programmi eBPF che il kernel verifica prima di eseguirli.

Qual è la differenza tra kernel mainline, stable e longterm?

Il ramo mainline è l'albero di Torvalds, con una nuova versione ogni 9-10 settimane; le nuove funzionalità vengono integrate prima al suo interno. Il ramo stable parte dall'ultima versione mainline e riceve correzioni di bug per alcune settimane. I rami longterm continuano a ricevere correzioni per anni e sono quelli su cui le distribuzioni basano i propri kernel. kernel.org elenca i rami longterm attuali con la data prevista di fine supporto per ciascuno.

Il kernel Linux accetta codice scritto dall'AI?

Sì, secondo una policy adottata nel dicembre 2025. Lo strumento deve essere indicato in un tag Assisted-by:, un agente AI non deve aggiungere una riga Signed-off-by e il codice generato deve essere compatibile con GPL-2.0-only. Il contributore umano appone la propria firma, dichiarando di aver esaminato la patch e di assumersene la responsabilità in base al Developer Certificate of Origin.

Quale versione del kernel dovrei usare su un server?

Nella quasi totalità dei casi, quella mantenuta dalla tua distribuzione. Il kernel della distribuzione è un ramo longterm con correzioni retroportate e test eseguiti dal fornitore; inoltre, è quello previsto dalle immagini del provider e dagli accordi di supporto. Compila un kernel mainline più recente quando ti serve un driver o una funzionalità specifica e, prima di adottarlo, controlla la data di fine supporto del ramo verso cui stai migrando.