Live data from Hacker News

Rsync 3.4.3 has hundreds of Claude commits

mastodon.gamedev.place

21–30 of 86 posts

Re: Rsync 3.4.3 has hundreds of Claude commits

#21
Reposting some of the (likely) bad commits with issues open against them, just to show that this isn't a one-off:

- https://github.com/RsyncProject/rsync/commit/4fa7156ccdb2ad3...: https://github.com/RsyncProject/rsync/issues/905 https://github.com/RsyncProject/rsync/issues/900

- https://github.com/RsyncProject/rsync/commit/1d5b5ab83af84db...: https://github.com/RsyncProject/rsync/issues/924

- https://github.com/RsyncProject/rsync/commit/859d44fa4f14207...: https://github.com/RsyncProject/rsync/issues/897

- https://github.com/RsyncProject/rsync/commit/30656c5e358b1c6...: https://github.com/RsyncProject/rsync/issues/896 https://github.com/RsyncProject/rsync/issues/915

- https://github.com/RsyncProject/rsync/commit/8112445318a35e4...: https://github.com/RsyncProject/rsync/issues/910 https://github.com/RsyncProject/rsync/issues/927

Re: Rsync 3.4.3 has hundreds of Claude commits

#22

Looks 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…

Yeah this is how software development works now, no matter how much anyone wants to disagree with it. The technology is here, you can't put it back in the box. If your tool has AI agents trying to find exploits 24/7, you'll need something comparable.

It is worth figuring out the new science of software engineering to get it right.

I suspect we are going to find plenty of new techniques that make this sort of development work better. After all, it took fifty years to arrive at our best known (unit test + reviewable tiny change, get an LGTM) model of software development.

Re: Rsync 3.4.3 has hundreds of Claude commits

#23

Looks 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.

Re: Rsync 3.4.3 has hundreds of Claude commits

#24
This is a problem of insufficient checking happening in-between a PR being made, and it being committed.

Imagine you have a low quality coder in your coders, they produce a lot of code, but while some of it is fine, some of it is... dubious. That is no different from an AI and the way you deal with it is the same. You check the PR before committing it.

To allow PRs from them (or anyone really) to get merged without proper checking for bugs etc is just sloppy repo management. The problem is not "AI bad, human good", it is that a human is allowing PRs through to release without properly checking them.

Re: Rsync 3.4.3 has hundreds of Claude commits

#25
So 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.

Re: Rsync 3.4.3 has hundreds of Claude commits

#27

So, has anyone actually checked if it's just an issue with 3.4.3? Going to back to 3.4.1 skips 3.4.2 which features many contributions that aren't either by Andrew or Claude.

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/issues/928

> NOTE: This also affects backported rsync versions when they're used on the Receiver: > Debian: 3.4.1+ds1-5+deb13u3 / 3.2.7-1+deb12u5 / 3.2.3-4+deb11u3 > Ubuntu: 3.2.7-1ubuntu1.4

Re: Rsync 3.4.3 has hundreds of Claude commits

#28

So, has anyone actually checked if it's just an issue with 3.4.3? Going to back to 3.4.1 skips 3.4.2 which features many contributions that aren't either by Andrew or Claude.

Seems like 3.4.2 was already vibe-maintained: https://github.com/RsyncProject/rsync/commits/v3.4.2

It's pretty shitty to accuse someone of vibe-coding without having any idea what their LLM-assisted development process is. Let's do better, please.

Re: Rsync 3.4.3 has hundreds of Claude commits

#29
Well, there's 1 +claude commit prior Mythos/Glasswing announcement and the rest are after the announcement. Take of it what you will.

Anyway, seems blown out of proportion. There are a few issues in the tracker, some repeated or obscure. Linux 5.10, really? You want to run frankenkernel from 5 years ago with 30 000+ patches never meant or developed against it applied on top? Good luck. Rsync is least of your worries.

Linux stable, especially these 5 year old trees are mostly a pacifier for companies that don't want to upstream and maintain their drivers and keep up with evolving internal kernel interface. It's nothing good for users, technically.

And I guess if I clone the repo and do a diff against pre-claude and claude assisted state, most of the changes will not be in the actual C code.

Re: Rsync 3.4.3 has hundreds of Claude commits

#30
post #20
post #10

It's rather ironic that in profit making enterprises using AI are not only encouraged but also part of KPIs. But in open source it's scourge

I don't think using AI as such is the core problem here. It's the type of use. Vibe coding, brain off coding and blind trust are the issue, and an issue everywhere, just enterprises were never really about quality in the first place. But eventually, they too will generate more crap than they can handle.

I mean, we have no idea how tridge is using claude. I would easily give him the benefit of the doubt that he's not vibe-coding, is involved in the change (not just turning on auto-accept), and reviews the output before committing.

But it seems like everyone's immediate hot take here and on Mastodon is to assume the worst and shit on him.

Post reply on HN