barmic 🦦 a écrit 5915 commentaires

Christoph Hellwig a finalement abandonné. Ce mois ci le noyau aura donc perdu 2 grands mainteneurs.

https://linuxfr.org/users/barmic/journaux/y-en-a-marre-de-ce-gros-troll

J'en parle parce que c'était l'un des problèmes remonté par un précédent contributeur r4l qui a abandonné. Peut être que la bonne pratique pose des fois problème au sein du noyau.

https://linuxfr.org/users/barmic/journaux/y-en-a-marre-de-ce-gros-troll

Oui, vu que tu rajoutes toi-même la majorité des dépendances dans le Makefile/Cmake, et donc t'a moins de dépendances surprises, que cargo t'a sortie, tu ne sais pas vraiment comment.

Ou alors ça donne plus de copier coller et ça fait reposer sur du code encore moins éprouvé ?

Je trouve toujours surprenant d'avoir à minima une affinité avec le libre et de trouver positif la difficulté de partager du code.

https://linuxfr.org/users/barmic/journaux/y-en-a-marre-de-ce-gros-troll

Effectivement mais ce n’est pas la première raison qu’il cite. Il pousse à ce que les nouveaux drivers soient écrit en rust pour les garanties que ce dernier apporte.

Typiquement l'exemple du void *, qui est au final assez peu utiliser, car on lui préfère généralement un retour sur un pointeur d'un type définit, mais si on a une vielle API qui n'a jamais changé, alors on peut garder du code, moins sécure.

C’est mieux mais tu ne peux pas par exemple en C (comme dans quasiment tous les langages) décrire la propriété d’un pointeur dans l’API. Si tu me renvoi un pointeur, suis‑je celui qui doit le libérer ou non ?

avoir confiance dans sa chaine de dépendance

Est‑il plus facile de faire confiance en sa chaîne de dépendance en C ?

https://linuxfr.org/users/barmic/journaux/y-en-a-marre-de-ce-gros-troll

Et qu'est-ce qui te fait croire que je n'aime pas le Rust ?

En 5 phrases tu dis 2 fois qu’il te pose problème.

Aurais-je commis un crime de lèse-majesté ?

Non

Peut-on rire de tout ?

Non

De rust ? De systemd ?

Bien sûr.

Pourquoi les nouvelles technos informatiques sont portées par des commu. toxiques ?

Je n’utilise pas rust je sais pas si on peut dire que je fais parti de sa communauté. Ne pas comprendre ta blague est un comportement toxique ?

Des jeunes générations envieuses de ne pas avoir connu son invention et veulent à tout prix "tuer le père" ?

Mon langage de prédilection et dont je suis un heureux utilisateur fait parti des langages que beaucoup de gens veulent voir mourir et qui et d’ailleurs est annoncé mort depuis longtemps.

Ça n'a pas grand chose à voir avec la discussion je le concède. Mais au départ ça ne devait être qu'une boutade en passant.

D’une part le fait que ce soit une tentative d’humour ne veut pas dire qu’il n’était pas porteur de message. Ensuite quand une blague ne passe pas, ça ne me parait pas malin de blâmer l’auditoire.

Significatif.

De tes préjugés ? J’ai dis que je ne comprenais pas ton message et tu me catégorise de toxique et tente de me traiter de gamin. J’ai dis que la seule chose que je comprenais de ton premier messages était un point de vu sur rust.

Entrer tardivement dans un débat pour tenter une blague avec quelque chose qui n’a pas grand chose à voir avec la discussion pour ensuite dire que ceux qui ne te comprennent pas sont toxiques c’est gonflé, tu ne crois pas ?

https://linuxfr.org/users/barmic/journaux/y-en-a-marre-de-ce-gros-troll

C’est une vraie question. J’ai bien compris ce que tu n’aime pas, mais je vois pas ce que ça vient faire dans la discussion.

https://linuxfr.org/users/barmic/journaux/y-en-a-marre-de-ce-gros-troll

Prend un bouquin de C et lit le chapitre sur le mot clef constante

https://linuxfr.org/users/barmic/journaux/y-en-a-marre-de-ce-gros-troll

Je sais pas de quoi tu parle. Si l’objectif de ton commentaire c’est de dire que tu n’aime pas rust ? C’est bien noté.

https://linuxfr.org/users/barmic/journaux/y-en-a-marre-de-ce-gros-troll

PS : je n’ai pas vérifié si Linux autorise l’usage des Threads C dans ses règles internes

c’est eux qui implémentent les threads donc non

https://linuxfr.org/users/barmic/journaux/y-en-a-marre-de-ce-gros-troll

Mais quand un mec

Mais si la question c’est pourquoi est-ce qu’il faut du rust dans le noyau les erreurs argumentaires de quelqu’un qui ne contribue pas ne sont pas pertinent.

L’un des développeurs historiques explique que même si rust n’set pas une silver bullet, il peut rendre impossible l’énorme majorité des failles de sécurité qu’ils rencontrent. Peut être que le niveau en C de la LKML n’est pas très bon et qu’ils ne font pas assez attention. Mais il semble que des gens comme Linus et GKH ont plus d’espoir en rust qu’en la capacité du groupe à s’améliorer en C.

En fait ça va assez loin puisque le C semble poser des problèmes d’expressivité. Il y a un certain nombre de situations où c’était :

• comment on utilise le void* renvoyé pas cette fonction ?
• regarde comment les autres utilisateurs s’en servent
• le quel ? chacun fait des trucs différent avec…
• ouep

C’est ce genre de choses qui font passer les développeurs rust pour des fouille merde/empêcheurs de tourner en rond.

https://linuxfr.org/users/barmic/journaux/y-en-a-marre-de-ce-gros-troll

Il me semble que pendant un temps Google a maintenu un fork de linux pour AOSP/Android.

https://linuxfr.org/users/barmic/journaux/y-en-a-marre-de-ce-gros-troll

Pas vraiment, tu peux écrire un programme en C tout aussi sécurisé qu'en Rust; c'est 'juste', qu'il va falloir être un poil plus attentif, comme vérifier, les entrées, vérifier la taille des tampons dans les string, et te battre avec le compilo qui va optimiser ton code avec des boucle exit early, supprimer des mise à 0 de valeurs car on s'en sert plus, mais le soucis c'est pas le C.

Ça fait 3 fois que je donne le lien, mais je pense sincèrement qu’au lieu de troller, lire les arguments d’un des premiers concernés serait un bon début à la discussion

https://lore.kernel.org/rust-for-linux/2025021954-flaccid-pucker-f7d9@gregkh/

https://linuxfr.org/users/barmic/journaux/y-en-a-marre-de-ce-gros-troll

C’est tout le sujet. Pourquoi est-ce que tu écrit ton message ? Est-ce que c’est pour que les gens changent ou est-ce que tu ne veut juste plus travailler avec cette personne ?

Quand Hector réagit mal au comportement de Christoph, la seule réaction de Linus c’est « le problème c’est toi ». Au vu de ce qu’il se passait entendre ça c’est assez logique de partir.

https://linuxfr.org/users/barmic/journaux/y-en-a-marre-de-ce-gros-troll

Je comprends pas. Il dit qu’il n’y a plus d’attaque personnel. Je fais remarquer que si et tu répond « et alors ? ». J’ai juste dit que ça existait.¹

Moi mon seul point c’est qu’entre ceux qui utilisent leurs droits pour mener des combats politiques hors de leurs attributions, ceux qui font du brigading sur Mastodon, ceux qui se gargarisent d’être "thin blue line" (terme dont il est difficile aujourd’hui de ne pas le reporter aux Blue Lives Matter) : la gestion tardive et par coup de tête de Linus ne parait pas optimale.

https://linuxfr.org/users/barmic/journaux/y-en-a-marre-de-ce-gros-troll

Je n’ai pas de jugement sur ce qu’a fait Hector Martin. De ce que je comprends Hector Martin (un jeune de 35 ans) tentait d’intégrer des fonctions rust pour qu’elles soient utilisables dans n’importe quel driver rust et Christoph Hellwig a mis un veto dessus expliquant que c’est un cancer. Il ne s’agit pas d’un contentieux entre Hector et Hellwig avec ce veto Hellwig bloquait tous les drivers rust. La situation étant bloquée Hector s’est répandu sur son compte Matodon et cela a mené Linus à affirmer qu’Hector était le problème. Sauf que dans les 10 jours qui ont suivi c’est Hellwig qui se prend sa soufflante parce que finalement il semble que lui aussi avait un comportement problématique.

Ce que je vois personnellement c’est 3 très bons développeurs qui ne savent pas communiquer autrement qu’en étant véhéments, le noyau qui a perdu un contributeur important et beaucoup d’énergie consommée dans cette histoire.

https://linuxfr.org/users/barmic/journaux/y-en-a-marre-de-ce-gros-troll

d'attaque personnelles

Ça arrive encore les attaques personnelles :

How about you accept the fact that maybe the problem is you.

https://lkml.org/lkml/2025/2/6/1292

https://linuxfr.org/users/barmic/journaux/y-en-a-marre-de-ce-gros-troll

TL;DR: Pourquoi des contributeurs souhaitent-ils écrire des parties du noyaux Linux en Rust ? Quel est cet intérêt, ou quels sont-ils, si important qu’il pourraient justifier une complexification global du projet, à plusieurs égards et de façon assez évidente.

L’avis d’un des plus vieux contributeur et mainteneur de la branche stable (entre autre) : https://lore.kernel.org/rust-for-linux/2025021954-flaccid-pucker-f7d9@gregkh/

https://linuxfr.org/users/barmic/journaux/y-en-a-marre-de-ce-gros-troll

Il n'y a pas de solution simple

Il n'y en a pas car il y a des inconvénients à l'intégration de Rust dans Linux:

Le projet deal quotidiennement avec ce genre de décisions.

La plupart de tes remarques consistent à dire qu’il y a plusieurs langages.

Zig/Odin/DasBetterC auraient été probablement plus simple à intégrer mais Zig n'est pas 1.0 (et n'est pas prêt de l'être) et les autres ne sont pas à la mode..

C’est pas dis qu’ils auraient étaient bien plus simple et payer le coût d’avoir 2 stacks pour avoir un second langage qui fait doublon avec celui que tu as déjà ne vaut pas forcément le coût. L’objectif c’est d’avoir la possibilité d’écrire un code plus sûre pas d’avoir un autre langage sinon C++ aurait était un candidat.

Odin semble être fait pour le confort plus que pour la sûreté. Tu peut appeler le langage D comme tu veux, je crois qu’on peut dire que D a échoué l’objectif qu’il s’est donné d’être le successeur de C. Pour Zig j’en sais rien. Mais ce que tu appelle hype (après 20 ans parler de hype est condescendant AHMA) c’est ce qui fait la différence entre se retrouver seul utilisateur du langage (et donc avoir une grosse dette technique) et avoir quelque chose de pérenne.

Si tu te pose la question de pourquoi rust GKH a rédigé un mail pour toi : https://lore.kernel.org/rust-for-linux/2025021954-flaccid-pucker-f7d9@gregkh/

https://linuxfr.org/users/barmic/journaux/y-en-a-marre-de-ce-gros-troll

Tu peux mais ce n'est pas la pratique standard et ça demande pas mal d'engagement parce que c'est ton équipe qui prend de la responsabilité en plus. En plus de suivre les mises à jour des images de bases tu dois suivre celles des projets que tu utilise et de leurs dépendances. C'est possible, mais ce n'est pas un travail anodin si on veut le faire correctement. Plus qu'un truc comme renovate il faut aussi avoir un analyseur d'images docker comme snyk ou aqua. C'est toujours du travail en plus (pour réagir à ces alertes et pour maintenir l'ensemble aller vérifier que les outils fonctionnent toujours etc).

Perso je n'ai fais la démarche que sur notre image qui représentait 90% de nos usages parce que ça avait du sens je l'aurais pas fait pour les autres. Là où je suis maintenant nous sommes nombreux, tout ça est effectivement fait

https://linuxfr.org/users/barmic/journaux/y-en-a-marre-de-ce-gros-troll

Par défaut pour son propre code on devrait dans la mesure du possir toujours utiliser scratch.

Que si tu fais de la compilation statique globalement.

• alpine
• fedora / centos / almalinux / rocky / amazon linux pour avoir une distro basée sur rpm
• la dernière ubuntu lts ou debian pour le monde deb.

Euh alors ça c'est si tu fais ops dans une grande boite et que tu veux proposer un large panel aux développeurs, sinon c'est une par runtime (python, js, R,…) + une part technologie sur étagère que tu déploie dans docker (ton sgbdr, rabbitmq, kafka, nginx, redis,…) + une distribution vanilla éventuellement.

Et en pullant 3-4 d'entre elles une fois par jour pour la mettre dans ta registry privée tu reste loin de la limite.

Pull + reconstruire les images + redéployer
Et c'est ce que tente de faire l'outil plus haut mais mal.

https://linuxfr.org/users/barmic/journaux/y-en-a-marre-de-ce-gros-troll

Je pense qu'avec une recherche moins spécifique tu peux trouver quelque chose de cool. Par exemple avec renovate. C'est un peu plus de travail si tu n'a pas de déploiement continue, mais ça n'est pas forcément si compliqué que ça à mettre en place

https://docs.renovatebot.com/docker/

https://linuxfr.org/users/barmic/journaux/y-en-a-marre-de-ce-gros-troll

Je te dis pas le contraire. Je dis que c'est de l'humain autant pour Asahi que pour ce dont parle Linus dans le journal (tu as d'autres exemples comme Christoph Hellwig qui explique que rust est un cancer). Ça n'est pas simplement des règles qu'il faut (c'est nécessaire mais pas suffisant) c'est que les gens arrivent à échanger de manière apaisée.

https://linuxfr.org/users/barmic/journaux/y-en-a-marre-de-ce-gros-troll

Les problèmes sont là depuis des mois. L'été dernier Linus expliquait que la situation était tendue. Il y a eu plusieurs départ de développeurs ou développeuses rust. Dont récemment le lead du projet Asahi après s'être fait prendre à parti violemment par Linus après que le développeur se soit trop étalé sur les réseaux sociaux.

L'entrée de rust dans le noyau est compliqué et c'est normal. Le problème n'est pas technique mais humain. Il y a une question de responsabilité mais aussi de communication importante. Il semble clair par exemple que les mainteneurs du projet placent leur ego dans le code qu'ils maintiennent. Voir débarquer un groupe de nouveaux qui t'expliquent que tes APIs sont mal décrites n'est pas particulièrement confortable.

Linus fait du Linus. Il aboie de temps en temps pour que les gens fassent moins de bruit, mais nous ne sommes pas dans une situation qui mène à des consensus forts. Tout le monde va souffrir mais tenter de continuer à avancer et bon an mal an les choses vont arriver sur un consensus mou. Dans l'intervalle un certains nombre de personnes auront jeté l'éponge.

Remarquez par exemple que le lead d'Asahi aura trouvé plus simple de s'attaquer à Apple Silicone que de contribuer à linux.

Il n'y a pas de solution simple mais je ne vois pas les aboiement de Linus comme la solution parfaite

https://linuxfr.org/users/barmic/journaux/y-en-a-marre-de-ce-gros-troll

Pardon mais il y a un truc que je ne comprends pas. Bon déjà ce logiciel est buggué de ce qui est décrit dans le ticket et tout cela le met en lumière. Disons pas optimisé si tu préfère, mais là ceux du ticket et toi vous avez de petites stacks pour ceux qui ont des choses plus conséquentes il doit être vraiment pénible à utiliser.

Ensuite je ne comprends pas le bien fondé du proxy refistry. Si me fait d'avoir un cache corrige les choses, c'est bien qu'ils font trop de choses.

Ça a l'air d'être un logiciel écrit dans l'idée que le réseau et les ressources du hub sont infini et gratuites et qui découvre qu'en fait c'est pas le cas.

https://linuxfr.org/users/barmic/journaux/y-en-a-marre-de-ce-gros-troll

D'ailleurs tu pourrais au contraire augmenter la fréquence à une fois par heure. Ça réduit le risque de toutes les mettre à jour en même temps et si ça arrive ça ne retarde que d'une heure l'application de la correction

https://linuxfr.org/users/barmic/journaux/y-en-a-marre-de-ce-gros-troll