Ginux: Kurtzer guida un kernel 'non Linux' compatibile con l'ABI Linux

In 11 giorni, Gregory Kurtzer ha presentato Ginux, un nuovo kernel scritto per lo più da un agente di intelligenza artificiale e capace di eseguire binari Linux grazie all’implementazione dell’ABI di Linux¹.

Kurtzer è noto nell’ecosistema: ha creato CentOS, ha avviato Rocky Linux come sostituto comunitario dopo le scelte di Red Hat e ha co-fondato CIQ, l’azienda che offre supporto enterprise per Rocky¹. Il progetto attuale non riguarda una distribuzione, ma il cuore del sistema operativo.

Ginux nasce come kernel indipendente, orientato a Rust e mirato all’architettura x86-64¹. Il codice non deriva da Linux. I principali sottosistemi arrivano da una base propria: gestione della memoria, scheduler, modello di processo, filesystem, rete e supporto ai dispositivi sono stati implementati da zero¹. La scelta impostata su Rust punta a un linguaggio moderno e tipizzato. Il dettaglio rilevante qui è l’autonomia del design, con componenti che si parlano senza ereditare interfacce storiche del kernel Linux.

La compatibilità con l’ecosistema esistente si ottiene a livello binario. Ginux espone l’ABI di Linux, l’interfaccia che i programmi compilati usano per dialogare con il kernel. Per l’utente questo significa poter avviare gli stessi eseguibili, senza ricompilare né modificare. Nelle parole del progetto, Linux è una “personalità” che Ginux espone, non il kernel sottostante¹. Il modello ricorda uno strato di compatibilità, ma qui l’interfaccia è parte del kernel stesso. La promessa è di far girare software Linux su un nucleo differente, mantenendo inalterata la superficie di chiamate di sistema.

Il ritmo di sviluppo iniziale è stato insolito. Kurtzer non ha scritto la maggior parte del codice. Un agente AI ha generato gran parte dell’implementazione, con l’obiettivo di assemblare rapidamente i sottosistemi di base e di arrivare a una compatibilità concreta con lo spazio utente Linux¹. Il ruolo umano resta nella guida, nelle scelte architetturali e nella verifica. L’agente, invece, accelera la stesura e l’integrazione delle parti.

Lo stato attuale è sperimentale. Ginux gira solo dentro una macchina virtuale QEMU. Non c’è un profilo di hardware fisico supportato. Mancano il supporto a GPU e a NVMe. Non risulta alcun audit di sicurezza indipendente¹. Chi prova oggi si muove quindi in un ambiente controllato, utile per test di compatibilità e per validare i sottosistemi di base. La mancanza di driver e di verifiche terze limita l’uso a scopi produttivi, ma chiarisce dove intervenire.

La scelta di inseguire l’ABI di Linux chiarisce la destinazione d’uso: eseguire lo spazio utente Linux su un kernel nuovo, scollegato dal codice di Torvalds. Se l’ABI resta allineata, il parco software disponibile rimane ampio. Se l’ABI diverge, la compatibilità si incrina. È un vincolo progettuale preciso, che però offre un percorso di adozione senza ricompilazioni.

Qui si apre il tema pratico: far uscire Ginux dalla VM, portarlo su hardware reale e colmare le lacune di driver e audit. Finché resta in QEMU, l’interesse principale è per chi vuole misurare l’idea di “personalità” Linux su un kernel distinto. L’equilibrio tra velocità garantita dall’AI e controllo ingegneristico deciderà quanto in fretta arriveranno supporto a GPU, storage moderno e verifiche di sicurezza, i tre tasselli che oggi mancano e che separano un prototipo da un sistema operativo spendibile¹.