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 !

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

Le , par Patrick Ruiz

59PARTAGES

11  1 
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

Hector Martin, chef de projet d'Asahi Linux, a annoncé sa démission du projet. Il blâme entre autres le manque de soutien de Linus Torvalds en matière d’intégration du code Rust dans le noyau open source. La situation part de l'opposition de Christoph Hellwig (mainteneur principal du noyau) à un correctif proposé le mois dernier par Hector Martin et qui devait permettre aux pilotes de périphériques écrits en Rust d'appeler l'API DMA du noyau, principalement basé sur le langage C, qui alloue et mappe des régions de mémoire pour l'accès direct à la mémoire. Des observateurs sont d’avis que ces oppositions entre mainteneurs C et Rust n’auraient pas lieu si les décideurs du noyau Linux avaient opté pour la conversion du code C du kernel vers du C++ moderne.

« Je démissionne de mon poste de chef du projet Asahi Linux, avec effet immédiat. Le projet continuera sans moi et je travaille avec le reste de l'équipe pour gérer le transfert des responsabilités et des références administratives. Mon Patreon personnel sera mis en pause, et ceux qui m'ont soutenu personnellement sont encouragés à transférer leur soutien à l'Asahi Linux OpenCollective (GitHub Sponsors ne me permet pas de mettre unilatéralement en pause les paiements, mais mes sponsors seront notifiés de ce changement afin qu'ils puissent annuler manuellement leur parrainage).

Je tiens à remercier toute l'équipe d'Asahi Linux, sans qui je ne serais jamais arrivé à rien tout seul. Vous savez tous qui vous êtes. J'exprime également ma plus grande gratitude à tous mes sponsors Patreon et GitHub, qui ont fait de ce projet une réalité viable au départ », annonce-t-il.



Linus Torvalds est d’avis que Rust est une solution d’avenir pour le noyau Linux

Il 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. » 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.


Certains intervenants pensent que le choix de Rust est une erreur et que C++ moderne est une meilleure alternative

« Maintenant, "pourquoi pas Rust" ? Tout d'abord, Rust utilise une syntaxe différente (souvent, à mon avis, gratuitement), et non seulement tous les développeurs du noyau devraient se familiariser intimement avec la syntaxe afin d'obtenir le même type de "feeling" que nous avons pour le C, mais convertir du code C en Rust n'est pas quelque chose qui ne peut être fait par les développeurs du noyau qu'au coup par coup, alors qu'avec quelques nettoyages le code C existant peut être compilé en C++.

Cependant, je ne suis pas d'accord avec certaines des conclusions de David. en fait, je crois que David est inutilement pessimiste, du moins en ce qui concerne le C++ moderne.

Notez que personne de sain d'esprit ne s'attend à utiliser toutes les fonctionnalités de C++. Tout comme nous avons le "kernel C" (actuellement un sous-ensemble de C11 avec un avec un ensemble relativement large d'extensions spécifiques au compilateur), nous aurions le "noyau C++", que je suggère d'être un sous-ensemble strictement défini de de C++20, combiné à un ensemble similaire d'extensions de compilateur). Je me rends compte que que la prise en charge du C++20 par les compilateurs est encore très récente pour des raisons évidentes, de sorte qu'au moins une partie de ce qui précède est tournée vers l'avenir », souligne le développeur Linux – Peter anvin.

Jiri Slaby de SUSE Lans s'est prononcé en faveur de cette initiative C++ pour le noyau Linux. David Howells de Red Hat s'est également prononcé en faveur de cette approche.

Source : Annonce

Et vous ?

Partagez-vous les avis selon lesquels le choix de Rust comme langage de développement du noyau est une erreur ? Voyez-vous le C++ moderne comme meilleure solution aux questions d’évolution du noyau ?

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
Vous avez lu gratuitement 2 articles depuis plus d'un an.
Soutenez le club developpez.com en souscrivant 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 20/02/2025 à 10:59
Citation Envoyé par d_d_v Voir le message
J'avais écrit sur un autre fil que seuls les incompétents ou très très débutants écrivaient du c++ avec une écriture non "sécurisée" (pas de conteneurs STL, pas de shared pointeurs), et on m'a répondu qu'on ne pouvait pas faire confiance dans le développeur.
Ce qui fait toute la différence entre Rust et C++ au niveau de la sécurisation, c'est qu'elle est opt-in en C++ alors qu'elle est opt-out en Rust.

Même si l'on considérait que la STL et les smart pointers sont memory safe (ce qui n'est pas le cas), il faudrait toujours s'assurer de bien les employer, tout le temps. En C++, quand on sort des clous par erreur, le plus souvent, rien ne nous l'indique. Il ne s'agit pas que d'un problème de débutant, même un développeur expérimenté finit par faire des erreurs, car il n'y a pas de démarcation précise entre ce qui est sûr et ce qui ne l'est pas.

En Rust, par défaut, tout est sécurisé d'un point de vue mémoire. il est peu probable d'écrire unsafe { x.get_unchecked(i) } en toute lettre, sans que l'auteur ne se rendre compte qu'il est en train de faire quelque chose de potentiellement dangereux, et que le relecteur n’identifie immédiatement le risque. Si on travaille avec des gens auquel on ne fait pas assez confiance (qui n'ont probablement pas besoin de code unsafe), il y a moyen de verrouiller son usage dans le projet, ou forcer à documenter chaque utilisation pour expliquer ce qui permet de vérifier que l'utilisation est correcte.
6  0 
Avatar de Uther
Expert éminent sénior https://www.developpez.com
Le 22/02/2025 à 6:18
Citation Envoyé par djm44 Voir le message
Il me semble qu'il est possible d'écrire un code exact en C ou dans un autre langage.
En théorie, avec des développeur parfait, oui. Mais dans la pratique, même les meilleurs développeurs font des erreurs. L'historique de Linux parle de lui-même : 1020 CVE pour des erreurs de corruption mémoire ont dû être corrigées l'année dernière. Utiliser un langage qui empêche par défaut certains types d'erreurs dont la corruption mémoire est un gros avantage.

Citation Envoyé par djm44 Voir le message
Beaucoup de publicités sont faites sur ce langage Rust auquel je n'adhère pas. Il y a déjà une profusion de langages qui nuit à la simplicité des approches . Chez Mozilla c'est Rust, chez Google c'est Go, chez Apple c'est Swift. Sur le web c'est Java, JavaScript, PHP.
Le terme publicité est très mal adapté. Rust a ses défenseurs qui apprécient ses qualités, mais il n'est pas la propriété d'une société qui aurait besoin qu'il soit largement adopté pour l'écosystème qu'elle distribue comme Apple avec Swift, ou Microsoft avec C#.
Mozilla à participé aux débuts du langage, mais il n'en a jamais particulièrement fait la promotion. Rust était déjà un projet indépendant de la fondation Mozilla lors de sa sortie officielle, il y a dix ans. Ca fait un moment que la contribution de Mozilla à Rust est anecdotique.

Citation Envoyé par djm44 Voir le message
Et finalement le mieux c'est encore le C ou mieux encore le C++ à mon avis vu le nombre de codes existants . Linus Torvalds devrait passer au C++ mais il a une aversion pour ce langage ce qui le pousse vers Rust.
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).
7  1 
Avatar de Pyramidev
Expert éminent https://www.developpez.com
Le 16/02/2025 à 1:07
Citation Envoyé par d_d_v Voir le message
pourquoi ne pas inventer des extensions aux langages existants pour expliciter l'utilisation obligatoire d'un code securisé
Dans le cas du C++, c'est techniquement possible, mais le comité C++ a refusé.
Le 11 septembre 2024, Sean Baxter avait proposé Safe C++.
Le 15 octobre 2024, pour contrer Sean Baxter, Herb Sutter a proposé d'ajouter des principes qui empêchent C++ d'avoir un sous-ensemble à la fois performant et sécurisé : P3466R0 "(Re)affirm design principles for future C++ evolution".
Le 24 octobre 2024, Sean Baxter a argumenté contre ces nouveaux principes ainsi que contre la proposition des "Safety Profiles" de Bjarne Stroustrup : Why Safety Profiles Failed.
En novembre 2024, le comité C++ a voté pour ces nouveaux principes à 29 voix pour, 22 neutres et 2 contre : Trip report: November 2024 ISO C++ standards meeting (Wrocław, Poland).
Le destin du C++ a été scellé.
5  0 
Avatar de d_d_v
Membre expérimenté https://www.developpez.com
Le 20/02/2025 à 10:09
Citation Envoyé par fdecode Voir le message
Et qui ferait ça? un débutant en programmation Rust?

En Rust, on évite de programmer en unsafe, quand on est un programmeur confirmé. D'une part, parce qu'on maitrise le paradigme de programmation safe par défaut, d'autre part parce qu'on a appris à minimiser l'usage d'unsafe.
J'avais écrit sur un autre fil que seuls les incompétents ou très très débutants écrivaient du c++ avec une écriture non "sécurisée" (pas de conteneurs STL, pas de shared pointeurs), et on m'a répondu qu'on ne pouvait pas faire confiance dans le développeur. Je ne vois donc pas pourquoi il en serait autrement en rust. Ca fait plus de 20 ans que j'ai travaillé sur plusieurs projets, et à chaque fois, dès que des facilités non recommandées sont offertes dans le langage, il y a toujours des gens qui les utilisent. Ca peut être quelqu'un d'incompétent, ou alors pour corriger un problème en quatrième vitesse en mettant un TODO qui restera ad vitam æternam dans le code, par exemple, ou alors un développeur qui se barre du projet dans une semaine et qui bacle ou sabote le code avant de partir.
Tu peux être sûr et certain, que si une facilité existe, elle sera utilisée, quel que soit le langage.
5  2 
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 Uther
Expert éminent sénior https://www.developpez.com
Le 17/02/2025 à 10:11
Tu penses a quoi précisément? Pour le moment le C++ n'a pas intégré grand chose qui vienne de Rust, c'est plutôt l'inverse.

Il y a plusieurs projets qui visent à reprendre des choses du Rust (SafeCpp, Carbon, FrontCpp, ...), mais rien qui ne semble concerner le C++ officiel pour le moment. Les profiles sont ce qui s'en rapproche le plus mais ça reste très nébuleux et ça n'arrivera pas avant dans quelques années.
2  0