Rust sous Linux : un outil puissant, mais comment trouver le bon équilibre ?

Le débat houleux sur l'inclusion de Rust dans le noyau Linux dure depuis un certain temps déjà dans la communauté des hackers. La plupart d'entre nous reconnaissent à la fois l'engouement et les hésitations à ce sujet. Jusqu'à présent, la plupart des discussions se sont concentrées sur des problèmes immédiats, tels que les avantages de Rust en matière de sécurité et les défis liés à son intégration dans l'écosystème existant basé sur C. Maintenant que Linus Torvalds a adhéré à cette idée , Rust a déjà commencé à faire son chemin dans le code source de notre système d'exploitation bien-aimé.

La vraie question n'est donc pas de savoir s'il faut utiliser Rust dans le noyau Linux, mais comment . Après tout, Rust n'est pas simplement un autre langage de programmation ; c'est aussi une philosophie de conception à part entière. Il ne s'agit pas d'une mise à niveau de C avec moins de bugs de corruption de mémoire, mais d'un système d'écriture de code qui impose un ensemble de règles strictes, évitant ainsi de nombreuses erreurs potentielles. Je pense que c'est l'aspect clé dont nous devons tenir compte lors de l'intégration de Rust dans le noyau Linux.

Rester efficace et adaptable

Selon les recherches sur l’ambidextrie organisationnelle , les projets à très grande échelle comme Linux doivent continuellement s’engager dans deux types d’activités pour rester adaptables, pertinents et réussis :

1. Exploitation : efficacité, perfectionnement et exécution. Sous Linux, cela fait référence à des activités telles que l'optimisation des fonctionnalités, la correction des bogues et la prise en compte des préoccupations des utilisateurs existants.
2. Exploration : expérimentation, prise de risque et innovation. Ces activités permettent à des projets comme Linux de développer de nouvelles approches, de s'adapter aux technologies disruptives et de répondre aux attentes changeantes des utilisateurs.

Les recherches montrent également que les activités d’exploitation à court terme ont tendance à évincer les activités d’exploration à long terme . C’est comme vouloir acquérir une nouvelle compétence ou travailler sur un projet non conventionnel, mais toujours donner la priorité aux tâches quotidiennes. Il en va de même pour les grands projets comme Linux : s’ils se concentrent trop sur l’efficacité à court terme, ils risquent de devenir obsolètes à long terme. Le monde continue de changer alors que le projet reste le même, ce qui rend ses offres de plus en plus inadaptées aux besoins changeants des utilisateurs.

Trouver le juste équilibre

D’un côté, l’adoption de Rust est une expérience très peu conventionnelle qui peut être considérée comme une activité d’exploration pour Linux. De ce point de vue, l’inclusion de Rust est bien fondée. Cependant, d’un autre côté, contrairement à C, qui accueille à bras ouverts toutes sortes de folies et de comportements indéfinis, ce qui en fait le langage de référence pour le piratage de bas niveau, Rust a une bureaucratie interne qui impose une certaine manière structurée d’écrire du code. Dans un sens, Rust fonctionne à la fois comme un langage de programmation et un système de gestion de processus, similaire à des méthodologies comme Six Sigma. Une manière spécifique et structurée d’écrire du code peut certainement aider à rationaliser les processus et à améliorer les résultats à court terme, tels que les vulnérabilités de sécurité et les problèmes de fiabilité. Cependant, tout comme dans le cas d’autres systèmes de gestion de processus , cette rigidité introduit également des risques pour l’agilité et l’adaptabilité à long terme.

Par conséquent, les mérites de Rust en matière de rationalisation des processus et de sécurisation de ceux-ci brilleraient particulièrement dans les composants du noyau où l'adaptabilité à long terme est moins critique. Par exemple, les pilotes de périphériques interagissent directement avec des entrées externes et sont des composants à haut risque en termes de sécurité et de fiabilité de la mémoire. Il est donc logique de les écrire avec Rust. Ils ont également tendance à avoir une durée de vie relativement plus courte, car les nouveaux périphériques remplacent fréquemment les anciens. En d'autres termes, la crainte que la méthodologie Rust puisse diminuer l'exploration, ou la possibilité que nous puissions éventuellement vouloir nous éloigner de Rust en raison de changements dans les philosophies d'écriture de code, devient moins pertinente. Lorsqu'un pilote de périphérique est développé avec Rust, il est généralement plus sûr et plus fiable, et les autres composants ne sont pas construits sur ce code. Par conséquent, cela n'oblige personne à adopter une manière particulière d'écrire du code dans quelques décennies.

En revanche, les composants de base du noyau, comme le planificateur, doivent rester adaptables pour s’adapter aux défis futurs et aux nouveaux paradigmes. L’utilisation de Rust dans ces domaines pourrait introduire des rigidités qui entravent l’exploration et conduisent à l’obsolescence. Voyez les choses de cette façon : le code futur doit s’appuyer sur les composants construits aujourd’hui, et lorsqu’une philosophie différente d’écriture de logiciels s’avèrera plus avantageuse à l’avenir, le code C très flexible pourra généralement être modifié progressivement jusqu’à ce qu’il soit transformé en la nouvelle approche (renouvellement stratégique incrémental). En revanche, Rust insiste sur sa propre façon d’écrire du code, ce qui risque de provoquer un dilemme entre continuer à développer avec l’ancienne approche et l’écrire à partir de zéro. Étant donné que le logiciel libre a toujours eu du mal à trouver un nombre suffisant de bénévoles qualifiés et réguliers ainsi qu’un montant suffisant de financement régulier, l’amélioration progressive est toujours beaucoup plus facile que de décider d’entreprendre un projet majeur comme jeter un composant et écrire à partir de zéro. Par conséquent, tout langage qui insiste sur une manière particulière d’écrire du code peut devenir un handicap à l’avenir, forçant Linux à continuer avec une ancienne manière d’écrire du code et à perdre sa position de pointe.

En bref, je propose une stratégie hybride dans laquelle Rust est davantage utilisé pour les composants à court terme où la sécurité est cruciale, tandis que C, le langage le plus agile qui n'est pas spécifique au matériel, est prioritaire pour les composants à long terme afin de maintenir la flexibilité pour les futurs paradigmes et approches.