Live data from Hacker News

Did Claude increase bugs in rsync?

alexispurslane.github.io

341–350 of 611 posts

Re: Did Claude increase bugs in rsync?

#341

Earlier quoted context omitted.

> An entire software industry built on top of a burning garbage pile of crappy, dead code. That has been the case for the last, oh, decade or so. Where do you think LLMs learned to slop code?

Things have been bad, but every company using its own bespoke LLM reimplementation of rsync and similar is so, so much worse.

Why would every company do it though? They'll just all be using the same (Anthropic's) AI-enabled fork.

Re: Did Claude increase bugs in rsync?

#342

I haven't used this thing for like 10 years, when my modus operandi was googling my question and installing whatever stackoverflow suggested. Can someone explain why one would ever use rsync (pre vibecode version) instead of cp and dd? Can't we just 'apt remove rsync' and save ourselves the time even spent on evaluating this dependency? Thanks

> rsync (remote sync) is a utility for transferring and synchronizing files between a computer and a storage drive and across networked computers by comparing the modification times and sizes of files.

https://wikipedia.org/wiki/Rsync

Re: Did Claude increase bugs in rsync?

#343
post #291

Earlier quoted context omitted.

> If I do rewrite everything myself, then it's evidence of deceptiveness... despite being asked by multiple people to do that I don't know who asked you to do it. I wouldn't have done it. Personally, the original intent matters far more to me. You intended to submit an AI-generated article, defending AI, to be read by humans. Anything short of taking the article down and rewriting the entire thing from scratch doesn'…

Okay, so let me get this straight. Because I used AI to, among other things, write the prose of the original draft of this article, all of the days of effort researching and carefully thinking through the metrics I would use, and the methodologies to analyze them, and rewriting the entire analysis multiple times from scratch based on specifically asking people in my life who are qualified in statistics what I should…

If you really did spend days on research and methodology (which, to be clear, I'm not denying), that just makes it all the more disappointing that you decided to cap it all off with a long AI generated article. The article is what I'm focusing on because it's what you expect other people to actually read, and it's what you submitted here.

Ultimately, I'm just trying to get you to understand how this decision undermines the presumed goal of trying to convince the anti-AI crowd that they're wrong. It's simply not fair to expect humans to engage with the article in good faith when the article itself was not written by a human in good faith, regardless of its contents or the numbers it's based on. If you still disagree, so be it, I have nothing else to argue.

And for the record, I didn't engage with the methodology itself or its merits because I don't believe this question can be answered via an automated statistical approach, or really any sort of objective approach. The only way to truly evaluate the quality of AI generated code is for a skilled developer who is at least moderately familiar with the codebase to carefully analyze each commit, understanding what it does and looking for dumb mistakes that a human likely wouldn't have made in the same situation. But it's very unlikely that anyone will waste their time on that, and the conclusion would still be subjective anyway.

Re: Did Claude increase bugs in rsync?

#344
post #264
post #256

I've been coding for over 2 decades. I love it, I've always loved it and I likely always will. I was an AI skeptic some months ago but truly Claude and Codex have changed my development style and velocity in a way I never imagined would ever be possible. With that, yes, I produce more code and am finding more bugs. So looking over at comments in HN articles the amount of polarising hate to anything produced with AI i…

I've always noticed, within any subject involving tools, there are people who like the tools, and some people who like to use the tools to do something else. With programming, I've always been in the later: it's a tool that allows me to do what I actually love, which is problem solving, system level thinking , and providing some nice solution to that problem, that happens to be through software. So, I have an absolut…

I'm not anti-AI but something I've been thinking about is the discipline it requires. As you said, it's a tool that allows you to rename a variable name on one end and do complete vibe coding on the other end. Developers may say that we should stay somewhere left on that spectrum, because that's where human's are more involved.

But developers also say good practices should be followed when talking to each other, and while some may do, reality is often very different.

It requires discipline, which varies a lot between developers, between projects, current mood, and so on.

In the beginning you might be careful doing small changes, but after a while you might get more tempted to accept the output for what it is, because ultimately that's much easier.

So the way I see it; the left side is harder work and potentially bigger but delayed dopamine hits, the right side is quick dopamine hits. How do we (at least those who struggle with discipline) resist just slipping to the right?

I started out carefully myself and slipped more into vibe coding, but I don't feel particularly proud of it for some reason.

Re: Did Claude increase bugs in rsync?

#345
post #295

For those commenting, I suggest you read the post linked by the rsync author: https://medium.com/@tridge60/rsync-and-outrage-d9849599e5a0 (Disclosure: while I haven't talked with him in years, Tridge was my colleague and mentor for many years. I feel it is worth considering his view before joining a crusade)

> I thought it would be a good idea to do the core structure for the new test suite in public on master first though given all the rage that has generated maybe that was a bad idea. I don't entirely understand what this is saying. People wouldn't have been outraged if only the tests had been updated and/or he pushed solely on master - but he pushed breaking changes onto the release branch(es) too. Breaking workflows…

It seems that wasn't the Claude part, though I haven't seen a full analysis of exactly what broke. I also only saw one report: are there multiple, or do you just perceive that?

Rsync has many options: I can totally believe that fixing a bug in one place broke someone's usage, to be fair.

Re: Did Claude increase bugs in rsync?

#346
post #294

Earlier quoted context omitted.

It doesn’t. It’s just that dereferencing a zeroed pointer reliably crashes the program (unless you specifically do funky things with mmap) but dereferencing garbage memory as a pointer could do a lot more insidious damage.

My point is that the developer's comment doesn't make sense. Zeroing the allocated memory doesn't change anything about overrunning the buffer. edit: removed unnecessary examples

Haven't looked at the code, but the allocated memory could be larger than necessary to make "off-by-one" or "off-by-a-few" errors less deadly. Then zeroing it out makes it even less so. Defense in depth.

Or it's an allocation for an arena? The zeroing might help trigger 0 derefs earlier if the overrun happens for the object that are then allocated in the arena (and not by allocating more objects than the arena can provide)

Re: Did Claude increase bugs in rsync?

#347

Earlier quoted context omitted.

Also the amount of commits is suspicious. In the last two months, rsync had about as much commits as in the last two years before that. Most of them written with claude. And then stuff like this is in there. That's exactly what I'd expect when someone is excited about AI usage and becomes... well, sloppy.

Tridge already explains this: "Like many developers of open source packages I’ve been hit by a flood of security reports lately in my role as the rsync maintainer. Many of those reports are AI generated (not all though, there are some notable ones with very careful and high quality manual analysis). As this flood started to get more intense I realised I needed to raise the defences on rsync a lot — we needed much mor…

Is using calloc for everything fixing a security issue or hardening it?

Re: Did Claude increase bugs in rsync?

#349

Was just looking at commits and came across a commit and its revert original commit: https://github.com/RsyncProject/rsync/commit/d046525de39315d... ``` - if (!ptr) - ptr = malloc(num * size); - else if (ptr == do_calloc) + if (!ptr || ptr == do_calloc) ptr = calloc(num, size); ``` Written with claude. This is a good example of what slips through LLM attention. It forces all allocations to be calloc as if it is a str…

Also the amount of commits is suspicious. In the last two months, rsync had about as much commits as in the last two years before that. Most of them written with claude. And then stuff like this is in there. That's exactly what I'd expect when someone is excited about AI usage and becomes... well, sloppy.

I would expect a 10x change rate, even carried out by clones of the existing maintainers to result in more bugs.

Re: Did Claude increase bugs in rsync?

#350
post #219

It's always the most insufferable people that make the biggest hullabaloo about a project they have nothing to do with and have never contributed to. People with literally zero skin in the game using the AI boogeyman to push some agenda or some anti-agenda. OSS has become so incredibly toxic in the past decade, and consumers of OSS have become extremely entitled. I run a smallish project with ~1k stars and I've stopp…

haha, that analogy says more about whoever wrote it than it ever could to get the intended point across!
Post reply on HN