IdentifiantMot de passe
Loading...
Mot de passe oublié ?Je m'inscris ! (gratuit)

Vous êtes nouveau sur Developpez.com ? Créez votre compte ou connectez-vous afin de pouvoir participer !

Vous devez avoir un compte Developpez.com et être connecté pour pouvoir participer aux discussions.

Vous n'avez pas encore de compte Developpez.com ? Créez-en un en quelques instants, c'est entièrement gratuit !

Si vous disposez déjà d'un compte et qu'il est bien activé, connectez-vous à l'aide du formulaire ci-dessous.

Identifiez-vous
Identifiant
Mot de passe
Mot de passe oublié ?
Créer un compte

L'inscription est gratuite et ne vous prendra que quelques instants !

Je m'inscris !

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

Le , par Mathis Lucas

102PARTAGES

8  0 
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é.

Citation Envoyé par Theodore Ts'o


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...
La fin de cet article est réservée aux abonnés. Soutenez le Club Developpez.com en prenant un abonnement pour que nous puissions continuer à vous proposer des publications.

Une erreur dans cette actualité ? Signalez-nous-la !

Avatar de Uther
Expert éminent sénior https://www.developpez.com
Le 24/02/2025 à 1:04
Citation Envoyé par djm44 Voir le message
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).

Citation Envoyé par djm44 Voir le message
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.

Citation Envoyé par djm44 Voir le message
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.
5  2 
Avatar de Uther
Expert éminent sénior https://www.developpez.com
Le 24/02/2025 à 18:36
Citation Envoyé par garvek Voir le message
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.

Citation Envoyé par garvek Voir le message
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.

Citation Envoyé par garvek Voir le message
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.

Citation Envoyé par garvek Voir le message
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.
5  2 
Avatar de djm44
Membre régulier https://www.developpez.com
Le 25/02/2025 à 0:26
Citation Envoyé par garvek Voir le message

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.
4  1 
Avatar de Uther
Expert éminent sénior https://www.developpez.com
Le 25/02/2025 à 10:42
Citation Envoyé par garvek Voir le message
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.
4  1 
Avatar de Uther
Expert éminent sénior https://www.developpez.com
Le 03/03/2025 à 7:47
Citation Envoyé par VBurel Voir le message
Une condition qui ferait venir des développeurs (comme moi ou d’autre) c’est d’avoir une gestion de projets aboutie, ou l'on peut monter des fichiers sources (généralement sur disque réseau local) et définir des options de compilation pérennes.
C'est la base de ce que permet un IDE non ? J'ai pas utilisé énormément d'IDE pour C, mais il me semble bien que Qt Creator ou Code::Block proposent ça. Même VS Code avec juste quelque plugins peut faire ça.

Citation Envoyé par VBurel Voir le message
Le but étant d’avoir une espace de travail ou l’ont construit des projets dans la durée, qu’on peut faire évoluer dans un univers cross-plateforme, comme on peut le faire avec XCODE et VisualStudio par exemple.
Pour le coup Visual Studio et XCode, c'est plutôt l'inverse de la portabilité vu qu'au contraire ils sont taillés respectivement pour Windows et Mac.

Après si tu veux que ça soit l'IDE qui gère le build et pas les Makefile via les différents outils pour les générer (autotools, CMake, ...), en effet il va y avoir un soucis, car c'est revoir tout le modèle de développement de Linux.
Si as peur des impacts potentiels de Rust dans le noyau, je pense que tu n'es pas prêt au bordel que ça serait pour les mainteneurs actuels de changer le mode de build de milliers de projets.

Citation Envoyé par VBurel Voir le message
Pour moi c’est le prérequis pour faire venir des légions de développeurs sur linux, et le fait que ce ne soit pas déjà fait, comme une priorité première, est un très mauvais signal. Ca veut dire qu’il n’y a personne qui comprend les besoin des développeurs d’applications…
Bah pour le coup Rust est donc un très bon moyen de faire venir des développeurs sur Linux vu qu'il propose un écosystème cohérent, un système de build standard, une arborescence claire et efficace, un analyseur qui peut être facilement branché sur un IDE pour qu'il gère le langage.

Citation Envoyé par VBurel Voir le message
Dans ce contexte, les débats sur la sécurisation de la mémoire ou l’implémentation d’autre langage que le C ou le C++ paraissent totalement hors sujet.
Tu mélanges encore le noyau et un OS en général. Une distribution Linux c'est des milliers de projets qui sont très décorrélés au niveau de la gestion de l'effort, le noyau n'étant que l'un d'entre eux. Déshabiller un projet ne permettra pas d'améliorer l'autre.
D'ailleurs la très très très très grande majorité du travail actuel rien que sur le noyau ne concerne pas l'introduction de Rust. Ne parlons même pas d'une distribution dans son ensemble.

Citation Envoyé par VBurel Voir le message
La portabilité n'est pas une question. Je parle de la capacité de gérer des projets avec des sources éparpillés sur des disques locaux ou réseaux (possiblement utilisé dans d'autres projets sur d'autre plateforme) et avoir un projet de compilation comme on a sur tout IDE Visual ou XCode, et ca a commencé avec Borland C++ et Visual en 1995 ou par là.
Je sais pas si tu te rends compte que tu ériges un besoin très spécifique qui ne doit vraiment pas concerner grand monde comme la condition de succès absolue d'un écosystème. Pas grand monde ne travaille avec le source sur des lecteurs réseau de nos jours, on utilise des dépots de git, svn ou autre.
D'ailleurs un lecteur réseau étant montable comme n'importe quel répertoire, je vois pas pourquoi, n'importe quel IDE ne pourrait pas faire ça.
3  0 
Avatar de floyer
Membre éclairé https://www.developpez.com
Le 23/02/2025 à 21:43
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.
5  3 
Avatar de floyer
Membre éclairé https://www.developpez.com
Le 25/02/2025 à 11:58
Citation Envoyé par djm44 Voir le message
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.
3  1 
Avatar de floyer
Membre éclairé https://www.developpez.com
Le 09/03/2025 à 12:06
D’ailleurs en parlant d’éditeurs de logiciels qui ont des produits sous Linux, on peut citer JetBrains. JetBrains est une référence en matière d’IDE dans une multitude de langages. Difficile de considérer qu’il n’existe pas d’IDE valables sous Linux.
2  0 
Avatar de floyer
Membre éclairé https://www.developpez.com
Le 24/02/2025 à 20:14
@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).
1  0 
Avatar de fdecode
Membre habitué https://www.developpez.com
Le 25/02/2025 à 11:03
Citation Envoyé par garvek Voir le message
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.
1  0