S’il vous plaît, ne sabotez pas ce logiciel avec le vibe coding
(github.com/RsyncProject)- Cette issue s’est terminée avec le statut Closed et, comme il s’agissait d’un message de contestation sans procédure de reproduction ni proposition de correctif dans le corps, aucune branche, PR ou milestone liée n’apparaît
- La plainte initiale portait sur la crainte que des modifications impliquant l’IA soient intégrées à rsync, au risque d’en fragiliser la stabilité, et le contenu a été publié principalement sous forme d’images, sans explication textuelle
- Un utilisateur rapporte que, comme log2ram utilise rsync, son imprimante 3D a tourné à 100 % CPU, affirmant ainsi que l’IA a en quelque sorte injecté ce bug dans un robot
- Un autre utilisateur estime que rsync était un outil stable qui n’avait besoin que de mises à jour de sécurité et de corrections de bugs, et que les deux dernières patch releases ont introduit des problèmes qui n’auraient pas dû modifier le comportement existant
- Un utilisateur qui emploie rsync pour des activités de DFIR explique que le simple fait que l’IA participe aux mises à jour suffit, au regard des politiques de son organisation, à faire classer le projet parmi les « outils d’IA », ce qui impose un examen supplémentaire
- En face, certains répondent que l’issue tracker n’est pas un espace destiné aux plaintes virales et qu’en l’absence de bug report concret ou de procédure de reproduction, il faudrait déplacer cela vers Discussions ou forker le projet
- Le conflit central s’est amplifié entre la position selon laquelle « c’est un logiciel libre, donc si cela ne vous convient pas, fork it » et celle selon laquelle rsync est déjà un outil d’infrastructure critique, au point que le simple débat sur l’épinglage des versions ou les forks côté downstream constitue en soi un signal d’alerte
- Certains ont évoqué une réécriture en Rust ou un fork, mais d’autres ont rappelé que rsync est apprécié pour sa stabilité et son comportement inchangé, et qu’une réécriture relèverait d’un projet distinct
- Du côté favorable à l’usage de l’IA, on soutient qu’il ne faut pas réduire toute mention de l’IA à du « vibe slop » et qu’il faut auditer directement l’historique des commits depuis mars pour vérifier les raisons des changements
- kaithar explique que les travaux récents comprennent des corrections de bugs et de failles de sécurité ainsi que du hardening, notamment sur des lectures de mémoire non initialisée, des overflows/underflows dans le protocole réseau, les timestamps 32 bits et des ajustements liés au standard C
- Le même commentaire rétorque que rester bloqué sur une ancienne release comme 3.4.1 peut laisser les utilisateurs sur une version comportant plusieurs CVE, et que les régressions peuvent provenir de cas limites que les tests n’ont pas couverts
- En conclusion, l’issue n’a pas abouti à une correction de bug concrète et reste surtout une controverse sur la manière de traiter la confiance, l’audit et la gouvernance du développement assisté par IA dans une infrastructure stable de long terme comme rsync
1 commentaires
Avis sur Hacker News
Cette chasse en meute est vraiment bizarre, et certains semblent agir de façon irrationnelle. Je peux comprendre jusqu’à un certain point la motivation de vouloir « gagner » cette bataille, mais certainement pas comme ça ; au final, ça donne juste l’air de fanatiques.
Cinq minutes suffisent pour parcourir les 17 résultats en cherchant regression sur la page des issues. Il y en a peut-être encore plus dans l’ancien système de suivi utilisé avant GitHub.
Ce comportement est extrêmement stupide, et on dirait que les gens essaient de s’accrocher à tout ce qu’ils peuvent pour justifier leur haine de l’IA. Comme s’ils avaient oublié que les gens faisaient déjà des erreurs avant l’IA.
S’il y a des preuves que l’IA a significativement augmenté le nombre d’issues non résolues de rsync, j’aimerais bien les voir. Je changerai volontiers d’avis dans ce cas.
Ce n’est peut-être pas la cause directe de ce commit-ci, mais cela peut être une réaction à d’autres problèmes accumulés, et cela mérite en soi d’être pris en compte.
J’ai l’impression que des gens en ont assez de devoir avaler de force des discours du genre « l’IA est ce qu’il y a de mieux depuis [métaphore culturelle] », et qu’ils s’agrippent au moindre prétexte pour résister ; je trouve que c’est une réaction assez normale.
Si personne n’exprime la préoccupation que les utilisateurs ne font pas confiance à l’IA, comment le mainteneur pourrait-il le savoir ? rsync était très stable. Les gens devraient simplement migrer en silence vers Openrsync sans rien dire ?
L’un des liens qu’elle contient mène vers un regroupement plus large de bugs signalés dans des distributions dérivées (https://github.com/void-linux/void-packages/issues/60825).
Vu la réputation des logiciels issus du vibecoding, cette colère est tout à fait rationnelle. Même des experts appréciés disent qu’« il faut les manier d’une manière très spécifique pour éviter d’introduire des bugs, et qu’il vaut probablement mieux ne les utiliser que pour des versions 0 servant à explorer un domaine ».
Et pourtant, on voit ici l’outil central de sauvegarde standard de l’industrie se faire retirer le tapis sous les pieds des utilisateurs, de manière manifestement peu sûre, parce qu’un mainteneur veut « ajouter davantage de fonctionnalités ».
Dans le fil Timeshift, on trouve aussi un message disant qu’« après une mise à jour de rsync, l’utilisation CPU pendant les sauvegardes quotidiennes est devenue tellement excessive qu’il a fallu arrêter timeshift qui tournait indéfiniment ».
Autrement dit, les gens sont frustrés et en colère parce que l’outil auquel ils confiaient leurs sauvegardes et leurs données est en train de casser toute leur infrastructure de sauvegarde avec un nombre énorme de régressions et de nouveaux bugs, et que la raison semble être que le développeur principal fait du vibecoding.
Même un expert du vibecoding comme Simon Wilson précise que cela n’est possible que « si l’on manipule les outils d’une certaine manière » ; soit ce mainteneur ne le fait pas, soit cette affirmation est fausse.
Si on lit réellement ce fil au lieu de simplement survoler les passages où deux personnes se disputent, on y trouve plusieurs témoignages indiquant que des utilisateurs dans des environnements industriels et gouvernementaux doivent refaire toute leur procédure pour mettre à jour ce logiciel. Le logiciel est devenu immédiatement non fiable, causant un préjudice direct aux utilisateurs et sapant la raison même de son existence.
Moi aussi, si j’avais confié plus de 500 Go de sauvegardes à ce logiciel, je serais en colère, et je me demanderais combien d’autres problèmes ont pu être introduits sans être détectés, jusqu’au jour où une entreprise qui ne teste pas régulièrement ses sauvegardes subira une perte de données de 10 millions de dollars.
Je ne comprends vraiment pas.
Il existe des logiciels robustes utilisés par énormément de personnes et de services. Ils fonctionnent bien, remplissent leur rôle, et n’ont besoin que de petites mises à jour occasionnelles pour corriger des bugs mineurs.
Pourquoi faut-il de l’IA ici ?
Et je ne comprends pas non plus pourquoi des gens disent : « fork le projet et utilisez l’ancienne version ». Ça devrait être l’inverse. Il faudrait créer un fork parallèle du type younamethetool-ai et laisser l’original tranquille.
Je vais devoir fork et maintenir tous mes outils système, maintenant ?
Se plaindre dans l’issue tracker, sans preuve, que l’IA est en train de ruiner le logiciel est une forme de harcèlement des contributeurs open source souvent évoquée sur Hacker News [1].
https://github.com/RsyncProject/rsync/issues/929#issuecommen...
« Un issue tracker n’est pas un endroit où récolter du contenu pour des posts viraux sur les réseaux sociaux. Signalez un bug exploitable ou faites votre propre fork. Déverser votre frustration sur les choix des développeurs n’est pas productif. »
https://github.com/RsyncProject/rsync/issues/929#issuecommen...
« @II-Paulus-II, arrête. Tu ne sais rien. Tu as déployé exactement zéro fonctionnalité à la main. Personne ne dépend de ton code. Tu n’es qu’un donneur de leçons qui pointe du doigt en disant “c’est l’IA qui a écrit ça”, caché derrière une prétendue supériorité morale parce que tu écris toi-même des projets jouets et des scripts depuis zéro. Tu ne sais pas déployer, tu ne sais pas t’adapter, et tu ne comprends même pas qu’un issue tracker n’est pas l’endroit pour afficher cette attitude. »
[1] https://news.ycombinator.com/item?id=43077833
Je n’ai pas lu dans le détail, mais la phrase « 6 CVE ont été corrigées dans cette release. Les six ont été attribuées par VulnCheck en tant que CNA. Dans tous les cas, les versions affectées sont 3.4.2 ou antérieures » me semble être une réponse assez forte à la question « pourquoi ? ».
https://download.samba.org/pub/rsync/NEWS#3.4.3
Il suffit d’imaginer : vous créez gratuitement quelque chose comme hobby, puis vous devez gérer une foule en colère qui n’a jamais payé un centime parce que vous avez fait quelque chose qui ne leur plaît pas.
Ma première réaction serait évidemment de leur dire d’aller voir ailleurs.
Si le « grand public » veut reprendre le projet pour le maintenir, il peut le fork, mais c’est un travail peu gratifiant.
Et dans un projet open source, il n’y a même pas besoin d’avoir une raison pour changer les outils utilisés, et encore moins de vous devoir cette raison.
La manière dont cette issue a été ouverte est vraiment déplaisante, mais je ne comprends pas pourquoi on a l’impression que les mainteneurs ont lâché de l’IA sur rsync. Pourquoi faire ça ? Ils ont déjà acquis réputation et confiance, ils sont leaders dans une niche précise, à l’abri de la pression du marché, les gens aiment l’outil, et il fait exactement bien ce qu’il doit faire ; alors pourquoi essayer un bric-à-brac relativement expérimental ?
Ça fait penser à cette courte tirade dans Matrix sur le fait que l’esprit humain primitif ne peut pas accepter le paradis. Ils avaient un outil parfait, ils avaient gagné, ils sont presque irremplaçables dans leur niche, dignes de confiance et, au sens figuré, devenus un nom connu de tous. Le risquer ou y toucher n’a de sens pour personne et laisse vraiment perplexe
Cela dit, faire ça sur l’issue tracker officiel reste un comportement vraiment déplaisant. L’attitude est mauvaise et ça ne semble pas animé de bonne foi
Mais aujourd’hui, l’IA ne me semble positive nulle part, et je vois cette réaction hostile à l’usage de l’IA générative comme un bon réajustement collectif
Il y a des textes sur la gratification immédiate liée à l’usage des LLM, et plus j’interagis avec des gens qui utilisent ces outils, plus je me dis que c’est peut-être vraiment le cœur du problème. Notre biologie n’est pas à la hauteur
Je vois des gens à l’origine très intelligents faire des choses vraiment stupides parce que la machine à sous leur a dit de le faire, puis se faire dresser à devenir impuissants quand la machine à sous échoue
On me traite de luddite incapable de voir le progrès, alors que je vois des collègues fabriquer des benchmarks sans signification et y coller de beaux graphiques générés par IA
Ensuite, je dois choisir entre sourire et faire semblant que c’est du bon travail, ou les réprimander parce que le benchmark est sans intérêt puisqu’il teste une portion figée en constante. Dans les deux cas, je finis par les traiter non comme des collègues intelligents, mais comme des enfants de 7 ans
Que les mainteneurs de rsync se situent quelque part entre des mainteneurs parfaits et responsables et des enfants incompétents, en réalité nous n’en savons rien
Mais au risque de m’éloigner un peu du sujet, je me fais la réflexion suivante. En laissant de côté le fait qu’un logiciel mûr comme rsync n’a pas besoin d’activité mesurée en lignes de code modifiées, supposons que les mainteneurs gèrent le projet avec les meilleures intentions
Si cela arrive dans l’open source, dans quel état est la qualité du logiciel propriétaire ?
L’usage de l’IA, c’est-à-dire le volume d’inputs, entre dans l’évaluation des employés comme s’il s’agissait d’un indicateur de réussite, et les gens paniquent face à la menace de licenciements massifs provoqués par l’IA
Vertigineux
https://github.com/RsyncProject/rsync/issues/929#issuecommen... montre qu’il ne fonctionne plus sur les anciens Darwin et sur Linux < 5.6, or Linux 5.6 est une version dont l’abandon était prévu dès 2020. Il y a aussi quelques autres bugs
On ne peut pas attendre d’un mainteneur qu’il prenne en charge les anciens systèmes et qu’il connaisse à l’avance tous les effets d’un changement, que ce soit fait par IA ou à la main
Pour référence, le bug lui-même a été introduit dans 30656c5e, généré par Claude Code, avec sans doute une revue et des tests menés par des personnes inadaptées
https://github.com/RsyncProject/rsync/commit/30656c5e
Quelqu’un a utilisé l’IA pour bisecter récemment rsync : https://github.com/themgt/rsync-compare-link-dest-341-343-re...
Tentative de correction avec encore plus de Claude Code : https://github.com/RsyncProject/rsync/pull/930
Ticket lié : https://github.com/RsyncProject/rsync/issues/915
Je recommande d’ajouter davantage de tests de régression au commit juste avant 30656c5e, puis de rebaser à partir de là en conservant la fonctionnalité
Ce n’était pas une « nouvelle fonctionnalité non désirée ». Tridge corrigeait un problème de sécurité lié à un rapport de bug. Je compatis. Nous nous faisons tous frapper par les problèmes de sécurité. Les corriger n’est pas facultatif
Je ne dirais pas qu’il est amusant de revenir sur un logiciel vieux de 10 ans pour traiter ce genre de chose, donc je trouve déjà impressionnant que tridge fasse l’effort
Moi aussi, j’ai le tort d’utiliser des LLM pour traverser ce genre de chaos. Je ne sais pas ce que fait tridge, mais moi je vérifie ligne par ligne le code produit par le LLM. Même ainsi, le risque qu’un bug se glisse dedans reste clairement élevé
Je n’avais pas regardé ce code depuis longtemps et je ne le connais plus aussi bien qu’avant. Donc voir un bug s’y glisser n’a rien de très surprenant
Ce qui est étrange dans cette explosion, c’est que l’auteur de la plainte initiale semble vouloir protéger de façon extrême son système de sauvegarde, alors que le commit de tridge ne datait que de deux semaines. Je sais que tridge est excellent, mais ce genre de chose ne devrait-il pas, par évidence, être traité comme un logiciel alpha ? À quoi pensait cette personne ? Elle devrait peut-être aussi apprendre un peu comment construire un système fiable
Il y a quelques années, ce genre de billet aurait eu une probabilité proche de zéro d’arriver en une de Hacker News. Indépendamment du fait que le fond soit juste ou non, c’est parce qu’il n’y avait pas ici une masse de gens ordinaires incapables de comprendre quels comportements sont inacceptables
Ce dont il est question ici, c’est du langage violent de l’issue. Or, désormais, nous sommes entourés de gens incapables de faire la distinction, même pour les choses les plus évidentes
Ce n’est pas une façon de dire aux mainteneurs qu’on n’est pas d’accord avec l’orientation du projet. Cette issue est totalement inutile. Il aurait mieux valu un rapport de bug disant que c’était « cassé à cause du vibe coded »
C’est cela qui allait droit au but. Aucun rapport de bug n’essaie ne serait-ce que de documenter la régression --compare-dest= avancée. Même avec un Ctrl-F, je n’ai vu personne remmentionner « compare-dest »
Les gens qui postent des commentaires de rage inutiles sur l’IA auraient pu demander à Opus 4.8 d’exécuter rsync 3.4.3 et 3.4.1, de documenter soigneusement la régression et de retrouver le commit fautif avec git bisect pour produire un rapport de bug mille fois plus professionnel et utile
Si la société veut considérer le travail humain comme plus précieux que celui de l’IA, mieux vaut éviter les comportements idiots que seuls les humains peuvent avoir
La raison pour laquelle c’est monté en une n’est-elle pas peut-être que d’autres ressentent la même chose à propos d’un logiciel qu’ils utilisent tous les jours pour un travail important ?
Les issues GitHub sont certes un exercice banal et manifestement ingrat, mais en pratique rsync est une pierre angulaire de nombreux pipelines sensibles
Si vous pensez vraiment qu’elle est hors sujet, la réponse polie consiste à fermer l’issue
Je ne vois toujours pas bien ce qui serait si évident. À mes yeux, « arrête. tu ne sais rien. tu as déployé zéro fonctionnalité à la main. personne ne dépend de ton code » paraît bien plus violent que « please do not vibe fuckup this software »
Dans ce fil d’issue, est-ce que quelqu’un a réellement expliqué le problème ? Je parle d’étapes de reproduction, du comportement attendu et du comportement observé
C’est sur un traqueur d’issues. « Un message de commit mentionne Claude, et quelqu’un sur Bluesky pense qu’un problème non spécifié qu’il a rencontré est lié à ces commits » ne constitue pas une issue exploitable
En mettant de côté tout le reste du débat, si c’était mon projet, j’aurais fermé et verrouillé pour « informations de reproduction insuffisantes ». Il existe de meilleurs endroits pour les discussions générales sur l’IA, les forks et les coups de colère
Les utilisateurs de Linux < 5.6 ne peuvent pas compiler depuis GitHub. Cela me semble une régression assez mineure. Les personnes utilisant une version maintenue de 5.6, principalement des versions de sécurité étendues, peuvent probablement compter sur leur mainteneur de distribution pour détecter l’échec de compilation et le corriger à temps
Le durcissement contre les attaques par traversée de chemin provoque des échecs chez les utilisateurs du protocole rsync natif sans chroot. Ironiquement, chroot = no n’est pas fortement recommandé
On ne devrait pas utiliser rsync natif de façon automatisée, et l’on pourrait même recommander de ne pas l’utiliser du tout. Le CVE corrigé par ce commit s’applique précisément à ce cas d’usage
https://www.cve.org/CVERecord?id=CVE-2026-29518
Il faut un daemon + no chroot. « daemon runs with elevated privileges. This vulnerability can only be triggered if the chroot setting is false. »
Ainsi, le workflow affecté est le plus vulnérable, et pourtant des gens recommandent de revenir à une ancienne version
De plus, si un test de régression aurait dû détecter cela, ce test aurait dû exister auparavant
Certains semblent avoir oublié ce qu’est un projet FOSS
« 15. Exclusion de garantie
Dans la mesure permise par le droit applicable, il n’existe aucune garantie pour ce programme. Sauf indication contraire écrite, les détenteurs du copyright et/ou les autres parties fournissent le programme “en l’état”, sans aucune garantie, expresse ou implicite. Cela inclut, sans s’y limiter, les garanties implicites de qualité marchande ou d’adéquation à un usage particulier. L’intégralité du risque concernant la qualité et les performances du programme vous incombe. Si le programme s’avère défectueux, vous assumez le coût de tous les services, réparations ou corrections nécessaires »
Je me réserve le droit de me plaindre, maugréer, critiquer, m’énerver ou commenter de toute autre manière toutes les décisions, commits, patchs, actions marketing et autres décisions prises par un projet. Ces commentaires ne garantissent en rien une quelconque adéquation à un usage et n’incluent aucune garantie implicite quant au fait d’être corrects, utiles ou aimables. Si mes commentaires s’avèrent indésirables, vous conservez le droit de vous les mettre où le soleil ne brille pas
Vous pouvez imprimer cette clause de non-responsabilité pour vous y référer lorsque vous tombez sur des critiques non sollicitées d’un projet FOSS
Je ne comprends pas pourquoi les gens n’arrivent pas à saisir que l’attitude « ils peuvent faire ce qu’ils veulent » vaut dans les deux sens. Les utilisateurs aussi peuvent faire ce qu’ils veulent. S’ils n’aiment pas quelque chose, ils peuvent l’exprimer
Un des commentaires de l’issue le dit ainsi
« Ce n’est pas parce qu’on offre de la soupe gratuite à un sans-abri qu’on peut uriner dedans »
Cette issue est déjà devenue un fiasco, et votre argument y a déjà été avancé. Tout le monde aurait pu mieux gérer les choses, mais citer aveuglément un texte juridique ne résout rien et n’améliore rien
C’est la troisième fois que je lis un post HN sur ce sujet. À chaque fois, on ne revoit que le même tweet, ou ce post comme on l’appelle sur Mastodon/Bluesky et consorts. Est-ce que quelqu’un a réellement débogué le problème ?
Est-ce que la cause était du code généré à la va-vite, ou bien un vrai correctif de sécurité qui l’a cassé par accident ? D’une manière qu’un humain aurait tout aussi bien pu produire
Cette hystérie anti-IA est un cas typique de panique morale
Comme pour toute panique morale, le fait que le point 1 soit vrai ou non est entièrement secondaire. L’essentiel, c’est de tirer du point 2 une forme de jouissance presque sexuelle
Dans ce cas, je sais qu’il y a du code généré par IA dans rsync. Comme c’est désormais le cas de la plupart des logiciels utiles. Mais en ligne, on voit chaque jour des chasses aux sorcières, et comme dans toute chasse aux sorcières, le fait que l’accusation soit fondée n’a pas beaucoup d’importance. L’hystérie est elle-même le but
La colère autour de l’IA n’existe pas parce que le public serait mal informé ou parce que le message serait mauvais, mais à cause de la réalité matérielle
Cette seule chose sert de prétexte à des licenciements de masse, les CEO de la tech disent presque tous les jours qu’ils vont aussi prendre le travail de tout le monde, et les grands groupes du cloud aspirent tout l’oxygène de la pièce. Même l’industrie du jeu vidéo n’y a pas échappé
Voir cela comme « juste une panique morale typique », c’est comme regarder de quel côté la mer se retire et courir droit dans cette direction
En lisant davantage, on voit aussi l’usage de termes émotionnels comme « chasse aux sorcières » et « hystérie »
Est-ce vraiment une chasse aux sorcières ? Et peut-on savoir si des gens de l’autre côté d’Internet s’approchent d’une forme de jouissance sexuelle ?
N’êtes-vous pas en train de réagir de la même manière aux formulations émotionnelles et au raisonnement relâché des autres ?
Depuis quand les issues GitHub sont-elles devenues un endroit où poster des captures d’écran de publications d’autres plateformes ?
Je n’ai vu ce genre de comportement que dans des endroits où l’on poste des mèmes ou du contenu de divertissement
Il n’y a ni rapport de bug exploitable ni demande de fonctionnalité. Il n’y a même pas de version texte. Pas même de lien vers le post original
La personne qui a posté ça a-t-elle pris les GitHub Issues pour son compte Twitter personnel ?