Ginux : avec l’IA, le fondateur de CentOS crée en 11 jours un noyau Rust compatible Linux

Onze jours, une seule tâche confiée à un agent IA et environ 139 000 lignes de code conservées à la fin des travaux. Et surtout à la clé Ginux, un noyau écrit en Rust capable d'exécuter des programmes Linux... sans noyau Linux. Derrière ce projet, on retrouve Gregory Kurtzer, le fondateur de CentOS et de Rocky Linux.

Le nom de Gregory Kurtzer ne vous dit rien ? Et pourtant, il est à l'origine de deux distributions Linux phares : CentOS, puis de Rocky Linux, lancé après la fin de CentOS Linux décidée par Red Hat. Aujourd'hui rattaché à CIQ, il a présenté Ginux sur X.

Voici comment s'est déroulée la construction de Ginux. Gregory Kurtzer a défini l'architecture, les contraintes, les jalons et les critères d'acceptation. Puis, il a lancé une tâche persistante avec OpenAI Codex pour accomplir cette mission en s'appuyant sur le modèle GPT-5.6 Sol. L'IA a donc réalisé un ensemble de tâches : implémentation, compilation, démarrage, tests, diagnostic et corrections. Selon lui, c'est ce qu'il appelle la méthode Human-Directed Agentic Engineering (HDAE) et la présente dans un rapport technique de 13 pages publié sur Zenodo.

Alors pourquoi ce nom, Ginux, s'il n'y a pas de lien avec le noyau Linux ? Ginux mélange Linux, GPT et Greg. Tout simplement. Ginux se présente sous la forme d'un noyau codé en Rust, avec à la clé un ensemble de 139 000 lignes de code.

Ginux, un noyau indépendant qui parle le langage de Linux

Ginux n'est pas une distribution Linux de plus. Il s'agit d'un noyau indépendant pour l'architecture x86-64, qui démarre directement via UEFI et qui fournit lui-même ses briques essentielles : gestion de la mémoire, ordonnanceur, modèle de processus, système de fichiers virtuel, pile réseau et prise en charge des périphériques. Linux n'est ici qu'une « personnalité » exposée aux applications.

Voici quelques caractéristiques à propos du prototype actuel de Ginux :

• Une image unique : le noyau, le contrôleur d'administration et les composants de démarrage sont regroupés dans un seul fichier GINUX.EFI. Le contrôleur tourne en espace utilisateur (ring 3).

• Des applications Linux non modifiées : certains programmes Alpine Linux (musl et BusyBox) et Rocky Linux (glibc) fonctionnent tels quels. Ginux parvient même à démarrer un espace utilisateur Rocky Linux 10 avec systemd (y compris avec multi-user.target).

• Une compatibilité partielle : sur les 375 appels système de l'interface Linux 6.12 x86-64, 82 sont implémentés complètement, 245 partiellement et 48 sont refusés volontairement.

• Des domaines isolés : les charges de travail tournent dans des « domaines », chacun avec ses propres processus, espaces d'adressage, systèmes de fichiers et capacités. Les images OCI servent seulement à fournir le système de fichiers, l'exécution et l'isolation relevant de Ginux.

Pour le moment, les tests se font en machine virtuelle QEMU, via KVM sur un hôte Linux x86-64 ou en émulation sur un Mac Apple Silicon. Le code est disponible sous licence Apache 2.0 sur GitHub. La matrice de compatibilité avec Linux est présentée en détail sur cette page.

Un prototype de recherche, pas un remplaçant de Linux

On est encore loin du but, et il est important de bien parler de prototype. Ginux ne sait faire tourner qu’une partie des programmes Linux, il n’a été validé que dans une machine virtuelle. Le projet est honnête sur ce point, notamment car tous les tests ne passent pas encore.

Du côté des performances, il y a tout de même des informations intéressantes publiées dans un document de benchmark qui compare Ginux et Rocky Linux. Les tests ont été effectués dans les mêmes conditions : une machine virtuelle QEMU (1 vCPU et 2 Gio de RAM), en émulation sur un Mac Apple Silicon, avec le même binaire sysbench.

Au démarrage, Rocky Linux 10 sur Ginux atteint la cible multi-user.target en 12,9 secondes (médiane), contre 42,6 secondes avec le noyau Linux, soit 3,3 fois plus vite. Sauf que Ginux ne charge ni second noyau ni initramfs et restaure un système de fichiers déjà en cache : la comparaison n'est pas équitable. Sous sysbench, les résultats sont proches : 15,2 % de mieux pour Ginux sur le CPU, 8,7 % de moins sur la consommation mémoire et 1,2 % de mieux sur les threads. Et ils reviennent de loin.

Mais bon, avant de parler de performances, Gregory Kurtzer estime qu'il faudra refaire ces mesures sur un hôte Linux x86-64 avec KVM, les multiplier et ajouter des tests réseau, stockage et IPC. Et aussi, avec une version plus aboutie.

Il rappelle aussi que la valeur de Linux tient moins à son code qu’à son écosystème. “Le code est relativement facile. Ce qui est difficile, ce sont les workflows, la compatibilité, la maintenance et la communauté.”, écrit-il. Gregory Kurtzer s'est bien amusé et il estime le coût de cette expérience à environ 8 000 dollars d'appels API. Mais pour l'heure, cela ne reste qu'une démonstration : à suivre !

Qu'en pensez-vous ?

Ajouter IT-Connect à mes
sources préférées

Cofondateur d'IT-Connect et Microsoft MVP "Cloud and Datacenter Management". Mon obsession depuis près de 15 ans ? Rendre l'administration système et la cybersécurité accessibles, que vous soyez junior ou confirmé. Plus qu'un métier, l'IT est pour moi une véritable passion. J’accompagne au quotidien les sysadmins et les professionnels de l’IT dans leur montée en compétences et leur veille technique.