Je m'interroge sur la pertinence de l'argument dans le cadre du noyau Linux et de l'introduction de Rust. En gros l'argument est que le vieux code (maintenu) a vu l'essentiel des bugs et vulnérabilités éliminées au cours du temps, et qu'en écrivant le nouveau dans des langage sur on insère pas de vulnérabilité mémoire, donc c'est plutôt gagnant.
Dans le cadre particulier de Linux et Rust par contre il semble que l'introdution de Rust impose de réécrire certaines parties du code en C. On pourrait alors arguer que ce soit à double tranchant : d'un côté c'est pour le meilleur parce que Rust est safe, et que la réécriture impose certaines contraintes de Rust et imposent de meilleures propriétés au code, d'un autre ... c'est une réécriture de code potentiellement éprouvé donc qui risque d'introduire de nouveaux problèmes, un peu à rebours des arguments de l'article.
# Le noyau Linux et cette approche
Posté par thoasm . En réponse au lien De l'intérêt majeur de choisir un langage memory safe pour tout nouveau code d'un projet existant. Évalué à 5.
Je m'interroge sur la pertinence de l'argument dans le cadre du noyau Linux et de l'introduction de Rust. En gros l'argument est que le vieux code (maintenu) a vu l'essentiel des bugs et vulnérabilités éliminées au cours du temps, et qu'en écrivant le nouveau dans des langage sur on insère pas de vulnérabilité mémoire, donc c'est plutôt gagnant.
Dans le cadre particulier de Linux et Rust par contre il semble que l'introdution de Rust impose de réécrire certaines parties du code en C. On pourrait alors arguer que ce soit à double tranchant : d'un côté c'est pour le meilleur parce que Rust est safe, et que la réécriture impose certaines contraintes de Rust et imposent de meilleures propriétés au code, d'un autre ... c'est une réécriture de code potentiellement éprouvé donc qui risque d'introduire de nouveaux problèmes, un peu à rebours des arguments de l'article.