Storia del kernel Linux: le scelte che hanno resistito

Una breve storia del kernel Linux

La storia del kernel Linux va dalla versione 0.01, pubblicata nel settembre 1991, fino alla serie 7.x, attiva oggi sui server. L’elenco delle release è l’aspetto meno interessante. Alcune decisioni hanno definito l’architettura del kernel e continuano ad avere conseguenze su una macchina che noleggi oggi stesso.

Le date e i numeri di versione riportati qui provengono da kernel.org e dalla cronologia delle release pubblicata sul sito. 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 è nella fase delle release candidate.

Perché la scelta della GPL nel 1992 è ancora importante

La versione 0.01 è stata pubblicata il 17 settembre 1991 con una licenza scritta dallo stesso Torvalds. La licenza imponeva la distribuzione del codice sorgente e aggiungeva una clausola ancora più importante: "Non è possibile distribuirla a pagamento, nemmeno per coprire i costi di 'gestione'." Nel 1991 il software veniva distribuito su floppy disk, e la duplicazione e la spedizione dei floppy disk avevano 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 poggia su questo cambiamento.

Il kernel è distribuito esclusivamente con la GPL versione 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 di quel 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 averne ricevuto comunicazione 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. Nessuno può quindi 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 chiamate di sistema. Per questo i database proprietari e gli agenti di monitoraggio vengono distribuiti per Linux senza violare la licenza. Una licenza permissiva crea una pressione opposta. È una differenza che conviene comprendere 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, nei quali driver e filesystem vengono eseguiti all'interno di un unico spazio degli indirizzi privilegiato, erano un progetto degli anni 1970. I microkernel, nei quali questi componenti vengono eseguiti come processi ordinari, rappresentavano il futuro. Inoltre, Linux era strettamente legato a Intel 386 e quindi non sarebbe mai stato portabile su altre piattaforme.

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

La tesi sul design fu affrontata con un compromesso. Linux non diventò mai un microkernel. Introdusse invece i loadable kernel modules: file oggetto che si possono inserire in un kernel in esecuzione e rimuovere successivamente, consentendo di distribuire un driver separatamente dal file binario del kernel.

lsmod | head
modinfo virtio_net | head -5

lsmod elenca i moduli attualmente caricati. 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 è costituita da moduli. Per questo una singola immagine del kernel può avviarsi su hardware che non aveva mai rilevato.

I moduli offrivano questa flessibilità senza il costo imposto dal design 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 mantenuto da Linux è quello da considerare nella pianificazione: un modulo viene eseguito con privilegi completi del kernel. Di conseguenza, un modulo difettoso può arrestare l'intera macchina invece di un singolo 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. È questa l'operazione eseguita da DKMS durante un aggiornamento. Se la compilazione non riesce, dopo il riavvio il dispositivo è semplicemente assente.

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 era quindi utile per i carichi che eseguivano calcoli nello spazio utente, ma offriva vantaggi molto limitati per i carichi composti da system call, perché queste restavano in coda dietro allo stesso lock.

La rimozione di quel lock ha richiesto quindici anni. I punti in cui veniva ancora usato sono stati convertiti al fine-grained locking, in gran parte 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) da 2.6.23 nel 2007 ed EEVDF, che ha sostituito CFS in 6.6 nell'ottobre 2023.

Questo lavoro spiega perché oggi un piano con 4 vCPU sia del tutto normale. Indica anche un limite che è importante 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 2.4 è stata rilasciata il 4 January 2001 e la 2.6 il 17 December 2003, quindi gli utenti hanno atteso quasi tre anni per la serie stabile successiva. Le distribuzioni non potevano aspettare e hanno quindi effettuato il backport delle modifiche. Due vendor che distribuivano entrambi la versione "2.4" potevano fornire kernel separati da migliaia di patch.

La distinzione è stata abbandonata dopo la 2.6. Oggi il ramo mainline apre una merge window di circa due settimane, accetta nuovo codice, poi esegue release candidate finché lo sviluppo si stabilizza e pubblica una nuova versione ogni 9-10 settimane, secondo la cadenza ancora documentata da kernel.org. L'altra metà del modello è arrivata il 4 March 2005 con la prima release dello stable tree: un aggiornamento della 2.6.11 contenente soltanto correzioni, mantenuto da Greg Kroah-Hartman e Chris Wright. Lo stable tree accetta correzioni e rifiuta nuove funzionalità.

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

Come la rottura con BitKeeper portò alla nascita di git nell'aprile 2005

A partire da febbraio 2002, lo sviluppo del kernel avveniva in BitKeeper, un sistema proprietario di controllo versione distribuito dell'azienda BitMover di Larry McVoy, iniziando dalla serie 2.5. BitMover forniva agli sviluppatori del kernel una licenza gratuita con alcune condizioni: non si poteva lavorare a uno strumento di controllo versione concorrente e non si poteva effettuare il reverse engineering di BitKeeper. A molti sviluppatori non piaceva sviluppare un kernel libero con uno strumento di cui non era consentito esaminare il codice.

La collaborazione si interruppe nell'aprile 2005, dopo che Andrew Tridgell aveva mostrato 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 corso di un ciclo di sviluppo.

Lo sviluppo di git iniziò il 3 aprile 2005. Torvalds lo annunciò il 6 aprile. Il 7 aprile git era già self-hosting: la cronologia di git veniva quindi conservata in git. Il primo merge di più branch fu eseguito il 18 aprile. Nel giugno 2005, git gestì il rilascio della versione 2.6.12. Poco dopo, Torvalds affidò la manutenzione a Junio Hamano e tornò a occuparsi del kernel.

Il design derivava direttamente dal problema: migliaia di contributori e maintainer che eseguono pull gli uni dagli altri attraverso una rete di cui nessuno si fida. Ogni oggetto è identificato dall'hash del proprio contenuto, quindi la modifica di un solo byte nella cronologia passata cambia il nome di ogni commit successivo. Per questo un clone costituisce una prova, non una semplice dichiarazione. Ogni pipeline di deploy, ogni repository di configurazione, l'host del codice su cui la maggior parte dei team esegue il push e il server git che puoi eseguire autonomamente derivano da una disputa sulla licenza relativa a un kernel.

Cosa promette il modello LTS e cosa invece non promette

Mainline non è la versione da eseguire in produzione. 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 e sono quelli 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 l'hanno distribuita e il ramo è stato mantenuto fino a febbraio 2016, oltre sei anni dopo la sua pubblicazione.

La durata del supporto è cambiata più volte. Inizialmente era di due anni, poi è diventata di sei anni per alcuni rami. Nel 2023 i manutentori di stable hanno ridotto nuovamente il valore predefinito a due anni, perché il backport delle correzioni nei vecchi alberi richiede tempo ai manutentori e i rami meno recenti ricevono pochi test effettivi. Il 25 febbraio 2026 Greg Kroah-Hartman ha pubblicato nuovamente proiezioni più lunghe, dopo aver discusso con le aziende che dipendono da questi rami, e l'attuale modello prevede durate da tre a 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
  }
]

Ad agosto 2026 kernel.org elenca 6 rami longterm. Il più vecchio, 5.10, avrà ricevuto correzioni per 6.0 anni quando raggiungerà la fine del ciclo di vita prevista in Dec 2026. Il più recente, 6.18, dovrebbe essere mantenuto fino a Dec 2028, per un totale di 3.1 anni di correzioni.

Considera queste date come una durata minima prevista, non come un contratto. Le proiezioni per 6.6 e 6.12 sono state entrambe estese a febbraio 2026, ma un ramo che non viene utilizzato da nessuno può essere abbandonato prima. Di norma è la tua distribuzione a scegliere per te: Debian 13 distribuisce 6.12 e Ubuntu 26.04 LTS distribuisce 7.0. Questa differenza è il contenuto pratico di la questione LTS contro release intermedia su un server ed è ciò che cambia effettivamente sotto il sistema quando aggiorni Ubuntu 24.04 a 26.04.

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

Di 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 nella versione 6.1, a 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 discussione riguarda la manutenzione. Un maintainer C che modifica un'interfaccia può rompere i binding Rust che non legge, e il punto controverso è stabilire chi debba correggerli.

La seconda discussione riguarda i contributi generati con l'AI. Sasha Levin ha proposto una policy a luglio 2025, dopo che un numero crescente di patch assistite da strumenti automatici ha 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 se ne assume la responsabilità.

La pressione alla base della policy è il tempo richiesto dalla revisione. Generare una patch richiede pochi secondi, mentre revisionarla può occupare un intero pomeriggio a un maintainer. Un tag non risolve questo squilibrio. Preserva però la provenienza: la cronologia continua a registrare chi ha firmato ogni modifica, che è proprio l'informazione che il DCO è stato introdotto per tutelare nel 2004.

Cosa comporta questa storia per il server che noleggi

• La licenza consente di leggere e ricompilare il kernel avviato dal provider e spiega perché anche il software proprietario può essere eseguito su di esso.
• Il design monolitico spiega perché un bug in un driver riavvia l'intera macchina e perché un modulo esterno all'albero del kernel 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 ciclo di vita forniscono quasi tutte le informazioni necessarie.
• 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 funziona e diversi sysctl sono di sola lettura.

FAQ

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

Nel 2007 Torvalds ha deciso di non adottare GPLv3, principalmente a causa del requisito anti-tivoisation, che impone a un dispositivo che distribuisce codice GPL di accettare anche una versione modificata di quel 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 è distribuito con licenza GPL-2.0-only, quindi il codice offerto esclusivamente con GPLv3 non può essere integrato.

Il kernel Linux è monolitico o è un microkernel?

È monolitico, con moduli caricabili. I driver e i filesystem vengono eseguiti nello spazio di indirizzamento del kernel, e lsmod mostra quelli attualmente caricati. Da un lato questo offre prestazioni elevate; dall'altro aumenta il raggio d'impatto dei guasti: un modulo difettoso può causare il panic dell'intera macchina, mentre con un microkernel si perderebbe un solo processo. Dal 1992 questa distinzione si è attenuata grazie ai filesystem FUSE nello spazio utente e ai programmi eBPF che il kernel verifica prima di eseguirli.

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

Mainline è il tree di Torvalds, pubblicato ogni 9-10 settimane; le nuove funzionalità vengono introdotte prima in questo ramo. Stable parte dalla versione mainline più recente 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 relativa data prevista di fine vita.

Il kernel Linux accetta codice scritto dall'AI?

Sì, in base a 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 il sign-off, dichiarando di avere esaminato la patch e di assumerne la responsabilità secondo il Developer Certificate of Origin.

Quale versione del kernel dovrei usare su un server?

Quella mantenuta dalla tua distribuzione, nella quasi totalità dei casi. Il kernel della distribuzione è un ramo longterm con correzioni backportate e i test del vendor; è 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, verifica la data di fine vita del ramo a cui stai passando.