barmic 🦦 a écrit 5709 commentaires

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

Ça ne change pas le problème si ton image de base est mise à jour tu va la pull, mais avoir toutes tes images de bases qui changent en même temps ça me surprend

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

Il ne le fait que si tu as effectivement de nouvelles images.

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

Une erreur de pull c'est tout de même plutôt clair. Sinon passe sur le registry d'un cloud provider ou de RedHat par exemple

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

Tes 22 images changent tous les jours ?

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

On mélange beaucoup de choses. Le problème c'est de dire à sa communauté "regardez lui ! X avec cet ensemble d'informations que j'ai sur lui. C'est mon ennemi". Ça, que tu soit un youtubeur ou un journal de presse, c'est inadmissible. Quand bien même cet X est problématique.

C'est ça le sujet, c'est de ça que parle la pétition et rien d'autre.

Ressortir par exemple que tout le monde se renvoie la balle n'est pas un problème en droit français, les règles sont plutôt simples à ce sujet.

Encore une fois tout ce qui a trait à ce qu'est ou ce que n'est pas le Point n'est pas le sujet de la pétition (même s'il faut avouer que le fait d'utiliser ce genre de procédés en faisant mine d'ignorer de quoi il s'agit ne donne pas une très bonne image de ce que fait ce journal).

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

Tu évacues quand même la question fondamentale de la responsabilité d'écrire dans Wikipédia "X est un journal d'extrême-droite / islamophobe" quand le journal ne le revendique pas, et encore moins quand le journal considère que c'est de la calomnie. Au mieux, tu peux écrire que le journal est parfois qualifié d'islamophobe, mais que cette ligne éditoriale n'est pas revendiquée, ou quelque chose comme ça.

T’es entrain de dire que tout le monde n’est pas d’accord avec ce qui est écrit sur wikipedia ? Si seulement il existait un moyen d’en discuter sur wikipedia.

Parce que s'il y a procès pour diffamation, c'est bien les contributeurs qui vont devoir répondre à la justice, sous leur vrai nom et à visage découvert.

Mais c’est justement à la justice de le faire. Le doxxing c’est simplement la porte ouverte à une vindicte populaire. Cette pétition n’existerait pas si le journal avait simplement décidé de porter l’affaire devant un tribunal. Des gens en auraient parlé mais c’est tout.

Je crois que c'est bien de ça dont il est question au fond[…]

Justement non. La question n’est pas de savoir si Le Point doit se défendre, ils en ont le droit. La question c’est qu’est qu’ils font pour se défendre.

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

Ça ne s'appellerait pas un plan social déguisé ?

Mais quelle est le rapport avec systemd ou wayland ? Si, a chaque frustration, tu ressasse tous les malheurs de l’univers, tu ne va pas t’en sortir. Il faut savoir ségréguer.

Je mets ça sur le compte de mon code, dans lequel je n'ai pas confiance (quelqu'un ici pour affirmer "mon code est nickel, zéro bugs" ?). Premier réflexe : où est-ce que ça pourrait déconner.
Mais ça déborde de ce domaine.

Mais c’est aussi un problème, c’est génial de trouver un bug. C’est infiniment mieux que lorsqu’il n’a pas était trouvé et il faut pas que le risque rende immobile ou paranoïaque. Même en informatique cette paranoïa n’est pas bonne, il faut évaluer les risques.

Ta formulation "te désigner des ennemis" supposerait que je n'en ai pas. On en a tous, même si on ne les connaît pas personnellement.

Les développeurs de systemd ne se lèvent pas le matin en complotant contre toi, les mainteneurs de debian n’ont pas ton portrait au dessus de leur bureau, ceux qui connaissent les évolutions récentes de linux ne les apprennent pas pour te mettre la honte.

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