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 !

Linus Torvalds envisagerait de fusionner le code du noyau Rust en dépit des objections des mainteneurs,
Qui assimilent le mélange de Rust et du C à un « cancer » qui rendrait Linux impossible à maintenir

Le , par Mathis Lucas

15PARTAGES

6  1 
Linus Torvalds annonce que Rust for Linux est susceptible d’être prêt pour la version 5.20 du noyau
Dans un contexte où le langage Rust apparaît comme candidat idéal à la mise au rebut du langage C

Les principaux mainteneurs du noyau Linux ont un âge qui commence par le chiffre 5. Certains se rapprochent même de la soixantaine. Du coup, la communauté du célèbre noyau open source commence à penser au changement de générations. Une nouvelle dont la tranche d’âge se situe dans la trentaine gravit les échelons, mais comme Linus lui-même le souligne : « Il s'avère qu'il est vraiment difficile de trouver des personnes qui sont des mainteneurs » ; un fait lié à ceci que le développement du kernel Linux continue de se faire en C et assembleur – des langages auxquels la vieille génération est plus accoutumée ? C’est une possibilité et elle est susceptible d’expliquer pourquoi 2022 pourrait être l’année du langage Rust au sein du noyau Linux. Linus Torvalds annonce en effet que Rust for Linux est susceptible d’être prêt pour la version 5.20 du noyau.

Linus Torvalds et Dirk Hohndel ont eu leur habituelle échange lors d’une session de l’édition 2022 de l’Open Source Summit. Linus Torvalds commentait alors sur les évolutions du projet Rust for Linux en soulignant qu’il est susceptible d’être prêt pour Linux 5.20. Les publications de Miguel Ojeda, chef du projet Rust for Linux, avait déjà permis de dresser une liste des progrès de l’initiative : support d’un compilateur Rust bêta, test du support des architectures ARM et RISC-V, nouvelles abstractions Rust, etc.


15,9 % des 2288 vulnérabilités qui ont affecté le noyau Linux en 20 ans (chiffres du dictionnaire Common Vulnerabilities and Exposure (CVE)) sont liées à des tares que traînent le langage C : 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. Linus Torvalds s’est penché il y a peu sur un potentiel problème de sécurité avec les fonctions primitives d'exécution spéculative de la liste liée du noyau écrit en ANSI C. C’est en corrigeant ce problème qu’il s’est rendu compte qu’en C99 l'itérateur passé aux macros de parcours de liste doit être déclaré dans une portée en dehors de la boucle elle-même. C’est de ce constat que venait sa récente décision de faire passer le noyau Linux au C moderne (C11) dont la normalisation est achevée en 2011. C’est le genre de raisons techniques susceptibles de justifier la mise au rebut du langage C au profit du Rust pour le développement du noyau sur le long terme.

La nouvelle arrive dans un contexte où le regard de Linus Torvalds sur le langage Rust a changé. En effet, la prise en charge de Rust pour le développement du noyau Linux commence à prendre forme et 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é.

Et vous ?

La difficulté de trouver des mainteneurs est-elle la conséquence de ce que le développement du noyau Linux continue de se faire en C et en assembleur au moment où les développeurs s’intéressent de plus en plus à des langages comme Rust ?
Êtes-vous aussi d’avis que la communauté Linux anticipe non seulement sur les départs en retraite des actuels mainteneurs et sur les qualités que Rust offre en comparaison au langage C ?
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
Vous avez lu gratuitement 3 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).
6  1 
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.
4  2 
Avatar de fdecode
Membre habitué https://www.developpez.com
Le 21/02/2025 à 9:42
Citation Envoyé par d_d_v Voir le message
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.
L'unsafe n'est pas vraiment une facilitée. C'est contraignant; c'est repérable; on doit réfléchir au préalable à la manière de s'en servir correctement...
Une facilité serait plutôt de cloner toutes les données en lecture seule afin de limiter l'usage de références non mutable et d'éviter le conflit avec une référence mutable.
Cela simplifie les choses, mais c'est sous optimal. Par contre, c'est parfaitement sûr.
3  1 
Avatar de smarties
Expert confirmé https://www.developpez.com
Le 20/02/2025 à 10:54
Là le dilemme est légitime :
- d'un côté on a les développeurs C qui qui font et ne documentent rien
- de l'autre on a un langage proche mais sécurisé qui force presque à écrire du code de qualité

De toute façon, introduire le Rust ne se fera pas sans "douleur", il y aura probablement des ratés au début comme tout nouveau changement. Mais quand les anciens développeurs C sont pas éternels, qui pourra alors maintenir ?
1  0 
Avatar de Le Lutin
Nouveau Candidat au Club https://www.developpez.com
Le 23/02/2025 à 22:55
Pourquoi cet article est-il daté du 23/02/2025 alors qu'il date de juin 2022 et d'un autre auteur ?
1  0 
Avatar de Minato Sensei
Membre habitué https://www.developpez.com
Le 23/02/2025 à 23:17
Citation Envoyé par Le Lutin Voir le message
Pourquoi cet article est-il daté du 23/02/2025 alors qu'il date de juin 2022 et d'un autre auteur ?
Bienvenue au club.

Alors, en fait dans ce fil de discussion, tu as plusieurs articles publiés par les chroniqueurs. Sur le portail tu verras la chronologie qui te mèneras directement à l'article que tu veux, dans le fil tu les verras comme simple "réponse".

Le premier article daté de juin 2022 et rédigé par un autre chroniqueur parle du début de l'affaire (notamment "Linus Torvalds annonce que Rust for Linux est susceptible d’être prêt pour la version 5.20 du noyau"). Au fur et à mesure qu'elle avance, d'autres chroniqueurs (ou le même, ou n'importe quel membre du club) peuvent reporter des mises à jour de la situation. En l'occurrence, la dernière avancée est la réponse de Linus Torvalds à un mainteneur.

Je ne sais pas si je parviens à répondre à ta question
1  0 
Avatar de RenarddeFeu
Membre averti https://www.developpez.com
Le 23/02/2025 à 17:08
Tout a une obsolescence en informatique, même Linux. Les afficionados du Rust ont tout intérêt à focaliser leurs efforts sur des projets types RedoxOS.
0  0 
Avatar de seb75net
Candidat au Club https://www.developpez.com
Le 23/02/2025 à 11:58
Je comprends que des développeurs qui maîtrisent le C depuis le berceau et plus est dans un écosystème pratiquement entièrement en C voient d'un très mauvais oeil qu'on leurs demandent d'oublier tout ce qu'ils ont appris. Surtout qu'il va falloir avoir une double compétence pour maintenir des milliers de lignes de code. Linus veut donner une nouvelle attractivité au maintien du noyau Linux mais il s'y prend peut être trop tôt à vouloir imposer Rust.
0  1 
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.
0  1