Un programme Linux qui tourne sans noyau Linux : voilà la démonstration recherchée par Gregory Kurtzer avec Ginux. Le fondateur de CentOS et de Rocky Linux présente un noyau indépendant, principalement écrit en Rust, développé avec l’aide de l’IA. Son expérience annoncée de onze jours a produit un prototype public, dont les limites sont aussi intéressantes que la vitesse de réalisation.
Le dépôt public décrit un système expérimental. Il ne se présente ni comme une distribution Linux prête à installer sur son PC principal, ni comme un remplaçant immédiatement utilisable au quotidien.
Ginux fait tourner certains programmes Linux avec son propre noyau
Une distribution assemble habituellement un noyau Linux et les logiciels nécessaires autour de lui. Ginux tente une autre approche : réimplémenter les mécanismes de base, puis fournir aux applications une interface suffisamment compatible avec celle qu’elles attendent.
Le noyau est la partie du système qui gère notamment la mémoire, les processus et les échanges avec le matériel. La compatibilité ne se résume donc pas à afficher un bureau ressemblant à Linux. Elle dépend du comportement des appels que les programmes adressent au système.
Dans sa documentation publique, Ginux indique pouvoir exécuter une sélection de programmes Alpine et Rocky Linux sans modification. Il décrit aussi un démarrage de l’environnement utilisateur Rocky Linux 10 jusqu’à une étape de fonctionnement en mode multi-utilisateur. Cette démonstration porte sur des configurations précises, pas sur l’ensemble des logiciels de ces distributions.
L’IA écrit du code dans un cadre défini par un développeur
Gregory Kurtzer présente le travail comme une expérience d’ingénierie dirigée par un humain. L’architecture, les contraintes et les critères de réussite orientent le travail de l’agent ; l’implémentation est ensuite confrontée à des tests. Le récit des onze jours est une affirmation de l’auteur sur cette expérience, et non une mesure générale du temps nécessaire pour produire un système fiable.
C’est un écart essentiel pour juger le résultat. Générer rapidement une quantité importante de code ne démontre pas que chaque comportement est correct. Un logiciel système doit aussi résister aux erreurs, protéger les processus les uns des autres et gérer des périphériques qui ne se comportent pas toujours comme prévu.
Un dépôt consultable rend au moins ces choix examinables. D’autres développeurs peuvent regarder l’architecture, les tests et les limites déclarées, plutôt que de s’en remettre à une vidéo de démarrage ou à un nombre de lignes.
Le premier terrain d’essai est une machine virtuelle
La cible de développement documentée est un environnement x86-64 virtualisé, avec une configuration matérielle définie. C’est un cadre utile pour reproduire une démonstration, mais beaucoup plus restreint que la diversité des ordinateurs personnels.
Le projet signale lui-même une couverture incomplète du matériel, des systèmes de fichiers, du réseau et de la compatibilité Linux. La validation de la sécurité reste également inachevée. Le statut de prototype constitue donc une limite d’usage explicite, pas un simple avertissement ajouté par précaution.
Une application compatible n’implique pas que toutes le soient
Ginux s’appuie sur une couche de compatibilité avec l’interface binaire de Linux, souvent abrégée ABI. Elle cherche à reproduire ce qu’un programme attend du système : créer un processus, accéder à un fichier, réserver de la mémoire ou communiquer avec un périphérique. Deux logiciels peuvent solliciter des parties très différentes de cette interface.
Faire fonctionner un programme donné constitue donc un résultat observable, sans prouver la compatibilité d’une distribution entière. Le démarrage d’un environnement texte et le fonctionnement d’un poste graphique complet ne demandent pas non plus les mêmes composants.
Le projet organise ses charges dans des environnements appelés domaines, avec leurs propres processus et ressources. Cette architecture est documentée, mais son isolement et sa validation restent incomplets. Pour un lecteur qui découvre le projet, le bon terrain d’observation est la configuration virtuelle décrite par l’auteur, où les résultats peuvent être comparés à ses démonstrations.
Ginux rend cette expérience examinable : le code, les tests et les limites sont publics. Le défi suivant est moins spectaculaire qu’un premier démarrage, mais autrement exigeant : garder les programmes compatibles et les données protégées au fil des usages.
Eric Thomas suit l’actualité de Windows, des logiciels, de la cybersécurité grand public et des outils web. Il s’intéresse aux mises à jour système, aux nouveautés informatiques et aux solutions pratiques qui améliorent l’expérience numérique au quotidien.
