Ubuntu Funding Automated C to Rust Translation Research
Canonical finance un projet de recherche de 3 ans avec l’Université de Bristol pour traduire automatiquement de grands dépôts C en Rust, une décision que l’intervenant juge coûteuse, risquée et motivée par des raisons autres que la sécurité ou la stabilité.

SYNTHÈSE STRUCTURÉE
Le contexte : Canonical double la mise sur Rust
L’intervenant souligne que Canonical ne se contente pas de remplacer sudo par un clone Rust, mais qu’elle étend cette stratégie aux utilitaires GNU coreutils et finance désormais un projet de recherche dédié. Il résume : « Ils ne doublent pas, ils ne triplent pas, ils quadruplent la mise sur “réécrivons tout en Rust” ». Ce projet, mené avec l’Université de Bristol, vise à créer une plateforme capable de traduire des dépôts C de centaines de milliers de lignes en Rust « sûr, comportementalement correct et maintenable ».
La contradiction du vice-président ingénierie
L’intervenant cite John Seager, VP ingénierie d’Ubuntu, qui défend Rust pour « éliminer de nombreuses classes de défauts de sécurité mémoire ». Mais il pointe une contradiction : le même VP a remplacé du code C éprouvé par des clones Rust que les propres recherches de Canonical montrent comme « significativement moins sécurisés ». Il ajoute : « Ils ont forcé des versions avant que les bugs de sécurité déjà identifiés dans le nouveau code Rust soient corrigés ». Pour lui, l’argument sécuritaire est « du vent enveloppé dans de la crotte de porc ».
Le plaidoyer involontaire pour garder le C
L’intervenant relève que Seager décrit lui-même les qualités du code C existant : « des années de corrections de bugs, des décisions de compatibilité, des connaissances opérationnelles, des optimisations de performance durement acquises ». Il ironise : « Il fait clairement le plaidoyer pour garder le C tout en essayant de justifier son remplacement par Rust ». Cette contradiction montre que la décision n’est pas technique mais idéologique ou stratégique.
Le coût du projet : entre 50 000 et 200 000 livres
L’intervenant a cherché le montant du financement, non divulgué par Canonical. Selon le site de l’Université de Bristol, un doctorat sponsorisé coûte entre 50 000 et 100 000 livres, mais d’autres sources évoquent jusqu’à 200 000 livres. Il conclut : « Ce n’est pas des millions, mais ce n’est pas rien non plus ». Ce montant est investi dans un projet dont les bénéfices concrets restent flous.
Les clones Rust des coreutils sont immatures
L’intervenant cite un développeur de uutils (le remplaçant Rust des coreutils GNU) qui décrit son propre travail comme « tellement médiocre que je n’ai pas de mots ». Ce développeur explique que GNU timeout est « absurdement rempli de cas limites non documentés » et que la version Rust n’en couvre même pas la moitié. Il a tenté une réécriture « 10 fois depuis octobre » sans succès. Ces aveux internes contredisent l’idée que les remplacements Rust sont prêts pour la production.
Une pression croissante pour imposer Rust
L’intervenant décrit comment Canonical rend de plus en plus difficile l’utilisation des versions C : « Vous voulez installer build-essential ? On va forcer les clones Rust des coreutils à écraser les versions C ». Cette stratégie d’intégration forcée, combinée à des déclarations comme « arrêtez de coder en Python, passez tout en Rust », montre une volonté politique plus qu’une nécessité technique.
Le parallèle avec Microsoft et WSL
L’intervenant note que Microsoft adopte également les clones Rust de uutils dans Windows Subsystem for Linux (WSL), et que la croissance d’Ubuntu y est plus forte qu’en standalone. Il s’interroge : « Pourquoi tant de grandes entreprises poussent-elles si fort ? » Une hypothèse avancée : ces clones sont sous licence MIT, pas GPL, ce qui permettrait d’éviter les contraintes de la GPL. Il conclut : « C’est peut-être une raison culturelle ou religieuse, mais il y a un bon argument à faire ».
Les risques techniques sous-estimés
L’intervenant rappelle que Rust n’est pas un langage « fini » : son compilateur n’est pas finalisé et ne supporte pas toutes les plateformes où tourne Linux. Il critique le fait de remplacer du code « qui fonctionne » par des logiciels « pas encore complètement testés, écrits dans un langage pas encore terminé ». Pour lui, cette course à la réécriture ignore les leçons de décennies de développement logiciel.
CONCEPTS CLÉS
- Coreutils GNU : ensemble d’utilitaires de base (ls, cp, timeout, etc.) écrits en C, considérés comme stables et éprouvés.
- Uutils : projet de réécriture des coreutils en Rust, souvent sous licence MIT, mais jugé immature par ses propres développeurs.
- Mémoire sûre (memory safety) : propriété d’un langage qui empêche les erreurs d’accès mémoire (débordement, use-after-free), censée réduire les failles de sécurité.
- GPL vs MIT : la GPL impose de partager les modifications sous la même licence ; le MIT est plus permissif, ce qui peut intéresser des entreprises voulant éviter les obligations de la GPL.
- WSL (Windows Subsystem for Linux) : couche de compatibilité de Microsoft permettant d’exécuter des distributions Linux sous Windows.
CONCLUSION
L’intervenant dénonce une stratégie industrielle qui privilégie l’idéologie à l’ingénierie : remplacer des logiciels C matures et sécurisés par des clones Rust immatures, sans preuve de bénéfice concret. Il souligne que les propres arguments des promoteurs de Rust, comme la sécurité mémoire, sont contredits par leurs actions (publier des versions avec des bugs connus). Pour un administrateur système, la leçon est de rester critique face aux discours marketing et de vérifier la maturité réelle des outils avant de les adopter en production.