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.
Did Claude increase bugs in rsync?
341–350 of 611 posts
Re: Did Claude increase bugs in rsync?
#342I 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
Re: Did Claude increase bugs in rsync?
#343Earlier 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…
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?
#344I'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…
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?
#345For 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…
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?
#346Earlier 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
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?
#347Earlier 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…
Re: Did Claude increase bugs in rsync?
#348Re: Did Claude increase bugs in rsync?
#349Was 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.
Re: Did Claude increase bugs in rsync?
#350It'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…