Frustrations et départ dans l’équipe Rust du noyau Linux
Sans huile dans le moteur, Linux risque de rouiller
La semaine dernière, Wedson Almeida Filho, l'un des principaux collaborateurs du projet Rust for Linux, a décidé d'arrêter de travailler sur l'intégration de ce langage dans le noyau libre. En cause, son « manque d'énergie et d'enthousiasme » face à des problèmes qui, selon lui, relèvent d' « absurdités non techniques », confirmant les difficultés de relations humaines qui entourent la gestion du noyau Linux.
Le 06 septembre à 15h24
6 min
Logiciel
Logiciel
Wedson Almeida Filho, l'un des responsables de l'équipe chargée d'encadrer l'utilisation du langage Rust dans le noyau Linux, a annoncé son départ la semaine dernière sur la liste de discussion du projet. Cet ingénieur de Microsoft explique qu' « après presque 4 ans, [il n'a] plus l'énergie et l'enthousiasme qu'[il avait] autrefois pour répondre à certaines des absurdités non techniques ».
Ce langage est de plus en plus utilisé dans des projets critiques pour assurer une gestion de la mémoire plus robuste. La DARPA l'utilise par exemple, ayant pour ambition d'éliminer « une fois pour toutes les vulnérabilités liées à la sécurité de la mémoire » et a même lancé un projet pour traduire automatiquement le code C en Rust. La Maison-Blanche exhorte même les développeurs à se mettre au Rust.
Une intégration qui prend du retard
Débuté en 2020, le projet Rust for Linux a pour ambition d'aider à augmenter encore la sécurité du noyau le plus connu du logiciel libre. En avril 2021, travaillant alors dans l'équipe Android de Google, Wedson Almeida Filho affirmait dans un billet de blog : « nous pensons que Rust est maintenant prêt à rejoindre le langage C en tant que langage pratique pour l'implémentation du noyau. Il peut nous aider à réduire le nombre de bugs potentiels et de vulnérabilités de sécurité dans le code privilégié, tout en s'intégrant proprement avec le noyau central et en préservant ses caractéristiques de performances ».
Mais il a fallu attendre fin 2023 pour que le langage s'insère pour la première fois dans la version 6.8 du noyau via un driver réseau, comme l'expliquent le chercheur Hongyu Li et ses collègues, dans une étude de l'intégration du langage dans le noyau publiée début juillet. Linus Torvalds, le créateur de Linux et toujours responsable de son développement, avait pourtant annoncé cette intégration pour la version 6.1.
Altercation virulente entre développeurs C et Rust
Mais ce retard ne mine pas la confiance de Wedson Almeida Filho dans l'utilité de Rust pour écrire des noyaux robustes. Au contraire, il affirme dans son message : « je crois vraiment que l'avenir des noyaux passe par des langages à mémoire sécurisée ». Il ajoute même que Linux pourrait se faire dépasser par d'autres noyaux : « 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 ».
Wedson Almeida Filho intègre aussi dans son message un lien vers une vidéo filmée en mai lors de la conférence Linux Storage, Filesystem, Memory-Management, and BPF Summit. Le passage qu'il pointe montre une discussion difficile entre l'ingénieur et un de ses collègues, Ted Ts'o, qui l'accuse de vouloir « convaincre tous les autres de s'orienter vers une religion promue par Rust ».
« Et la réalité, c'est que ça ne va pas arriver, car nous avons plus de 50 systèmes de fichiers dans Linux qui ne vont pas être convertis immédiatement en Rust. Avant ça, nous allons continuer à réécrire du code C, car nous voulons que le code en C soit meilleur », argumentait le second. Il avait ajouté : « vous n'allez pas tous nous forcer à apprendre Rust ».
Des développeurs Rust solidaires
Comme l'a repéré ArsTechnica, la développeuse Asahi Lina (responsable du projet Asahi Linux) a partagé un avis similaire à celui de Filho en le soutenant : « je comprends malheureusement tout à fait les frustrations de Wedson ».
Elle évoque son expérience lorsqu'elle a voulu proposer des modifications au Direct Rendering Manager(DRM) de Linux : « lorsque j'ai essayé d'apporter en amont des corrections mineures au code C pour rendre le comportement plus robuste et les exigences de durée de vie plus raisonnables, le mainteneur l'a bloqué et a dit que je devais simplement faire "ce que font les autres pilotes" ». Elle ajoute qu' « un sous-ensemble de développeurs du noyau C semble déterminé à rendre la vie des mainteneurs de Rust aussi difficile que possible ».
« À ce jour, des bugs dans l'ordonnanceur du DRM ont été les seules causes de kernel panics déclenchées par le pilote de mon GPU Apple en production [...] », explique Asahi Lina, « parce que je code en Rust ».
Dans un billet de blog, Drew DeVault, le fondateur de la plateforme d'outils open source Source Hut, suggère aux développeurs Rust de développer un noyau compatible Linux à partir de zéro. Ceci devrait, selon lui, les libérer des batailles politiques des mailing lists du noyau Linux. Celles-ci seraient plus un « far west » qu'un milieu « enthousiaste et prêt à accueillir en son sein des innovateurs motivés pour faciliter cet impact ».
Constat désemparé de Linus Torvalds
Ce n'est pas le premier conflit interpersonnel à surgir dans le projet du noyau Linux. Linus Torvalds a lui-même installé pendant longtemps un climat brutal dans ses conversations, qu'elles soient internes ou externes. En 2018, il avait envoyé un message d'excuses.« Je vais prendre du temps pour moi et demander de l’aide pour comprendre les émotions des autres et comment y répondre de manière appropriée », annonçait-il.
Torvalds expliquait à Zdnet au mois d'aout : « je m'attendais à ce que les mises à jour soient plus rapides, mais le problème réside en partie dans le fait que les développeurs de noyau de longue date sont habitués au C et ne connaissent pas Rust. Ils ne sont pas vraiment enthousiastes à l'idée de devoir apprendre un nouveau langage qui est, à certains égards, très différent. Il y a donc eu des réactions négatives à l'égard de Rust ». Il ajoutait cependant qu' « une autre raison est que l'infrastructure Rust elle-même n'a pas été très stable ».
L'un des membres de la Rust core team, Steve Klabnik, a commenté sur Bluesky : « des responsables du noyau Linux se comportent si mal que d'autres abandonnent. Windows se contente de livrer discrètement du code Rust. Nous verrons comment tout cela va se dérouler… »
Frustrations et départ dans l’équipe Rust du noyau Linux
-
Une intégration qui prend du retard
-
Altercation virulente entre développeurs C et Rust
-
Des développeurs Rust solidaires
-
Constat désemparé de Linus Torvalds
Commentaires (44)
Vous devez être abonné pour pouvoir commenter.
Déjà abonné ? Se connecter
Abonnez-vousLe 06/09/2024 à 15h51
Le 06/09/2024 à 15h57
Le 06/09/2024 à 16h20
Le 06/09/2024 à 21h32
Le 06/09/2024 à 16h43
Le 06/09/2024 à 16h49
Le 06/09/2024 à 18h07
Le 07/09/2024 à 08h59
Le 06/09/2024 à 21h34
Le 06/09/2024 à 22h27
Le 06/09/2024 à 16h13
Autant dans le premier cas, je peux comprendre la frustration de devoir passer son temps libre à apprendre, autant dans le second, c'est juste... puéril. En choisissant de bosser dans l'informatique, on accepte une formation continue, sinon autant bosser en Cobol pour une grosse banque.
Le 06/09/2024 à 17h02
Pour la formation continue, ils bossent dans le noyau qui demande pas mal de rétrocompatibilité.
Ça doit jouer dans le fait de ne pas évoluer trop vite. C'est pas une nouvelle solution a la mode qui sera abandonné dans 3 ans.
Le 06/09/2024 à 17h23
Rust a 10 ans passés. Il est maintenant mûr, il a montré de très grandes qualités native sur la sécu, le multitâche, les perfs et la conso de ressources.
Mais je comprends parfaitement l'agacement de la réécriture face à la maintenance. Le risque à réécrire est grand. Et les développeurs noyau ont un sacré égo - donc rust pour la ligne de commande ça ne les dérange pas, mais rust dans les pilotes ça les gêne.
De même, le C, c'est très (très très) proche de l'assembleur - on a l'impression de piloter hyper finement, de maîtriser, là ou rust n'est pas aussi transparent.
Par contre rust implémente certains concepts comme le parallélisme et le SIMD via des librairies de base et la syntaxe normale, pour le C c'est franchement de l'extension et ça sent bon la verrue depuis toujours par exemple.
Le 06/09/2024 à 22h18
Le 06/09/2024 à 22h36
Non, Rust n'est pas mur. Son ABI n'est pas encore très stable dans le temps et il évolue encore trop vite pour parler de maturité. Pour faire des codes qui vont être oublié dans le user-space, pourquoi pas. Mais pour un kernel (je parle pas des drivers), Rust va demander une plus grande maintenance de par ses futures évolutions.
Sur la sécu mémoires uniquement, Rust est en effet assez novateur.
Pour la partie perf, en monocoeur Rust est moins bon que le C compilé avec GCC en raison de LLVM, idem pour la partie conso des ressources. Mais ça reste à la marge en général. Par contre niveau du temps de compilation assez délirants pour être devant être mur.
Pour le multitâche, Rust est pas mal pour de la mémoire distribuée, il ne fait guère mieux que le C. Mais en mémoire partagées, sa manie de tout copier ou de mettre des verrous partout le rendent moins rapide que le C.
Par contre rust implémente certains concepts comme le parallélisme et le SIMD via des librairies de base et la syntaxe normale, pour le C c'est franchement de l'extension et ça sent bon la verrue depuis toujours par exemple.
Vrai question. Tu trouves le parallélisme sous Rust plus facile ? Déjà que la syntaxe de Rust est son plus gros défaut (à ce niveau même l'API de Windows est plus lisible) mais pour piger le calcul parallèle en Rust c'est juste infect. Trop verbeux, trop syntaxe inutilement cryptique. Pour le SIMD en Rust, c'est la même chose en plus de nécessiter de l'unsafe et devoir écrire de l'assembleur haut-niveau.
Alors, le parallélisme en C, ça peut vite devenir dégeu. Je suis d'accord. Mais le SIMD en C, non c'est clairement plus lisible qu'en Rust.
Et pour les deux, les libraires sont natives (i.e., fournit avec le compilateur).
Le 07/09/2024 à 22h15
Le 07/09/2024 à 22h26
Mais dans ce cas, pourquoi s'embêter à maintenir deux langage ensemble si l'un des n'est qu'un wrapper ? J'en vois pas l’intérêt, et qui plus Rust est a une courbe d'apprentissage assez raide par rapport à du C.
Par contre, et c'est un scénario qui va arriver dans le futur si Rust reste, quid des fonctions codés en Rust vont devoir se brancher avec du C durant la migration de pans du kernel de C-> Rust ?
Modifié le 09/09/2024 à 09h17
Penser maintenant à intégrer du Rust dans le cœur de Linux, c'est clairement mettre la charrue avant les bœufs. Ça n'arrivera pas avant de très très longues années, si jamais ça arrive, D'ici à ce que la question de généraliser l'usage de Rust se pose, Rust aura probablement déjà une API stable (il y a des travaux en cours).
Je pense qu'une grosse partie des problèmes actuels viennent de cette incompréhension. Le projet Rust for Linux n'a pas assez communiqué sur la limitation du scope de Rust. Certains ont eu l'impression que le but du projet était de tout réécrire en Rust.
Le 06/09/2024 à 17h08
Faire une revue avec du code illisible (rust reste peu connu), ca nécessite d'engager sa responsabilité.
Bien sûr, je pense qu'il y a un peu de côté puéril genre blessure profonde à l'amour propre: Rust est censé apporter une sécurité par défaut, que les dev on la fierté d'apporter par leur contribution.
Le 06/09/2024 à 17h09
Paix à vos âmes Silverlight, Flash, Shockwave et probablement plein d'autres (OK, c'est plutôt des technologies que des langages mais c'est l'idée).
Le 06/09/2024 à 17h45
Rust gagne en popularité, et le noyau Linux aurait certainement à gagner à inclure du Rust. Je ne dis pas le contraire.
Maintenant, il faut se replacer dans le contexte : Linux est un projet qui a 33 ans, qui est constitué de millions de lignes de code, et jusqu'à présent est écrit quasiment exclusivement en C, avec quelques morceaux d'assembleur propre à chaque architecture quand il n'est pas possible de faire autrement.
Rust, bien que présentant des avantages, a aussi des défauts. Le langage dans sa forme actuelle est encore jeune, sa popularité est récente, il a failli tomber après l'abandon par Mozilla en 2020. Il s'est plus ou moins stabilisé ces dernières années.
Sa courbe d'apprentissage n'est pas simple et nécessite un véritable investissement. Le noyau Linux, de part sa nature, nécessite aussi un véritable investissement pour y aller. Pour l'instant, il n'est qu'en C (ou quasiment). Si demain, il faut connaitre à fond et le C et le Rust, cela risque d'en rebuter plus d'un.
Le problème, pour moi, n'est pas tant de décider d'avoir du C ou du Rust, mais de faire cohabiter les deux, avec les soucis que cela peut engendrer. Une base de code, avec un seul langage, c'est quand même bien plus pratique. Comme il y a déjà des millions de lignes de code en C dans le noyau, le C à forcément un avantage certains de ce point de vue.
J'entends certains des arguments avancés par "l'équipe Rust". Mais j'ai l'impression aussi parfois qu'ils font une montagne d'un non-événement et parce que ce qui est présent actuellement ne permet pas à Rust de fonctionner correctement doit être changé (cf. les propos d'Asahi Lina).
Elle interprète ce refus comme des bâtons mis dans les roues de l'équipe Rust, alors qu'il peut très bien s'agir de conserver un comportement et un style de code homogène à travers l'ensemble des drivers. Car un changement, aussi mineur soit-il, quand il y a 50 drivers qui en dépendent, peut facilement créer des incompatibilités ou des effets de bords non prévus dans certains d'entre eux.
Vue la criticité du projet, il me parait plus que normal de ne pas sauter sur l'effet de mode du moment.
Modifié le 06/09/2024 à 22h09
On comprends aussi la réserve: Tous les 10 ans on nous annonce le langage qui va être le fossoyeur du C qui est toujours là. Pour du bas niveau, avec des développeurs typés logiciel de base qui doivent déjà se fader la complexité croissante du matériel, je pense que tout langage qui en rajoutera sa couche avec en prime une perte de performance, même faible mais là ou elle est vraiment importante, surtout pour le pb très largement réglé de la mémoire, ne fera pas son trou. C'est aussi un domaine ou la chasse aux dépendances est féroce...
Ils mènent un combat côté kernel qui n'est pas le bon AMHA. Côté applicatif avec gros requis sécurité, cela ferait plus sens.
Le 06/09/2024 à 22h28
Ils mènent un combat côté kernel qui n'est pas le bon AMHA. Côté applicatif avec gros requis sécurité, cela ferait plus sens.
Mon interprétation de la chose (je ne sais pas si elle est bonne) : le noyau linux serait une superbe publicité pour démocratiser le langage et lui donner une assise stable et une crédibilité qui ferait de lui un langage sûr pour les années à venir (sûr dans le sens de prendre du temps d'investir dedans, je ne parle pas de la sureté inhérente à ce langage pour la gestion de la mémoire par exemple)
Le 07/09/2024 à 18h58
Puis c'est une méritocratie: Si les mecs croient qu'on va leur dérouler le tapis rouge ils ne tapent pas à la bonne porte je pense. Il va falloir faire leurs preuves à tous niveaux.
Le 07/09/2024 à 19h06
Le 06/09/2024 à 22h30
Justement, Rust est un peu le premier langage a avoir réussi à améliorer des choses niveau perf, et niveau fonctionnalités. D'où son acceptation dans les kernels (Linux, Windows, BSD un jour?)
Certaines constructions sont très intéressantes, sa façon de les compiler plutôt clean.
Franchement, c'est un vrai langage neuf - malgré effectivement une syntaxe dure à appréhender au 1er abord (et au 2nd, et au 3ème...)
"surtout pour le pb très largement réglé de la mémoire"
Bof bof. C'est réglé par de bonnes pratiques difficiles à maintenir/vérifier, soit par des mitigations compilo potentiellement coûteuses.
Mais attention: si Rust règle les problèmes mémoire, il ne règle pas les problèmes de sécu ou de perf liés à l'architecture même du programme ou des protocoles.
Le 06/09/2024 à 22h41
Certaines constructions sont très intéressantes, sa façon de les compiler plutôt clean.*
Améliorer les choses niveau perf ? Tu peux m'expliquer stp. Parce que niveau perf code, sa syntaxe est un frein à l'optimisation et son temps de compilation (même pas parallélisable) est infecte.
Quelles sont, selon toi, les ajouts utiles de Rust pour dev kernel ? Pour du dev de soft, voir de drivers pas de soucis mais pour des fonctions kernels pures et dures ?
Le 07/09/2024 à 12h38
Modifié le 09/09/2024 à 09h26
Certes c'est plus pratique d'avoir un seul langage, mais il faut voir que le Rust ne va pas se retrouver partout dans le code de Linux. Le but du projet et de permettre d'écrire de drivers en Rust. Le noyau reste en C, les driver existants restent en C. Les seules personnes exposées au Rust sont celles qui ont fait le choix de développer leur drivers en Rust.
Elle partage juste sa mauvaise expérience mais, contrairement à Wedson Almeida Filho, elle n'en a pas fait une montagne. Elle a continué a développer son driver malgré le refus du mainteneur qui aurait rendu le fonctionnement plus logique, y compris pour les autres drivers si j'ai bien compris.
J'ai l'impression qu'elle se plaint plus du ton des échanges que de la décision qui, comme tu le dis peut se justifier d'un point de vue risque de régression.
Le 09/09/2024 à 09h50
L'indépendance de Rust est récente. La fondation Rust a été créé il y a un peu plus de 3 ans en 2021.
Pour Servo, pour recadrer, j'ai cru comprendre que nombre de contributeur de Rust faisait tout simplement parti de l'équipe en charge du développement de Servo. Donc Servo abandonné, c'était une bonne partie de contributeurs à Rust qui tombait. Et ça, c'était en 2020 (donc avant la création de la fondation Rust).
Tant que le développeur originel du driver est là, pas de souci. Le jour où il part, s'il y a un bogue à corriger dans un driver, il faut un développeur qui connaisse Rust. Idem, les contributions externes, il faudra connaitre Rust. Aujourd'hui, vu le ratio des dev qui connaisse C par rapport à ceux qui connaisse Rust, ça peut être un véritable frein à la maintenance d'un driver.
Modifié le 11/09/2024 à 05h57
Au moment de son retrait, Mozilla n'était plus le principal supporter de Rust. En effet certains employés de Mozilla, dont certains travaillaient aussi sur Servo, ont quitté le projet, mais ils ne constituaient plus qu'une petite partie des contributeurs, le projet a pu le supporter.
La fondation à été créée, assez tard il est vrai, pour reprendre les aspects juridiques historiques (marques et logo notamment) qui étaient encore dans les mains de Mozilla et coordonner les soutiens. Mais dans la pratique le projet fonctionnait sans. La Fondation Rust, comme Mozilla à l'époque, n'a pas de pouvoir hiérarchique sur le projet Rust et n'en est pas propriétaire.
Le 09/09/2024 à 10h52
Pas tout à fait vrai. La Fondation Rust, si j'ai bien suivi, dispose justement des marques et nom de domaines associés. Elle en est donc propriétaire, légalement parlant.
Mais j'ai bien compris que le côté décisionnel est géré par une équipe (la Rust Team Core existe-elle toujours du coup ?) plus ou moins indépendante vis-à-vis de l'évolution du langage lui-même.
Modifié le 09/09/2024 à 11h17
Le projet Rust est organisée en différentes team qui gèrent chacune certains aspect du langage (langage,compilateur, lib, doc, ...), la team Core gérant les aspect généraux. l’évolution du langage en lui même est plutôt géré par la Team Language
Le 09/09/2024 à 11h41
J'avoue que je ne suis pas Rust au jour le jour, donc c'est pas toujours évident d'avoir toutes les informations ^^
En pratique, la fondation peut quand même faire sacrément pression : vous acceptez ça, ou on vous interdit dorénavant d'utiliser le logo, la marque, et les noms de domaines associés.
De son côté, elle peut forker le projet (il est libre), et faire ensuite évoluer sa marque Rust et le langage associé comme bon lui semble (et d'appeler le langage Rust).
Je ne sais pas si elle est propriétaire ou pas (d'ailleurs, y a-t-il un propriétaire) ? Par contre, elle peut changer la licence. Si je me souviens bien, Rust est sous licence MIT, qui autorise le relicensing tant qu'on conserve les attributions.
Modifié le 09/09/2024 à 12h32
A la limite si il y avait une dispute terrible dans les équipes du projet au point qu'ils décident de se séparer, elle pourrait arbitrer qui aurait le droit de garder nom.
Pour la licence, dans le cas de la licence MIT/Apache, la propriété du code n'est, en effet, pas vraiment utile. Si la licence avait été du type GPL, par contre ça ouvrait des opportunités.
Mais enfin, là on est dans la fiction improbable, le mandat de la fondation est de soutenir le projet Rust.
Le 06/09/2024 à 17h25
Pour les résumer simplement : 🖕 versus 🖕
Le 06/09/2024 à 20h58
Ces déchets s'expriment encore plus violemment dans un contexte/repaire d'expertise, tel qu'un noyau système.
Classique.
Le 07/09/2024 à 12h37
Modifié le 07/09/2024 à 13h36
D'un point de vue pur projet, quand tu bloques de manière destructive, tu gênes, et quand tu fais ça en position de force, c'est encore pire.
Quand tu transformes de faux arguments en attaques, en accusant la personne en face de choses fausses, tu es dans le royaume de l'ad hominem. Ce n'est pas acceptable.
Ça, c'est uniquement sur la base de la vidéo lié par la personne en illustration de ce à quoi elle doit constamment faire face, attaques face auxquelles elle n'a plus la force.
Regarde la vidéo : ne te trompe pas de cible.
Tu imagines bien que l'intensité augmente en privé, et il y a des choses dites/disséminées qui sont certainement encore pire par derrière.
L'illustration du courage (ou son manque) moyen. Comme d'hab'.
On ne parle pas d'évolution de projet, on parle de gens qui ont peur et qui se servent de cette peur comme justification d'une "défense" qui n'est rien d'autre, factuellement, que de l'attaque toxique.
Des déchets toxiques. CQFD.
Cela est transférable à bien d'autres domaines, car ça n'est que de l'humain : autres métiers, autres secteurs, dès que des humains se rassemblent (entreprises, associations, groupe informelles, listes de diffusion, équipes sportives, etc.).
Dommage pour le projet que les nuisibles restent et que les forces positives s'en aillent.
Même si c'est souvent comme cela, car les premiers ont les seconds à l'usure. Et personne n'a à être un punching ball.
Modifié le 07/09/2024 à 01h49
J'ai l'impression que vous donnez beaucoup la parole aux pro rust et juste l'avis de Linus en réponse un peu argumenté.
Vu la criticité du code et le nombre d'architectures supportées, l'argument du manque de connaissances de l'équipe historique de mainteneurs ne me semble pas déconnant. Comment peuvent ils valider les commits engageant leur responsabilité sans maitriser le langage?
M. Wedson Almeida Filho de Microsoft annonce abandoner sa participation après 4ans, c'était peut être juste un test de motivation de l'équipe kernel Linux?
Le 07/09/2024 à 18h59
Recoder en Rust, c'est la partie fun d'un projet. Maintenir le projet, c'est long et chiant. Et souvent, comme ici, les pro-rust vont arriver avec des propositions de modifs, mais c'est les mainteners qui devront rester sur le long terme et maintenir le code, qu'il n'auront pas écrit, et qu'ils auront même du mal à comprendre.
D'un point de vue long-termiste, c'est pas tenable.
D'ailleurs, je pense que les pro-rust pourront tenter de recréer un noyau from scratch en rust, mais je doute qu'ils arriveront à le maintenir sur le long terme. C'est un boulot ingrat, la maintenance.
Bref, je comprend la frustration des pro-rust, mais au lieu de soumettre du code, ils devraient devenir référent sur des parties du noyau, et maintenir ces parties, en le faisant en rust. Ca, ça pourrait fonctionner.
Le 08/09/2024 à 10h24
Ou j'ai pas compris votre propos ?
Un mainteneur peut faire de la conversion de code?
Le 10/09/2024 à 18h38
Si tu connais pas le code actuel, tu peux pas devenir mainteneur. C'est logique. Faut donc maîtriser un module, et donc le language dans lequel il est construit. Ensuite, bloc par bloc, tu peux convertir le code actuel en Rust : c'est une évolution positive (tant que ça reste à features constantes), et tu es mainteneur, donc tu prendras soin de ton code dans le futur.
C'est ça la voie à suivre.
Le 08/09/2024 à 12h07
Ça a l'air plus large si on en croit cette citation de Jeremy Soller, créateur de Redox OS (OS codé en Rust) : « Les développeurs Linux sont des mégalomanes pédants et condescendants »
Mais sur cette citation, je dirais qu'il vaut mieux éviter les généralités, d'autant qu'il y a un conflit d'intérêt car en disant ça, ça lui permet de mettre en avant son OS.
Je retiens par contre que faire co-évoluer deux technologies dans le même projet Linux, c'est peut être plus un inconvénient, même ça parait être un avantage pour la "transition". La transition peut en effet ne jamais se terminer.
Le côté redévelopper tout le noyau, ça parait tout aussi insurmontable, mais en fait je pense que ça l'est moins, car il n'y aurait pas forcément besoin de porter tout le code concernant de vieilles architectures, juste le code concernant les architectures récentes. Je trouve que c'est un projet intéressant de tout repenser à zéro. Le fait de tout repenser sur Rust plutôt que d'adapter un noyau initialement pensé pour le C vers le Rust peut éventuellement être moins complexe. Faudrait voir ce que donne des projets comme Redox ou autre.