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 )