Connexion
Abonnez-vous

Frustrations et départ dans l’équipe Rust du noyau Linux

Sans huile dans le moteur, Linux risque de rouiller

Frustrations et départ dans l’équipe Rust du noyau Linux

Photo de Mohamed Marey sur Unsplash

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

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… »

Commentaires (44)

Vous devez être abonné pour pouvoir commenter.

Abonnez-vous
votre avatar
Bientôt un fork du noyau Linux : "Linust" ? 😜
votre avatar
"Rinust" :prof:
votre avatar
La maladie associée sera vite trouvée !
votre avatar
Lirust !
votre avatar
Rustix !
votre avatar
Et quand Rustix sera aussi connu que Linux, on donnera son nom à un personnage d'Asterix, dans 30 ans à peu près.
votre avatar
Ce serait peut-etre plus sympa de commencer par ça et le personnage serait sculpteur de noyaux d'avocats .
votre avatar
Sans oublier kernelpanix
votre avatar
Windows ? (c'est trolldi, j'ai le droit :p)
votre avatar
votre avatar
Question naïve, mais ces développeurs qui se bloquent sur leur propre progression (ne veulent pas apprendre un nouvel outil) sont ils des contributeurs individuels (bénévoles) ou bien des salariés de boites genre Red Hat ?

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.
votre avatar
Les principaux développeurs du noyau linux sont employé, Ted Ts'o c'est par google.

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.
votre avatar
"C'est pas une nouvelle solution a la mode qui sera abandonné dans 3 ans."

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.
votre avatar
Le Rust du Kernel d'implémente pas tout. Je ne suis pas sûre qu'il y ait le support du parallélisme et du SIMD.
votre avatar
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.


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).
votre avatar
Non, Rust n'est pas mur. Son ABI n'est pas encore très stable dans le temps.
Dans le contexte de Rust for Linux, l'ABI n'est pas un problème. en effet le code Rust devant interagir avec du C, il utilisera l'ABI C qui est stable.
votre avatar
C'est vrai et c'est actuellement ce qui est fait. Mais c'est uniquement valable si Rust ne reste qu'un wrapper du kernel, et ne mets pas à profit certains de ses avantages pour des fonctions bas-niveau du kernel plus sensible (e.g., FS, scheduler, IPC...). à l'heure actuelle sous Linux.
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 ?
votre avatar
Pour le moment, il n'y a aucun plan pour aller au delà de l'écriture de module en Rust qui utiliseront l'ABI C. Si on arrive a avoir un nombre conséquent de drivers disponibles en Rust d'ici quelque années, ça serait déjà un très gros progrès vu que la majorité du code de Linux, c'est les drivers, et c'est la partie qui a le plus de problèmes de qualité.

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.
votre avatar
Je suis moyennement d'accord. Quand on est dans une organisation, on contribue mais on a des deadlines.
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.
votre avatar
Apprendre correctement un langage prend 5 ans environ. Moi aussi j'ai souvent voulu suivre l'évolution technologique. Mais le risque qu'un langage fasse plouf est très grand, même quand il est soutenu par de grosses entreprises.

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).
votre avatar
Pour ma part, je vois ça comme une guerre d'ego... de la part de l'équipe de Rust.

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.
votre avatar
S'ils veulent refaire un Linux Rust-Inside, bon courage quand même. La maturité de l'infra/chaîne de générations jeunes est un véritable obstacle: Linux n'est pas un projet tout neuf et il faut du stable à ce niveau sinon, au delà des querelles de chapelle du kernel c'est de toutes manières les distributions qui ne suivront pas.
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.
votre avatar
Plutôt d'accord avec toi dans l'ensemble.
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.

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)
votre avatar
Linux n'a pas besoin de pub et je ne suis pas certain que mélanger (pour longtemps, vu les volumes de code en question) Rust et C soit une si bonne idée et je comprends Tso qui ne saute pas de joie à ré-écrire un fondement comme un FS et Ext.
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.
votre avatar
Linux n'a pas besoin de pub
quand je parlais de "pub", c'était pour Rust, pas pour Linux ^^
votre avatar
"je pense que tout langage qui en rajoutera sa couche avec en prime une perte de performance, même faible"

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.
votre avatar
*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.*


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 ?
votre avatar
à ceux qui connaissent la langage, est ce que ça règles les problèmes de dépassement de tampons ou pas du tout ?
votre avatar
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.
Rust va vers ses 10 ans, c'est vrai que comparé au C c'est jeune, mais il a quand même prouvé sa stabilité. Il n'a absolument pas failli tomber après l'abandon de financement de Mozilla (contrairement a son projet jumeau Servo), car ça faisait longtemps que Mozilla avait rendu le projet indépendant et qu'il était était devenu un support minoritaire.
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.
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.
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 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.
votre avatar
Rust va vers ses 10 ans, c'est vrai que comparé au C c'est jeune, mais il a quand même prouvé sa stabilité. Il n'a absolument pas failli tomber après l'abandon de financement de Mozilla (contrairement a son projet jumeau Servo), car ça faisait longtemps que Mozilla avait rendu le projet indépendant et qu'il était était devenu un support minoritaire.
Je réagis la dessus, car je n'ai pas la même vision que toi.

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).
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.
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.
votre avatar
Il ne faut pas confondre le projet Rust et la Rust Fondation. Le projet Rust est devenu une entité hiérarchiquement indépendante de la fondation Mozilla avant la sortie officielle du langage. Mozilla n'était qu'un supporter du projet, certes vital au début, en faisant contribuer certains de ses salariés et en fournissant l'infrastructure du projet. Au fur et a mesure, d'autres sociétés ont apporté des contributeurs payés et offert accès à leurs infrastructure (Azure, AWS, ...).
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.
votre avatar
D'accord, je comprends mieux ce que tu veux dire. Merci pour tes précisions ;)
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.
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.
votre avatar
La fondation est propriétaire de la marque, mais pas du projet. Théoriquement elle pourrait forcer le projet a changer de nom et de logo mais c'est tout. Elle ne peut notamment pas imposer le développement de certaines fonctionnalités, ou imposer des personnes dans les groupes de travail du projet. Comme elle n'est pas propriétaire du code, elle ne peut pas non plus changer les licence du code.

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
votre avatar
D'accord, merci pour les précisions (oui, je sais, je me répète).

J'avoue que je ne suis pas Rust au jour le jour, donc c'est pas toujours évident d'avoir toutes les informations ^^
Théoriquement elle pourrait forcer le projet a changer de nom et de logo mais c'est tout. Elle ne peut notamment pas imposer le développement de certaines fonctionnalités, ou imposer des personnes dans les groupes de travail du projet.
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).
Comme elle n'est pas propriétaire du code, elle ne peut pas non plus changer les licence du code.
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.
votre avatar
En effet elle peut théoriquement forker et garder le nom, mais sans le projet Rust qui suit ça serait n'irait nulle part. La fondation ne gère que de l'administratif, et n'a pas les moyens humains de soutenir un tel projet. Il faudrait qu'une partie substantielle des équipes actuelles la soutienne dans la démarche.
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.
votre avatar
Ah les débats de technologies...

Pour les résumer simplement : 🖕 versus 🖕
votre avatar
Toute l'arrogance de développeurs qui confonde expérience & ego.
Ces déchets s'expriment encore plus violemment dans un contexte/repaire d'expertise, tel qu'un noyau système.

Classique.
votre avatar
ces déchets, carrement.... c'est quoi ton taf ? juste pour savoir :D
votre avatar
Ouaip, car il faut appeler les choses par leurs noms.

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.
votre avatar
Bonjour,

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?
votre avatar
Pour le coup, je comprend les deux points de vues, même si je partage plus celui des mainteners :
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.
votre avatar
Comment ces personnes peuvent devenir référent pour maintenir des parties qui ne sont pas encore en Rust puisque on ne les aide pas à les transformer en Rust?
Ou j'ai pas compris votre propos ?
Un mainteneur peut faire de la conversion de code?
votre avatar
Réponse à la dernière question qui répond à tout : oui.

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.
votre avatar
Personnellement, je comprends que l'engouement de la part des dev soit pas fou pour changer progressivement de langage, surtout un langage qui ne s'aborde pas de la même façon. Un noyau, c'est plusieurs millions de lignes de code, c'est critique, le chantier parait insurmontable quand on le dit comme ça. Maintenant, le rejet de ceux qui veulent tenter quelque chose de nouveau avec le langage Rust ne m'étonne pas vraiment. Pour en avoir fait l'expérience ici, critiquer le C, c'est s'exposer à des attaques ad hominem, et à des arguments d'autorité. Mais l'argument de dire, si ton programme n'est pas stable en C, c'est que tu es mauvais en C date depuis plusieurs dizaines d'années j'ai l'impression.

Ç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.

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

Fermer