Qu'est ce que c'est un 'Nontechnical Nonsense' ?; Des problèmes humains? Des problématiques historiques ? Des outils incompatibles entre C/ASM/Rust ? Des réfractaires à LLVM ? Un projet lancé trop tôt car Rust évolue encore et que rust-gcc n'est pas encore prêt ( prévu pour GCC 15.1 ) ?
Il doit bien y avoirs des adorateurs du crabe qui passent sur le site; si ils ont des réponses…
Il doit bien y avoirs des adorateurs du crabe qui passent sur le site; si ils ont des réponses…
J’ai cru comprendre que c’est une partie du problème : les mainteneurs sont accusés de faire partie d’une religion/secte qui veut imposer sa vision du monde au noyau, alors qu’eux s’estiment plutôt dans une optique d’élargissement des possibilités.
Un projet lancé trop tôt car Rust évolue encore […]
Quasiment tous les langages intéressants évoluent encore (à diverses vitesses) du fait des découvertes/inventions dans cette discipline si jeune qu’est l’informatique. Le formuler ainsi évite de détailler les potentiels problèmes sous-jacents : stabilité (Rust la garantit officiellement, la pratique est parfois plus compliquée, mais rarement, pas trop un problème pour RfL), maturité en fonctionnalités (RfL nécessite actuellement des features instables, ce qui est un problème ; RfL n’utilise pas l’écosystème Cargo, qui n’est donc pas un problème dans ce contexte).
Il y a aussi le problème de l'abi non stable en rust, ce qui oblige à inclure en statique les dépendances d'un logiciel (en tout cas dans le cas d'un projet rust normal géré avec Cargo, je ne sais pas si Rust for Linux fonctionne différemment et est concerné).
L’ABI par défaut est instable. Et c’est plutôt bien, une ABI stable par défaut étant plus un inconvénient qu’un avantage pour un langage avec des génériques monomorphisés comme le Rust ou le C++ (le C++ permet de pré-monomorphiser pour contourner le problème, mais c’est limité et il faut y avoir pensé).
Cependant, on peut volontairement passer à une ABI stable via repr(C)/extern "C" (par exemple). Je n’ai pas vérifié, mais RfL étant une surcouche d’une API écrite en C, ils en utilisent probablement beaucoup à l’interface. C’est possiblement un peu plus de travail, mais ce n’est pas fondamentalement différent des restrictions à l’ajout de champs dans une struct exposée en C : une API n’a une ABI stable que si elle a été pensée pour.
Il existe toutefois un risque sur l’ABI lié au fait que GCC et LLVM ne sont pas toujours parfaitement d’accord et que mixer des objets en provenance des deux est risqué, les différences ne générant généralement aucun avertissement au moment de la liaison.
Interessant, merci, de ce que j'avais compris compiler le même code avec les même versions de libs et de compilateur ne produit pas necessairement le même binaire, ce qui peut poser problème pour le linking).
J'avais noté que Bevy utilise une autre approche pour faire ça (avec https://docs.rs/bevy_dynamic_plugin/latest/bevy_dynamic_plugin/), ils précisent eux même que ça risque de péter dans le cas de compilation séparé, mais que ça fonctionne si tout est compilé en même temps (le gain étant alors le découplage du binaire, dans Bevy, un des cas avancé est la distribution de dlc par exemple).
Il faut donc éviter les "génériques monomorphisés" dès que possible pour le code devant être partagé et réutilisé à grande échelle, et en effet, "mettre des templates dans des headers" ne serait plus un problème.
Il y a extern "C" aussi en c++. Mais plus de gestion des exceptions / RTTI (il vaut mieux un bon vieux GC dans ce cas de toute façon).
Les "templates" font exploser la section "code" des binaires. J'entends dire malgré cela que ça permet des micro-optimisation inaccessible aux autres langages … Comme si compiler Firefox en O3 le rendait plus rapide qu'Os …
Visiblement (d'après le lien youtube), ce serait plus des problème de relationnels ces 'Nontechnical Nonsense'.
On a par exemple un gars au ton plutôt acide qui leur explique lors de leur conf, qu'ils ne sont pas autorisé à faire des changements dans le code en C (parce qu'ils pourraient le casser), et que si un changement dans le code C casse le binding Rust c'est pas son problème, parce que lui il connaît pas Rust et qu'il ne veut pas faire du Rust.
Il leur reproche aussi de pousser le Rust façon religion (il me semble qu'il est religieux du C pour sa part).
Ça doit être usant à force.
Pareil (en moins pire évidemment) pour celui qui soulève des problèmes entre fonction et méthode, on lui explique qu'il n'y a pas d'objet et d'héritage en Rust. C'est pas grand chose, mais devoir se justifier en permanence sur des points technique auprès de gens qui ne connaissent rien au langage ou qui font des assomptions erronées c'est usant aussi (mais au moins ça reste poli).
Il y a pleins de gens qui semblent être contre rust dans le noyau, je ne saurait dire si c'est justifié ou non, c'est trop pointu pour moi.
Au contraire il est lancé suffisamment tôt parce que le projet est encore agile et peu prendre en compte les retours des développeurs kernel sans avoir trop d'existant à gérer.
C'est normal que rust est du mal à se faire une place. Quand tu es expert d'un domaine voir venir des inconnus qui t'expliquent que ce que tu fais ne marche pas est humainement compliqué. C'est difficile de ne pas mettre d'ego dans ce que l'on fait. Et d'autre part les règles de Crocker qui sont la norme dans linux montrent leurs limites. C'est confortable quand t'es le sachant, mais sinon ça peut être plus compliqué.
De mon humble avis ce qu'on voit ce sont des difficultés à collaborer plus qu'un échec de rust dans linux. Il faut se rappeler que c'est une première et que c'est une révolution dans le développement du noyau. Rencontrer ce des difficultés (même non technique) est la norme.
taking advantage of Crocker's Rules does not imply reciprocity. How could it? Crocker's Rules are something you do for yourself
De ce que je comprends, ça ne peut pas être une "norme" vu que ça impliquerait d'obliger les hackers du noyau à accepter une règle qu'ils n'ont pas choisie. C'est sûrement ce qui a amené Linus à s'excuser à l'époque : à moins que ton interlocuteur ait dit qu'il fonctionne selon ces règles, tu dois continuer à "mettre les formes". Parler n'importe comment sous prétexte qu'on suit les règles de Crocker c'est —ne pas les avoir comprises —être un mufle.
# Dommage
Posté par pif17 . Évalué à 6 (+5/-0).
Qu'est ce que c'est un 'Nontechnical Nonsense' ?; Des problèmes humains? Des problématiques historiques ? Des outils incompatibles entre C/ASM/Rust ? Des réfractaires à LLVM ? Un projet lancé trop tôt car Rust évolue encore et que rust-gcc n'est pas encore prêt ( prévu pour GCC 15.1 ) ?
Il doit bien y avoirs des adorateurs du crabe qui passent sur le site; si ils ont des réponses…
[^] # Re: Dommage
Posté par Ltrlg . Évalué à 5 (+5/-0).
J’ai cru comprendre que c’est une partie du problème : les mainteneurs sont accusés de faire partie d’une religion/secte qui veut imposer sa vision du monde au noyau, alors qu’eux s’estiment plutôt dans une optique d’élargissement des possibilités.
Quasiment tous les langages intéressants évoluent encore (à diverses vitesses) du fait des découvertes/inventions dans cette discipline si jeune qu’est l’informatique. Le formuler ainsi évite de détailler les potentiels problèmes sous-jacents : stabilité (Rust la garantit officiellement, la pratique est parfois plus compliquée, mais rarement, pas trop un problème pour RfL), maturité en fonctionnalités (RfL nécessite actuellement des features instables, ce qui est un problème ; RfL n’utilise pas l’écosystème Cargo, qui n’est donc pas un problème dans ce contexte).
[^] # Re: Dommage
Posté par Aldebaran (site web personnel) . Évalué à 5 (+4/-0).
Il y a aussi le problème de l'abi non stable en rust, ce qui oblige à inclure en statique les dépendances d'un logiciel (en tout cas dans le cas d'un projet rust normal géré avec Cargo, je ne sais pas si Rust for Linux fonctionne différemment et est concerné).
[^] # Re: Dommage
Posté par Ltrlg . Évalué à 6 (+6/-0).
L’ABI par défaut est instable. Et c’est plutôt bien, une ABI stable par défaut étant plus un inconvénient qu’un avantage pour un langage avec des génériques monomorphisés comme le Rust ou le C++ (le C++ permet de pré-monomorphiser pour contourner le problème, mais c’est limité et il faut y avoir pensé).
Cependant, on peut volontairement passer à une ABI stable via
repr(C)/extern "C"(par exemple). Je n’ai pas vérifié, mais RfL étant une surcouche d’une API écrite en C, ils en utilisent probablement beaucoup à l’interface. C’est possiblement un peu plus de travail, mais ce n’est pas fondamentalement différent des restrictions à l’ajout de champs dans unestructexposée en C : une API n’a une ABI stable que si elle a été pensée pour.Il existe toutefois un risque sur l’ABI lié au fait que GCC et LLVM ne sont pas toujours parfaitement d’accord et que mixer des objets en provenance des deux est risqué, les différences ne générant généralement aucun avertissement au moment de la liaison.
[^] # Re: Dommage
Posté par Aldebaran (site web personnel) . Évalué à 2 (+1/-0).
Interessant, merci, de ce que j'avais compris compiler le même code avec les même versions de libs et de compilateur ne produit pas necessairement le même binaire, ce qui peut poser problème pour le linking).
J'avais noté que Bevy utilise une autre approche pour faire ça (avec https://docs.rs/bevy_dynamic_plugin/latest/bevy_dynamic_plugin/), ils précisent eux même que ça risque de péter dans le cas de compilation séparé, mais que ça fonctionne si tout est compilé en même temps (le gain étant alors le découplage du binaire, dans Bevy, un des cas avancé est la distribution de dlc par exemple).
[^] # Re: Dommage
Posté par YBoy360 (site web personnel) . Évalué à 1 (+0/-0).
Il faut donc éviter les "génériques monomorphisés" dès que possible pour le code devant être partagé et réutilisé à grande échelle, et en effet, "mettre des templates dans des headers" ne serait plus un problème.
Il y a extern "C" aussi en c++. Mais plus de gestion des exceptions / RTTI (il vaut mieux un bon vieux GC dans ce cas de toute façon).
Les "templates" font exploser la section "code" des binaires. J'entends dire malgré cela que ça permet des micro-optimisation inaccessible aux autres langages … Comme si compiler Firefox en O3 le rendait plus rapide qu'Os …
[^] # Re: Dommage
Posté par Aldebaran (site web personnel) . Évalué à 7 (+6/-0).
Visiblement (d'après le lien youtube), ce serait plus des problème de relationnels ces 'Nontechnical Nonsense'.
On a par exemple un gars au ton plutôt acide qui leur explique lors de leur conf, qu'ils ne sont pas autorisé à faire des changements dans le code en C (parce qu'ils pourraient le casser), et que si un changement dans le code C casse le binding Rust c'est pas son problème, parce que lui il connaît pas Rust et qu'il ne veut pas faire du Rust.
Il leur reproche aussi de pousser le Rust façon religion (il me semble qu'il est religieux du C pour sa part).
Ça doit être usant à force.
Pareil (en moins pire évidemment) pour celui qui soulève des problèmes entre fonction et méthode, on lui explique qu'il n'y a pas d'objet et d'héritage en Rust. C'est pas grand chose, mais devoir se justifier en permanence sur des points technique auprès de gens qui ne connaissent rien au langage ou qui font des assomptions erronées c'est usant aussi (mais au moins ça reste poli).
Il y a pleins de gens qui semblent être contre rust dans le noyau, je ne saurait dire si c'est justifié ou non, c'est trop pointu pour moi.
[^] # Re: Dommage
Posté par barmic 🦦 . Évalué à 4 (+2/-0).
Au contraire il est lancé suffisamment tôt parce que le projet est encore agile et peu prendre en compte les retours des développeurs kernel sans avoir trop d'existant à gérer.
C'est normal que rust est du mal à se faire une place. Quand tu es expert d'un domaine voir venir des inconnus qui t'expliquent que ce que tu fais ne marche pas est humainement compliqué. C'est difficile de ne pas mettre d'ego dans ce que l'on fait. Et d'autre part les règles de Crocker qui sont la norme dans linux montrent leurs limites. C'est confortable quand t'es le sachant, mais sinon ça peut être plus compliqué.
De mon humble avis ce qu'on voit ce sont des difficultés à collaborer plus qu'un échec de rust dans linux. Il faut se rappeler que c'est une première et que c'est une révolution dans le développement du noyau. Rencontrer ce des difficultés (même non technique) est la norme.
https://linuxfr.org/users/barmic/journaux/y-en-a-marre-de-ce-gros-troll
[^] # Re: Dommage
Posté par Faya . Évalué à 3 (+1/-0).
De ce que je comprends, ça ne peut pas être une "norme" vu que ça impliquerait d'obliger les hackers du noyau à accepter une règle qu'ils n'ont pas choisie. C'est sûrement ce qui a amené Linus à s'excuser à l'époque : à moins que ton interlocuteur ait dit qu'il fonctionne selon ces règles, tu dois continuer à "mettre les formes". Parler n'importe comment sous prétexte qu'on suit les règles de Crocker c'est —ne pas les avoir comprises —être un mufle.
# de l'influence du rôle des développeur sur leur perspective
Posté par GwenLg . Évalué à 1 (+1/-0). Dernière modification le 30 août 2024 à 16:44.
pour compléter, voici un post de David Airlied qui aborde les difficultés de cohabitation entre développeur en fonction de leur "rôle" : https://airlied.blogspot.com/2024/08/on-rust-linux-developers-maintainers.html
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.