Journal Linus répond à la controverse sur R4L (Rust pour Linux)

Posté par  (site web personnel) . Licence CC By‑SA.
Étiquettes :
53
21
fév.
2025

NB: Ceci est une traduction du courrier de Linus sur la liste de diffusion publique.

Mercredi, 19 Février 2025 à 22:42, Christoph Hellwig hch@infradead.org a écrit:

Le document prétend qu'aucun sous-système n'est forcé d'utiliser Rust. Linus a démontré que c'était faux. Et bien que vous ne le saviez peut être pas quand vous avez écrit ce document, vous le saviez parfaitement quand vous avez posté sur cette liste.

J'avais espoir que cette longue discussion aboutisse à quoi que ce soit de constructif, mais il semblerait que tout va de travers (ou tout du moins, le débat n'avance pas).

Dans les fait, la "pull request" que tu as rejeté NE TOUCHAIT PAS LA COUCHE DMA DU TOUT.

C'était littéralement juste un autre utilisateur de cette couche, dans un sous-répertoire complètement séparé, qui ne changeait pas le code que tu maintiens d'un quelconque manière.

Je trouve pénible que tu te plaignes de nouveaux utilisateurs de ton code, et que tu continue d'apporter ce type d'argument de merde.

Honnêtement, ce que tu as fait, c'est basiquement dire "en tant que mainteneur du DMA, je contrôle comment le code du DMA est utilisé".

Et ça n'est pas du tout comme ça que les choses fonctionnent.

C'est quoi la suite ? Dire qu'un driver en particulier ne peut pas utiliser le DMA, parce que tu n'aimes pas ce périphérique, et en tant que mainteneur tu contrôle qui peut utiliser le code ?

C'est littéralement ce que tu essayes de faire avec le code Rust.

Tu dis que tu es en désaccord avec Rust (dans le noyau Linux), ce qui est acceptable, personne ne t'as jamais obligé d'écrire ou de lire du code Rust.

Mais après, tu prends cette position pour affirmer que le code Rust ne peut même pas utiliser ou s'interfacer avec du code que tu maintiens.

Alors laisse moi être très clair: si en tant que mainteneur tu estimes que tu contrôle qui ou quoi utilise ton code, TU TE TROMPES.

Je te respecte techniquement, et j'aime travailler avec toi.

Et non, je ne cherche pas des gens qui disent "Amen" à tout, et j'aime bien quand vous me reprenez sur mes conneries. Je dis parfois des choses stupides, et il y a besoin de gens pour me tenir tête quand je débite de la merde.

Mais maintenant, c'est moi qui tiens tête à TON débit de conneries.

Donc ce courrier n'est pas à propos d'une quelconque "Politique Rust". Ce courrier est à propos d'un bien plus gros problème: en tant que mainteneur, tu es responsable de ton code, ok - mais tu n'es pas garant de qui l'utilise ni comment il est utilisé.

Tu n'as pas a aimer Rust. Tu n'as même pas t'en soucier. Cela a été clarifié dès le tout début, personne n'est soudainement obligé d'apprendre un nouveau langage, et les gens qui veulent uniquement travailler sur la partie C peuvent très bien continuer à le faire.

Donc pour revenir au coeur de ton propos :

Le document prétend qu'aucun sous-système n'est forcé d'utiliser Rust.

C'est bien vrai.

Tu n'es pas forcé d'accepter du code Rust, ou de te soucier de code Rust dans le DMA. Tu peux l'ignorer.

Mais "ignorer la partie Rust" signifie automatiquement que tu n'as aucun mot à dire non plus.

Tu ne peux pas avoir le beurre et l'argent du beurre. Tu ne peux pas dire "Je ne veux rien avoir à faire avec Rust", et ensuite dans la phrase suivante dire "Et ça signifie que le code Rust que je vais ignorer ne peux pas utiliser les interfaces C que je maintiens".

Les mainteneurs qui veulent s'impliquer dans la partie Rust peuvent le faire, et en étant impliqués, il vont avoir leurs mot à dire sur la conception des "bindings" Rust. Basiquement, ils deviennent également les mainteneurs des interfaces Rust.

Mais les mainteneurs qui choisissent "Je ne veux rien avoir à faire avec Rust" n'auront bien évidement pas besoin de se soucier des "bindings" Rust - mais en conséquence, ils n'auront également rien à dire sur ce qu'il se passe dans la partie Rust.

Donc quand tu changes les interfaces C, les développeurs Rust vont devoir gérer les retombées et corriger les "bindings" Rust. C'est un peu la promesse ici : il y a ce "mur de protection" autour des développeurs C qui ne veulent pas gérer les problèmes avec Rust, ils n'ont pas à se préoccuper de Rust.

Mais ce "mur de protection" va dans les deux sens. Si tu ne veux pas te préoccuper du code Rust, tu n'as rien à dire sur le code Rust.

En d'autres termes : le "personne n'est forcé de se préoccuper de Rust" ne veut pas dire "tout le monde est autorisé à mettre son veto sur du code Rust".

Tu vois ?

Et non, je ne pense pas qu'il y ait besoin que ce soit tout "noir et blanc". J'ai expliqué ci-dessus d'une manière très "noir et blanc" ("devenir mainteneur des "bindings" Rust également" vs "ne pas vouloir se préoccuper du tout de Rust"), mais dans bien des cas je suppose que la ligne sera bien plus floue, où un mainteneur d'un sous-système peut être conscient de l'existence des "bindings" Rust, et disposé à travailler avec la partie Rust, mais sans être très impliqué.

Donc vraiment, il n'y a pas besoin que cela soit "tout ou rien".

-- Linus

  • # Correction

    Posté par  . Évalué à 2 (+1/-0).

    J'ai pertinenté (même si un peu de contexte aurait pas fait de mal) mais
    "Cela a été prouvé incorrect par" c'est pas naturel, on n'utilise pas la voie passive pour ça en français, "Linus a démontré que c'était faux" pique moins les yeux.

    : si en tant que mainteneur tu estime que tu contrôle qui ou quoi utilise ton code

    Il manque les s

    Les mainteneurs qui veulent s'impliquer dans la partie Rust peuvent le faire, et en étant impliqué, il vous avoir leurs mot à dire

    Impliqués, ils vont

    tout le monde est autorisé à veto du code Rust".

    À mettre son véto sur du code rust

    ligne sera bien plus floue, ou un mainteneur

    Où

    Voilà c'était le commentaire relou du matin (possible qu'en plus j'en ai loupé je suis sur le téléphone)

    • [^] # Re: Correction

      Posté par  (site web personnel) . Évalué à 4 (+2/-0).

      Merci pour les corrections !

      J'avoue que j'ai encore du mal avec certaines expressions anglaises, je les comprends mais les retranscrire est parfois difficile. Je suis pas traducteur professionnel après tout :p Mais j'aime bien cet exercice occasionnel.

      Si un modérateur peut éditer :)

      https://link-society.com - https://kubirds.com - https://github.com/link-society/flowg

      • [^] # Re: Correction

        Posté par  (site web personnel) . Évalué à 3 (+1/-0).

        Si un modérateur peut éditer :)

        C'est fait, avec quelques modifs supplémentaires. Et merci pour cet intéressant journal :)

        11c11
-   Rust. Cela a été prouvé incorrect par Linus. Et bien que vous ne le
---
+   Rust. Linus a démontré que c'était faux. Et bien que vous ne le
38c38
- C'est littéralement ce que tu essaye de faire avec le code Rust.
---
+ C'est littéralement ce que tu essayes de faire avec le code Rust.
47c47
- Alors laisse moi être très clair: si en tant que mainteneur tu estime
---
+ Alors laisse moi être très clair: si en tant que mainteneur tu estimes
52,55c52,55
- Et non, je ne cherche pas des gens qui disent "Amen" à tout, and
- j'aime bien quand vous me reprenez sur mes conneries. Je dis parfois
- des choses stupides, et il y a besoin de gens pour me tenir tête quand
- je débite de la merde.
---
+ Et non, je ne cherche pas des gens qui disent "Amen" à tout, et j'aime
+ bien quand vous me reprenez sur mes conneries. Je dis parfois des
+ choses stupides, et il y a besoin de gens pour me tenir tête quand je
+ débite de la merde.
57c57
- Mais maintenant, c'est moi qui tiens tête à TON débit de connerie.
---
+ Mais maintenant, c'est moi qui tiens tête à TON débit de conneries.
84c84
- phrase suivant dire "Et ça signifie que que le code Rust que je vais
---
+ phrase suivante dire "Et ça signifie que le code Rust que je vais
88,90c88,90
- le faire, et en étant impliqué, il vous avoir leurs mot à dire sur le
- la conception des "bindings" Rust. Basiquement, ils deviennent
- également les mainteneurs des interfaces Rust.
---
+ le faire, et en étant impliqués, il vont avoir leurs mot à dire sur la
+ conception des "bindings" Rust. Basiquement, ils deviennent également
+ les mainteneurs des interfaces Rust.
93c93
- avec Rust" n'aurons bien évidement pas besoin de se soucier des
---
+ avec Rust" n'auront bien évidement pas besoin de se soucier des
107,108c107,108
- Rust" ne veut pas dire "tout le monde est autorisé à veto du code
- Rust".
---
+ Rust" ne veut pas dire "tout le monde est autorisé à mettre son veto
+ sur du code Rust".
112c112
- Et non, je ne pense pas qu'il y a besoin que ce soir tout "noir et
---
+ Et non, je ne pense pas qu'il y ait besoin que ce soir tout "noir et
115,116c115,116
- se préoccuper du tout de Rust"), mais dans bien des cas Je suppose que
- la ligne sera bien plus floue, ou un mainteneur d'un sous-système peut
---
+ se préoccuper du tout de Rust"), mais dans bien des cas je suppose que
+ la ligne sera bien plus floue, où un mainteneur d'un sous-système peut

        • [^] # Re: Correction

          Posté par  . Évalué à 3 (+2/-0).

          Il faudrait également corriger "soir" en "soit" dans :

          Et non, je ne pense pas qu'il y ait besoin que ce soir tout "noir et blanc".

    • [^] # Re: Correction

      Posté par  . Évalué à 1 (+0/-0).

      mais peut être pas très impliqué.

      -> mais sans être très impliqué.

    • [^] # Re: Correction

      Posté par  (site web personnel) . Évalué à 8 (+6/-0).

      J'irai même plus loin !

      Je réécrirais « bien que vous ne le saviez peut être pas quand vous avez écrit ce document, vous le saviez parfaitement quand vous avez posté sur cette liste » en « bien que vous ne le sussiez peut être pas quand vous écrivîtes ce document, vous le saviez parfaitement quand vous postâtes sur cette liste. »

      Voilà. C'est important, quand même.

  • # liens connexes

    Posté par  (site web personnel) . Évalué à 6 (+4/-0).

    https://linuxfr.org/users/antistress/liens/ep1-linus-torvalds-would-reportedly-merge-rust-kernel-code-over-maintainer-objections
    https://linuxfr.org/users/antistress/liens/ep2-greg-kroah-hartman-makes-a-compelling-case-for-new-linux-kernel-drivers-to-be-written-in-rust
    https://linuxfr.org/users/woffer/liens/greg-k-h-tout-nouveau-code-ecrit-en-rust-pour-le-noyau-linux-est-un-gain-pour-tous

    pertinent adj. Approprié : qui se rapporte exactement à ce dont il est question.

  • # Clair

    Posté par  (site web personnel) . Évalué à 10 (+10/-0).

    Ça a le mérite d'être clair, et assume bien les choix de protéger les dev C qui sont encore majoritaire, et faire porter l'effort aux Rust. Et ce que ça implique comme limite de responsabilité entre dev et utilisateurs d'une interface.

    Maintenant imaginez qu'un CTO dans votre propre société soit aussi clair sur ce qu'il sacrifie et pourquoi. Ça change non? :)

    • [^] # Re: Clair

      Posté par  . Évalué à 2 (+1/-1).

      Clair mais un peu tardif.

      • [^] # Re: Clair

        Posté par  (site web personnel) . Évalué à 2 (+1/-1).

        C'est tout à fait vrai. Il semble dire qu'il attendais que ça se calme de soit même, mais en effet un mainteneur qui refuse le code d'un utilisateur, il aurait dû poper à ce moment là, et pas attendre. Et on ne peux pas dire que ça n'a pas fait du bruit.

        • [^] # Re: Clair

          Posté par  . Évalué à 7 (+5/-0).

          C'est peut-être le temps qu'il a pris pour étudier le code, pour pouvoir ensuite faire en connaissance de cause cette affirmation :

          Dans les fait, la "pull request" que tu as rejeté NE TOUCHAIT PAS LA COUCHE DMA DU TOUT.

          • [^] # Re: Clair

            Posté par  (site web personnel) . Évalué à 7 (+6/-0).

            Tu peux aussi rajoute le fait, que quelques postes plus haut, des mainteneurs disent avoir parlé en privé avec Linus.

            Je suppose que ça à du pas mal discuter avant de répondre en public.

      • [^] # Re: Clair

        Posté par  (site web personnel) . Évalué à 3 (+2/-0).

        Un commentaire avisé disait sur Phoronix (un sacré repaire de vieux réac' quand même) qu'il a probablement décidé volontairement de rester en retrait un temps pour voir si les choses s'arrangeraient d'elles même, de ne pas faire d'ingérence entre les responsables de subsystem et les contributeur. Il a probablement décidé de réagir au bon moment, quand il a vu que ça ne s'arrangeait pas et se transformait en drama. Ce n'est qu'un point de vue, il n'y avait probablement pas de "bon" moment pour ça, le fait d'y arriver dénote des points de contentions assez grave parmi les développeurs, et que certain abusent de leur position pour refuser systématiquement ce qu'ils n'aiment pas, ou quand ça provient de gens qu'ils n'aiment pas.

        • [^] # Re: Clair

          Posté par  . Évalué à 2 (+2/-1).

          Les commentaires sur Phoronix (et la non-modération) m'ont stupéfait.

          Hector Martin s'en est tellement pris, alors qu'il ne voulait qu'utiliser une interface Rust pour le DMA.

          • [^] # Re: Clair

            Posté par  . Évalué à 3 (+1/-0).

            Je suis allé lire, histoire de me faire une idée, :

            I'm hoping another company will end up forking the Linux kernel to replace the current one and the Linux Foundation about it. I'm really hoping Elon and X can. "X OS" the "X Kernel" would be nice.

            OK… Je continuerai à ne pas lire les commentaires sur Phoronix.

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.