I have to deeply respect Tridge's godly patience in dealing with the people that want to strangle him for daring to use a tool he quite clearly knows how to use properly and (knows the limitations...
Exemplary
I have to deeply respect Tridge's godly patience in dealing with the people that want to strangle him for daring to use a tool he quite clearly knows how to use properly and (knows the limitations contained therein).
As for rsync itself, it's software. It'll have bugs. To me it doesn't matter if the bug was introduced by the maintainer by hand or by an AI tool. As much as the Mastodon puritans are foaming at the mouth about this, there's no rule that says that you have to be this bug-free to be load bearing software. If that was the case, the world wouldn't run on Excel and Acrobat.
At this point, it seems like the only real recommendation is to turn off LLMs co-authoring feature so that Claude and Codex don't sign the commits with their logo as well. This doesn't fix the underlying problem, if there is one, but would at least prevent further harassment from unkind people who just want to be angry at someone who develops a free utility for free, on their own time, on their own dime.
If this had happened to me I'd've burned rsync to the ground. Fuck these people. This is just as unreasonable as Lennart Poettering receiving death threats over systemd.
Verbal abuse, threats of violence, and unhinged hostility are why I stopped contributing to Open Source twenty years ago. I love playing with computers, but if there is a single community that...
Verbal abuse, threats of violence, and unhinged hostility are why I stopped contributing to Open Source twenty years ago. I love playing with computers, but if there is a single community that does a better job of rules-lawyering badgering smug misanthropy, I've yet to find it. Individually I know several other fellow techies who are delights to work with, but good god is the online world a toxic cesspool. And, like much of the world, it's gotten quite a bit angrier over the past few years. Glad to see Tridge isn't too put out, but what a pain.
It's not unique to tech/coding, but it is the kind of industry that attracts people who are somewhat clever but wash out of other industries because they can't be decent, as you can just hole up...
It's not unique to tech/coding, but it is the kind of industry that attracts people who are somewhat clever but wash out of other industries because they can't be decent, as you can just hole up in a room, be antisocial, and still give useful output.
With personalities like Jobs being worshiped ("Boy i sure wish i could get rich calling everyone else an idiot!") and communication done in a way that naturally avoids any real accountability, it is sadly a miserable and hostile breeding ground.
I and others have all commented that the best thing AI has done for linux is allowing you to get feedback without being outright attacked, and it's about as accurate as the hostile people anyways.
Here is a (for now) working libmedium link if you don't want to visit Medium directly: https://libmedium.ducks.party/@tridge60/rsync-and-outrage-d9849599e5a0 I also recommending reading this other...
Here is a (for now) working libmedium link if you don't want to visit Medium directly:
Have you gone over the code to verify thar this is the case? The article is pretty clear that most regression was due to CVE fixes. Someone also did put in some actual work and showed that there...
Have you gone over the code to verify thar this is the case? The article is pretty clear that most regression was due to CVE fixes. Someone also did put in some actual work and showed that there are not significantly more bugs in the last two releases compared to previous ones. In fact they found a previous release from before AI that had significant more regression.
This doesn't rule out that Claude did introduce bugs. But I am also not convinced the regression was introduced because of Claude or because tests didn't cover those areas. Basically, if they had written the code themselves would the bugs not have been there?
To be clear, I am also not comfortable with many projects starting to more heavily rely on claude code. Even more so because my own experimentation has shown you really need to be on top of things to work. At the same that same experimentation has shown me that someone with solid experience can achieve goos results if they are diligent, methodical and disciplined in how they use a harness like claude code.
Given this article and the other article I linked I strongly feel that has been the case here. I see no tangible evidence that rsync has gotten worse because the author used claude.
Which leaves only the fact that some people are against LLM usage out of principle. For that group I understand them being disappointed that yet another project involves LLM usage. But, that is also not what the outrage was claimed to be about.
Solid agree. When using a harness I absolutely watch and correct code and it streams through, change the architectural direction etc. Do I still ship bugs? Yes. Are there more bugs than there were...
Solid agree. When using a harness I absolutely watch and correct code and it streams through, change the architectural direction etc. Do I still ship bugs? Yes. Are there more bugs than there were previously? By all measures I have for myself: no (net new bug fixes that can be tracked to generated code). Are there more bugs tickets overall? Yes, but because I have more time to push harder on our codebase things that would have been ignored previously are being picked up. I don't love LLMs, I think we are absolutely taking an axe to the talent pipeline that I don't think we will ever recover from and at this point I only hope that tools become good enough to cover for the expertise that we are losing at an insane rate as people age out with no replacements of equal experience.
None of that means that Claude code caused an increase of bugs per loc in rsync.
Yes, this is also my concern as well. Professionally both through how I see juniors acting during onboarding and how my and other companies look at them. But in the OSS sense it is also why I am...
I don't love LLMs, I think we are absolutely taking an axe to the talent pipeline that I don't think we will ever recover from
Yes, this is also my concern as well. Professionally both through how I see juniors acting during onboarding and how my and other companies look at them. But in the OSS sense it is also why I am still weary when I see an AGENTS.md or CLAUDE.md file as I don't have a strong sense what the repos owner baseline is in knowledge, experience and overall critical thinking. Sometimes you can get somewhat of an impression by the contents of these files but overall I very much do understand why people rather not have LLMs involved with software they rely on.
At the same time I am absolutely not on board with calling anything LLM related slop and lashing out to individual developers who end using it, certainly not when they do try to do so responsibly.
I know that people are against LLMs in principle and I think that is valid for all sorts of reasons. At the same time, and people might disagree here, I firmly believe that if everyone was always 100% true to their principles we would be living in an even more polarized world than we already are. In fact, I think it is impossible to do so.
That's not to say that I think people should throw away their principles or even meet others in "the middle" because that is also problematic for a whole host of reasons. What I do mean is that people should try and be aware of the practical limitations on some of their principles.
For example in this case. If you have a OSS project, you will be faced with a massive increase of CVE reports that originate from the use of LLMs. By all accounts these reports over the past half year have increasingly become reliable exposing actual exploitable CVEs. If we take a 100% purist route of not wanting any LLM involvement at all, should OSS maintainers just ignore those reports? Hope that a human finds the same vulnerabilities manually? We know that the latter isn't happening, so even if someone wants to avoid LLM involvement if they care about security they are already forced to accept some.
Which brings me to my next point and where it comes back to rsync. How then are OSS maintainers expected to magically find more time to actually fix these CVEs? Many OSS projects have been chronically understaffed and have been for quite some while. This xkcd meme isn't actually a meme and true for a worryingly large amount of projects. Speaking from some experience (though not nearly on this scale) finding people to actually stick around and do more than incidental contributions can be next to impossible.
In summary, I don't think it is practically next to impossible to demand no LLM involvement at all in software development. Certainly not when we are dealing with software like rsync, curl, etc where security is essential. I am not advocating that people who demand this tack up the slack and start contributing their time or anything. But I do think they should stop and consider who they are actually directing their anger against.
My kid loves coding. I'm trying to introduce happy mediums, explaining how you need to understand before using to generate. AI tooling works best for a junior as a teacher checking a math test....
My kid loves coding. I'm trying to introduce happy mediums, explaining how you need to understand before using to generate.
AI tooling works best for a junior as a teacher checking a math test.
And for a senior dev, they're checking the AI's math test.
Problem is you can't let the 2nd grader check their own test.
I have to deeply respect Tridge's godly patience in dealing with the people that want to strangle him for daring to use a tool he quite clearly knows how to use properly and (knows the limitations contained therein).
As for
rsyncitself, it's software. It'll have bugs. To me it doesn't matter if the bug was introduced by the maintainer by hand or by an AI tool. As much as the Mastodon puritans are foaming at the mouth about this, there's no rule that says that you have to be this bug-free to be load bearing software. If that was the case, the world wouldn't run on Excel and Acrobat.At this point, it seems like the only real recommendation is to turn off LLMs co-authoring feature so that Claude and Codex don't sign the commits with their logo as well. This doesn't fix the underlying problem, if there is one, but would at least prevent further harassment from unkind people who just want to be angry at someone who develops a free utility for free, on their own time, on their own dime.
If this had happened to me I'd've burned
rsyncto the ground. Fuck these people. This is just as unreasonable as Lennart Poettering receiving death threats oversystemd.Verbal abuse, threats of violence, and unhinged hostility are why I stopped contributing to Open Source twenty years ago. I love playing with computers, but if there is a single community that does a better job of rules-lawyering badgering smug misanthropy, I've yet to find it. Individually I know several other fellow techies who are delights to work with, but good god is the online world a toxic cesspool. And, like much of the world, it's gotten quite a bit angrier over the past few years. Glad to see Tridge isn't too put out, but what a pain.
It's not unique to tech/coding, but it is the kind of industry that attracts people who are somewhat clever but wash out of other industries because they can't be decent, as you can just hole up in a room, be antisocial, and still give useful output.
With personalities like Jobs being worshiped ("Boy i sure wish i could get rich calling everyone else an idiot!") and communication done in a way that naturally avoids any real accountability, it is sadly a miserable and hostile breeding ground.
I and others have all commented that the best thing AI has done for linux is allowing you to get feedback without being outright attacked, and it's about as accurate as the hostile people anyways.
Here is a (for now) working libmedium link if you don't want to visit Medium directly:
https://libmedium.ducks.party/@tridge60/rsync-and-outrage-d9849599e5a0
I also recommending reading this other topic as a sort of followup:
Did Claude increase bugs in rsync?
https://lobste.rs/s/k1b0za/rsync_outrage
If I understand this correctly, the claude contributions were limited to rewriting the test suite, and did not actually introduce bugs in the system?
No, they were primarily adding to the test suite, but Claude did edit the actual program code as well, including introducing bugs.
Have you gone over the code to verify thar this is the case? The article is pretty clear that most regression was due to CVE fixes. Someone also did put in some actual work and showed that there are not significantly more bugs in the last two releases compared to previous ones. In fact they found a previous release from before AI that had significant more regression.
https://tildes.net/~comp/1ujj/did_claude_increase_bugs_in_rsync
This doesn't rule out that Claude did introduce bugs. But I am also not convinced the regression was introduced because of Claude or because tests didn't cover those areas. Basically, if they had written the code themselves would the bugs not have been there?
To be clear, I am also not comfortable with many projects starting to more heavily rely on claude code. Even more so because my own experimentation has shown you really need to be on top of things to work. At the same that same experimentation has shown me that someone with solid experience can achieve goos results if they are diligent, methodical and disciplined in how they use a harness like claude code.
Given this article and the other article I linked I strongly feel that has been the case here. I see no tangible evidence that rsync has gotten worse because the author used claude.
Which leaves only the fact that some people are against LLM usage out of principle. For that group I understand them being disappointed that yet another project involves LLM usage. But, that is also not what the outrage was claimed to be about.
Solid agree. When using a harness I absolutely watch and correct code and it streams through, change the architectural direction etc. Do I still ship bugs? Yes. Are there more bugs than there were previously? By all measures I have for myself: no (net new bug fixes that can be tracked to generated code). Are there more bugs tickets overall? Yes, but because I have more time to push harder on our codebase things that would have been ignored previously are being picked up. I don't love LLMs, I think we are absolutely taking an axe to the talent pipeline that I don't think we will ever recover from and at this point I only hope that tools become good enough to cover for the expertise that we are losing at an insane rate as people age out with no replacements of equal experience.
None of that means that Claude code caused an increase of bugs per loc in rsync.
Yes, this is also my concern as well. Professionally both through how I see juniors acting during onboarding and how my and other companies look at them. But in the OSS sense it is also why I am still weary when I see an
AGENTS.mdorCLAUDE.mdfile as I don't have a strong sense what the repos owner baseline is in knowledge, experience and overall critical thinking. Sometimes you can get somewhat of an impression by the contents of these files but overall I very much do understand why people rather not have LLMs involved with software they rely on.At the same time I am absolutely not on board with calling anything LLM related slop and lashing out to individual developers who end using it, certainly not when they do try to do so responsibly.
I know that people are against LLMs in principle and I think that is valid for all sorts of reasons. At the same time, and people might disagree here, I firmly believe that if everyone was always 100% true to their principles we would be living in an even more polarized world than we already are. In fact, I think it is impossible to do so.
That's not to say that I think people should throw away their principles or even meet others in "the middle" because that is also problematic for a whole host of reasons. What I do mean is that people should try and be aware of the practical limitations on some of their principles.
For example in this case. If you have a OSS project, you will be faced with a massive increase of CVE reports that originate from the use of LLMs. By all accounts these reports over the past half year have increasingly become reliable exposing actual exploitable CVEs. If we take a 100% purist route of not wanting any LLM involvement at all, should OSS maintainers just ignore those reports? Hope that a human finds the same vulnerabilities manually? We know that the latter isn't happening, so even if someone wants to avoid LLM involvement if they care about security they are already forced to accept some.
Which brings me to my next point and where it comes back to rsync. How then are OSS maintainers expected to magically find more time to actually fix these CVEs? Many OSS projects have been chronically understaffed and have been for quite some while. This xkcd meme isn't actually a meme and true for a worryingly large amount of projects. Speaking from some experience (though not nearly on this scale) finding people to actually stick around and do more than incidental contributions can be next to impossible.
In summary, I don't think it is practically next to impossible to demand no LLM involvement at all in software development. Certainly not when we are dealing with software like rsync, curl, etc where security is essential. I am not advocating that people who demand this tack up the slack and start contributing their time or anything. But I do think they should stop and consider who they are actually directing their anger against.
My kid loves coding. I'm trying to introduce happy mediums, explaining how you need to understand before using to generate.
AI tooling works best for a junior as a teacher checking a math test.
And for a senior dev, they're checking the AI's math test.
Problem is you can't let the 2nd grader check their own test.