À lire les témoignages, on peut se demander si ces développeurs ne se trouveraient pas plus à l'aise sur des projets tel que RedOX OS.
Le logiciel libre est un environnement au darwinisme exacerbé, peut-être viendra-t-il un jour où Linux se fera remplacer par un successeur en Rust, comme il l'a fait avec les Unices de l'époque, non ?
Les dévelopeurs Rust qui esaient de participer au noyau Linux sont pour certains aussi impliqués dans Redox. Mais il y a pas mal de travail à faire dans Redox avant d'avoir un système utilisable.
C'est donc pas une mauvaise idée d'essayer de faire avancer Rust dans Linux en attendant, et on pourrait même envisager que certains modules soit portables entre les deux.
Mais si les développeurs de Linux se montrent complètement réfractaires à cette idée (comme ils l'ont été avec C++ il y a quelques années), il est probable que les développeurs qui ont envie de faire du code noyau en Rust aillent voir ailleurs.
Ce n'est pas forcément un reproche pour les développeurs de Linux: maintenir un projet avec un mélange de 2 langages de programmation pose aussi un certain nombre de problèmes. Personellement je l'envisagerais pour migrer d'un langage à un autre progressivement, mais pas pour maintenir éternellement les 2 langages.
Il y a beaucoup de choses à mettre en place avant de pouvoir écrire le premier pilote. Il faut mettre en place les outils nécessaires pour la compilation et intégrer avec le système de build existant.
Pour tirer profit de Rust il faut définir beaucoup d'interfaces pour faire le lien entre le code C et Rust afin d'avoir un modèle cohérent entre les deux et pouvoir communiquer ensemble sans broncher.
C'est assez fastidieux et les premiers bénéfices ne sont pas très visibles au début, surtout qu'en général les premiers tests se font souvent sur des pilotes ou composants légers où le gars de l'écriture en Rust est difficile à réellement estimer.
Cela rend tout le travail de ce petit monde long, pas très agréable d'autant que l'accueil par les développeurs en place est de fait froid, cela peut créer des frictions pour le travail en C actuel (car si une structure change, le code Rust pour faire l'interface doit être adaptée).
C'est donc une situation difficile jusqu'à que la situation se stabilise et que Rust quitte l'état d'expérimentation dans le noyau Linux pour faire partie intégrante du noyau sur le long terme. C'est d'autant plus gênant que jusqu'à cette étape il y a des difficultés. LLVM ne gère pas toutes les architectures que le noyau Linux gère jusqu'à présent. Les outils de compilations du noyau dans les différentes distributions ou chaine de compilation (type Yocto ou buildroot) sont bien impactés par son introduction du moins si certains composants rendent Rust obligatoires. Et beaucoup de développeurs du noyau ne connaissent pas vraiment Rust ce qui rend la cohabitation forcément problématique pour la revue des correctifs ou pour corriger du code Rust qui dépend sur du code C qui est changé.
Je pense en effet qu'introduire Rust ne peut se faire que dans une optique de progressivement remplacer le code C existant jusqu'à qu'il disparaisse presque complètement. Mais cela sera très long. La cohabitation à long terme me semble problématique.
L'approche tout refaire avec Redox OS de 0 évite cet écueil mais Linux a un bel écosystème, a beaucoup (mais vraiment beaucoup) de pilotes, systèmes de fichiers, et ses sous systèmes peuvent gérer une grande variété de situations que peu de noyau savent faire, etc. Ce n'est pas pour rien je pense que l'ambition du noyau Fushia a été revue à la baisse, car incapable de rattraper le retard de Linux sur la prise en charge du matériel sans un investissement réellement massif. C'est ce qui risque de compliquer la tâche à Redox OS. Linux n'est pas irremplaçable, mais c'était bien moins ambitieux de détrôner Unix en 1990 avec un noyau neuf que de faire de même avec Linux aujourd'hui.
Cela n'est pas simple, mais si la communauté du noyau Linux est trop conservatrice, ce n'est pas impossible qu'à terme un tel concurrent puisse rivaliser sur tous les aspects à long terme avec les avantages de Rust en prime.
# OK, l'humain, c'est compliqué....
Posté par pif17 . Évalué à 1 (+0/-0).
C'est à mètre en lien avec ce lien.
À lire les témoignages, on peut se demander si ces développeurs ne se trouveraient pas plus à l'aise sur des projets tel que RedOX OS.
Le logiciel libre est un environnement au darwinisme exacerbé, peut-être viendra-t-il un jour où Linux se fera remplacer par un successeur en Rust, comme il l'a fait avec les Unices de l'époque, non ?
[^] # Re: OK, l'humain, c'est compliqué....
Posté par pulkomandy (site web personnel, Mastodon) . Évalué à 3 (+1/-0).
Les dévelopeurs Rust qui esaient de participer au noyau Linux sont pour certains aussi impliqués dans Redox. Mais il y a pas mal de travail à faire dans Redox avant d'avoir un système utilisable.
C'est donc pas une mauvaise idée d'essayer de faire avancer Rust dans Linux en attendant, et on pourrait même envisager que certains modules soit portables entre les deux.
Mais si les développeurs de Linux se montrent complètement réfractaires à cette idée (comme ils l'ont été avec C++ il y a quelques années), il est probable que les développeurs qui ont envie de faire du code noyau en Rust aillent voir ailleurs.
Ce n'est pas forcément un reproche pour les développeurs de Linux: maintenir un projet avec un mélange de 2 langages de programmation pose aussi un certain nombre de problèmes. Personellement je l'envisagerais pour migrer d'un langage à un autre progressivement, mais pas pour maintenir éternellement les 2 langages.
[^] # Re: OK, l'humain, c'est compliqué....
Posté par Renault (site web personnel) . Évalué à 4 (+1/-0).
Le plus difficile est forcément le début.
Il y a beaucoup de choses à mettre en place avant de pouvoir écrire le premier pilote. Il faut mettre en place les outils nécessaires pour la compilation et intégrer avec le système de build existant.
Pour tirer profit de Rust il faut définir beaucoup d'interfaces pour faire le lien entre le code C et Rust afin d'avoir un modèle cohérent entre les deux et pouvoir communiquer ensemble sans broncher.
C'est assez fastidieux et les premiers bénéfices ne sont pas très visibles au début, surtout qu'en général les premiers tests se font souvent sur des pilotes ou composants légers où le gars de l'écriture en Rust est difficile à réellement estimer.
Cela rend tout le travail de ce petit monde long, pas très agréable d'autant que l'accueil par les développeurs en place est de fait froid, cela peut créer des frictions pour le travail en C actuel (car si une structure change, le code Rust pour faire l'interface doit être adaptée).
C'est donc une situation difficile jusqu'à que la situation se stabilise et que Rust quitte l'état d'expérimentation dans le noyau Linux pour faire partie intégrante du noyau sur le long terme. C'est d'autant plus gênant que jusqu'à cette étape il y a des difficultés. LLVM ne gère pas toutes les architectures que le noyau Linux gère jusqu'à présent. Les outils de compilations du noyau dans les différentes distributions ou chaine de compilation (type Yocto ou buildroot) sont bien impactés par son introduction du moins si certains composants rendent Rust obligatoires. Et beaucoup de développeurs du noyau ne connaissent pas vraiment Rust ce qui rend la cohabitation forcément problématique pour la revue des correctifs ou pour corriger du code Rust qui dépend sur du code C qui est changé.
Je pense en effet qu'introduire Rust ne peut se faire que dans une optique de progressivement remplacer le code C existant jusqu'à qu'il disparaisse presque complètement. Mais cela sera très long. La cohabitation à long terme me semble problématique.
L'approche tout refaire avec Redox OS de 0 évite cet écueil mais Linux a un bel écosystème, a beaucoup (mais vraiment beaucoup) de pilotes, systèmes de fichiers, et ses sous systèmes peuvent gérer une grande variété de situations que peu de noyau savent faire, etc. Ce n'est pas pour rien je pense que l'ambition du noyau Fushia a été revue à la baisse, car incapable de rattraper le retard de Linux sur la prise en charge du matériel sans un investissement réellement massif. C'est ce qui risque de compliquer la tâche à Redox OS. Linux n'est pas irremplaçable, mais c'était bien moins ambitieux de détrôner Unix en 1990 avec un noyau neuf que de faire de même avec Linux aujourd'hui.
Cela n'est pas simple, mais si la communauté du noyau Linux est trop conservatrice, ce n'est pas impossible qu'à terme un tel concurrent puisse rivaliser sur tous les aspects à long terme avec les avantages de Rust en prime.
Envoyer un commentaire
Suivre le flux des commentaires
Note : les commentaires appartiennent à celles et ceux qui les ont postés. Nous n’en sommes pas responsables.