Hacker News new | ask | show | jobs
by RustyRussell 14 days ago
I'm shocked that people are jumping on one of the most productive and powerful OSS maintainers in existence.

The actual Claude "churn" is mainly test suite enhancement.

3 comments

One of the most reliable OSS sync/backup tools on the planet for 2+ decades broke under people's daily backup use of it because of a large pile of LLM-driven changes basically out of nowhere from the project maintainer in a minor point release. I think they're right to be annoyed and to complain about it.

Whilst a lot of the Claude changes are test related, there were still other changes that obviously broke things for people - and who's to say that some of the testing changes may not have thinned out the testing too given one commit "rewrote all shell tests in python" with over 4000 lines added and removed at once. And even after all that Claude churn on the testing, these breaking changes obviously weren't caught by tests, so it's not exactly an "enhancement" from the end user perspective.

It has broken many times before. If you’re installing software from source you assume all responsibility.

Go use Debian if you don’t want to deal with breakage.

Just because you got shat on the head once it doesn't mean it's fine to be shat on the head every day now.
> Just because you got shat on the head once it doesn't mean it's fine to be shat on the head every day now.

This happens frequently when there are fixes for CVEs, since regression tests can't catch many things which incremental rollouts can. It happened for example in 2025. People are right to imply the reaction is totally outsized here, and it's almost certainly the case that people are overreacting to AI (rather than the somewhat weak idea that it's because of the frequency of these issues).

What's really funny is that the people opposing AI here are showing far less literacy than those who wrote the code. People claiming to be affected by this bug severely are likely exposing themselves: * One bug is for Linux < 5.6, where it didn't hit distributions. This is a low severity bug where it can't build, where distribution maintainers may be reasonably expected to fix it themselves (although rsync will also fix it eventually too).

* The other bug affects precisely the people impacted by the CVE https://github.com/RsyncProject/rsync/issues/897

You probably don't want to revert in this scenario. If someone is hit by this bug and is running rsync in an automated manner, it is highly likely they're ignoring very many security practices: you're usually not supposed to run native rsync in an automated manner (the main use case is for public users, where you can't SSH etc; since it's unencrypted, you're supposed to check a checksum against a website etc); these cases are hit with chroot false, which is deeply discouraged and leads to far larger attack surfaces.

I wonder if the maintainer got jumpy because of all the llm generated valid bug reports lately?
Besides the syscall regressions...