Discussion :

[Bruno]

Fatigue des Mainteneurs dans le Noyau Linux et rôle de l’IA dans le développement open source,
une vision partagée par Linus Torvalds au sommet Open Source de la Fondation Linux

Lors de l'Open Source Summit Japan, Linus Torvalds, le créateur de Linux, a abordé divers sujets, tels que la prochaine itération du noyau Linux, la fatigue des mainteneurs et le rôle futur de l'intelligence artificielle (IA) dans le développement open source. Il a partagé des détails sur la version 6.7 du noyau Linux, soulignant que le rôle de mainteneur exige un goût pour évaluer le code des autres et une présence constante. De plus, il a évoqué son évolution personnelle en tant que leader de projet.

Au cours du sommet Open Source de la Fondation Linux au Japon, Torvalds a discuté de la situation actuelle de Linux avec son ami proche Dirk Hohndel, responsable de l'Open Source chez Verizon. Hohndel a soulevé la question de la fatigue des mainteneurs, notant que les mainteneurs du noyau Linux se sentent de plus en plus dépassés par ce rôle essentiel et exigeant.

Torvalds a répondu en soulignant qu'il est plus facile de trouver des développeurs que des mainteneurs, et que le rôle de mainteneur nécessite un certain goût pour juger le code des autres, une qualité qui peut être innée mais nécessite également de la pratique sur de nombreuses années.

En ce qui concerne l'utilisation de Rust dans le noyau Linux, Torvalds a souligné son importance pour éviter la stagnation, anticipant son intégration progressive dans des parties importantes du noyau au cours de l'année à venir. Il a noté que bien que Rust ne se soit pas encore imposé comme la prochaine grande nouveauté, son intégration active dans les pilotes et les sous-systèmes majeurs commencera dans l'année à venir.

En parlant de l'avenir, Hohndel a évoqué les "modèles de langage à grande échelle (LLM) de l'intelligence artificielle". Torvalds a exprimé sa conviction que l'utilisation de ces modèles pour écrire du code deviendra une réalité, soulignant que l'automatisation a toujours été présente dans le domaine de la programmation.

Les deux intervenants ont également discuté du prochain lancement du noyau Linux, Linux 6.7, avec Torvalds diffusant la quatrième version candidate avant son départ pour Tokyo. En prévoyant une sortie aux alentours de la période de Noël, Torvalds a souligné l'importance de la Fondation Linux en tant qu'espace neutre favorisant la collaboration au-delà des intérêts individuels et commerciaux, expliquant ainsi sa décision de soutenir la Fondation Linux plutôt que de travailler dans une entreprise Linux.

Diversité et inclusivité au sein de la communauté du noyau Linux

La discussion entre Linus Torvalds et Dirk Hohndel au sommet Open Source de la Fondation Linux offre un aperçu intéressant des défis auxquels sont confrontés les mainteneurs du noyau Linux. La question de la fatigue des mainteneurs, soulevée par Hohndel, met en lumière un aspect crucial et souvent négligé du développement open source.

La constatation que les mainteneurs se sentent de plus en plus dépassés dans leur rôle souligne une réalité préoccupante au sein de la communauté Linux. Cela souligne également la nécessité de trouver des solutions pour atténuer la pression exercée sur ces acteurs clés du processus de développement.

La réponse de Torvalds, bien que soulignant la difficulté de trouver des mainteneurs par rapport aux développeurs, met en avant la nécessité d'avoir un "goût" pour évaluer le code des autres. Cette caractéristique, qu'il considère comme innée et nécessitant des années de pratique, pourrait être interprétée comme une barrière à l'entrée pour ceux qui souhaitent prendre en charge le rôle de mainteneur. Cela pourrait susciter des questions sur la diversité et l'inclusivité au sein de la communauté du noyau Linux, en particulier si ces qualités sont perçues comme innées plutôt que développées avec le temps.

La remarque selon laquelle il est plus facile de trouver des développeurs que des mainteneurs soulève par ailleurs des questions sur la manière dont la communauté peut encourager davantage de personnes à assumer ces responsabilités critiques. Identifier des solutions pour rendre le rôle de mainteneur plus accessible et attractif pourrait contribuer à résoudre le problème de la fatigue des mainteneurs.

La discussion entre Linus Torvalds et Dirk Hohndel expose les défis et les préoccupations valables entourant la fatigue des mainteneurs, elle soulève également des interrogations sur la manière dont la communauté peut élargir et diversifier la base de mainteneurs pour garantir la pérennité et la vitalité du noyau Linux.

Source : Vidéo

Et vous ?

Selon vous, pourquoi Torvalds considère-t-il la Fondation Linux comme un espace neutre crucial pour la collaboration au-delà des intérêts individuels et commerciaux, par rapport à travailler dans une entreprise Linux ?

Que pensez-vous la diversité et l'inclusivité au sein de la communauté du noyau Linux dans le contexte de la difficulté de trouver des mainteneurs, selon les remarques de Torvalds ?

À votre avis, quelle est la perspective de Dirk Hohndel sur les modèles de langage à grande échelle de l'IA et leur impact potentiel sur l'écriture de code, et comment cela s'aligne-t-il avec les idées de Torvalds ?

Quelles sont les implications possibles de l'intégration active de Rust dans les pilotes et les sous-systèmes majeurs du noyau Linux, telles que mentionnées par Linus Torvalds ?

Voir aussi :

Rust dans le noyau Linux: un projet prometteur, mais pas sans complications. La communauté dresse un bilan, lors de l'édition 2023 du Kernel Maintainers Summit

Trois systèmes d'exploitation Linux axés sur les jeux battent Windows 11 dans les benchmarks de jeux : Arch Linux, Pop!_OS et Nobara OS, selon les résultats des évaluations de ComputerBase

Une nouvelle mise à jour de Systemd permettra à Linux de bénéficier de l'infâme "écran bleu de la mort" de Windows, mais la fonctionnalité a reçu un accueil très mitigé

[Patrick Ruiz]

« Rust est une solution pour éviter au noyau Linux et aux mainteneurs de plonger dans la stagnation », d’après Linus Torvalds
A propos de l’impact de ce langage dans le développement du kernel

Les principaux mainteneurs du noyau Linux sont des habitués du langage C dont l’âge commence par le chiffre 5. Certains se rapprochent même de la soixantaine. Une nouvelle génération de mainteneurs dont la tranche d’âge se situe dans la trentaine gravit les échelons et donc la difficulté de trouver des mainteneurs pour le noyau Linux risque d’aller croissant si son développement se poursuit en langage C. Ce pourrait être un motif de stagnation dans le processus de développement du kernel. C’est l’une des raisons de l’adoption du Rust comme deuxième langage pour la poursuite de cette activité. En sus, il y a que « Rust est digne d'intérêt d’un point de vue technique » comme le souligne Linus Torvalds lors du récent sommet Open Source de la Fondation Linux.

En effet, il y a une liste de griefs qui reviennent à l’encontre du langage C : les problèmes liés à la gestion de la mémoire – dépassements de mémoire tampon, allocations non libérées, accès à des zones mémoire invalides ou libérées, etc. D’après les chiffres du dictionnaire Common Vulnerabilities and Exposure (CVE), 15,9 % des 2288 vulnérabilités qui ont affecté le noyau Linux en 20 ans sont liées à des dépassements de mémoire tampon.

C’est là qu’intervient le langage Rust considéré par des acteurs de la filière comme le futur de la programmation système en lieu et place du langage C ou encore comme la meilleure chance de l’industrie informatique pour la mise sur pied d’applications système sécurisées. Chez Amazon par exemple, on est d’avis que « choisir Rust c’est opter pour une meilleure sécurisation des logiciels qu’avec le C, mais une efficacité énergétique et une performance d’exécution que seul le C offre. »

En effet, certains benchmarks suggèrent que les applications Rust sont plus rapides que leurs équivalents en langage C. Et c’est justement pour ces atouts que sont la parité en termes de vitesse d’exécution en comparaison avec le C, mais surtout pour la sécurisation et la fiabilité que de plus en plus d’acteurs de la filière du développement informatique recommandent le Rust plutôt que le C ou le C++.

Ainsi, en adoptant Rust, la communauté autour du noyau Linux entend mettre à profit ces atouts du langage sur le C. Et elle devrait faire d’une pierre deux coups étant donné que Rust peut faciliter l’arrivée de nouveaux contributeurs. C’est en tout cas ce que laisse entrevoir une étude de l’université de Waterloo.

« Nous commencerons à intégrer certains pilotes et sous-systèmes développés en Rust dès l’an prochain, mais il faudra de nombreuses années avant que Rust ne constitue une grosse part de la base de code dont dépend le noyau », déclare Linus qui suscite de l’intérêt sur le bilan de cette initiative

En effet, Rust est un projet prometteur, mais pas sans complications. Le projet Rust-for-Linux a recruté un ingénieur à temps plein l’année dernière, ainsi qu’un étudiant développeur. Plusieurs entreprises ont rejoint le projet pour soutenir ce travail. Il y a aussi un travail en cours pour faire fonctionner l’outil Coccinelle avec le code Rust. Une priorité actuelle est de trouver plus de relecteurs pour le code qui est soumis.

Sur le plan de la chaîne d’outils, le travail sur gccrs, le compilateur Rust basé sur GCC, a considérablement ralenti. Le générateur de code GCC pour rustc progresse mieux ; il peut compiler du code noyau maintenant et a été fusionné dans le compilateur. Ce backend basé sur GCC permettra d’étendre le support de Rust à des architectures qui ne sont pas supportées par rustc basé sur LLVM. Pendant ce temps, le projet Rust lui-même s’implique davantage dans ce travail ; c’est une bonne chose, car le noyau a des besoins spécifiques et aura besoin de garanties que les changements de langage ne casseront pas le code du noyau à l’avenir.

Au sein du noyau, le travail se poursuit dans un certain nombre de sous-systèmes. L’implémentation Rust du binder d’Android fonctionne bien et ses performances sont équivalentes à celles de l’implémentation C. La quantité de code non sécurisé qui a été nécessaire pour y parvenir était agréablement faible. Les liaisons avec les systèmes de fichiers font l’objet d’un travail de Wedson Almeida Filho, qui vise pour l’instant un support en lecture seule. L’objectif est de rendre possible l’implémentation d’un système de fichiers en Rust 100% sécurisé.

Il y a un nombre croissant de mainteneurs qui sont ouverts à l’idée d’utiliser Rust. Cependant, ces derniers se heurtent à la non disponibilité d’exemples de la façon dont les pilotes peuvent être écrits. Un palliatif serait de permettre la duplication de quelques pilotes uniquement à des fins d’usage comme exemples pour les développeurs

Il y a en sus d’autres défis ; l’intégration des abstractions de la couche bloc a rencontré une certaine résistance. Le mainteneur de la couche virtuelle de systèmes de fichiers souligne qu’il n’était pas opposé à fusionner ces abstractions, mais qu’il préférerait ne pas le faire et voir des systèmes de fichiers construits dessus tout de suite. Il préférerait voir une implémentation de quelque chose de relativement simple, dans le style du pilote binder, pour montrer que les choses fonctionnent comme prévu.

Dave Airlie, le mainteneur du sous-système DRM (graphique), a dit que, s’il en avait le pouvoir, il y aurait un pilote DRM Rust fusionné dans les prochaines versions. Christoph Hellwig a répliqué qu’Airlie était prêt à « rendre la vie de tout le monde infernale » pour qu’il puisse jouer avec son jouet préféré. Fusionner Rust, a dit Hellwig, obligerait les autres à gérer un second langage, de nouvelles chaînes d’outils, et « des wrappers avec des sémantiques bizarres ». Dan Williams a estimé que la situation actuelle « est ce à quoi ressemble le succès », et que la communauté du noyau s’était déjà engagée en faveur de Rust.

Airlie a poursuivi en disant qu’une grande partie du travail sur Rust est actuellement bloquée dans une sorte de problème de l’œuf et de la poule. Les abstractions ne peuvent pas être fusionnées tant qu’il n’y a pas d’utilisateur pour elles, mais le code qui a besoin de ces abstractions est bloqué en attendant que le code soit intégré dans plusieurs sous-systèmes. En conséquence, les développeurs travaillant sur Rust se traînent de grandes piles de correctifs dont ils ont besoin pour travailler sur leur code. Il a suggéré qu’il serait peut-être bon de créer une branche spéciale pour le code Rust, où les abstractions pourraient être fusionnées plus facilement, en attendant qu’elles soient prêtes pour la branche principale.

Rust : oui, mais...

Greg Kroah-Hartman, le mainteneur du noyau stable, a dit qu’il n’était pas opposé à l’idée d’une branche Rust, mais qu’il faudrait qu’elle soit maintenue par quelqu’un d’autre que lui. Il a aussi demandé comment le code Rust serait testé, et s’il y aurait des outils pour vérifier la qualité du code et la conformité aux normes de codage du noyau. Ojeda a répondu qu’il y avait déjà des outils pour le formatage du code Rust, et qu’il travaillait sur un outil pour vérifier les règles spécifiques au noyau. Il a aussi dit qu’il y avait des tests unitaires pour le code Rust, et qu’il espérait que le code Rust serait intégré dans les systèmes de test existants du noyau.

Dave Chinner s'inquiète du fait que les responsables manquent d'expertise pour examiner correctement les abstractions en cours de fusion. Airlie a répondu que les responsables fusionnent désormais de nombreuses API C sans vraiment comprendre comment elles fonctionnent. De nombreuses erreurs ont été commises au cours du processus, mais « nous sommes toujours là ». Lorsque des choses s’avèrent être cassées, elles peuvent être réparées, et cela se produira plus rapidement si le code remonte en amont.

Ted Ts'o s'est dit préoccupé par le fardeau que l'ajout du code Rust imposerait aux responsables. Les développeurs de Rust établissent des normes plus élevées que celles fixées par le passé, a-t-il déclaré. Fusionner de bonnes abstractions est une chose, mais qui est responsable de la révision des pilotes et comment les modifications à l'échelle de l'arborescence seront-elles gérées ? L’effort de Rust, a-t-il dit, arrive à un point où il touche une partie croissante de la communauté.

Williams a souligné que durant la session précédente, la difficulté de faire migrer les sous-systèmes du noyau vers de nouvelles API avait été évoquée ; maintenant, dit-il, on parle de passer à un tout nouveau langage. Hellwig a déclaré que le vrai problème est que les liaisons Rust ont tendance à fonctionner différemment des API C pour lesquelles elles fournissent des abstractions ; les nouvelles API sont peut-être meilleures, mais ce sont toujours des API complètement nouvelles. Ce qu’il faudrait faire, dit-il, c’est d’abord corriger les API C afin qu’elles soient directement utilisables par le code Rust. Il a proposé que, pour chaque sous-système envisageant d'introduire du code Rust, un an ou deux soient d'abord consacrés au nettoyage de ses API dans ce sens. Ojeda a déclaré que ce type d'amélioration de l'API s'était déjà produit dans certains sous-systèmes.

Linus Torvalds a déclaré qu'il voyait un fossé entre le système de fichiers et les responsables des pilotes. Les développeurs du côté des systèmes de fichiers ont tendance à être plus conservateurs, tandis que le monde des pilotes « c'est le Far West ». Les auteurs de pilotes ont tendance à ne pas comprendre la concurrence, a-t-il déclaré, et une grande partie du code est défectueux et irréparable. Il n’est donc pas surprenant qu’il y ait un intérêt à introduire un langage qui prenne mieux en charge l’écriture d’un code correct et sûr.

Brauner a déclaré que Rust peut aider à résoudre de nombreux problèmes, car le compilateur peut empêcher de nombreux bogues de pénétrer dans le noyau. Mais il s'inquiétait de savoir s'il y aurait un support pour le mainteneur et le développement dans quelques années. Airlie a de nouveau mentionné les développeurs avec du code hors arborescence nécessaire au code Rust; Cook a répondu que les personnes qui supervisent ce code sont des responsables, et que l'introduire entraînerait les responsables avec lui. Airlie a ajouté que ces responsables sont le genre de jeunes développeurs que la communauté du noyau aimerait attirer.

Les incertitudes sur le langage

Ts'o a demandé quand la communauté se sentirait suffisamment en confiance pour pouvoir avoir des modules dont la seule implémentation est dans Rust. Binder pourrait être un bon début, a-t-il déclaré, peut-être suivi par un pilote dont l'utilisation serait plus large. Airlie a déclaré qu'il envisageait un pilote graphique virtuel qui réimplémenterait un pilote C existant. Il existe également le pilote pour les GPU Apple M1. Il ressent une forte pression pour l'amener en amont et se demande s'il y a une raison pour laquelle il devrait le garder à l'écart. Après cela, il adorerait voir une réécriture du pilote Nouveau pour les GPU NVIDIA.

Arnd Bergmann a déclaré que ces pilotes pourraient être OK, mais qu'il faudra un peu plus de temps avant que quelque chose comme un pilote de clavier puisse être fusionné ; La chaîne d'outils n'est tout simplement pas prête, a-t-il déclaré, pour un pilote qui serait largement utilisé. Cela a conduit à une question sur les mises à niveau fréquentes de version observées dans le noyau, qui est passé à Rust 1.73.0 pour 6.7. Ce processus de mise à niveau finira par s'arrêter et une version minimale de Rust sera définie une fois que les fonctionnalités importantes dont dépend le noyau se seront stabilisées. Il a déclaré qu'il travaillait pour intégrer le code du noyau dans les tests d'intégration continue de Rust afin de garantir qu'il continue de fonctionner à mesure que le compilateur et le langage évoluent.

Bergmann a déclaré qu'il n'avait pas l'intention d'examiner sérieusement le langage jusqu'à ce qu'il puisse être compilé avec GCC. Torvalds a répondu que, même s'il avait l'habitude de trouver des problèmes dans le compilateur LLVM Clang, il est désormais plus susceptible de rencontrer des problèmes avec GCC ; il construit maintenant avec Clang. Ojeda a déclaré qu'il travaillait à la recherche de ressources de développement pour gccrs ; le projet repose actuellement sur plus de 800 correctifs hors arborescence et a encore beaucoup de travail à faire en plus. Le soutien du CCG prendra du temps, a-t-il déclaré.

Ts'o s'est plaint du fait que le langage n'est toujours pas entièrement stable. Cela pourrait constituer un problème particulier pour la communauté informatique confidentielle ; ils sont préoccupés par la sécurité et, par conséquent, par les rétroportages vers des noyaux supportant à long terme. Mais si ces noyaux sont sur des versions Rust différentes, ces rétroportages seront problématiques. Ojeda a déclaré que, bien qu'il s'agisse d'une "idée folle", le rétroportage des mises à niveau de version pourrait être envisagé. Il ne pense cependant pas que le taux de changement sera suffisamment élevé pour constituer un problème.

En conclusion, Torvalds a souligné qu'il y avait eu des problèmes au fil des années avec les changements de GCC qui cassaient le noyau ; la même chose arrivera sûrement avec Rust, mais ce sera finalement la même chose. La séance, bien au fil du temps, a été interrompue à ce stade. Reste à savoir si la communauté du noyau a réellement conclu à son engagement envers Rust ; il y aura presque certainement des Pull Request ajoutant du code Rust important dans un avenir proche.

Source : Video, LWN

Et vous ?

Quels sont les avantages et les inconvénients de Rust par rapport au C pour le code du noyau ?
Pourquoi le langage C pourrait encore avoir de longues années devant lui ?
Le C a-t-il vraiment besoin d’un remplaçant en matière de programmation système ?
Le problème avec le C n’est-il pas plutôt le mauvais usage que certains développeurs en font ?
Voyez-vous des firmes comme Intel faire migrer des projets comme l’UEFI vers le Rust ? Doivent-elles plutôt envisager de passer au Rust pour leurs futurs projets ?

Voir aussi :

Programmation : une étude révèle les langages les plus voraces en énergie, Perl, Python et Ruby en tête, C, Rust et C++, les langages les plus verts

Linus Torvalds souligne une bonne avancée du langage Rust dans le développement du noyau Linux, et aurait qualifié le C++ de « langage de m... », après le message de Google

Microsoft, Google, AWS, Huawei et Mozilla s'associent pour créer la Fondation Rust, une organisation à but non lucratif chargée de gérer le langage de programmation

Facebook rejoint AWS, Huawei, Google, Microsoft et Mozilla dans la Fondation Rust, et renforce son équipe Rust par des nouveaux talents

[prisme60]

Comme toutes les nouveautés, cela se paye, mais cela est nécessaire pour avoir une amélioration de la qualité du noyau. Personnellement, je suis un fervent partisan du Rust, et des API bien construites. Une bonne API doit être intuitive et dans la mesure du possible rendre tout mauvais usage impossible. Pour un tel résultat, il faut notamment un typage fort que l'on a pas en C (C++). Le Rust sans unsafe interdit les transtypage à base de cast (comme caster un entier en pointeur, ou un pointeur d'un type dans un pointeur d'un autre type).

[JPLAROCHE]

Avoir une belle voiture au top de ses performances, répondant à ce que l'on attend d'elle, mais n'avoir qu'un seul ingénieur capable de remonter le réveil, n'est pas encourageant pour l'avenir, il est important d'activer l'engagement d'acteurs pour la suite de Linux.
ps( j'ai vécu cela )

[Patrick Ruiz]

Linus Torvalds exprime sa déception de voir le faible taux d’adoption de Rust comme langage de programmation pour le noyau Linux
Car les principaux mainteneurs du noyau sont plus habitués au langage C

Après plus de 30 ans, un deuxième langage a fait l’objet d’adoption pour le développement du noyau Linux : le Rust. Linus Torvalds vient de faire un bref état des lieux en termes d’adoption après une année : le taux d’adoption de Rust comme langage de programmation pour le noyau Linux reste faible. Le créateur de Linux a exprimé sa déception à ce propos étant donné qu’il a déjà pris position sur le sujet en soulignant que Rust est une solution pour éviter au noyau Linux et aux mainteneurs de plonger dans la stagnation.

« Je m'attendais à ce que les mises à jour [de la base de code vers Rust] soient plus rapides, mais une partie du problème réside dans le fait que les développeurs de noyau de longue date sont habitués au C et ne connaissent pas Rust. Ils ne sont pas vraiment enthousiastes à l'idée de devoir apprendre un nouveau langage qui est, à certains égards, très différent. Il y a donc eu des réactions négatives à l'égard de Rust », indique-t-il lors du dernier sommet de la Fondation Linux dédié à l’Open Source.

Linus Torvalds at #KubeCon Hong Kong today discussing #Rust in Linux kernel:

“It has taken us more than two years. We are not there yet, but it will happen!”@rustlang is already in #Linux. The main barrier is the lack of experienced Rust devs on the kernel team.… pic.twitter.com/yySHAVUsI2

— Michael Yuan (@juntao) August 23, 2024

C’est une posture compréhensible quand on se souvient que Linus Torvalds est d’avis que Rust est une solution d’avenir pour le développement du noyau Linux

La prise en charge de Rust pour le développement du noyau Linux est vue comme une « une étape importante vers la capacité d'écrire les pilotes dans un langage plus sûr. » Rust de Mozilla Research est le type de langage de programmation auquel ceux qui écrivent du code pour des systèmes d’entrée/sortie de base (BIOS), des chargeurs d’amorce, des systèmes d’exploitation, etc. portent un intérêt. D’avis d’observateurs avertis, c’est le futur de la programmation système en lieu et place du langage C. En effet, des experts sont d’avis qu’il offre de meilleures garanties de sécurisation des logiciels que le couple C/C++. Chez AWS on précise que choisir Rust pour ses projets de développement c’est ajouter l’efficacité énergétique et la performance d’exécution du C à l’atout sécurité.

En effet, il y a une liste de griefs qui reviennent à l’encontre du langage C : les problèmes liés à la gestion de la mémoire – dépassements de mémoire tampon, allocations non libérées, accès à des zones mémoire invalides ou libérées, etc. D’après les chiffres du dictionnaire Common Vulnerabilities and Exposure (CVE), 15,9 % des 2288 vulnérabilités qui ont affecté le noyau Linux en 20 ans sont liées à des dépassements de mémoire tampon.

De plus, certains benchmarks suggèrent que les applications Rust sont plus rapides que leurs équivalents en langage C. Et c’est justement pour ces atouts que sont la parité en termes de vitesse d’exécution en comparaison avec le C, mais surtout pour la sécurisation et la fiabilité que de plus en plus d’acteurs de la filière du développement informatique recommandent le Rust plutôt que le C ou le C++.

Ainsi, en adoptant Rust, la communauté autour du noyau Linux devrait mettre à profit ces atouts du langage sur le C. Et elle devrait faire d’une pierre deux coups étant donné que Rust peut faciliter l’arrivée de nouveaux contributeurs. C’est en tout cas ce que laisse entrevoir une étude de l’université de Waterloo.

Les mainteneurs pointent des raisons additionnelles comme l’instabilité de l’infrastructure Rust comme raison de poursuivre avec le C

Greg Kroah-Hartman, le mainteneur du noyau stable, a dit qu’il n’était pas opposé à l’idée d’une branche Rust, mais qu’il faudrait qu’elle soit maintenue par quelqu’un d’autre que lui. Il a aussi demandé comment le code Rust serait testé, et s’il y aurait des outils pour vérifier la qualité du code et la conformité aux normes de codage du noyau. Ojeda a répondu qu’il y avait déjà des outils pour le formatage du code Rust, et qu’il travaillait sur un outil pour vérifier les règles spécifiques au noyau. Il a aussi dit qu’il y avait des tests unitaires pour le code Rust, et qu’il espérait que le code Rust serait intégré dans les systèmes de test existants du noyau.

Dave Chinner s'inquiète du fait que les responsables manquent d'expertise pour examiner correctement les abstractions en cours de fusion. Airlie a répondu que les responsables fusionnent désormais de nombreuses API C sans vraiment comprendre comment elles fonctionnent. De nombreuses erreurs ont été commises au cours du processus, mais « nous sommes toujours là ». Lorsque des choses s’avèrent être cassées, elles peuvent être réparées, et cela se produira plus rapidement si le code remonte en amont.

Ted Ts'o s'est dit préoccupé par le fardeau que l'ajout du code Rust imposerait aux responsables. Les développeurs de Rust établissent des normes plus élevées que celles fixées par le passé, a-t-il déclaré. Fusionner de bonnes abstractions est une chose, mais qui est responsable de la révision des pilotes et comment les modifications à l'échelle de l'arborescence seront-elles gérées ? L’effort de Rust, a-t-il dit, arrive à un point où il touche une partie croissante de la communauté.

Williams a souligné que durant la session précédente, la difficulté de faire migrer les sous-systèmes du noyau vers de nouvelles API avait été évoquée ; maintenant, dit-il, on parle de passer à un tout nouveau langage. Hellwig a déclaré que le vrai problème est que les liaisons Rust ont tendance à fonctionner différemment des API C pour lesquelles elles fournissent des abstractions ; les nouvelles API sont peut-être meilleures, mais ce sont toujours des API complètement nouvelles. Ce qu’il faudrait faire, dit-il, c’est d’abord corriger les API C afin qu’elles soient directement utilisables par le code Rust. Il a proposé que, pour chaque sous-système envisageant d'introduire du code Rust, un an ou deux soient d'abord consacrés au nettoyage de ses API dans ce sens. Ojeda a déclaré que ce type d'amélioration de l'API s'était déjà produit dans certains sous-systèmes.

Linus Torvalds a déclaré qu'il voyait un fossé entre le système de fichiers et les responsables des pilotes. Les développeurs du côté des systèmes de fichiers ont tendance à être plus conservateurs, tandis que le monde des pilotes « c'est le Far West ». Les auteurs de pilotes ont tendance à ne pas comprendre la concurrence, a-t-il déclaré, et une grande partie du code est défectueux et irréparable. Il n’est donc pas surprenant qu’il y ait un intérêt à introduire un langage qui prenne mieux en charge l’écriture d’un code correct et sûr.

Brauner a déclaré que Rust peut aider à résoudre de nombreux problèmes, car le compilateur peut empêcher de nombreux bogues de pénétrer dans le noyau. Mais il s'inquiétait de savoir s'il y aurait un support pour le mainteneur et le développement dans quelques années. Airlie a de nouveau mentionné les développeurs avec du code hors arborescence nécessaire au code Rust; Cook a répondu que les personnes qui supervisent ce code sont des responsables, et que l'introduire entraînerait les responsables avec lui. Airlie a ajouté que ces responsables sont le genre de jeunes développeurs que la communauté du noyau aimerait attirer.

Ts'o a demandé quand la communauté se sentirait suffisamment en confiance pour pouvoir avoir des modules dont la seule implémentation est dans Rust. Binder pourrait être un bon début, a-t-il déclaré, peut-être suivi par un pilote dont l'utilisation serait plus large. Airlie a déclaré qu'il envisageait un pilote graphique virtuel qui réimplémenterait un pilote C existant. Il existe également le pilote pour les GPU Apple M1. Il ressent une forte pression pour l'amener en amont et se demande s'il y a une raison pour laquelle il devrait le garder à l'écart. Après cela, il adorerait voir une réécriture du pilote Nouveau pour les GPU NVIDIA.

Arnd Bergmann a déclaré que ces pilotes pourraient être OK, mais qu'il faudra un peu plus de temps avant que quelque chose comme un pilote de clavier puisse être fusionné ; La chaîne d'outils n'est tout simplement pas prête, a-t-il déclaré, pour un pilote qui serait largement utilisé. Cela a conduit à une question sur les mises à niveau fréquentes de version observées dans le noyau, qui est passé à Rust 1.73.0 pour 6.7. Ce processus de mise à niveau finira par s'arrêter et une version minimale de Rust sera définie une fois que les fonctionnalités importantes dont dépend le noyau se seront stabilisées. Il a déclaré qu'il travaillait pour intégrer le code du noyau dans les tests d'intégration continue de Rust afin de garantir qu'il continue de fonctionner à mesure que le compilateur et le langage évoluent.

Bergmann a déclaré qu'il n'avait pas l'intention d'examiner sérieusement le langage jusqu'à ce qu'il puisse être compilé avec GCC. Torvalds a répondu que, même s'il avait l'habitude de trouver des problèmes dans le compilateur LLVM Clang, il est désormais plus susceptible de rencontrer des problèmes avec GCC ; il construit maintenant avec Clang. Ojeda a déclaré qu'il travaillait à la recherche de ressources de développement pour gccrs ; le projet repose actuellement sur plus de 800 correctifs hors arborescence et a encore beaucoup de travail à faire en plus. Le soutien du CCG prendra du temps, a-t-il déclaré.

Ts'o s'est plaint du fait que le langage n'est toujours pas entièrement stable. Cela pourrait constituer un problème particulier pour la communauté informatique confidentielle ; ils sont préoccupés par la sécurité et, par conséquent, par les rétroportages vers des noyaux supportant à long terme. Mais si ces noyaux sont sur des versions Rust différentes, ces rétroportages seront problématiques. Ojeda a déclaré que, bien qu'il s'agisse d'une "idée folle", le rétroportage des mises à niveau de version pourrait être envisagé. Il ne pense cependant pas que le taux de changement sera suffisamment élevé pour constituer un problème.

En conclusion, Torvalds a souligné qu'il y avait eu des problèmes au fil des années avec les changements de GCC qui cassaient le noyau ; la même chose arrivera sûrement avec Rust, mais ce sera finalement la même chose. La séance, bien au fil du temps, a été interrompue à ce stade. Reste à savoir si la communauté du noyau a réellement conclu à son engagement envers Rust ; il y aura presque certainement des Pull Request ajoutant du code Rust important dans un avenir proche.

Source : Linus Torvalds

Et vous ?

Quels sont les avantages et les inconvénients de Rust par rapport au C pour le code du noyau ?
Pourquoi le langage C pourrait encore avoir de longues années devant lui ?
Le C a-t-il vraiment besoin d’un remplaçant en matière de programmation système ?
Le problème avec le C n’est-il pas plutôt le mauvais usage que certains développeurs en font ?
Voyez-vous des firmes comme Intel faire migrer des projets comme l’UEFI vers le Rust ? Doivent-elles plutôt envisager de passer au Rust pour leurs futurs projets ?

Voir aussi :

Programmation : une étude révèle les langages les plus voraces en énergie, Perl, Python et Ruby en tête, C, Rust et C++, les langages les plus verts

Linus Torvalds souligne une bonne avancée du langage Rust dans le développement du noyau Linux, et aurait qualifié le C++ de « langage de m... », après le message de Google

Microsoft, Google, AWS, Huawei et Mozilla s'associent pour créer la Fondation Rust, une organisation à but non lucratif chargée de gérer le langage de programmation

Facebook rejoint AWS, Huawei, Google, Microsoft et Mozilla dans la Fondation Rust, et renforce son équipe Rust par des nouveaux talents

[NotABread]

> Quels sont les avantages et les inconvénients de Rust par rapport au C pour le code du noyau ?
Pourquoi le langage C pourrait encore avoir de longues années devant lui ?
La sécurité de la mémoire et de la concurrence garanti à la compilation et sans ramasse-miette est LE point fort de Rust. Cependant, Rust reste relativement jeune et son écosystème manque de maturité (lib parfois incompatible entre elle à cause du multithreading, grosse tendance à la sur-inclusion de dépendances, beaucoup en version 0.x, pas encore de framework UI qui se soit démarqué, ...)
C ne sera pas mis au placard par Rust dans la prochaine décennie au sein de Linux pour une simple: Linux est majoritaire écrit en C et le restera car aucun ne veut tout ré-écrire en Rust.

> Le C a-t-il vraiment besoin d’un remplaçant en matière de programmation système ?
Le problème avec le C n’est-il pas plutôt le mauvais usage que certains développeurs en font ?
En théorie, on peut faire du code sûr en C, en pratique cela demande beaucoup d'effort et d'attention. Le monde est vaste et complexe, il y aura toujours un pour trouver un scénario tordu auquel le développeur n'aura pas pensé et qui causera une mauvaise manipulation de la mémoire. Même pour opensshd, logiciel solide et exemplaire, on a trouvé un scénario menant à une mauvaise manipulation de mémoire.
Il est facile de blâmer les développeurs mais ils restent humain, soumis à la fatigue, aux deadlines et aux ressources limités. L'usage d'un langage garantissant sûreté de la mémoire et performance permet de combler le manque d'attention ou de forcer la main sur les problèmes mémoires.

> Voyez-vous des firmes comme Intel faire migrer des projets comme l’UEFI vers le Rust ? Doivent-elles plutôt envisager de passer au Rust pour leurs futurs projets ?
Pour l'UEFI, BIOS, driver et microcode, oui, cela fera sense car se sont des parties critiques pour un OS, mais aussi parce que sont des programmes très isolé du reste en dehors de ce qu'ils exposent.
Pour des logiciels plus orienté utilisateur (tableur, logiciel de peinture, calculatrice, ...), non car tant que la haute performance et la stabilité ne sont pas primordiales (et que l'écosystème de Rust ne sera pas mature) il n'y a pas de raison à privilégier python ou un kit webapps à Rust

[23JFK]

La syntaxe de Rust est un peu dégueulasse, elle reprend des vieux concepts de vieux langages qui ont justement pour partie périclité à cause de ces syntaxes.

[NotABread]

@23JFK Qu'est-ce qui fait vieux/dégueulasse dans la syntaxe Rust ? As-tu un exemple que tu considères plus modern/exemplaire ?

[23JFK]

...

Le genre lambda calcul avec les closures, le mot redondant let : ; les tuples ; les types... C'est un genre, mixe-up d'Ocamel et de ce qui a précédé ; ça ne peut pas plaire à tout le monde, et en l'occurence, ça ne plaît pas des masses à la génération qui est actuellement en train de coder le noyau.

[floyer]

Lambda calcul avec closure, tuples… ce sont des éléments de sémantique, pas de syntaxe. (La syntaxe c’est plutôt le choix des accolades, begin/end, parentheses…). Et ce n’est pas parce que le lambda calcul ou les tuples (proposé par Python d’ailleurs) datent de 1958 avec Lisp que c’est une mauvaise chose.

Les types… comment un langage peut être sûr en vérifiant la cohérence à la compilation des types sans cela ? Et côté performance, il faut bien des types statiques comme en C. Non je ne vois pas où est le procès.

Le typage dynamique (Lisp, Python, Javascript…) c’est bien pour des scripts, du prototypage… dès que l’on fait des choses plus sérieuses, le typage statique (Typescript…) s’impose, et dans les langages assez modernes, l’inference de type évite que ce soit trop une gêne.

En quoi let est redondant… il indique la déclaration d’une variable par opposition a une affectation qui ne marche qu’avec des variables déjà crées. Cette distinction contribue aux vérifications sémantiques et permet de détecter des erreurs. Par ailleurs il permet l’inférence de type (let a=42)… évitant de devoir préciser le type si celui inféré est adéquat.

[23JFK]

...

C'est la syntaxe de ces trucs qui est mal foutu, et parfois le truc en lui-même qui est sans grand intérêt... Mais si vous êtes fan de Rust vous ne pouvez pas y voir les défauts que d'autres y voient.

[d_d_v]

Le minimum auquel je m'attend de la part d'un nouveau langage, c'est que la syntaxe soit agréable et intuitive. Rien que de voir des exemples de manipulation de chaînes, désolé, mais ça ne va pas le faire.

[floyer]

La syntaxe de Rust ne me semble pas parfaite non plus (je pense qu’il faut un peu d’habitude). Notamment pour les chaînes de caractères (où il y a pas mal de & à placer ici où là).

Mais critiquer la syntaxe avec let et les tuples alors que c’est assez naturel:

let tuple = ('Hello', 5, 3.14);

Je pense que l’exemple est fort mal choisi.

Bon évidemment tuple.0 surprendra le programmeur Python (habitué à tuple[0]). Mais pas de quoi disqualifier le language.

[23JFK]

...

Pour le let, c'est surtout qu'il faille saisir 3 lettres à chaque fois... il ne semble pas y avoir d'opérateur séquentiel comme en C : pour être clair sa donne des trucs du genre ("en C" int a, b, c, d ; "en Rust" let a : u64 let b : u64 let c : u64 let d : u64 ) Désolé, mais à la fin, c'est le C qui gagne.

[floyer]

Effectivement, si taper des lettres de plus t’est pénible, le C est peut-être préférable (peut-être lorgner sur APL réputé plus compact ?). Mais les constructions de plus haut niveau (pas de malloc à transtyper), free implicite, etc font que le language présente des avantages. J’avoue que j’aurais a priori plus confiance pour du code en Rust qu’en C. S’il compile, tu as déjà une partie des bugs potentiels détectés. Les autres aspects me semblent un peu secondaires.

(J’utilise actuellement plutôt OCaml qui est assez efficace, même si moins que C/Rust, mais présente le bon niveau d’abstraction).

[NotABread]

Je trouve la comparaison un poil injuste dans la mesure où le cas idéal de Rust est d'user de l'inférence de type alors qu'en C, on préféra expliciter le type.
Donc, en utilisant le typage automatique, Rust fait gagner une lettre (auto fait parti du standard 23 de C). Quite à pousser le vise sur le nombre de lettre, on peut compter le nombre de lettre des types de base:
- 'double' => 'f64'
- 'float' => 'f32'
- 'unsigned long long int' => 'u64'.
Bref, je trouve l'argument un peu léger, je ne pense pas qu'un code C en équivalent Rust soit significativement plus long pour le rayer des potentiels remplaçant de C.
Par contre mentalement, ça peut être agaçant de taper trois fois les même lettres partout dans le code.

[floyer]

Il me semble que les int du C sont propres à l’implémentation. Si je veux vraiment du 64 bits (pour des échanges avec le réseaux selon un protocole donné), j’utiliserai int64_t ou uint64_t comme équivalent des i64 ou u64 de Rust. (Cela reste plus long et il faut le include stdint.h).

[Pyramidev]

Pour le let, c'est surtout qu'il faille saisir 3 lettres à chaque fois... il ne semble pas y avoir d'opérateur séquentiel comme en C : pour être clair sa donne des trucs du genre ("en C" int a, b, c, d ; "en Rust" let a : u64 let b : u64 let c : u64 let d : u64 ) Désolé, mais à la fin, c'est le C qui gagne.

En Rust, on peut écrire :

Code Rust :

Sélectionner tout - Visualiser dans une fenêtre à part

1
2
3
4
5
6
7
8
9
10
fn main() {
    let (a, b, c, d);
    a = 1;
    b = 2;
    c = 3;
    d = 4;
    for (id, value) in [("a", a), ("b", b), ("c", c), ("d", d)] {
        println!("{id} == {value}");
    }
}

On peut aussi écrire :

Code Rust :

Sélectionner tout - Visualiser dans une fenêtre à part

1
2
3
4
5
6
fn main() {
    let (a, b, c, d) = (1, 2, 3, 4);
    for (id, value) in [("a", a), ("b", b), ("c", c), ("d", d)] {
        println!("{id} == {value}");
    }
}

[archqt]

Ils auraient du reprendre la syntaxe du C++ pour les éléments de base, un peu comme Dart.

Puis rajouter toutes les sécurités du Rust dedans, c'est vrai que c'est toujours pénible de devoir apprendre de nouvelles syntaxes.

Sinon y a t il un document syntaxe Rust avec son équivalent C++. C'est comme cela que j'avais appris le C, on avait en école d'ingénieur un livre qui demandait de faire des exercices du Pascal (fait en classe prépa et avant) en C, sur plein de problèmes concrets.

[NotABread]

J'en ai trouvé un, mais je doute qu'il soit exhaustif.
https://medium.com/programming-conce...s-edce2f93271c

Je rajouterai aussi que Rust ne permet pas l'héritage (le plus proche, c'est d'étendre un trait, aka dire que l'implémentation du trait C requière le trait A et B)