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.