Outils pour utilisateurs
26/12/2025/H00:31:56
L'un des responsables de la maintenance du noyau Linux Rust se retire du projet, invoquant des “absurdités non techniques”
L'un des responsables de la maintenance du noyau Linux Rust se retire du projet~? invoquant des “absurdités non techniques”
L'un des responsables de la maintenance du noyau Linux Rust a annoncé se retirer du projet. La raison est qu'il n'a “plus l'énergie et l'enthousiasme” pour répondre à certaines “absurdités non techniques”. Le projet Rust pour le noyau Linux est considéré comme prometteur, mais il n'est pas sans complications, notamment la gestion des Pull Request.
Rust est un langage de programmation généraliste qui met l'accent sur les performances, la sécurité des types et la concurrence. Il assure la sécurité de la mémoire, c'est-à-dire que toutes les références pointent vers une mémoire valide, sans ramasse-miettes. Depuis 2015, Rust a été adopté par des entreprises telles qu'Amazon, Discord, Dropbox, Google (Alphabet), Meta et Microsoft. En décembre 2022, il est devenu le premier langage autre que le C et Assembly à être pris en charge dans le développement du noyau Linux.
Les principaux mainteneurs du noyau Linux ont un âge qui commence par le chiffre 5, voire la soixantaine. Linus Torvalds, le créateur du noyau Linux lui-même a souligné qu'“il est vraiment difficile de trouver des personnes qui sont des mainteneurs”. C'est pourquoi, le projet Rust for Linux est né. L'objectif n'est pas de réécrire le noyau entier du Linux en Rust, mais plutôt dajouter du nouveau code, écrit en Rust. Rust pourrait ainsi apporter des bénéfices en termes de qualité, de performance et de sécurité du code du noyau, tout en réduisant les coûts de développement et de maintenance.
Lors de l'édition 2023 du Kernel Maintainers Summit, la communauté a dressé un bilan du projet Rust-for-Linux, le décrivant comme prometteur, mais pas sans complications. L'un des défis des développeurs du projet étant les nombreux Pull Request ajoutant du code Rust important.
Mais Wedson Almeida Filho, l'un des responsables du noyau Rust pour Linux, a décidé de se retirer du projet. Cette décision serait motivée, du moins en partie, par la nécessité de faire face à l'augmentation des “absurdités non techniques” liées à l'utilisation du langage de programmation Rust dans le noyau Linux.
Wedson a écrit sur la liste de diffusion du noyau Linux :
Il s'agit d'une série aussi courte que possible : je me retire du projet Rust pour Linux en tant que responsable de la maintenance.
Je me retire du projet. Après presque 4 ans, je n'ai plus l'énergie et l'enthousiasme que j'avais autrefois pour répondre à certaines absurdités non techniques, il est donc préférable de laisser cela à ceux qui l'ont encore en eux.
À l'équipe de Rust for Linux : merci, vous êtes formidables. Ce fut un plaisir de travailler avec vous tous ; les moments que nous avons passés à discuter de questions techniques, à trouver des moyens de résoudre les problèmes de solidité, etc. ont toujours été quelque chose que j'ai apprécié et que j'attendais avec impatience. Je me considère chanceux d'avoir collaboré avec un groupe aussi [talentueux] et amical.
Je souhaite que le projet soit couronné de succès.
Je crois sincèrement que l'avenir des noyaux passe par des langages à mémoire sécurisée. Je ne suis pas un visionnaire, mais si Linux n'intériorise pas cela, je crains qu'un autre noyau ne lui fasse ce qu'il a fait à Unix.
Enfin, je vais laisser un petit échantillon de 3min 30s pour le contexte : https://yo...9YEBV0Q?t=1529 – et pour réitérer, personne n'essaie de forcer quelqu'un d'autre à apprendre Rust ni d'empêcher les refactorisations de code C. » Voici la vidéo pour le contexte :
Wedson est un ingénieur de Microsoft qui a été prolifique dans ses contributions au code Rust pour le noyau Linux au cours des dernières années. Wedson a travaillé sur de nombreuses fonctionnalités du noyau Linux Rust et a même réalisé un portage expérimental du pilote du système de fichiers EXT2 vers Rust. Mais il en a eu assez et se retire maintenant des efforts de Rust pour Linux.
S'il est regrettable de voir Wedson se retirer des efforts de Rust pour Linux, au moins il y a plusieurs autres mainteneurs qui continuent à superviser l'effort pour permettre l'utilisation du langage de programmation Rust dans le noyau Linux.
Source : Annonce de Wedson
Et vous ?
Quel est votre avis sur cette annonce ?
Voir aussi :
Rust dans le noyau Linux: un projet prometteur, mais pas sans complications. La communauté dresse un bilan, lors de l'édition 2023 du Kernel Maintainers Summit
Linus Torvalds exprime sa déception de voir le faible taux d'adoption de Rust comme langage de programmation pour le noyau Linux, car les principaux mainteneurs du noyau sont plus habitués au langage C
L'enquête Rust révèle que les utilisateurs de Linux et de VS Code sont plus nombreux à cibler WebAssembly. La France se situe à la cinquième place mondiale en nombre de développeurs Rust
Uther
Expert éminent sénior
Cela dit, c'est un vrai problème: si on ré-écrit toute une api C en Rust, on fait quoi des mainteneurs C de cette API ?
Si on veut supporter les deux langage su le même noyau, les API pour le C et le Rust sont forcément synchronisées. Il y a des outils pour générer automatiquement une l'API pour Rust à partir des headers C (bindgen) et inversement (cbindgen), même si je ne suis pas sur si ils sont utilisés dans les cadre de Rust for Linux. Par contre, quand il y a un changement de l'API, il faut adapter tous les drivers, qu'ils soient en Rust ou en C.
ouch, quant-on te dis que “si je casse ton code, c'est ton problème, pas le mien”, c'est vraiment pas un bon signe pour le projet. La personne se plaint surtout parce que s'il doit casser l'API, il se sent capable d'adapter lui même la totalité des drivers C existants actuellement dans le noyau, mais que comme il ne connait pas Rust, il n'est pas capable de le faire pour les drivers Rust. Ça serait entendable comme argument si ce n'était pas accompagné d'un clair mépris du travail du groupe qui travaille sur Rust.
le 30/08/2024 à 8:28
Avant que les les défenseurs acharnés de Rust
ne me tombe dessus, je précise que je n'ai rien contre ce dernier, qui pour ce que j'en ai vu, est très prometteur, même si je ne suis pas enthousiasmé personnellement par ce dernier (mais ce n'est pas le sujet).
Je comprend les anciens mainteneurs de longue date, qui ont accompli (en C) un travail de dingue sur le noyau.
Ils n'ont rien contre Rust, mais il faut comprendre et accepter qu'ils n'ont pas envie (à leur âge), de continuer.
Je pense que tout le monde est d'accord pour dire que la récriture complète du noyau linux en Rust, n'est pas une bonne idée. Techniquement, je peux comprendre que de nouveaux ajouts soit fait en [B]Rust[/R], mais cela pose certains problèmes:
Deux langages différents dans une base de code, ça complexifie la chaîne de production.
Y'a-t-il suffisamment de développeurs très compétents en Rust pour garantir l'évolution et la maintenance d'un projet de cette envergure ?
Si la balance se fait vers Rust, qui voudra bien assurer la maintenance du vieux code C ?
Si certains nouveaux contributaires veulent qu'on accepte d'introduire Rust dans la base de code, ils doivent aussi accepter de maintenir et permettre d'évoluer tout ce qui est et restera en C
Je ne suis pas spécialiste en Rust, mais j'ai lu (désolé, je n'ai pas noté les références) que bon nombres du code Rust de bas niveau se fait en mode unsafe, pour contourner la rigidité de Rust sur certaines parties de ce code. Et, dites-moi si je me trompe, Rust en mode unsafe, n'apporte pas grand chose au niveau sécurité par rapport au C. Je peux donc comprendre la réticences de bon nombres d'excellents développeurs C qui ne jugent pas nécessaires/souhaitable d'ajouter la complexité d'une base de code utilisant 2 langages.
Les “Pro Linux” (Perso, je ne suis ni Pro, ni Contre), n'ont eu de cesse de dire (à juste tire), que Linux était meilleur, plus stable, moins sujet aux vulnérabilités que d'autres OS. Et pourtant, tout cela a été fait en C…
BàV et Peace & Love
le 30/08/2024 à 12:38
Je vais tenter de répondre point par point parce qu'il y a pas mal d'incompréhension.
Ils n'ont rien contre Rust, mais il faut comprendre et accepter qu'ils n'ont pas envie (à leur âge), de continuer. Pourquoi ne pas partir à la retraite dans ce cas ? Pour l'avenir du projet, il vaut mieux permettre d'utiliser un langage plus récent (qui correspond aux besoins du projet) car il y aura plus de développeurs maitrisant ce langage. C'est l'argument principal de Linus pour pousser Rust dans le kernel (en plus des avantages fournis par Rust).
Je pense que tout le monde est d'accord pour dire que la récriture complète du noyau linux en Rust, n'est pas une bonne idée. C'est un but long terme. Si une partie fonctionne, je ne pense pas qu'ils la réécriront avant un bon moment.
Techniquement, je peux comprendre que de nouveaux ajouts soit fait en [B]Rust[/R], mais cela pose certains problèmes:
Deux langages différents dans une base de code, ça complexifie la chaîne de production.
Y'a-t-il suffisamment de développeurs très compétents en Rust pour garantir l'évolution et la maintenance d'un projet de cette envergure ?
Si la balance se fait vers Rust, qui voudra bien assurer la maintenance du vieux code C ?
Si certains nouveaux contributaires veulent qu'on accepte d'introduire Rust dans la base de code, ils doivent aussi accepter de maintenir et permettre d'évoluer tout ce qui est et restera en C Je pense que le ratio développeur Rust/développeur C va lentement bouger en faveur de Rust (normal, le C commence à se faire vieux maintenant…). Mais même au-delà de ça, il serait dommage de se priver des avantages fournis par un nouveau langage.
Je ne suis pas spécialiste en Rust, mais j'ai lu (désolé, je n'ai pas noté les références) que bon nombres du code Rust de bas niveau se fait en mode unsafe, pour contourner la rigidité de Rust sur certaines parties de ce code. Non. C'est pour appeler du code C ou alors pour appeler des intrinsics que les blocks unsafe sont nécessaires. Et dans le kernel linux, c'est plutôt commun le C.
Et, dites-moi si je me trompe, Rust en mode unsafe, n'apporte pas grand chose au niveau sécurité par rapport au C. Je peux donc comprendre la réticences de bon nombres d'excellents développeurs C qui ne jugent pas nécessaires/souhaitable d'ajouter la complexité d'une base de code utilisant 2 langages. Hé bien oui, tu te trompes, même assez lourdement. Le code unsafe n'enlève pas les vérifications de Rust, par-contre ça te permet d'appeler des fonctions unsafe (donc des fonctions C notamment) et de déréférencer un pointeur. Ce sont grosso-modo les seules différences. Je ne sais pas trop pourquoi les gens pensent que l'unsafe enlèvent magiquement tous les checks de Rust…
Les “Pro Linux” (Perso, je ne suis ni Pro, ni Contre), n'ont eu de cesse de dire (à juste tire), que Linux était meilleur, plus stable, moins sujet aux vulnérabilités que d'autres OS. Et pourtant, tout cela a été fait en C… Mouais. Tu me vois moyennement convaincu là. Vu le nombre de failles de sécurité qui sont corrigés tous les ans, je pense qu'il serait plus intéressant de faire une comparaison avec le nombre d'installations de l'OS corrélé avec le nombre d'utilisateurs. C'est toujours très difficile de déterminer ce genre de choses.
le 30/08/2024 à 13:54
Uther
Expert éminent sénior
Je comprend les anciens mainteneurs de longue date, qui ont accompli (en C) un travail de dingue sur le noyau. Ils n'ont rien contre Rust, mais il faut comprendre et accepter qu'ils n'ont pas envie (à leur âge), de continuer.
Qu'ils n'aient pas envie d'apprendre le Rust, c'est très compréhensible. Mais s'opposer activement au travail des autres, c'est un autre problème. Il n'y a pas de mal dans un projet communautaire de demander l'assistance de quelqu'un qui connait la technologie plutôt que de rejeter tout au prétexte qu'on ne peut pas le faire soi-même.
Je pense que tout le monde est d'accord pour dire que la récriture complète du noyau linux en Rust, n'est pas une bonne idée. Techniquement, je peux comprendre que de nouveaux ajouts soit fait en [B]Rust[/R], mais cela pose certains problèmes En effet la réécriture de tout Linux en Rust n'est pas un objectif pour le moment et si elle devait se faire ça sera certainement pas avant plusieurs dizaines d'années.
Il faut comprendre que la majorité du code de Linux est constitué des modules (des drivers) que l'on peut traiter de manière relativement indépendante. Ces modules peuvent maintenant être écrits en Rust, mais pour le moment le cur du noyau reste en C et il n'y a aucun plan officiel pour que ça change. Ça pourrait peut-être arriver dans le futur mais pas avant très longtemps. Il faudrait déjà que les module en Rust deviennent largement majoritaires pour que l'on commence a l'envisager.
Deux langages différents dans une base de code, ça complexifie la chaîne de production. En effet c'est le rôle du projet Rust4Linux de mettre en place la chaine coté Rust pour que ça marche au mieux possible, mais c'est difficile de nier que ça apporte forcément un minimum de complexité générale, au minimum ça impose l'ajout d'un compilateur Rust. Ceci dit au vu de la séparation en module, qui semble devoir durer un moment, la plupart les personnes qui font un driver en C n'ont pas a se soucier du Rust et vice versa.
Y'a-t-il suffisamment de développeurs très compétents en Rust pour garantir l'évolution et la maintenance d'un projet de cette envergure ? C'est en effet la question, et c'est pour ça que le support de Rust est limité pour le moment aux modules. Le but est de permettre une transition progressive et voir comment les choses se passent sur la durée.
Si la balance se fait vers Rust, qui voudra bien assurer la maintenance du vieux code C ? La situation serait la même que pour le Rust en ce moment mais inversée. Les modules C resteraient développés en C, tout comme les modules Rust sont actuellement développés en Rust. Si il n'y a plus personne pour assurer la maintenance d'un module en C, une migration pourrait être envisagée, au cas par cas.
Je ne suis pas spécialiste en Rust, mais j'ai lu (désolé, je n'ai pas noté les références) que bon nombres du code Rust de bas niveau se fait en mode unsafe, pour contourner la rigidité de Rust sur certaines parties de ce code. Et, dites-moi si je me trompe, Rust en mode unsafe, n'apporte pas grand chose au niveau sécurité par rapport au C. Je peux donc comprendre la réticences de bon nombres d'excellents développeurs C qui ne jugent pas nécessaires/souhaitable d'ajouter la complexité d'une base de code utilisant 2 langages. C'est vrai qu'en bas niveau on peut avoir un besoin spécifique de recourir au unsafe, par exemple pour accéder directement aux adresses mémoires qui permettent de manipuler le matériel. Mais dans la pratique ça n'arive que dans des parties très limitées limitée du code. Les premiers retours montrent que même sur des drivers, le recours au unsafe reste quand même relativement rare. De loin le premier usage de unsafe que je constate en Rust, c'est juste pour s'interfacer avec un code C unsafe par nature.
Les “Pro Linux” (Perso, je ne suis ni Pro, ni Contre), n'ont eu de cesse de dire (à juste tire), que Linux était meilleur, plus stable, moins sujet aux vulnérabilités que d'autres OS. Et pourtant, tout cela a été fait en C… La comparaison se faisant avec d'autres OS aussi écrits en C, ça ne veut pas dire grand chose. Linux comme ses concurrents a eu de nombreuses vulnérabilités liées à la sécurité mémoire.
le 30/08/2024 à 16:15
Uther
Expert éminent sénior
Pourquoi ne pas partir à la retraite dans ce cas ? Pour l'avenir du projet, il vaut mieux permettre d'utiliser un langage plus récent (qui correspond aux besoins du projet) car il y aura plus de développeurs maitrisant ce langage. C'est l'argument principal de Linus pour pousser Rust dans le kernel (en plus des avantages fournis par Rust).
Pour le coup, pousser des gens très compétents à la retraite s'il ne le souhaitent pas ne me parait un problème. Et si c'est comme ça qu'on présente sérieusement l'introduction de Rust, il ne faut pas s'étonner que les gens le traitent comme une menace plutôt qu'une opportunité.
Il reste clairement assez de C a écrire pour des dizaines d'années, les experts barbus ne pas encore bon pour l'ANPE Pole Emploi
France travail.
C'est un but long terme. Si une partie fonctionne, je ne pense pas qu'ils la réécriront avant un bon moment. Ce n'est clairement pas un but annoncé en tout cas. Rien nempêche que ça le devienne à l'avenir, mais le seul objectif pour le moment est de permettre de faire des modules en Rust qui sintègrent dans la base existante.
Non. C'est pour appeler du code C ou alors pour appeler des intrinsics que les blocks unsafe sont nécessaires. Et dans le kernel linux, c'est plutôt commun le C. Dans les drivers et les OS, il y a quand même des usages particuliers du unsafe, par exemple pour permettre d'écrire à des endroits fixes de la mémoire, ou faire de l'assembleur pour accéder a des fonctionnalités particulières des processeurs, …
Hé bien oui, tu te trompes, même assez lourdement. Le code unsafe n'enlève pas les vérifications de Rust, par-contre ça te permet d'appeler des fonctions unsafe (donc des fonctions C notamment) et de déréférencer un pointeur. Ce sont grosso-modo les seules différences. Je ne sais pas trop pourquoi les gens pensent que l'unsafe enlèvent magiquement tous les checks de Rust… En même temps certaines fonction unsafe comme “transmute” pouvant casser à peu prêt toute la sécurité offerte par le typage, je comprend comment on peut en venir a cette conclusion. Ce qu'il faut retenir c'est surtout que les blocs unsafe permettent d'identifier simplement le code à risque et donc de réduire son usage au minimum.
le 30/08/2024 à 16:49
Et pourquoi COBOL existe encore… Y a trop de code à réécrire, et peu de spécialistes capables de transcoder du code, peut-être qu'une IA pourra faire le taff, mais COBOL n'est pas près de disparaître des serveurs de services financiers, et le C n'est pas près de disparaître du noyau Linux non plus.
le 29/08/2024 à 20:37
ouch, quant-on te dis que “si je casse ton code, c'est ton problème, pas le mien”, c'est vraiment pas un bon signe pour le projet. Cela dit, c'est un vrai problème: si on ré-écrit toute une api C en Rust, on fait quoi des mainteneurs C de cette API ?
le 30/08/2024 à 0:05
En plus la compilation n'est pas simplifiée puisqu'il faut à présent compiler deux codes sources différents pour avoir un kernel fonctionnel… Les amateurs LFS vont adorer.
le 30/08/2024 à 17:32
Je vais tenter de répondre point par point parce qu'il y a pas mal d'incompréhension.
Merci
Pourquoi ne pas partir à la retraite dans ce cas ? Pour l'avenir du projet, il vaut mieux permettre d'utiliser un langage plus récent (qui correspond aux besoins du projet) car il y aura plus de développeurs maitrisant ce langage. C'est l'argument principal de Linus pour pousser Rust dans le kernel (en plus des avantages fournis par Rust). C'est bien ce qu'il se passe, les anciens développeurs/mainteneurs arrivent tout doucement a se faire vieux, et se retirent petit à petit. Il faudra donc bien que les développeurs qui reprennent le flambeau, puissent également maintenir une grande partie de code écrit en C. Parce que même si Rust semble devenir plus populaire, il n'est pas certains que pour le développement de bas niveau (sur des petits microcontrolleurs) il puisse s'imposer ni même perdurer (pour certains µControlleurs, seul un compilateur C est disponible).
Ada fait aussi bien que Rust, et il existe depuis des décénnies, et pourtant il n'est pas forcément très utilisé.
C'est un but long terme. Si une partie fonctionne, je ne pense pas qu'ils la réécriront avant un bon moment. Je suis totalement d'accord. Je pense même qu'ils ne devraient même pas essayer de réécrire quoique ce soit. Si je prend l'exemple du domaine bancaire, des tentatives on été faites pour réécrire le (très) vieux code COBOL, et ça n'a jamais abouti. Et la base de code est finalement restée en COBOL.
Je pense que le ratio développeur Rust/développeur C va lentement bouger en faveur de Rust (normal, le C commence à se faire vieux maintenant…). Mais même au-delà de ça, il serait dommage de se priver des avantages fournis par un nouveau langage. Ce n'est que mon avis, mais le C est partout, dans pratiquement tous les domaines, il faut utiliser du C, et avant qu'il ne soit remplacé majoritairement par Rust, il va vivre encore des décénies. Je parierais bien, mais je serais 6 pieds sous terre depuis bien longtemps si/quand ça arrivera, et je ne pourrais pas payer mon paris…
Mais sinon, oui, si Rust a des avantages, il faut en profiter. Mais entre un “vieux développeur C” et un “Junior développeur Rust, mon coeur balance
Non. C'est pour appeler du code C ou alors pour appeler des intrinsics que les blocks unsafe sont nécessaires. Et dans le kernel linux, c'est plutôt commun le C. Le mot “unsafe” est alors très mal choisi si là c'est son utilsation première (utiliser du code C unsafe). Il aurait fallu le nommer “c-compatible”. C'est un peu d'humour… Quoique rien que le fait qu'il existe (le mode “unsafe”) ça me fait penser au “friends” dans le C++. Ce n'est pas au même niveau, je suis bien d'accord. Mais de grand espoirs avaient été espéré avec le C++, et la POO. Avec le recul, on peut dire que ce n'est pas la panacée, malheureusement.
Hé bien oui, tu te trompes, même assez lourdement. Le code unsafe n'enlève pas les vérifications de Rust, par-contre ça te permet d'appeler des fonctions unsafe (donc des fonctions C notamment) et de déréférencer un pointeur. Ce sont grosso-modo les seules différences. Je ne sais pas trop pourquoi les gens pensent que l'unsafe enlèvent magiquement tous les checks de Rust… Il ne les enlève pas tous, mais c'est justement là où ça fait mal qu'il est utilisé ce mode “unsafe”
Mouais. Tu me vois moyennement convaincu là. Vu le nombre de failles de sécurité qui sont corrigés tous les ans, je pense qu'il serait plus intéressant de faire une comparaison avec le nombre d'installations de l'OS corrélé avec le nombre d'utilisateurs. C'est toujours très difficile de déterminer ce genre de choses. Je me suis sûrement mal exprimé, je voulais juste dire qu'on a su faire un OS de qualité (linux) avec du C.
En tout cas, merci pour le partage
BàT et Peace & Love.
le 30/08/2024 à 17:53
ALORS ON VA OU MAINTENANT
le 29/08/2024 à 19:39
https://rust.developpez.com/actu/362076/L-un-des-responsables-de-la-maintenance-du-noyau-Linux-Rust-se-retire-du-projet-invoquant-des-absurdites-non-techniques/
https://%ip%:4444
Ping (erfordert Windows mit Anpassungen)
Ping (Ping.eu)
Robtex IP Lookup
Google Search
http://%ip%
https://%ip%
ftp://%ip%
ssh://%ip% (erfordert Windows mit Anpassungen)
whois.domaintools.com/%ip%
https://www.shodan.io/search?query=%ip%
https://mxtoolbox.com/SuperTool.aspx?action=blacklist%3a%ip%&run=toolpage
you see this when javscript or css is not working correct