Rust is Going to Save Us Says Linux Kernel Number 2 Guy
Cette vidéo analyse les récentes présentations de Greg Kroah-Hartman (mainteneur en second du noyau Linux) et du vice-président d’Ubuntu, qui poussent à l’adoption massive de Rust dans l’écosystème Linux, tout en pointant les risques techniques et stratégiques de...
SYNTHÈSE STRUCTURÉE
Greg Kroah-Hartman et la vision Rust pour le noyau
L’intervenant principal, Greg Kroah-Hartman, a présenté à la conférence Rust NL une keynote intitulée « Linux : How Rust is going to save us ». Selon l’auteur de la vidéo, le discours n’a pas clairement identifié ce dont Rust sauverait Linux : « It wasn’t really clear exactly what Linux would be saved from. » La présentation s’est concentrée sur l’énorme travail de création de bindings et de code de colle pour permettre l’écriture de drivers en Rust, sans démontrer de bénéfice concret.
Deux approches divergentes chez les développeurs
L’auteur distingue deux courants : d’un côté, des développeurs C qui, voyant les idées intéressantes de Rust (gestion mémoire, fonctions de déchargement), les ont simplement implémentées en C : « They implemented those sorts of things in C and boom, it’s done. Not in Rust. » De l’autre, des développeurs Rust qui exigent que les codeurs C créent des bindings pour faciliter l’intégration, sous peine d’être jugés « mauvais ».
Aucun bug critique résolu par Rust
Malgré l’ajout de plus de 100 000 lignes de code Rust dans le noyau, l’auteur note qu’aucun problème spécifique n’a été corrigé : « Not fixing anything in particular, not any new features, just it’s Rust now. » Les arguments de sécurité mémoire sont jugés trop généraux et non étayés par des exemples concrets de bugs évités.
La déclaration finale de Kroah-Hartman
La présentation s’est conclue par l’affirmation que « Rust is more fun for maintainers and more secure for Linux users. We need more Rust Linux developers. » L’auteur souligne que l’audience, majoritairement composée de développeurs Rust, a accueilli ce message avec enthousiasme, mais que cela reste une fraction infime du noyau.
Une approche prudente : pas de réécriture massive
Un point positif relevé : Kroah-Hartman a précisé que l’objectif n’est pas de réécrire tout le code C existant, mais uniquement d’écrire du nouveau code en Rust. L’auteur compare cela à la démarche d’Ubuntu, qui a remplacé les coreutils GNU par des réécritures Rust non testées : « Throwing out the good code and replacing it with untested code. That’s terrifying. »
Le problème du support des architectures par le compilateur Rust
L’auteur insiste sur un obstacle technique majeur : le compilateur Rust (un seul fonctionnel) ne supporte pas un grand nombre des plateformes que Linux couvre actuellement. Cela réduit la portabilité, l’un des points forts historiques de Linux : « That takes away from some of the strength that Linux has had over the years is its massive portability. »
La complexité des bindings multi-langages
L’ajout de Rust dans le noyau implique de maintenir des bindings entre C et Rust, ce qui augmente la taille et la complexité du code sans ajouter de fonctionnalités. L’auteur qualifie cette approche de « bizarre » et prédit qu’elle « shackles Linux in an unnecessary way ».
La position d’Ubuntu : Rust par défaut, sans excuses
Le vice-président de l’ingénierie d’Ubuntu a présenté à Rust Nation UK une stratégie agressive : remplacer les coreutils GNU (ls, cp, mv, etc.) par des réécritures Rust, avec des bugs assumés. Citation : « We were just going to do it by default with no apology. » Il a également ordonné à ses équipes d’arrêter d’écrire en Python et de se concentrer sur Rust.
La menace de l’IA générative dans le noyau
L’auteur alerte sur l’arrivée massive de correctifs générés par IA dans le noyau Linux, avec « hundreds and hundreds of Linux kernel patches just filled with AI generated code ». Il prédit que Linux pourrait être « vibe codé » d’ici la fin de l’année, combinant Rust et IA dans une approche risquée.
Le scénario d’une fork C pur
L’auteur envisage une scission inévitable : d’un côté, un noyau Linux en C pur avec des outils GNU éprouvés ; de l’autre, un noyau « Rust AI vibecoded » avec des utilitaires réécrits. Il pose la question : « How long before there’s a pure C fork of the Linux kernel? »
CONCEPTS CLÉS
- Bindings : Code de colle permettant à du code Rust d’interagir avec des fonctions C existantes. Dans le noyau, cela ajoute une couche de complexité sans apporter de nouvelles fonctionnalités.
- Vibe coding : Terme désignant l’écriture de code généré automatiquement par IA, sans contrôle humain rigoureux. L’auteur l’utilise pour critiquer l’afflux de correctifs non vérifiés.
- Coreutils : Ensemble de programmes de base (ls, cp, mv, rm, etc.) fournis par GNU. Leur remplacement par des réécritures Rust est présenté comme un risque de régression.
- Portabilité : Capacité d’un système à fonctionner sur différentes architectures matérielles. Le support limité du compilateur Rust menace cet avantage historique de Linux.
CONCLUSION
Le message principal est que l’adoption de Rust dans le noyau Linux et l’écosystème Ubuntu est poussée par des considérations idéologiques plutôt que techniques, sans bénéfice démontré et au prix d’une complexité accrue, d’une perte de portabilité et d’un risque de régressions. L’auteur met en garde contre une transition forcée qui pourrait fragmenter la communauté Linux entre un noyau C éprouvé et un noyau Rust/IA non testé. Pour un administrateur système, cela signifie qu’il faut surveiller attentivement les versions des outils système et du noyau, et envisager de conserver des alternatives C stables si la fiabilité est critique.