Discussion :

[Mathis Lucas]

Le mainteneur du pilote graphique Nouveau du noyau Linux se retire du projet en �voquant � un environnement non inclusif et toxique �
tandis que le d�saccord sur l'ajout de Rust dans le noyau se poursuit

La communaut� du noyau Linux semble se d�chirer ces derniers mois. Entre autres, l'on assiste � des tensions entre les factions au sein de la communaut� du noyau et � des d�missions tr�s m�diatis�es. La derni�re personne en date � avoir quitt� le projet est Karol Herbst ; il �tait charg� du pilote graphique Nvidia � Nouveau � et de l'outil de suivi MMIO. Il a d�nonc� l'environnement toxique qui r�gne au sein de la communaut� du noyau. Avant lui, Hector Martin, fondateur et d�veloppeur principal d'Asahi Linux (le projet qui apporte Linux � Apple Silicon), a quitt� son poste en d�non�ant le leadership de Linus Torvalds et un certain nombre d'autres choses.

Karol Herbst a �t� d�veloppeur du pilote Nouveau pendant plus de dix ans. Nouveau est un projet de la fondation X.Org et de Freedesktop.org visant � produire des pilotes libres et open source pour les GPU Nvidia. Ils sont d�velopp�s principalement par r�tro-ing�nierie des pilotes propri�taires de Nvidia.

Karol Herbst a par la suite �t� embauch� par Red Hat. Bien qu'il soit plus connu ces jours-ci pour son travail sur Mesa et le pilote Rusticl OpenCL qui lui est associ�, il est rest� un mainteneur du pilote Nouveau pour le noyau Linux. Toutefois, le 15 f�vrier 2025, Karol Herbst a annonc� qu'il quittait son poste de mainteneur du pilote Nouveau en raison de divergences avec la communaut� du noyau en amont. Karol Herbst d�nonce un certain nombre de choses.

Karol Herbst d�nonce un environnement non inclusif et toxique

La d�cision de Karol Herbst est bas�e sur son m�contentement face � l'absence d'un environnement inclusif au sein du groupe de d�veloppeurs, o�, selon sa vision, la collaboration devrait �tre bas�e sur le respect mutuel et l'�quit�, sans permettre � certains pouvoirs tacites d'influencer le processus.

La controverse s'est intensifi�e apr�s qu'un autre mainteneur du noyau, Theodore Ts'o, a utilis� la m�taphore � fine ligne bleue � pour d�crire le r�le des mainteneurs, les comparant � une barri�re qui s�pare l'ordre de l'anarchie et garantit la qualit� et la durabilit� du code accept�.

Je vais vous dire un secret : les responsables de la maintenance ne sont pas � tout-puissants �. Ils constituent la � fine ligne bleue � qui tente de maintenir le code debout, abordable et de haute qualit�. Comme la plupart des dirigeants b�n�voles d'une organisation, qu'il s'agisse de l'Internet Engineers Task Force (l'organisme de normalisation d'Internet), nous n'avons en fait que tr�s peu de pouvoir.

Nous ne pouvons pas *ordonner* aux gens de travailler � l'annulation de la dette technique, � l'am�lioration de l'infrastructure de test ou au d�veloppement d'une fonctionnalit� particuli�re que nous aimerions vraiment pour nos utilisateurs. Tout ce que nous pouvons faire, c'est emp�cher que des choses soient accept�es (que ce soit dans notre sous-syst�me ou dans l'imprimatur de l'IETF). Avec un peu de chance, nous ne faisons qu'emp�cher les mauvaises choses de progresser, mais c'est *vraiment* tout ce que nous pouvons faire.

L'expression � fine ligne bleue � est la traduction litt�rale de l'anglais � Thin Blue Line �. Ce terme symbolise le r�le des forces de l'ordre comme une barri�re prot�geant la soci�t� du chaos et de la criminalit�. Toutefois, pour Karol Herbst, l'utilisation de cette analogie est � inacceptable �. Selon le mainteneur, elle peut avoir un impact n�gatif sur les personnes marginalis�es et sur la perception d'une communaut� qui devrait normalement �tre inclusive.

Karol Herbst a d�clar� que � ce langage ne cr�e pas un environnement inclusif � et a ajout� qu'un responsable qui prononce ces mots � ne peut pas �tre gard� � au sein de la communaut� du noyau Linux. Mais Karol Herbst a fait l'objet de critiques pour avoir sugg�r� de mettre � l'�cart l'auteur de ces propos.

� Thin Blue Line � : une expression entour�e de controverses

En effet, l'utilisation de � Thin Blue Line � a suscit� des controverses. Certains estiment qu'elle cr�e une division entre la police et le public, renfor�ant une mentalit� de � nous contre eux �. Ce symbole a �t� associ� � des mouvements politiques et r�cup�r� par des groupes d'extr�me droite, conduisant certaines institutions � interdire son affichage pour �viter toute pol�mique. Ainsi, la perception peut varier selon les contextes culturels et g�ographiques.

� Je ne peux pas, en toute bonne foi, continuer � faire partie d'une communaut� o� ces mots sont tol�r�s. Ces mots ne sont pas techniques, ils constituent une d�claration politique. M�me si ce n'est pas intentionnel, ces mots ont un pouvoir, ils ont une signification dont il faut �tre conscient �, a not� Karol Herbst. Il a soulign� que malgr� son d�part, le pilote Nouveau continuera � �tre maintenu par deux d�veloppeurs, qui feront � un excellent travail �.

Certains critiques ne partagent pas toutefois son avis. � J'ai l'impression que le mainteneur essayait de dire qu'en tant que mainteneurs, nous voulons essayer de garder le chaos hors du code, et malheureusement la formulation qu'il a utilis�e pour le dire �tait politiquement charg�e �, note un critique.

Le d�bat met �galement en �vidence le fait que les mainteneurs, bien qu'essentiels pour �viter d'incorporer des changements instables ou d�ficients, perdent une partie de leur influence une fois que le code est int�gr� dans le noyau, ce qui les rend responsables des cons�quences qui en d�coulent.

Ce sc�nario est aggrav� lorsque des �quipes int�ress�es uniquement par la promotion de leurs propres cr�ations disparaissent apr�s l'acceptation du code, laissant aux responsables la t�che ardue de corriger les erreurs. Il s'agit d'un probl�me r�current dans la communaut� du noyau Linux.

Lyude Paul et Danilo Krummrich, tous deux de Red Hat, restent responsables du pilote Nouveau. Les d�veloppeurs de Red Hat travaillent �galement au d�veloppement de NOVA, le nouveau pilote de noyau Nvidia open source bas� sur Rust, qui exploite l'interface GSP pour les GPU Turing et plus r�cents.

Changements � la t�te d'Asahi Linux � la suite d'une controverse

La communaut� de d�veloppement du noyau Linux semble traverser une crise et certains mainteneurs de longue date du projet l'abandonnent. � en croire les messages publi�s sur la liste de diffusion du noyau Linux, plusieurs causes profondes seraient � l'origine de cette situation : les divergences autour de l'int�gration du langage Rust dans le noyau Linux, un environnement jug� toxique et le m�contentement � l'�gard du leadership de Linus Torvalds.

Des inqui�tudes sont apparues en ao�t 2024 lorsque l'ing�nieur logiciel de Microsoft Wedson Almeida Filho s'est retir� du projet Rust for Linux, citant sa frustration face � des � absurdit�s non techniques �, ce qui est une fa�on de d�crire la difficult� de collaborer avec ceux qui ont des objectifs diff�rents.

Le probl�me s'est � nouveau pos� en janvier 2025, lorsqu'une proposition d'abstraction permettant aux pilotes de p�riph�riques �crits en Rust d'appeler l'API DMA de Linux principalement bas� sur le langage C s'est heurt�e � l'opposition ferme de Christoph Hellwig, un responsable du noyau.

Au d�but du mois, Hector Martin, chef du projet Asahi Linux, a annonc� brusquement qu'il quitte son poste. Hector Martin a d�clar� que le projet �tait � devenu moins amusant au fil du temps �, les frustrations des utilisateurs concernant la prise en charge des puces M3 et M4 et les fonctionnalit�s manquantes ayant eu raison de son plaisir. Dans son message de d�part, il a �galement d�nonc� le leadership de Linus Torvalds en mati�re de gestion du noyau.

Hector Martin a expliqu� dans son message sur la liste de diffusion du noyau : � je d�missionne de mon poste de chef du projet Asahi, avec effet imm�diat. Le projet se poursuivra sans moi. Je travaille avec le reste de l'�quipe pour g�rer le transfert des responsabilit�s et des r�f�rences administratives �.

Christoph Hellwig a assimil� le m�lange des langages Rust et C dans le noyau Linux � un � cancer � et s'oppose vivement � la fusion du code du noyau Rust. Hector Martin a d�nonc� les propos de Christoph Hellwig et le 7 f�vrier 2025, il a demand� � �tre retir� de la liste des mainteneurs de Linux.

Int�gration de Rust dans le noyau Linux : une source de conflits

L'int�gration du langage Rust dans le noyau Linux continue de cr�er des divergences d'opinions dans le rang des mainteneurs. Certains voient en Rust une opportunit� d'am�liorer la s�curit� et la robustesse de Linux, notamment gr�ce � sa gestion de la m�moire et � sa pr�vention des erreurs courantes en C. D'autres expriment des r�serves, soulignant la complexit� du langage et les risques li�s � son adoption dans un projet aussi vaste que Linux.

La principale raison d'envisager l'utilisation de Rust r�side dans ses caract�ristiques de s�curit� de la m�moire. Le noyau Linux est �crit en C, un langage qui, bien que puissant, n�cessite une gestion minutieuse de la m�moire pour �viter les bogues. Le langage Rust facilite l'�criture de codes s�rs, r�duisant potentiellement les vuln�rabilit�s et am�liorant la stabilit�. La possibilit� d'�crire des pilotes plus s�rs est donc une motivation cl� pour l'adoption de Rust.

Il n'est pas pr�vu de r��crire l'ensemble du noyau Linux en Rust, mais de l'introduire progressivement, en commen�ant par les nouveaux pilotes. Cette approche progressive vise � minimiser les perturbations et � donner aux responsables le temps de s'adapter au nouveau langage. Christoph Hellwig s'y oppose.

Il a d�clar� : � si vous voulez rendre Linux impossible � maintenir � cause d'une base de code interlangage, faites-le dans votre pilote pour que vous ayez � le faire au lieu de r�pandre ce cancer dans les sous-syst�mes centraux... Je ne veux pas qu'il s'approche d'une �norme base de code C que je dois maintenir �.

Les remarques de Christoph Hellwig contrastent avec les analyses du cr�ateur de Linux, Linus Torvalds. Il est d'avis que Rust peut aider � corriger des erreurs commises en C. Il pense que Rust est une solution d�avenir pour le d�veloppement du noyau. Ainsi, Linus Torvalds consid�re la prise en charge de Rust pour le d�veloppement du noyau Linux comme une � une �tape importante vers la capacit� d'�crire les pilotes dans un langage plus s�r �.

Plus r�cemment, Christoph Hellwig a rapport� que Linus Torvalds est favorable � l'ajout de Rust dans le noyau et veut aller de l'avant dans ce projet. Selon Christoph Hellwig, Linus Torvalds aurait d�clar� en priv� qu'il passera outre le veto des mainteneurs pour fusionner le code du noyau Rust.

Source : liste de diffusion du noyau Linux

Et vous ?

Quel est votre avis sur le sujet ?
Que pensez-vous du d�part du mainteneur du pilote Nvidia libre Nouveau pour Linux ?
Il juge la communaut� du noyau Linux non inclusive et toxique. Qu'en pensez-vous ?
Que pensez-vous des tensions au sein de la communaut� Linux, notamment au sujet de l'ajout de Rust au noyau ?
Quels impacts ces tensions pourraient-elles avoir sur le d�veloppement du noyau Linux ?

Voir aussi

Le m�lange de Rust et de C dans Linux est assimil� � un � cancer � par un responsable du noyau, � je ne veux pas qu'il s'approche d'une �norme base de code C que je dois maintenir �, dit-il � propos de Rust

Apr�s un conflit au sujet de Rust dans Linux, le mainteneur principal de la distribution Asahi Linux annonce sa d�mission du projet et d�nonce le leadership de Linus Torvalds en mati�re de gestion du kernel

Linus Torvalds envisagerait de fusionner le code du noyau Rust en d�pit des objections des mainteneurs, qui assimilent le m�lange de Rust et du C � un � cancer � qui rendrait Linux impossible � maintenir

[seb75net]

Je comprends que des d�veloppeurs qui ma�trisent le C depuis le berceau et plus est dans un �cosyst�me pratiquement enti�rement en C voient d'un tr�s mauvais oeil qu'on leurs demandent d'oublier tout ce qu'ils ont appris. Surtout qu'il va falloir avoir une double comp�tence pour maintenir des milliers de lignes de code. Linus veut donner une nouvelle attractivit� au maintien du noyau Linux mais il s'y prend peut �tre trop t�t � vouloir imposer Rust.

[St�phane le calme]

Face � la pol�mique, Linus Torvalds clarifie sa position concernant l'int�gration du code Rust dans le noyau Linux,
affirmant qu'il n'est pas question d'imposer Rust aux mainteneurs qui ne souhaitent pas travailler avec ce langage

Dans une r�cente discussion au sein de la communaut� du noyau Linux, Linus Torvalds a clarifi� sa position concernant l'int�gration du code Rust dans le noyau, en r�ponse aux objections de certains mainteneurs. Cette intervention fait suite aux pr�occupations exprim�es par Christoph Hellwig, un d�veloppeur influent du noyau, qui s'oppose � l'utilisation de Rust aux c�t�s du C traditionnel. Hellwig a notamment affirm� que l'introduction de Rust entra�nerait une fragmentation et des directives de langage ambigu�s, imposant une charge suppl�mentaire aux mainteneurs. Il a �galement rapport� que Torvalds aurait indiqu� en priv� son intention de fusionner du code Rust, m�me en cas d'opposition de la part des mainteneurs concern�s.

L�introduction de Rust dans le noyau Linux est l�un des changements techniques les plus significatifs de ces derni�res ann�es. Ce langage de programmation, r�put� pour sa s�curit� m�moire et sa modernit� par rapport au C, a suscit� un d�bat intense parmi les d�veloppeurs du noyau.

Depuis l'annonce de la prise en charge exp�rimentale de Rust dans le noyau Linux, plusieurs mainteneurs ont exprim� des inqui�tudes quant � l'impact de ce changement. Parmi eux, Christoph Hellwig a pris une position ferme contre l'utilisation de Rust, mettant en avant des arguments relatifs � la complexit� et � la fragmentation du d�veloppement du noyau.

Hellwig, connu pour ses opinions tranch�es, a notamment affirm� que l'introduction de Rust compliquerait le travail des d�veloppeurs en les obligeant � apprendre et � maintenir un deuxi�me langage aux c�t�s du C. Il a aussi insist� sur le fait que Rust apporterait une surcharge inutile pour les outils et les cha�nes de compilation, ce qui compliquerait le travail des mainteneurs. Il a d�clar� : � si vous voulez rendre Linux impossible � maintenir � cause d'une base de code interlangage, faites-le dans votre pilote pour que vous ayez � le faire au lieu de r�pandre ce cancer dans les sous-syst�mes centraux... Je ne veux pas qu'il s'approche d'une �norme base de code C que je dois maintenir �.

Dans ce contexte, Hellwig a r�cemment affirm� que Linus Torvalds lui-m�me aurait envisag� d�int�grer du code Rust dans le noyau malgr� les objections des mainteneurs concern�s :

� Certains sous-syst�mes peuvent d�cider de ne pas avoir de code Rust pour le moment, g�n�ralement pour des raisons de bande passante. C'est une bonne chose et on s'y attend �. Alors que Linus a dit en priv� qu'il allait absolument fusionner du code Rust malgr� l'objection d'un mainteneur. (Il l'a fait en priv� au cas o� vous chercheriez une r�f�rence.)

Ainsi, � partir de maintenant, en tant que d�veloppeur ou mainteneur Linux, vous devez faire face � Rust, que vous le vouliez ou non.

Cette d�claration a imm�diatement suscit� des interrogations au sein de la communaut� Linux, certains y voyant un passage en force de la part du cr�ateur du projet.

Torvalds clarifie sa position : Rust ne sera pas impos�

Face aux pr�occupations soulev�es, Linus Torvalds a rapidement r�pondu pour rectifier les d�clarations de Hellwig. Il a affirm� qu'il n'�tait pas question d'imposer Rust aux mainteneurs qui ne souhaitent pas travailler avec ce langage.

Torvalds a expliqu� que les mainteneurs ne seront pas contraints d'interagir avec du code Rust s'ils n'en voient pas l�utilit�. Cependant, cela ne signifie pas qu'ils ont le droit de bloquer son int�gration dans des domaines o� il est jug� b�n�fique.

Il a pr�cis� que la demande d�int�gration d�un module en Rust, qui �tait � l�origine du d�bat, n�avait aucune incidence directe sur le code existant maintenu par Hellwig. D�s lors, il n��tait pas justifi� que ce dernier cherche � bloquer l��volution du noyau dans ce sens.

Torvalds a �galement insist� sur un principe fondamental du d�veloppement de Linux : le pragmatisme et la flexibilit�. Selon lui, l'objectif n'est pas d'obliger quiconque � travailler avec Rust, mais de permettre � ceux qui veulent l�utiliser de le faire sans contraintes excessives.

Ci-dessous, un extrait de son courriel adress� � Hellwig :

Le fait est que la pull request � laquelle vous vous �tes oppos� n'a PAS DU TOUT TOUCH� � LA COUCHE DMA. Il s'agissait litt�ralement d'un autre utilisateur, dans un sous-r�pertoire compl�tement s�par�, qui ne modifiait pas le code que vous maintenez de quelque mani�re que ce soit... Honn�tement, ce que vous avez fait, c'est essentiellement dire "en tant que mainteneur du DMA, je contr�le ce � quoi le code DMA est utilis�".

Et ce n'est pas du tout comme cela que cela fonctionne. Quelle est la prochaine �tape ? Dire que certains pilotes ne peuvent pas faire de DMA, parce que vous n'aimez pas ce p�riph�rique, et qu'en tant que mainteneur DMA vous contr�lez qui peut utiliser le code DMA ? C'est litt�ralement exactement ce que vous essayez de faire avec le code Rust. Vous dites que vous n'�tes pas d'accord avec Rust - ce qui est tr�s bien, personne ne vous a jamais demand� d'�crire ou de lire du code Rust. Mais ensuite, vous prenez cette position pour signifier que le code Rust ne peut m�me pas utiliser ou s'interfacer avec le code que vous maintenez...

Vous n'�tes pas oblig� d'aimer Rust. Vous n'avez pas � vous en pr�occuper. Cela a �t� dit clairement d�s le d�but, personne n'est oblig� d'apprendre soudainement un nouveau langage, et les personnes qui veulent travailler uniquement en C peuvent continuer � le faire. Pour en revenir au c�ur m�me de votre d�claration :

"Le document affirme qu'aucun sous-syst�me n'est forc� de prendre Rust"

c'est tout � fait vrai. Vous n'�tes pas oblig� de prendre du code Rust, ou de vous pr�occuper du code Rust dans le code DMA. Vous pouvez l'ignorer...

On ne peut pas avoir le beurre et l'argent du beurre. Vous ne pouvez pas dire � Je ne veux rien avoir � faire avec Rust �, et dans la phrase suivante dire � Et cela signifie que le code Rust que j'ignorerai ne pourra pas utiliser les interfaces C que je maintiens �.... Ainsi, lorsque vous modifiez les interfaces C, les gens de Rust devront faire face aux retomb�es, et devront corriger les liaisons Rust. C'est un peu la promesse ici : il y a ce � mur de protection � autour des d�veloppeurs C qui ne veulent pas s'occuper des probl�mes Rust dans la promesse qu'ils n'ont pas devoir s'occuper de Rust.

Mais ce � mur de protection � va dans les deux sens. Si vous ne voulez pas vous occuper du code Rust, vous n'avez rien � dire sur le code Rust. En d'autres termes, � personne n'est oblig� de traiter avec Rust � n'implique pas que � tout le monde est autoris� � opposer son veto � tout code Rust �.

Une r�ponse loin de faire l'unanimit�

Si certains ont appr�ci� le retour plus mod�r� d'un Linus Torvalds qui aurait, selon eux, �t� plus incendiaire il y a deux d�cennies, d'autres estiment que le probl�me n'est pas r�solu en r�alit�. Nous avons par exemple ce d�veloppeur qui indique qu'il s'y prend � trop tard � (le d�bat a d�but� depuis plusieurs mois d�j�) et qu'en plus il ne r�pond pas vraiment aux arguments avanc�s :

� Le probl�me est que les d�veloppeurs C ne veulent pas maintenir le code Rust. Les d�veloppeurs de Rust disent qu'ils le feront. Le probl�me est que la r�gle de Linus dit que les d�veloppeurs C sont oblig�s de r�parer le code Rust s'ils le cassent, et donc, l'id�e que "vous ne pouvez pas contr�ler les utilisateurs de votre code" tombe � plat, parce que la r�gle de Linus dit qu'ils sont oblig�s de maintenir tous les utilisateurs de leur code, ce qui signifie maintenant qu'ils doivent maintenir le code Rust. C'est la question fondamentale que les deux parties doivent accepter. Le fait que les d�veloppeurs de R4L disent qu'ils s'occuperont du probl�me quand il sera cass� ne changera rien au fait que les r�gles de Linus disent que cela ne doit pas se produire en premier lieu. Et non seulement cette r�gle doit changer, mais les d�veloppeurs C only doivent croire que Linus ne va pas simplement revenir sur ce changement de r�gle � l'avenir. Plus Linus attendra pour r�gler ce probl�me, plus il y aura de drames et moins les gens pourront croire que Linus ne va pas simplement revenir sur ce changement � l'avenir �.

Il faut noter que l'adoption de Rust soul�ve des d�fis :

• Apprentissage du langage : Certains mainteneurs ne sont pas familiers avec Rust, et il faudra du temps pour qu�une partie significative de la communaut� Linux se l�approprie.
• Support des outils et cha�nes de compilation : Bien que Rust dispose d�un excellent �cosyst�me, son int�gration au sein des infrastructures existantes du noyau n�cessite un travail suppl�mentaire.
• �quilibre entre conservatisme et innovation : Linux a toujours �t� un projet o� le pragmatisme prime sur la mode technologique. Torvalds veut s�assurer que Rust apporte une v�ritable valeur ajout�e avant de l��tendre plus largement.

Pourquoi Rust dans le noyau Linux ?

L'adoption de Rust dans le noyau Linux repose sur plusieurs motivations majeures :

• S�curit� m�moire am�lior�e : L�un des principaux atouts de Rust est sa gestion de la m�moire s�curis�e par conception. Contrairement au C, qui repose sur une gestion explicite de la m�moire (et donc sujet � des erreurs comme les d�passements de tampon et les acc�s � des pointeurs invalides), Rust emp�che ces erreurs � la compilation. Cela permet de r�duire la surface d�attaque du noyau, particuli�rement pour les pilotes et modules de bas niveau.
• Fiabilit� et modernit� : Rust introduit des concepts modernes, tels que le syst�me de propri�t� et l�emprunt de m�moire, qui facilitent l��criture de code robuste. Pour un projet aussi critique que le noyau Linux, cela peut se traduire par une r�duction significative des bogues et des failles de s�curit�.
• Un d�veloppement plus modulaire : Rust permet de d�velopper des modules et pilotes isol�s qui peuvent coexister avec du code en C sans n�cessiter une r��criture compl�te du noyau. Cela signifie que les d�veloppeurs peuvent progressivement tester et adopter Rust sans perturber le fonctionnement global de Linux.
• L�adoption croissante dans l�industrie : De grandes entreprises technologiques, comme Google, Microsoft et Meta, soutiennent l'utilisation de Rust pour des composants critiques de bas niveau. Google, par exemple, a d�j� commenc� � utiliser Rust dans le noyau Android pour renforcer la s�curit�.

Source : Linus Torvalds

Et vous ?

Que pensez-vous des propos de Linus Torvalds ? Torvalds a-t-il raison de consid�rer que Rust doit �tre accept� m�me en cas d�opposition de certains mainteneurs ?

Jusqu�o� doit aller le consensus dans la prise de d�cision sur un projet aussi critique que le noyau Linux ?

Rust est-il r�ellement une avanc�e en mati�re de s�curit� m�moire ou pourrait-il introduire de nouvelles cat�gories de vuln�rabilit�s ?

Existe-t-il des preuves tangibles que Rust r�duit le nombre de failles exploitables dans un syst�me aussi complexe que le noyau Linux ?

Est-ce que la courbe d�apprentissage de Rust ralentira le d�veloppement du noyau, notamment pour les nouveaux contributeurs ?

Peut-on garantir que l�interop�rabilit� entre le C et Rust ne cr�era pas de nouveaux probl�mes de compatibilit� ou de performance ?

L�ajout d�un deuxi�me langage va-t-il alourdir la charge des mainteneurs et compliquer le suivi des contributions ? Comment s�assurer que les d�veloppeurs qui ne souhaitent pas travailler avec Rust ne seront pas forc�s, m�me indirectement, � le faire ?

[RenarddeFeu]

Tout a une obsolescence en informatique, m�me Linux. Les afficionados du Rust ont tout int�r�t � focaliser leurs efforts sur des projets types RedoxOS.

[djm44]

Ce qui fait que le Rust a �t� choisi l� ou d'autres ont �t� �cart�, c'est parce qu'il apportait des garanties de s�curit�s(contrairement au C++), sans sacrifier les performances et le contr�le du bas niveau (contrairement � la plupart des langages s�rs).

Mais on r�p�te sans cesse cette histoire de s�curit� avec Rust alors qu'il est parfaitement possible de faire un code s�r en C et mieux encore en C++ .
C'est une mauvaise id�e de m�langer du C et du Rust dans le noyau linux parce que ce serait plus facile si c'�tait soit tout C ou soit tout Rust. Les deux langages ne vont pas �voluer dans le m�me sens . Cela demande une double comp�tence qui va r�duire le nombre de d�veloppeurs pouvant contribuer au noyau linux. C'est cela le cancer du Rust.

[floyer]

Oui, il est possible de faire de C s�r� tous les programmes Hello world l�attestent, et � un autre bout de complexit�, SeL4 l�atteste aussi� avec une subtilit� : toute l��nergie d�pens�e � coder en C sur SeL4 est d�pens�e avec un facteur 6 ou 7 pour formaliser des �l�ments de preuve de conformit� du code C, chose qu�aucun d�veloppeur Linux ne fait.

C�t� Linux, il convient de regarder le nombre de CVE pour mauvais usage de m�moire. Certes, il aurait �t� th�oriquement possible de les �viter, mais cela reste de la th�orie remise en cause par la pratique.

Rappelons que Linux fait 28 millions de lignes de code� une erreur toutes les 10 000 (ou m�me 100 000) lignes font beaucoup de bugs.

[Uther]

Mais on r�p�te sans cesse cette histoire de s�curit� avec Rust alors qu'il est parfaitement possible de faire un code s�r en C et mieux encore en C++.

Pourtant comme je l'ai explicit� dans le premier paragraphe du message cit�, on voit bien que qu'un nombre tr�s important d'erreurs passe malgr� toute la comp�tence des gens qui d�veloppent et relisent le code de Linux (plus d'un millier de CVE l'ann�e derni�re pour les erreurs de corruption m�moire).

Les deux langages ne vont pas �voluer dans le m�me sens .

C'est pas tr�s clair pour moi ce qui est entendu par l�.

D'un point de vue logique, �videment que les langages ont des diff�rences, sinon on se serait content� d'un seul. Mais il sont interop�rables et et gardent l'objectif d'�tre adapt� au bas niveau. Je dirais m�me au contraire qu'ils se sont plut�t rapproch�s avec l'arriv�e de Rust for Linux. En effet Rust � prioris� certaines �volutions pour am�liorer l'int�gration de Rust � Linux.

D'un point de vue technique, le C de base �volue tr�s peu, et absolument pas dans un sens qui pose probl�me � Rust, au contraire. Quant � Rust, ses �volution sont tout � fait compatibles avec le C et le bas niveau, y compris en ce qui concerne l�interfa�age avec le C.

Cela demande une double comp�tence qui va r�duire le nombre de d�veloppeurs pouvant contribuer au noyau linux. C'est cela le cancer du Rust.

Si Rust a �t� choisi c'est parce qu'il est attendu qu'� terme, les b�n�fices surpassent les probl�mes que �a pose.

Vu que le choix d'utiliser d'utiliser Rust se fait par sous-syst�me selon la volont� de leurs mainteneurs, il est pr�vu que l'impact soit faible pour les mainteneurs existants. La complexit� suppl�mentaire se limitant � la transition entre les sous-syst�mes en C et ceux en Rust, travail qui est g�n�ralement � la charge du projet Rust for Linux. C'est justement ce qu'indique la r�ponse de Linus Torvalds : Christoph Hellwig se plaignait des probl�mes que Rust allait introduire en terme de maintenance alors que son sous-syst�me n'�tait absolument pas impact�. C'est le projet Rust for Linux qui a d�velopp� l'interface DMA pour Rust et �tait en charge de la maintenir.

[jbe]

"Le d�veloppement du kernel Linux continue de se faire en C et en assembleur � des langages auxquels la vieille g�n�ration est plus accoutum�e ?"

Alors qu'il faudrait �crire cela autrement :

Le d�veloppement du kernel Linux, car fortement optimis� en taille et pour la vitesse, est toujours d�velopp� en C et en assembleur - des langages que les nouvelles g�n�rations ma�trisent de moins en moins !"

[garvek]

Pour moi, passer � Rust co�te que co�te pour �viter les soucis de m�moire n'est pas la bonne solution. C'est un peu comme passer � Java en se disant que �a supprime les soucis d'allocation m�moire.

L'autre point qui me d�range aussi c'est de dire que c'est l'avenir de la programmation syst�me. Je pense qu'effectivement, au vu du nombre intimidant de failles de s�curit�s, l'attrait d'un nouveau langage qui fait miroiter l'absence de failles, a du coup un pouvoir d'attraction important. La pub faisant, c'est devenu aux yeux de beaucoup la "solution � tout".

Je ne comprends pas l'analyse qui dit que Rust est choisi pour attirer les jeunes d�veloppeurs. Dans le domaine de la Cyber oui c'est abord�, mais sinon les jeunes d�veloppeurs sont plut�t form�s au Python, et encore au C/C++ ou au Java pour beaucoup d'applications, y compris dans l'embarqu�.

Inversement, � l'heure actuelle les diff�rents programmes que j'ai pu voir en Rust ont une syntaxe vraiment tr�s contraignante et posent de s�rieux soucis de lisibilit�. De plus la toolchain est encore jeune et �volue fortement d'ann�e en ann�e.

Si l'on combine la technicit� tr�s �lev�e du code noyau, l'aspect tr�s chronophage qui n'est plus compatible avec nos modes de vie actuels et la dette technique qui peut rendre le portage ou la maintenance un calvaire, sinc�rement je ne pense pas que pour attirer les nouveaux, en particulier jeunes, est "juste" changer de langage et justifier par un gain de s�curit�.

Permettre le recours � Rust comme nouveau langage et une opportunit�, pourquoi pas, mais si c'est juste pour suivre la mode ou esp�rer que �a sauve magiquement de tous les probl�mes, �a me ressemble plus � une Rust-ine qu'autre chose (d�sol� du jeu de mots ...)

Je leur souhaite bon courage quoi qu'il en soit.

[St�phane le calme]

L'int�gration de Rust dans le noyau Linux trouve un autre soutien de poids en Greg Kroah-Hartman,
le mainteneur en chef des versions stables de Linux en souligne les avantages

Le d�bat sur la politique du noyau Linux concernant le langage de programmation Rust se poursuit... Alors que certains responsables du noyau s'y opposent, Linus Torvalds a clarifi� sa position concernant l'int�gration de Rust. Greg Kroah-Hartman, le commandant en second de Linux, est �galement un fervent partisan du code Rust pour le noyau. Il a r�dig� un autre message sur la liste de diffusion du noyau Linux soulignant les avantages de Rust et encourageant les nouveaux codes/pilotes du noyau � �tre en Rust plut�t qu'en C.

Le noyau Linux, pierre angulaire des syst�mes d'exploitation bas�s sur Unix, a longtemps �t� domin� par le langage C, r�put� pour sa puissance mais aussi pour sa complexit� et ses failles potentielles en mati�re de gestion de la m�moire. Depuis quelques ann�es, un changement majeur se dessine avec l'introduction de Rust, un langage moderne con�u pour offrir s�curit� et performance. R�cemment, Greg Kroah-Hartman, mainteneur en chef des versions stables de Linux et figure influente de la communaut�, a r�affirm� son soutien � cette int�gration, marquant ainsi une �tape d�cisive dans l'�volution du projet.

Un tournant strat�gique pour le d�veloppement du noyau

L'id�e d�introduire Rust dans le noyau Linux n�est pas nouvelle. Depuis 2021, plusieurs discussions et contributions ont permis d�explorer cette possibilit�. La version 6.1 de Linux a marqu� une avanc�e concr�te en int�grant les premi�res bases du support Rust, permettant aux d�veloppeurs d�exp�rimenter et d��valuer son apport.

Greg Kroah-Hartman, en tant que gardien du bon fonctionnement du noyau, joue un r�le cl� dans cette transition. Son soutien explicite t�moigne de la maturit� du projet et de l�acceptation croissante de Rust parmi les mainteneurs du noyau. Ce choix est motiv� par plusieurs avantages qu�offre Rust par rapport � C, notamment :

• Une s�curit� m�moire accrue : Rust emp�che les erreurs classiques de corruption m�moire gr�ce � son syst�me de gestion des emprunts et des r�f�rences.
• Une r�duction des vuln�rabilit�s : De nombreuses failles de s�curit� dans le noyau sont li�es � la gestion manuelle de la m�moire en C, un probl�me que Rust att�nue consid�rablement.
• Un code plus robuste et maintenable : Les fonctionnalit�s de Rust, comme son syst�me de types strict et son mod�le de concurrence s�curis�e, permettent d��crire un code plus fiable.

L�engagement de Greg Kroah-Hartman : un signal fort

Greg Kroah-Hartman n�est pas seulement un observateur de cette transition : il y participe activement. Son engagement en faveur de Rust t�moigne de la reconnaissance de ses b�n�fices � long terme pour le noyau Linux. Cela indique aussi que les mainteneurs les plus influents du projet sont pr�ts � soutenir cette modernisation, � condition qu�elle se fasse de mani�re progressive et bien r�fl�chie.

Son r�le en tant que mainteneur des versions stables implique qu�il veille � la fiabilit� et � la robustesse des nouvelles fonctionnalit�s introduites. Son soutien signifie donc que l�utilisation de Rust n�est pas simplement une exp�rimentation, mais bien une �volution concr�te et planifi�e du noyau.

Greg KH affirme que la grande majorit� des bogues du noyau sont dus � de � stupides petits cas de figure en C qui ont totalement disparu en Rust �. Il est tout � fait d'accord pour passer de la base de code C � un nouveau code progressivement en Rust o� ces bogues de s�curit� de la m�moire et d'autres d�fauts du C ne sont pas possibles.

Greg reconna�t que tout le code C du noyau Linux ne dispara�tra pas de sit�t, mais il esp�re que les nouveaux codes/pilotes seront en Rust afin d'�viter les bogues et les probl�mes li�s au code C.

Les r�flexions de Greg Kroah-Hartman sur le sujet

Voici l'int�gralit� du post LKML de Greg pour ceux qui sont int�ress�s par ses derni�res r�flexions sur le code Rust dans le noyau.

� En tant que personne qui a vu presque CHAQUE correction de bogue et probl�me de s�curit� du noyau depuis plus de 15 ans (avec un peu de chance, tous finissent dans les arbres stables, nous en manquons parfois lorsque les mainteneurs/d�veloppeurs oublient de les marquer comme corrections de bogue), et qui voit CHAQUE CVE du noyau �mise, je pense que je peux parler de ce sujet.

� La majorit� des bogues (quantit�, pas qualit�/gravit�) que nous avons sont dus � de stupides petits cas de figure en C qui ont totalement disparu en Rust. Des choses comme de simples �crasements de m�moire (non pas que Rust puisse les attraper tous, loin de l�), des nettoyages de chemins d'erreurs, l'oubli de v�rifier les valeurs d'erreurs, et des erreurs d'utilisation apr�s la lib�ration. C'est pourquoi je souhaite que Rust soit int�gr� au noyau, ces types de probl�mes disparaissent, permettant aux d�veloppeurs et aux mainteneurs de se concentrer sur les VRAIS bogues qui se produisent (c'est-�-dire les probl�mes de logique, les conditions de course, etc.)

� Je suis tout � fait d'accord pour faire �voluer notre base de code C afin de rendre ces types de probl�mes impossibles � rencontrer, le travail que Kees et Gustavo et d'autres font ici est merveilleux et totalement n�cessaire, nous avons 30 millions de lignes de code C qui ne vont nulle part de sit�t. C'est un effort louable qui ne va pas s'arr�ter et qui ne devrait pas s'arr�ter quoi qu'il arrive.

� Mais pour le nouveau code / les nouveaux pilotes, les �crire en Rust o� ces types de bogues ne peuvent tout simplement pas se produire (ou se produisent beaucoup moins) est une victoire pour nous tous, pourquoi ne le ferions-nous pas ? Le C++ ne va pas nous offrir cela de sit�t, et les questions du comit� du langage C++ semblent indiquer que tout le monde ferait mieux d'abandonner ce langage d�s que possible s'ils souhaitent avoir une base de code qui puisse �tre maintenue pendant un certain temps.

� Rust nous donne �galement la possibilit� de d�finir nos apis dans le noyau de mani�re � ce qu'il soit presque impossible de se tromper lors de leur utilisation. Nous avons beaucoup trop d'apis difficiles / d�licates qui n�cessitent beaucoup trop de r�vision de la part du mainteneur juste pour "s'assurer que vous avez bien compris", ce qui est une combinaison de la fa�on dont nos apis ont �volu� au fil des ans (combien de fa�ons diff�rentes pouvez-vous utiliser une 'struct cdev' de mani�re s�re ?) et de la fa�on dont le C ne nous permet pas d'exprimer les apis d'une mani�re qui les rend plus faciles/plus s�res � utiliser. Forcer les mainteneurs de ces apis � les repenser est une bonne chose, car cela nous oblige � les nettoyer pour TOUT le monde, y compris les utilisateurs de C, ce qui rend Linux meilleur dans l'ensemble.

� Et oui, les bindings Rust me semblent magiques par endroits, moi qui n'ai que tr�s peu d'exp�rience en Rust, mais je suis pr�t � apprendre et � travailler avec les d�veloppeurs qui se sont port�s volontaires pour nous aider. Il ne faut pas vouloir apprendre et changer sur la base de nouvelles preuves (voir mon point sur la lecture de tous les bogues du noyau que nous avons).

� Rust n'est pas une "solution miracle" qui r�soudra tous nos probl�mes, mais il est certain qu'il aidera dans un grand nombre d'endroits, donc pour les nouvelles choses � venir, pourquoi ne le voudrions-nous pas ? Linux est un outil que tout le monde utilise pour r�soudre ses probl�mes, et ici nous avons des d�veloppeurs qui disent "hey, notre probl�me est que nous voulons �crire du code pour notre mat�riel qui ne peut pas avoir tous ces types de bugs automatiquement".

� Pourquoi l'ignorerions-nous ?

� Oui, je comprends notre probl�me de mainteneurs surcharg�s (�tant moi-m�me l'une de ces personnes), mais ici nous avons des gens qui font r�ellement le travail !

� Oui, les bases de code en langage mixte sont difficiles � maintenir, mais nous sommes des d�veloppeurs de noyau, bon sang, nous maintenons et renfor�ons Linux depuis plus longtemps qu'on ne l'aurait cru possible. Nous avons transform� notre mod�le de d�veloppement en une merveille d'ing�nierie bien huil�e cr�ant quelque chose que personne d'autre n'a jamais �t� capable d'accomplir. L'ajout d'un autre langage ne devrait pas �tre un probl�me, nous avons g�r� des choses bien pires par le pass� et nous ne devrions pas abandonner maintenant notre volont� d'assurer le succ�s de notre projet pour les 20 prochaines ann�es. Nous devons continuer � aller de l'avant lorsque nous sommes confront�s � de nouvelles bonnes id�es, et accueillir les personnes qui proposent de nous rejoindre pour faire le travail afin de s'assurer que nous r�ussissons tous ensemble �.

Greg Kroah-Hartman : le commandant en chef de la branche stable de Linux

Une position qui n'est pas unanime

Depuis l'annonce de la prise en charge exp�rimentale de Rust dans le noyau Linux, plusieurs mainteneurs ont exprim� des inqui�tudes quant � l'impact de ce changement. Parmi eux, Christoph Hellwig a pris une position ferme contre l'utilisation de Rust, mettant en avant des arguments relatifs � la complexit� et � la fragmentation du d�veloppement du noyau.

Hellwig, connu pour ses opinions tranch�es, a notamment affirm� que l'introduction de Rust compliquerait le travail des d�veloppeurs en les obligeant � apprendre et � maintenir un deuxi�me langage aux c�t�s du C. Il a aussi insist� sur le fait que Rust apporterait une surcharge inutile pour les outils et les cha�nes de compilation, ce qui compliquerait le travail des mainteneurs. Il a d�clar� : � si vous voulez rendre Linux impossible � maintenir � cause d'une base de code interlangage, faites-le dans votre pilote pour que vous ayez � le faire au lieu de r�pandre ce cancer dans les sous-syst�mes centraux... Je ne veux pas qu'il s'approche d'une �norme base de code C que je dois maintenir �.

Dans ce contexte, Hellwig a r�cemment affirm� que Linus Torvalds lui-m�me aurait envisag� d�int�grer du code Rust dans le noyau malgr� les objections des mainteneurs concern�s :

� Certains sous-syst�mes peuvent d�cider de ne pas avoir de code Rust pour le moment, g�n�ralement pour des raisons de bande passante. C'est une bonne chose et on s'y attend �. Alors que Linus a dit en priv� qu'il allait absolument fusionner du code Rust malgr� l'objection d'un mainteneur. (Il l'a fait en priv� au cas o� vous chercheriez une r�f�rence.)

Ainsi, � partir de maintenant, en tant que d�veloppeur ou mainteneur Linux, vous devez faire face � Rust, que vous le vouliez ou non.

Face aux pr�occupations soulev�es, Linus Torvalds a rapidement r�pondu pour rectifier les d�clarations de Hellwig. Il a affirm� qu'il n'�tait pas question d'imposer Rust aux mainteneurs qui ne souhaitent pas travailler avec ce langage. Torvalds a expliqu� que les mainteneurs ne seront pas contraints d'interagir avec du code Rust s'ils n'en voient pas l�utilit�. Cependant, cela ne signifie pas qu'ils ont le droit de bloquer son int�gration dans des domaines o� il est jug� b�n�fique.

Un pas vers l�avenir du noyau Linux

L�adoption de Rust dans le noyau Linux, avec l�appui de figures influentes comme Greg Kroah-Hartman, marque une avanc�e majeure pour la s�curit� et la stabilit� du syst�me. Bien que des d�fis techniques et culturels restent � surmonter, la direction prise semble irr�versible.

Si Rust ne remplacera pas imm�diatement C, il s�impose comme un compl�ment strat�gique, apportant des garanties suppl�mentaires pour �viter les erreurs critiques. � mesure que son adoption se g�n�ralise, il pourrait devenir un �l�ment cl� du d�veloppement futur de Linux, ouvrant la voie � une nouvelle �re de programmation syst�me plus s�re et plus robuste.

Source : Greg Kroah-Hartman

Et vous ?

Que pensez-vous de l'argumentation de Greg Kroah-Hartman ?

Rust pourrait-il un jour remplacer totalement le C dans le noyau Linux, ou restera-t-il un langage compl�mentaire ?

Quels types de composants du noyau b�n�ficieront le plus de l�adoption de Rust ?

L�introduction de Rust complique-t-elle le travail des d�veloppeurs et mainteneurs du noyau, ou au contraire le simplifie-t-elle ?

Comment assurer une interop�rabilit� efficace entre Rust et le code existant en C ?

L'int�gration de Rust ralentira-t-elle les performances du noyau, ou pourrait-elle au contraire les am�liorer ?

[Uther]

Pour moi, passer � Rust co�te que co�te pour �viter les soucis de m�moire n'est pas la bonne solution.

J'ai l'impression de devoir r�p�ter tous les dix messages qu'il ne s'agit pas d'imposer Rust a marche forc�e quand on a d�j� un code C robuste, juste de l'autoriser au cas par cas pour les sous syst�mes qui en ressentiraient le besoin, particuli�rement les nouveaux drivers. Actuellement il n'est pas utilis� ailleurs que pour de nouveaux drivers. La question de remplacer le C existant n'est pas � l'ordre du jour.

C'est un peu comme passer � Java en se disant que �a supprime les soucis d'allocation m�moire.

La situation est quand m�me relativement diff�rente de Java dans le sens ou Rust est clairement un langage adapt� au bas niveau.

Inversement, � l'heure actuelle les diff�rents programmes que j'ai pu voir en Rust ont une syntaxe vraiment tr�s contraignante et posent de s�rieux soucis de lisibilit�. De plus la toolchain est encore jeune et �volue fortement d'ann�e en ann�e.

Je ne sais pas quel est ton niveau d'exp�rience avec Rust, mais je pense que c'est vraiment juste une question d'habitude. Globalement, je trouve le Rust bien plus lisible que le C.

Si l'on combine la technicit� tr�s �lev�e du code noyau, l'aspect tr�s chronophage qui n'est plus compatible avec nos modes de vie actuels et la dette technique qui peut rendre le portage ou la maintenance un calvaire, sinc�rement je ne pense pas que pour attirer les nouveaux, en particulier jeunes, est "juste" changer de langage et justifier par un gain de s�curit�.

Justement, les retours d'exp�rience de ceux qui ont d�velopp� des quantit�s de code significatives pour des drivers Rust (en particulier Asahi Lina) est que le langage leur a permis d'�tre plus productif en perdant moins de temps sur les probl�mes technique qui �taient imm�diatement identifi�s par le compilateur.

[floyer]

@garvek� Java manque d�un compilateur en langage machine et le GC est probablement inadapt� pour un syst�me d�exploitation. Rust arrive � des capacit�s proches en �tant de plus bas niveau : pas de GC, langage machine en cible mais met plus de charge pour le d�veloppeur (prise en compte des contraintes d�emprunt).

[djm44]

Je ne comprends pas l'analyse qui dit que Rust est choisi pour attirer les jeunes d�veloppeurs. Dans le domaine de la Cyber oui c'est abord�, mais sinon les jeunes d�veloppeurs sont plut�t form�s au Python, et encore au C/C++ ou au Java pour beaucoup d'applications, y compris dans l'embarqu�.

Inversement, � l'heure actuelle les diff�rents programmes que j'ai pu voir en Rust ont une syntaxe vraiment tr�s contraignante et posent de s�rieux soucis de lisibilit�. De plus la toolchain est encore jeune et �volue fortement d'ann�e en ann�e.

Je suis d'accord avec cette remarque. On est loin d'avoir une p�nurie de d�veloppeurs en C et C++. C'est plut�t du c�t� de Rust que les d�veloppeurs manquent ce qui s'explique facilement. Mais on surestime sans doute l'apport de Rust sur ses facilit�s de d�busquer les erreurs � la compilation alors qu'en C on les observe � l'ex�cution du code. On peut faire du code sur en C et C++ s'il faut le souligner. La s�curit� Rust n'est qu'un d�tail dans le processus de d�veloppement. Et le code de Rust n'est pas tr�s ergonomique c'est une �criture surcharg�e. Le C++ aussi peut aboutir � une �criture inutilement opaque.

[garvek]

@garvek� Java manque d�un compilateur en langage machine et le GC est probablement inadapt� pour un syst�me d�exploitation. Rust arrive � des capacit�s proches en �tant de plus bas niveau : pas de GC, langage machine en cible mais met plus de charge pour le d�veloppeur (prise en compte des contraintes d�emprunt).

En fait, j'avais pris l'exemple de Java car on pense souvent � ce dernier comme exemple pour mettre en avant les probl�mes de gestion m�moire du C/C++, d�sol� si je n'ai pas �t� clair ...

La situation est quand m�me relativement diff�rente de Java dans le sens ou Rust est clairement un langage adapt� au bas niveau.

Je n'ai pas d'exp�rience en Rust sur du code bas niveau, je ne l'ai vu que dans le cadre de programmes r�seau. Dans ce contexte la performance est secondaire et on empile les crates network/s�cu et les fonctions avec des contraintes dans tous les sens ... La perspective de retrouver �a ailleurs me fait un peu peur. C�t� syntaxe, je pense qu'il y a beaucoup d'habitude mais de l� � dire que c'est plus simple que le C ... (je pense notamment aux s�quences avec plein de qualifiers et de | & ...), mais plus lisible que le C++, je suis plut�t d'accord.

Justement, les retours d'exp�rience de ceux qui ont d�velopp� des quantit�s de code significatives pour des drivers Rust (en particulier Asahi Lina) est que le langage leur a permis d'�tre plus productif en perdant moins de temps sur les probl�mes technique qui �taient imm�diatement identifi�s par le compilateur.

Bon � savoir. Merci pour cette information

[smarties]

Je n'ai pas d'exp�rience en Rust sur du code bas niveau, je ne l'ai vu que dans le cadre de programmes r�seau. Dans ce contexte la performance est secondaire et on empile les crates network/s�cu et les fonctions avec des contraintes dans tous les sens ... La perspective de retrouver �a ailleurs me fait un peu peur. C�t� syntaxe, je pense qu'il y a beaucoup d'habitude mais de l� � dire que c'est plus simple que le C ... (je pense notamment aux s�quences avec plein de qualifiers et de | & ...), mais plus lisible que le C++, je suis plut�t d'accord.

Crates.io (Rust), Maven (Java), Pypi (Python), Go modules, ... Aujourd'hui, plusieurs langages ont mis � disposition un repository regroupant les biblioth�ques et les installant au niveau projet ou utilisateur. En Python (comme en Rust), je prends le temps de consulter les sous-d�pendances, la popularit� et si c'est toujours maintenu. En C ou C++ �a n'existe pas ce genre de chose au sein du dossier du projet, rien n'est automatis� et souvent, il faut chercher quelle biblioth�que il nous manque pour compiler un projet C ou C++ car de l'exp�rience que j'ai eu, dans 80% des cas certaines avait �t� oubli�es dans la doc.

[Uther]

Je n'ai pas d'exp�rience en Rust sur du code bas niveau, je ne l'ai vu que dans le cadre de programmes r�seau. Dans ce contexte la performance est secondaire et on empile les crates network/s�cu et les fonctions avec des contraintes dans tous les sens ... La perspective de retrouver �a ailleurs me fait un peu peur. C�t� syntaxe, je pense qu'il y a beaucoup d'habitude mais de l� � dire que c'est plus simple que le C ... (je pense notamment aux s�quences avec plein de qualifiers et de | & ...), mais plus lisible que le C++, je suis plut�t d'accord.

Il est vrai que parfois Rust va �tre plus verbeux que du code C simpliste, mais cette verbosit� suppl�mentaire est souvent ce qui permet d'assurer la s�curit�. Un code C aussi s�r serait probablement aussi verbeux et moins lisible.

Par exemple le Rust va obliger � prendre en compte les erreurs via le type Result<Ok,Err>, ce qui peux impliquer des ? pour remonter l'erreur ou des lambda pour les traiter, mais au final c'est bien mieux cadr� que le C qui va retourner parfois un null, parfois un code magique, ou un errno qui peuvent �tre ignor�s sans que �a soit manifestement visible.

[fdecode]

Je n'ai pas d'exp�rience en Rust sur du code bas niveau, je ne l'ai vu que dans le cadre de programmes r�seau. Dans ce contexte la performance est secondaire et on empile les crates network/s�cu et les fonctions avec des contraintes dans tous les sens ...

Comme d'autres l'ont mentionn�, le syst�me de repository de Rust (crates) qui ne m'a pas trop pos� de probl�mes de conflits jusqu'� pr�sent, am�ne � constituer les projets � partir de plusieurs crates. Il faut bien les choisir, et favoriser ce qui est �prouv�.
Par contre, la s�curisation du langage Rust et son expressivit� permettent aussi de se laisser aller � des architectures complexes pour les projets et les librairies, notamment avec un objectif de g�n�ricit�; on peut construire quelque chose de complexe sans que cela explose; car le langage et son infrastructure sont puissants. Pour autant, c'est � �viter. Je fais attention maintenant � simplifier mes approches lorsque je d�veloppe en Rust.

[floyer]

En C/C++ on peut aussi empiler des crates� sauf que cela ne s�appelle pas comme cela. Sous Linux, les biblioth�ques externes s�installent directement comme un logiciel (apt sous Debian ou Ubuntu, dnf avec les RedHat) et pkgconfig facilite la compilation avec ces biblioth�ques. Sous Windows, il y a le site vcpkg. (Mais effectivement rien de centralis� et multiplateforme).

[floyer]

Mais on surestime sans doute l'apport de Rust sur ses facilit�s de d�busquer les erreurs � la compilation alors qu'en C on les observe � l'ex�cution du code. On peut faire du code sur en C et C++ s'il faut le souligner.

Pour les probl�mes d�allocation, Rust les d�tecte � la compilation� c�est mieux qu�une erreur al�atoire � l'ex�cution qui peut passer inaper�ue.

Pour les d�passement de tableaux, il est plut�t question d�exception : une erreur franche � l�ex�cution plut�t que des effets de bords donnant un r�sultat al�atoire.

Il n�y a pas de surestimation. Cela ne couvre pas tous les causes de bug, mais un outil qui en supprime me semble pr�f�rable � un outil moins s�r.

Oui, faire du code s�r, mais sur des projets de taille modeste� � moins de consid�rer les d�veloppeurs de Linux qui y ont commis des CVE comme mauvais.

[VBurel]

Pour les probl�mes d�allocation, Rust les d�tecte � la compilation� c�est mieux qu�une erreur al�atoire � l'ex�cution qui peut passer inaper�ue.

Pour les d�passement de tableaux, il est plut�t question d�exception : une erreur franche � l�ex�cution plut�t que des effets de bords donnant un r�sultat al�atoire.

Il n�y a pas de surestimation. Cela ne couvre pas tous les causes de bug, mais un outil qui en supprime me semble pr�f�rable � un outil moins s�r.

Oui, faire du code s�r, mais sur des projets de taille modeste� � moins de consid�rer les d�veloppeurs de Linux qui y ont commis des CVE comme mauvais.

Je suis �tonn� que ces sujets soient encore d'actualit�, moi qui programme exclusivement en 'C', cela fait bien longtemps que j'ai fait une surcouche aux fonctions malloc/free et un watchdog qui v�rifie en temps r�el que je n'�cris pas en dehors de l'espace allou�.

Il y'a 20 ans le BoundChecker par exemple le faisait pour nous avec h�las trop de bug (j�ai perdu trop de temp � debugger cet outil plut�t que mes programmes), c'est pour cela que je l'ai abandonn� au profit d'une librairie personnelle (donc maitris�e). Je n'ai donc plus de probl�me de gestion m�moire, car il est d�tect�, et donc corrig� d�s qu'il apparait.

Le code "sure" ne d�pend pas du langage, il d�pend du d�veloppeur et des outils dont il se dotent pour maitriser, v�rifier et valider l'ex�cution du code. C�est �a le processus d�ing�nierie. Passer le noyaux Linux en Rust n'a aucun sens et constitue une perte de temps incroyable pour le d�veloppement de Linux au sens large. Je le rappelle le 'C' est le langage des syst�mes et des programmes ex�cut�s. Y'a aucun int�r�t � perdre son temps sur d'autres langages quand on veut s'adresser � la machine.