Du code « jetable »
Gregory Kurtzer, créateur de CentOS et Rocky Linux, a créé un noyau compatible Linux, nommé Ginux. Loin d’être une proposition concrète, le projet était surtout une expérience : était-il possible de proposer un noyau compatible principalement développé par IA ?
L’expérience fait parler d’elle depuis plusieurs jours. Gregory Kurtzer est loin d’être un inconnu, il est connu pour avoir créé CentOS, une distribution Linux 100 % compatible avec Red Hat Enterprise Linux (RHEL), dont elle est une reconstruction. Apparue en 2003, CentOS attire l’attention, jusqu’à ce que Red Hat commence à sponsoriser la distribution en 2014. Dans les années suivantes, Red Hat embauche progressivement les développeurs travaillant sur CentOS, jusqu’à récupérer la gestion du projet.
Décembre 2020, patatras : Red Hat met fin à CentOS et pousse Stream, sa variante conçue pour intégrer les nouveautés. Le positionnement est alors clair : Fedora pour son aspect laboratoire, CentOS Stream pour intégrer les nouveautés en vue d’une utilisation professionnelle, RHEL pour l’offre commerciale. Gregory Kurtzer, frustré par le nouveau positionnement de Red Hat, crée alors Rocky Linux, à nouveau une reconstruction de RHEL, avec la même compatibilité complète.
Alors quand le développeur annonce avoir créé un noyau compatible Linux, développé avec l’IA, le sujet attire l’attention. Mais pas toujours pour les « bonnes » raisons.
Un noyau compatible, pas un fork
Le projet Ginux est surtout une expérience. Il la présente sur X le 27 octobre comme « un nouveau noyau de système d’exploitation compatible avec Linux qui démarre Rocky Linux 10 avec systemd, le tout en utilisant l’ingénierie agentique dirigée par l’humain (HDAE) ».
Le noyau est conçu pour l’architecture x86-64 et est indépendant. Il ne s’agit pas d’un fork du noyau actuel. Le code utilisé est principalement écrit en Rust. Ginux propose sa propre gestion mémoire, son processus de démarrage, son ordonnanceur, son modèle de processus, ses systèmes de fichiers, son réseau, ses périphériques et sa couche de compatibilité Linux.
Sa particularité est d’implémenter l’interface binaire (ABI) de Linux afin de faire tourner les exécutables Linux existants, sans modification. Gregory Kurtzer indique que cette compatibilité est partielle : sur 375 appels système recondensés dans l’ABI Linux 6.12 en x86-64, 82 sont entièrement implémentés, 245 le sont partiellement et 48 sont refusés volontairement.
Dans l’architecture choisie par le développeur, les charges de travail sont réparties dans des environnements nommés « domaines ». Chacun dispose de ses processus, espaces d’adressage, systèmes de fichiers, points de montage, privilèges et cycle de vie. Il présente ces frontières comme plus marquées que les espaces de noms Linux et les conteneurs OCI (Open Container Initiative).
Des limites assumées
Gregory Kurtzer affirme que son projet a pris 11 jours. Il tâche de rester « humble » dans l’annonce en précisant plusieurs points. D’abord, le nom Ginux fait référence aussi bien à Greg qu’à GPT. Dans le README du projet sur GitHub, l’auteur plaisante : pour s’assurer que son égo reste contenu, le G est officiellement une référence à GPT, puisque le projet a été entièrement réalisé avec GPT-5.6 Sol.
En outre, Ginux ne fonctionne pour l’instant qu’au sein d’une machine virtuelle QEMU. Il n’y a donc ni profil matériel physique, ni support des GPU et disques NVMe, ni audit de sécurité indépendant. Le code est publié sous licence Apache 2.0 comme prototype de recherche.
Le développement cible principalement QEMU/KVM avec une configuration x86-64 Q35, et le dépôt documente aussi une exécution en émulation QEMU sur Apple Silicon. Kurtzer reconnaît que la couverture ABI est incomplète et le matériel peu pris en charge. Réseau, systèmes de fichiers, application des limites de ressources et sécurité demandent encore un travail décrit comme « considérable ».
Dans la méthode HDAE évoquée, c’est lui-même qui a fixé l’architecture, les contraintes, les jalons et les critères d’acceptation. L’agent, lui, menait la boucle d’implémentation : il était chargé d’écrire, démarrer, tester, diagnostiquer, corriger, recommencer face à des vérifications exécutables. C’est l’ensemble de ces actions qui ont alimenté une tâche unique confiée à GPT-5.6 Sol, produisant finalement 139 000 lignes de code et de tests, réparties sur un millier de validations Git environ.
Une expérience, pas un concurrent
En quelques jours, le projet a généré une attention croissante. Face à un nombre croissant de questions sur la possibilité que Ginux puisse concurrencer le noyau Linux, Gregory Kurtzer est intervenu le 29 octobre pour expliquer que « les gens passent à côté du but de Ginux » et que ce dernier n’a pas été conçu pour rivaliser avec Linux : « Ce serait idiot ! ».
Il considère le code produit comme jetable, car Ginux en tant que tel n’était pas le but de l’expérience. Il s’agissait bien du processus de création, c’est-à-dire confier à un agent un travail de longue haleine, guidé par une infrastructure, pour répondre à la question : « L’IA, dirigée par un ingénieur expérimenté, pouvait-elle construire et valider un système logiciel extraordinairement complexe ? ».
Il répète d’ailleurs que l’article de recherche documente la méthodologie, les résultats et les limitations, pas le noyau comme possibilité alternative. Il estime que les questions posées sur la méthode sont plus intéressantes que le résultat. Par exemple : « Combien de temps faut-il pour reproduire un problème, identifier la cause racine, implémenter une correction et valider le résultat ? Quelle intervention humaine est réellement requise ? ».
« Parce que la vraie question n’a jamais été de savoir si l’IA pouvait remplacer Linux. Même si elle peut remplacer certains aspects de sa fonction, elle ne peut pas reproduire la communauté, les normes, la collaboration, l’alignement ou la stabilité », affirme-t-il. Dans une autre publication le 30 octobre, il détaille d’ailleurs comment il a collecté les retours pour déclencher de nouveaux travaux, pour continuer à tester sa méthode.
Ginux est donc davantage une démonstration de faisabilité qu’un produit. Rien n’empêche bien sûr la communauté de s’emparer du projet et de le poursuivre. Rien ne permet d’affirmer que ce noyau alternatif, s’il était développé plus avant, offrirait des avantages concrets et mesurables par rapport au noyau Linux.
Si l’expérience a fait parler, c’est aussi parce que la question de l’IA agite largement le domaine du logiciel libre. La récente enquête publiée par Linux Foundation a montré en partie l’ampleur de ce questionnement, avec des développeurs et mainteneurs de projets dans une position ambivalente, entre abaissement du ticket d’entrée et besoins accrus de vérifier toute la production de code. Dans cette optique, l’expérience de Kurtzer donne un aperçu de ce qu’une IA, employée par un développeur expérimenté, peut accomplir quand elle est strictement encadrée.
