
Envoyé par
OuftiBoy
Si de nouveaux mainteneurs veulent introduire (ce qui n'est pas interdit) le Rust c'est à eux qu'ils revient la charge d'une bonne introduction.
Et c'est exactement le cas. L'introduction de Rust a été faite de manière prudente en limitant Rust a des modules isolés. Les gens qui travaillent sur Rust4Linux ne demandent pas aux contributeurs qui ne sont pas intéressés par les modules en Rust de lire, ni d'écrire la moindre ligne de Rust.
A priori, la seule chose qui leur a été demandée c'est, dans certains cas, d'expliciter les règles que doivent actuellement respecter l'API des drivers, bref des choses qui sont de toute façon nécessaire pour faire des drivers C corrects et qui auraient dues être officiellement documentées. Le système de type de Rust permettra d'assurer que ces contraintes soient respectés, corrigeant en partie le problème du manque de documentation des API actuelles.

Envoyé par
OuftiBoy
Quand je lis: Les principaux mainteneurs du noyau sont plus habitués au langage C et veulent poursuivre sur cette lancée. Ils refusent donc de porter le code existant en Rust ou de passer du temps pour aider d’autres contributeurs à le porter en Rust. Je suis tout à fait d'accord avec eux.
Ce qui tombe bien, car on ne leur demande pas, même si certains se plaignent comme si c'était le cas

Envoyé par
OuftiBoy
Les mainteneurs historique ne veulent pas aider d'autres contributeurs à le porter en Rust. Ils sont là pour coder ces vieux développeurs barbus, ils ne sont pas des instituteurs ou des formateurs pour expliquer à d'autres comme faire un portage vers un autre langage qu'une nouvelle génération veut utiliser.
On ne leur demande évidement pas non plus des cours magistraux de C. Les gens qui travaillent sur Rust4Linux connaissent bien évidement le C.

Envoyé par
OuftiBoy
On parle ici des développeurs extrêmement expérimentés du noyaux. S'il considèrent que Rust n'apportent pas de plus-value significativement au kernel on peut quand même prendre leur opinion au sérieux, me semble-t-il ?
On peut les écouter attentivement, sans pour autant prendre tout ce qu'ils disent pour parole d'évangile. Je suis prêt a entendre que le Rust pourrait poser plus de problèmes qu'il apporte de solution, mais pour le moment les arguments avancés ne sont généralement pas pertinents. Particulièrement pour ceux qui sont virulents, j'entends plus une résistance de principe que de vrais arguments. Quand j'entends le mainteneur dire qu'il ne veut pas de la religion du Rust, je pense que c'est assez symptomatique de sa vision et qu'il défend lui même la religion du C sur une base plus dogmatique que pragmatique.

Envoyé par
OuftiBoy
Voilà une partie très intéressante. Je reprend les chiffres donnés: 2288 en 20 ans. 2288/20 = 144,4. 15,9% de ces vulnérabilités à des problèmes lié au C (gestion mémoire, dépassement de tampons, allocation non libérées, accà des zones mémoire invalide ou libérée, etc)
15,9% c'est juste pour le dépassement de tampon, ce qui n'est qu'une partie des erreurs de sécurité mémoires. J'ai pas de chiffres dont je suis certain pour le cas particulier de Linux, mais de ce qu'on constate en général sur les grosses applications C on est généralement au dessus de 60% de failles majeures dues à la sécurité mémoire. Si on en crois
ce site, sur les dernières années plus de 99% des failles sont dues à la sécurité mémoire.

Envoyé par
OuftiBoy
Bien, certains benchmarks, disent que Rust. Mais de combien de % sont-elles plus "rapide" ? Pas de grand chose, et d'autres benchmarks disent le contraire.
En effet l'approche la plus correcte au niveau des performance, c'est de considérer que Rust et C sont en moyenne aussi rapides.

Envoyé par
OuftiBoy
Une partie de ces "atouts" sont annihilés par le fait qu'il faut passer en mode "unsafe" pour certains accès au noyau. Et donc une partie de l'avantage de Rust s'évapore à cause de ce passage en mode "unsafe" qu'il est forcé d'utiliser à certains endroits.
L'existence du bloc unsafe n’annihile absolument pas tout l’intérêt de Rust. Le fait de contenir les risques de sécurité mémoire dans des petites sections clairement identifiées et donc plus facile a surveiller efficacement, reste un énorme avantage comparé à un langage qui est unsafe partout.

Envoyé par
OuftiBoy
Je peux les comprendre... Quand il faut créer des "passerelles", ça ajoute une couche de complexité. Puisque ces "passerelles" sont apparement nécessaires pour l'introduction du code Rust dans le noyau, c'est à eux que revient cette chargent, et pour se faire, ils doivent être aussi compétant en C qu'en Rust.
Et c'est justement le cas.

Envoyé par
OuftiBoy
Je ne connais pas ce projet @redox_os, mais s'il a fallut 30 ans pour que Linux soit ce qu'il est aujourd'hui, je doute fort que @redox_os le fasse en quelques années seulement.
Bien évidement qu'on ne va pas refaire Linux à l'identique avec 10 fois moins de temps et de contributeurs. Il n’empêche que Redox est d'une qualité surprenante au vu de son jeune age et de son équipe limitée. De là à dire que Rust peut aider à développer du code de qualité plus vite, il y a un pas que je ne franchirais pas encore, mais je laisse la question en suspens.

Envoyé par
OuftiBoy
Faut-il comprendre que pour certaines parties, Rust ne fait pas le taf ?
Même Linux n'est pas 100% en C, il contient de l'assembleur.
A ma connaissance le noyau de Redox est bien en Rust et le bootloader est en assembleur. Bien évidement les applications de l'espace utilisateur ne sont pas toutes en Rust. Beaucoup sont des portages d'application C (GCC, make, curl, ...)

Envoyé par
OuftiBoy
Quand au fait de parler de faire passer vos changements devant des mégalomanes pédants et condescendants (je redis que je ne connaît pas cette communauté), et que de cela découle le fait de créer un nouveau noyaux (ou OS complet, je ne sais pas), montre en tout cas très peu d'humilité, mais également un sentiment de supériorité face à des gens qui ont fait leurs preuves depuis 30 ans.
Ce n'est certainement qu'une des raisons qui l'ont poussé a créer Redox OS, qui n'est pas un Linux réécrit en Rust, mais un OS structurellement très différent. C'est un micro-kernel, qui a la base ne visait pas la compatibilité directe avec POSIX, bien qu'il semble changer sur ce point.
Pour le reste je vais pas répondre sur tout au point par point parce que c'est très long et certain trucs sont beaucoup trop confus, ce qui est n'est pas vraiment votre faute vu que vous commentez la série de petites citations de l'article qui manquent énormément de contexte.

Envoyé par
OuftiBoy
Et bien qu'il continue son travail sur cet outils, qui, d'après lui même n'est pas terminé. Puis il pourra avancer.
C'est évident, mais cette charge de travail revient à ceux qui veulent introduire Rust, et donc à la communauté Rust
Encore une fois personne ne dit l'inverse. Le projet Rust4Linux essaie de mettre en place toute l'infrastructure pour qu'écrire un driver en Rust soit le plus naturel possible et s’intègre au mieux dans l'existant. Le statut est toujours expérimental et tout n'est pas encore prêt mais ça n’empêche pas le travail d'avancer sans avoir d'impact négatif sur les développeurs actuel, a par les inciter à mettre au clair les éléments actuellement mal documentés de l'API, ce qui est une bonne chose même pour les drivers C.

Envoyé par
OuftiBoy
Ce processus de mise à niveau finira par s'arrêter et une version minimale de Rust sera définie une fois que les fonctionnalités importantes dont dépend le noyau se seront stabilisées.
Cest du bon sens. Le noyau linux ne peut pas être construit sur un langage qui évolue toujours en permanance. Rust n'est pas "prêt" actuellement, laissons-le se stabiliser avant de l'intégrer dans un si grand projet.
Rust est stable (dans le sens rétrocompatible) depuis presque 10 ans, mais il continue d'évoluer et n'a pas de raisons de s’arrêter. Ca n'est pas un problème, au contraire, vu qu'il manque encore certaines fonctionnalité pour s'intégrer plus efficacement au noyau.

Envoyé par
OuftiBoy
Ojeda a déclaré qu'il travaillait à la recherche de ressources de développement pour gccrs ; le projet repose actuellement sur plus de 800 correctifs hors arborescence et a encore beaucoup de travail à faire en plus...
Il n'y a peut-être pas autant de développeurs compétant que de développeurs C compétant. Rust est encore jeune.
C'est un plutôt le contraire, gcc étant écrit en C++, y compris le nouveau frontend pour Rust en cours de développement. La difficulté c'est surtout qu'il faut des développeurs qui maitrisent les arcanes de gcc et motivés pour y ajouter un fontend en Rust. Le compilateur de référence ne manque pas de contributeurs compétants.
5 |
0 |