Maybe time to pursue alternative implementations[1].
[1]: https://michael.stapelberg.ch/posts/2026-05-24-minimal-memor...
Rsync 3.4.3 has hundreds of Claude commits
31–40 of 86 posts
Re: Rsync 3.4.3 has hundreds of Claude commits
#32Maybe he got notified from the mythos team of a bunch of vulnerabilities and then followed up using claude. Doesn't seem that unlikely. What would you do if suddenly there were a dozen exploitable CVEs in your highly used open source project staring you down? Maybe you'd use the tool that found them to patch them as quickly as possible.
I am absolutely willing to give tridge the benefit of the doubt here, but a note on what you said: I don't think you should ever patch a CVE "as quickly as possible". You should do it slowly, be very sure of the change, and test the hell out of it. You can easily introduce a new security vulnerability by rushing something like that.
Re: Rsync 3.4.3 has hundreds of Claude commits
#33Looks fine? most of the commits are tests, ci, docs and issues that could cause memory corruption / hidden bugs rather than any new feature development. Of course it's unfortunate that it caused this bug to surface and it would be curious to investigate exactly why this happened, maybe the "safe" c operations have different (unexpected) behavior instead of immediately pointing out that "ai bad". I think patching issu…
> Everyone is still learning how and how much AI should be used and we shouldn't be too harsh on opensource developers. The main problem with using AI in open source software is that millions of people rely on your code, but you risk exposing them all to something unverified.
You also risk exposing users to any other error you make. That's called a bug.
Unless someone points to vibe coded/hallucinated code causing the breakage or provides clues that might indicate unreviewed slop code being committed and shipped, I'd hold my horses.
Re: Rsync 3.4.3 has hundreds of Claude commits
#34So they’re just kind of implying a relationship between the 2 things? Maybe there is one, but it doesn’t support the underlying “and that must mean AI bad” hypothesis as much as the author may think. Somebody on the Rsync team has a new tool. They may have neglected their traditional responsibilities using it, but that’s not really a fault of the tool.
My guess is just open source maintainers trying out new genAI tools out of curiosity. Unintentional slopification
Re: Rsync 3.4.3 has hundreds of Claude commits
#35Looks fine? most of the commits are tests, ci, docs and issues that could cause memory corruption / hidden bugs rather than any new feature development. Of course it's unfortunate that it caused this bug to surface and it would be curious to investigate exactly why this happened, maybe the "safe" c operations have different (unexpected) behavior instead of immediately pointing out that "ai bad". I think patching issu…
> Everyone is still learning how and how much AI should be used and we shouldn't be too harsh on opensource developers. The main problem with using AI in open source software is that millions of people rely on your code, but you risk exposing them all to something unverified.
Well maybe we shouldn't then? Before LLMs some not just clueless but also malicious rando could've send a PR too. And the maintainers might've gotten burned out any and just said f-it and merged stuff randomly.
I don't see how AI changed the calculation here much.
Re: Rsync 3.4.3 has hundreds of Claude commits
#36So they’re just kind of implying a relationship between the 2 things? Maybe there is one, but it doesn’t support the underlying “and that must mean AI bad” hypothesis as much as the author may think. Somebody on the Rsync team has a new tool. They may have neglected their traditional responsibilities using it, but that’s not really a fault of the tool.
> Maybe there is one, but it doesn’t support the underlying “and that must mean AI bad” hypothesis as much as the author may think.
It's a tweet. Do you expect thorough null-hypothesis validation from a tweet?
Re: Rsync 3.4.3 has hundreds of Claude commits
#37Looks fine? most of the commits are tests, ci, docs and issues that could cause memory corruption / hidden bugs rather than any new feature development. Of course it's unfortunate that it caused this bug to surface and it would be curious to investigate exactly why this happened, maybe the "safe" c operations have different (unexpected) behavior instead of immediately pointing out that "ai bad". I think patching issu…
> Everyone is still learning how and how much AI should be used and we shouldn't be too harsh on opensource developers. The main problem with using AI in open source software is that millions of people rely on your code, but you risk exposing them all to something unverified.
If millions of people are relying on free software, that's their problem, isn't it? The maintainer has zero obligations to them, and they are not entitled to anything. If they want commercial support or SLAs, they could tender an offer, or else they can fork it and maintain it themselves. I think the maintainer here is being a silly goose but it's their right to be as silly as they want in their own repo.
Re: Rsync 3.4.3 has hundreds of Claude commits
#38LGTM, ship it.
/s
Is there any sign of enough code review this release got?
Re: Rsync 3.4.3 has hundreds of Claude commits
#39So they’re just kind of implying a relationship between the 2 things? Maybe there is one, but it doesn’t support the underlying “and that must mean AI bad” hypothesis as much as the author may think. Somebody on the Rsync team has a new tool. They may have neglected their traditional responsibilities using it, but that’s not really a fault of the tool.
I agree that it is not a fault of the tool, but of the human who must have used it improperly.
However, rsync is one of those applications where correctness has an extreme importance. If it fails completely, that is still not so bad, but any kind of subtle corruption in file data or in file metadata can be catastrophic.
I expect from an rsync developer a much higher standard for program correctness verification than for most other computer applications, so these events are very worrisome.
I do not care whether someone uses an AI tool, but I care very much about whether any written code, regardless of its author, is verified very thoroughly, or not.
Re: Rsync 3.4.3 has hundreds of Claude commits
#40Earlier quoted context omitted.
Seems like 3.4.2 was already vibe-maintained: https://github.com/RsyncProject/rsync/commits/v3.4.2
So? May main point is: Which commits actually broke the functionality? Going from 3.4.3 to 3.4.2 to test should be easy for anyone affected and would have been more helpful than this rant. I'm not defending bad slop commits, especially for such a long running project but the tribal Fediverse outrage whenever LLMs are involved is often just lazy and uninformed. To quote this PR: https://github.com/RsyncProject/rsync/i…
Figuring out which commit broke what functionality is not something you can expect users to do.