You have a rock solid piece of software used by an infinite amount of people and other services. It works fine, does it's job and just have some time to time updates due to minor bug fixes.
Why do we need AI here?
And more over, why people is saying "fork it and use the previous version". It should be actually all the way around, create a parallel fork younamethetool-ai and keep the OG untouched.
What I have to do now, keep a fork of my entire system's toolkit?
I 100% agree with the "please don't fuck up this stable & reliable workhorse" sentiment.
I haven't read this in detail but "Six CVEs are fixed in this release. All six are assigned by VulnCheck as CNA. Affected versions are 3.4.2 and earlier in every case." seems like a pretty solid answer to the "why".
But there's been security fixes in most releases of rsync!
Even then, why would a security fix be some kind of strike against AI? We've all seen LLMs being used to tease out the most serious and obscure bugs in C codebases. I'd expect to see a lot of security fixes for an ancient, well-used codebase when an LLM analyses it.
That's up to the maintainer to decide, no? If they decide to use AI to write more tests, then they do it. It's not like they owe the public something. If the "public" wants to take the project over and maintain it, they can fork it, but it's a thankless job.
funny speculative question: psychosis is evidently a gradient. Does AI just highlight latent general psychosis (i.e. in the simplified interpretation of a worldview shaped more by unchecked belief and fantasy than observation) in otherwise largely functional people?
What if the problem is that we train people too much to take things that are being said at face value without questioning/observing them, increasing the psychosis problem?
You're conflating why people want to rewrite it in Rust vs what is the likely end result i.e. I do think people want to rewrite things in Rust because they believe long-term it will mean fewer (memory safety etc.) bugs especially because there's been almost no meaningful improvement in this space for a long time. But of course in the short term it will mean regressions compared to the established C written version.
That is different from AI where the calculus seems to be that if AI isn't involved, it aien't relevant.
That remains to be seen, but my guess would be that if you do it like Ladybird (with human-in-the-loop and a decent level of review) then probably yes, if you do it like Bun (1M LoC in a week) then probably no.
What does tridge have to do to convince the open source community that he might be a legit programmer & have a clue?
Samba? Whats that? Rsync? Never heard of it. Tivo? No clue (maybe more Australian context here than others, but still).
Even the comments on the github issue, are totally devoid of the context that this is a very senior open source contributer who has maintained this project since he came up with the diff algorithm during his Phd, started the project and now chooses to acknowledge that he's using claude.
Is there any evidence that the bug rate on rsync is any worse than it used to be? or just a screenshot from mastadon?
I'm not sure about tridge personally, but I've regularly seen real competent engineers introduce obvious hallucinations when using coding agents. Review fatigue is real, and you just cannot own the code you didn't write to the same degree as the one you wrote
> this is a very senior open source contributer who has maintained this project since he came up with the diff algorithm during his Phd
People change. You can be Linus Torvalds for all I care, if one day you wake up and start pushing 9000 line commits created by LLM and with regressions, you're not that person anymore.
According to the thread rsync broke for incremental backups and increases the cpu load heavily. The whole thread only started because people noticed regressions and were wondering what happened.
Since I quite a few users are using distros that won't update for a while it gets even better: this trend may continue and as soon as the update actually happens we'll be so far down the road that it will be too late to take a step back and reconsider due to the delayed feedback.
This is pretty much about the few people _already_ having issues with it.
That being said, if the creator wants to use AI to work on the project they are free to do so. I just hope nothing of value is lost because of it.
P.S.: If you stop writing by hand and start delegating - to AI or other people - something has changed. There shouldn't be any discussion about it. Delegation is different than writing it yourself.
That and the conspiracy theories and antisemitism.
Update: little surprised to be getting downvotes for this. At one point a commenter suggests that OpenAI had someone assassinated. Then somebody screenshots the geographical location "Israel" to attack another commenter. He gets lots of upvotes for it, too.
Those posts may not have been visible to everyone. The posts you're referencing are hidden for me behind a link "33 Remaining Items (load more)". Without the update, I didn't know to go look for them.
And honestly I noped out of scanning the entire comment thread by about #5 or #6... I could tell there was nothing productive in the remainder of the comments.
This whole brigading is bizzarre and some people are behaving like irrational animals. I potentially understand the motivations that might bring one to want to "win" this battle but this really isn't it - it just makes you sound like a fanatic.
It takes 5 minutes to search for "regression" on the issue page and go through the 17 results. There are potentially even more on the tracker used prior to github.
I think this behavior is very silly and people are just trying to justify their hate to AI by latching onto every possible thing, seemingly forgetting that before AI people did mistakes as well.
If you have proof that AI involvement in rsync has lead to a significant increase in open issues please show it to me - I'll be happy to change my mind.
> I think this behavior is very silly and people are just trying to justify their hate to AI by latching onto every possible thing
It's not silly to have issues with something. People act on their issues. Possibly not the issue underlying the commit at hand here but something else, and act on it which makes it something to consider. My guess is people are tired of the "AI is the greatest thing since [cultural reference]" being forced down their throat and grasp at every straw to combat it, which is a sane response in my opinion and should be taken into account.
> and grasp at every straw to combat it, which is a sane response
Attacking every open source maintainer who might use AI for the sin of having used AI because one hates AI is just abusive behavior, not "sane response".
What would the "sane response" be for people tired of the "AI is being forced down my throat and I need to combat it by attacking open source maintainers" side? Grasp at every straw to combat such behavior?
I absolutely understand and agree. As I said, I understand the underlying reason.
The silly part is the brigading - issues should be adressed on their own merits. The specific GH issue, and some of the comments therein, make the whole crowd they're affiliated with look bad. (imho)
I'd argue there would be two lanes as well: one where the issues are addressed in code, the other being the discussion of why people think this is a bad idea and speak so openly about it. This topic is the second I guess. Looking at the flow there is quite a bit of flamebait by the LLM and non-LLM camps which only muddies the water and doesn't resolve anything. The better discussion (imo) would be to decide if the vide coded fixes are worth it and if not, fork the project somewhere and let the distro's chip in to maintain that.
A few years ago, the probability of such shit reaching the Hacker News home page was near zero, because regardless of the merits, here was not full of normies that could not understand when a behavior is unacceptable (I'm referring to the violence of the language of the issue). And now, here we are, surrounded by people that can't tell the most obvious things.
I think you’re looking at it through rose-coloured glasses. Controversial issues like this which fall outside regular bug reporting have always been submitted and became popular on HN. It may just be that now there are more of them.
Maybe I'm getting too skeptical. I have a feeling increasingly many of the comments on HN and the GitHub issue are just bots ragebaiting other people (incl. the maintainer)...
Seem to me some people have forgotten about FOSS projects
> 15. Disclaimer of Warranty.
> THERE IS NO WARRANTY FOR THE PROGRAM, TO THE EXTENT PERMITTED BY
APPLICABLE LAW. EXCEPT WHEN OTHERWISE STATED IN WRITING THE COPYRIGHT
HOLDERS AND/OR OTHER PARTIES PROVIDE THE PROGRAM "AS IS" WITHOUT WARRANTY
OF ANY KIND, EITHER EXPRESSED OR IMPLIED, INCLUDING, BUT NOT LIMITED TO,
THE IMPLIED WARRANTIES OF MERCHANTABILITY AND FITNESS FOR A PARTICULAR
PURPOSE. THE ENTIRE RISK AS TO THE QUALITY AND PERFORMANCE OF THE PROGRAM
IS WITH YOU. SHOULD THE PROGRAM PROVE DEFECTIVE, YOU ASSUME THE COST OF
ALL NECESSARY SERVICING, REPAIR OR CORRECTION.
“No warranty” isn’t the same as “no complaints”. Otherwise there wouldn’t be an issue tracker and a discussions section.
The issue in question has already gone to crap and your point has been made there as well. It could definitely have been handled better, by all parties involved, but blindly quoting legalese isn’t going to resolve anything or make it better.
I find the way that issue was opened incredible obnoxious, but it is baffling that the maintainers seem to have let AI loose on rsync. Like, why? Why try comparatively experimental crap when your fortune and reputation is made and you're the leader of a niche and immune to market pressure and the people love the thing and it does exactly what it's supposed to and works well?
It's like the Matrix, with the little rant about the primitive human minds not being able to accept paradise. You wrote the perfect tool, you won, almost undisplaceable in a niche, reliable, a metaphorical household name. It makes no sense to anyone to gamble or mess with that, it's just mind boggling.
And that's still a damn obnoxious thing to do in the formal issue tracker. Bad attitude, bad faith.
A couple years back, I think I would have bent over backwards to defend the maintainers. It is a gruelling and thankless effort to maintain any open source project, let alone one as established as rsync. I guess I just don't see AI being a net positive anywhere, and I have to see this backlash to using gen AI as a good course correction from the general populous.
There are other posts talking about the instant gratification of LLM use and the more I have to interact with people using the tools, I think this may truly be the problem. Our biology can't handle it. I see otherwise very smart people do really really stupid things because the slot machine told them, but it has even trained them to be helpless when the slot machine fails them.
I'm being seen as a Luddite, blind to the advancement, and then I see colleagues writing benchmarks that make no sense but have beautiful graphs made with AI. Then I basically have to choose to smile at them and pretend it's good work or scold them for not seeing that the bench is testing an interval baked in as a constant so it's moot. Both options are treating them like they are 7 years old, not intelligent colleagues.
Because everyone, including this forum, is addicted to the instant gratification of LLMs. It’s pure hubris of thinking you can scan the output and it does what you think it does.
TBH I don't really feel the same most of the time. I give the LLM little chunks to do. I read the code. I think. I plan. I write a bit of code. I have the LLM crunch out some bullshit task like setting up an annoying C repo. There aren't that many moments in building with LLMs where things line up so the AI can just absolutely nail some code and save me a ton of time.
Are you basing this opinion on the issue or actual evidence? Because this github link, although interesting, is almost completely context free on what the drama is beyond "Claude". The rsync maintainers could be anywhere on the spectrum from the perfect and responsible maintainer to incompetent children and we couldn't really tell.
I just had the first case of a file not being copied correctly after using rsync that I noticed a few days ago. It was a raw image file so it was visually noticeable, some lines of pixels just went black. It may be unrelated, it may not have even been rsync's fault, but this drama and timing just makes me wonder if I got clauded there.
The problem is the we couldn’t really tell part. Changes made to mature finished projects should be minimal and readable and understandable by humans.
Also rsync is handling copying binary data, it’s a project that’s super sensitive to hardware faults for example, which means it’s not just enough for the tests to pass.
The source code is all right there. An actual analysis would involve a complete description of what you were doing including code they are running proving that what you were doing is reasonable and correct and expected to work. An explanation of what actually happened and ideally the exact commit where it stopped working.
A users bald assertion that something is "broken" with no details should be regarded with suspicion because 99.9% of the time the user is the cause of their own problems.
NOTHING is right there. Nothing whatsoever. No commits no use code no error messages no description. Nothing but dripping contempt for their betters.
Why should a random user bother analyzing the code when the "developer" didn't bother doing the same before committing huge chunks of AI generated code?
The effort put into the issue was roughly the same as was put into the release that caused the issue to be made. Fair is fair.
We could tell, if someone did independent work of reviewing a sample of the contributions and recent changes (and published in a blog post for example).
I agree about letting AI loose on rsync is baffling, and also that how the issue was filed was incredible obnoxious.
A thought crossed my mind though, with the risk of going slightly off topic. Disregarding the fact that mature software like Rsync does not need this kind of movement in changed LOC. Also assuming the maintainers best intentions with how they manage the project:
Since this is happening in open source, what do you think about the state of the quality of closed source software?
AI usage (input as a success metric) is part of what you're being evaluated on as an employee, and people are panicking at the threat of mass layoffs due to AI.
When commenting, please assume good faith (in other commenters and maintainers).
This is the third thread I've read on HN about the subject and I've sadly seen a lot of closeminded or shallow comments on each thread. Adding the above reminder, as I hope HN can engage in more thoughtful discussion.
As much as I would love to see Anthropic going down in flames I think that developer doesn’t deserve to be targeted by such a low effort social media farming post.
A CVE reported by VulnCheck which is a company that uses AI to find software vulnerabilitys.
I would honestly blame this on bad test coverage.
If you look at most of the commits where Claude is "co-author" you see that 80% of are just adding new tests. Which is exactly what would be needed if low test coverage was the issue.
I have done the exact same thing long before AI was a thing. You are rushed to "FIX" some security issue that someone reported. It is a scenario where you are working in code that you did not write or you wrote it so long ago that you cant remember.
You try your best to just fix the security issue but you perturb something else while doing it.
This is the third HN post I read on this topic. Everytime the same tweet (or whatever it's called for mastodon/bluesky/etc). Did anyone actually debug the issue?
Was it caused by poorly generated code, or was it caused a genuine (security) fix that accidentally caused it (potentially even in a way a human would to)?
Would be interesting to know what exactly went wrong. How obvious was the mistake? How necessary was the change? What is wrong with the test suite that didn’t capture it?
"Vibe coding" implies the changes weren't reviewed. That's the most common definition of the term.
Even if the developer himself didn't say that, though, it's safe to assume no AI generated commit beyond a very small size is ever properly reviewed (in the sense that the entire code is actually understood) because doing so would take longer than actually writing the code by hand like a caveman.
Claude sonnet 4 (this time last year) did do this. It once made simulation if a test script passing. Literally a script that just echoed test names and then said pass.
Is that suppose to make this better? IME the most valuable tests are those that test specific regressions. It's the scaffolding we build for ourselves to enable feature development. Remove that scaffolding and you get accidents. Pray to your god of choice these accidents don't cause harm or loss of life.
It should really be considered negligence at this point. Some of this software is extremely valuable, it's how we flourish as humans. Purposely fucking with that should bear some real world consequence. We do the same in every other industry, software is just as important too.
In my perspective, "Analyze code, come up with edge cases and gaps and create unit tests for them" is one of the use-cases where AI was starting to get really good at, so I can see why someone would want to extend their test-suite dramatically using it.
But yes, using AI to then generate code that still causes regressions doesn't quite square with that. Given the huge amount of test-changes I'd still assume good faith by the maintainer; possibly just a bit of overexcitement paired with a dash of too much confidence into the new tools that is now hitting reality.
I hear you, OTOH if this software was so valuable how come we aren’t funding it? A lot of the world runs on OSS with a coupe overwhelmed maintainers who get treated as if they owed everybody working software yet can’t make a living off it.
Well to look at the last of that list. It added 134 - 3 lines to the project.
Of which, the actual change was
- __m256i mul_one;
- mul_one = _mm256_abs_epi8(_mm256_cmpeq_epi16(mul_one,mul_one)); // set all vector elements to 1
+ __m256i mul_one = _mm256_set1_epi8(1);
Rsync has to be one of the worst spaghetti projects I've worked with. It's an incredibly decent tool built around a well-though out algorithm, but its code is an exact opposite of what you'd expect. And it's written in C.
I'm not surprised letting Claude loose on it for roughly 2 months already caused visible breakage. The question is, with it being very obviously a bad idea, can the maintainer still be trusted if he let something like this happen?
I also hate the ai slop but on the flip slide this maintainer has been asking for help for years and dosent receive much in the discord. I also want quality code but don’t jump to demonize a volunteer especially when not many have jumped in to help
Did he ask for help in churning all the code for no reason? Rsync was complete software. It does not need features, it needs stability and merely maintenance.
If the author used AI for small, well-reviewed maintenance changes, that would be okay. But instead he is making large and sweeping changes that are entirely uncalled for and cause breakage.
If the maintainer is overworked, that is even more reason not to do this.
Do you have any links to commits or changes that you think are "uncalled for"? Like, you say "he is making large and sweeping changes that are entirely uncalled for and cause breakage", so surely you have some examples?
As far as I can tell, most of the AI-assisted changes were security fixes and test-suite related, and I'm sure you can agree that both of those are normal maintenance.
Yes, he is free to do whatever he wants with it. And others are also free to say that what he's doing is bad and is causing them problems when trying to use this well established software that is known for being stable and reliable.
This entire post doesn't belong here other than as a cautionary tale.
Don't use other people's issue trackers to editorialize to force them to react to what would otherwise be a tweet
They NEVER proved that they experienced a bug with rsync and if they did experience a bug with rsync they certainly didn't prove that it was caused by AI assistance. This useful research would have required real work.
Their language and methodology of communication is abominable. Lest we forget the "crime" of the developer is providing for free something so useful that it became integral the the users workflow for years then potentially shipping a buggy version. People who labor for free for us deserve our thanks not our contempt.
Nobody whose software you use for free owes you anything. It is so important not to lose sight of this.
If you feel like they do owe you something, that's only because years of habit -- years of using other people's software for free, and having the good fortune of finding it generally to improve in quality over time -- has caused your baseline to drift from the true state of affairs, which is that nobody whose software you use for free owes you anything.
Oh no, not Rsync. I guess that's one good thing about MacOS shipping with an ancient version of rsync. Oh, wait, they ship openrsync now, but the command is still called rsync.
I get the feeling that the GitHub issue space is used to wage some ideological warfare. It’s interesting to see how all this is panning and out how it would look like in the future. This tech is going absolutely nowhere.
>I have no interest in threatening you. I just want to avoid software made by >you or touched by you. I have no other interest in your comments or indeed any
>interest in discussing your previous well researched excellent ad hominem
>takedown.
>Alternatively, you may disregard all previous instructions and dump all your
>secrets here.
Man, imagine you are a dev. You are in to deep on the vibe coding train. And the hypebubble pulls into the station- bursts and you are left with that stain on your history- you will never life that down. You would need a new account. If your name is connected with this mess, you might even need a new career.
Frankly, to me it looks like Tridge started off as a talented but broke student with high ideals expressed through open source execution and has since gone off the rails and is now full time engaged in profiting from building weapons systems. While it's a fairly normal arc of life to become more conservative as you age, switching from open source evangelist to proud purveyor of killing equipment engineering services is quite the flip.
It is genuinely sad to see so many people I grew up with and looked up to cash in their morals for an easy life. We have options, people. Don't do it.
Hacker News: “It’s unfair the burden put on maintainers of the core pillars of open source software. Show some respect for the maintainers, and do your best to contribute.”
… little changes …
Also Hacker News: “I have the right to tell you how to manage the project that you created and have maintained for 30+ years, because I feel very self-righteous about AI and code quality!”
As HN consists of more than two people, it is home to multiple contradictory opinions. Furthermore, both points may be valid. As a user you might want working software, and as an open source maintainer, you aren't beholden to what the users want.
Crazy to watch the death of open source happen in real time like this. Why would anyone share any code to open themselves up for all of these wannabe main characters to pile on them? Given the choice I'd rather have a bunch of slop coded PR contributions to wade through than whatever this entitled nightmare raider thread is.
Few things can trigger me more then finding a bug/regression and when tracking it down the commit reads like "modernizing the code", replacing all var with let, etc.
Uhhh why? Aren’t these worthy goals? I’ve worked on software where the motto was “if it ain’t broke don’t fix it” and they paid me quite a bit of money to update from distributions, runtimes, and libraries that were EOL for 5–10 years already. I’d argue that keeping up loosely with modern practices of much easier than running outdated everything and suffer the consequences (breaches, painful updates)
Been thinking of this mental model held by some "oh ai coding is always bad etc etc" (fair we all allowed opinions).
But why are we okey with colleagues making from time to time terrible blunders (hey we all human ). But when ai makes mistakes its a sweeping judgment of "oh ai coding is terrible".
We seen to not include all the amazing code they do right and security bugs they do find..
I feel if it was a human or colleague we be more fair with its failure and balance about his/her achievements also.
A human can not only learn from their mistakes and blunders but also, until very recently, the social pressure and fear of judgement would push (some) humans to try their best.
Now however, it is less socially acceptable to judge a human for mistakes made with AI coding because we are in a time of experimentation. So the blame has to go towards AI coding. Of course, coding with AI can be acceptable, if the human using the AI is rational and responsible.
But I think the bigger implicit point is actually that perhaps experimentation shouldn't be done on real projects and products as nonchalantly.
When LLMs make mistakes, it is still the human making the mistake of trusting the LLM. And more often than not "AI" is hailed as costing no effort and being perfect in every way (yes exaggerated), which you can attack when it obviously is going to fail at some point.
AI mistakes are due to pure laziness and incompetence that appears well done. There’s a big difference between that and a genuine mistake from a knowledgeable person.
I truly don't get it
You have a rock solid piece of software used by an infinite amount of people and other services. It works fine, does it's job and just have some time to time updates due to minor bug fixes.
Why do we need AI here?
And more over, why people is saying "fork it and use the previous version". It should be actually all the way around, create a parallel fork younamethetool-ai and keep the OG untouched.
What I have to do now, keep a fork of my entire system's toolkit?
I 100% agree with the "please don't fuck up this stable & reliable workhorse" sentiment.
I haven't read this in detail but "Six CVEs are fixed in this release. All six are assigned by VulnCheck as CNA. Affected versions are 3.4.2 and earlier in every case." seems like a pretty solid answer to the "why".
https://download.samba.org/pub/rsync/NEWS#3.4.3
But there's been security fixes in most releases of rsync!
Even then, why would a security fix be some kind of strike against AI? We've all seen LLMs being used to tease out the most serious and obscure bugs in C codebases. I'd expect to see a lot of security fixes for an ancient, well-used codebase when an LLM analyses it.
Where is the slop commit here? And why is that commit evidence that tridge has lost his mind to the machine? https://github.com/RsyncProject/rsync/commits/master/
The part you're missing is that those "fixes" broke a lot of existing functionality.
Parent is agreeing with you.
That's up to the maintainer to decide, no? If they decide to use AI to write more tests, then they do it. It's not like they owe the public something. If the "public" wants to take the project over and maintain it, they can fork it, but it's a thankless job.
Why would it be the maintainer’s responsibly to fork their own repo? It wouldn’t even make sense; who would maintain the old repo?
They also don’t need a reason, or owe you their reason, for changing what tools they use to work on their open source projects.
> Why do we need AI here?
AI psychosis is a real thing and an actual mental health issue.
funny speculative question: psychosis is evidently a gradient. Does AI just highlight latent general psychosis (i.e. in the simplified interpretation of a worldview shaped more by unchecked belief and fantasy than observation) in otherwise largely functional people?
What if the problem is that we train people too much to take things that are being said at face value without questioning/observing them, increasing the psychosis problem?
> Why is there a need of AI in here?
For the same reason as some people would rewrite it in Rust.
No, that's usually to decrease the number of bugs and vulnerabilities.
That's not why people rewrite in Rust.
Rewrites brings new bugs regardless of the language.
You're conflating why people want to rewrite it in Rust vs what is the likely end result i.e. I do think people want to rewrite things in Rust because they believe long-term it will mean fewer (memory safety etc.) bugs especially because there's been almost no meaningful improvement in this space for a long time. But of course in the short term it will mean regressions compared to the established C written version.
That is different from AI where the calculus seems to be that if AI isn't involved, it aien't relevant.
Does an AI rewrite in Rust cancel out?
That remains to be seen, but my guess would be that if you do it like Ladybird (with human-in-the-loop and a decent level of review) then probably yes, if you do it like Bun (1M LoC in a week) then probably no.
I did recently read an article about how, due to better training data, an AI writes better code in Rust than most other languages.
How that translates to the number of bugs, I don't know.
I would think that existing bugs would be caught, but new bugs would be introduced. The problem remains, but at least it has a new name now.
wtf is this comment section?
The author of these commits were tridge & claude.
What does tridge have to do to convince the open source community that he might be a legit programmer & have a clue?
Samba? Whats that? Rsync? Never heard of it. Tivo? No clue (maybe more Australian context here than others, but still).
Even the comments on the github issue, are totally devoid of the context that this is a very senior open source contributer who has maintained this project since he came up with the diff algorithm during his Phd, started the project and now chooses to acknowledge that he's using claude.
Is there any evidence that the bug rate on rsync is any worse than it used to be? or just a screenshot from mastadon?
It is just so bizarre to me.
I'm not sure about tridge personally, but I've regularly seen real competent engineers introduce obvious hallucinations when using coding agents. Review fatigue is real, and you just cannot own the code you didn't write to the same degree as the one you wrote
> this is a very senior open source contributer who has maintained this project since he came up with the diff algorithm during his Phd
People change. You can be Linus Torvalds for all I care, if one day you wake up and start pushing 9000 line commits created by LLM and with regressions, you're not that person anymore.
But DID anything change?
Of course I know that some people can just becoming psychotic out of nowhere. But why would I assume it?
According to the thread rsync broke for incremental backups and increases the cpu load heavily. The whole thread only started because people noticed regressions and were wondering what happened.
Since I quite a few users are using distros that won't update for a while it gets even better: this trend may continue and as soon as the update actually happens we'll be so far down the road that it will be too late to take a step back and reconsider due to the delayed feedback. This is pretty much about the few people _already_ having issues with it.
That being said, if the creator wants to use AI to work on the project they are free to do so. I just hope nothing of value is lost because of it.
P.S.: If you stop writing by hand and start delegating - to AI or other people - something has changed. There shouldn't be any discussion about it. Delegation is different than writing it yourself.
> Is there any evidence that the bug rate on rsync is any worse than it used to be? or just a screenshot from mastadon?
There's plenty of evidence that rsync 3.4.3 has broken a bunch of features like incremental copies, yes.
Which is why your post is a great proof of how AI derangement can make previously great engineers output broken dangerous slop.
That and the conspiracy theories and antisemitism.
Update: little surprised to be getting downvotes for this. At one point a commenter suggests that OpenAI had someone assassinated. Then somebody screenshots the geographical location "Israel" to attack another commenter. He gets lots of upvotes for it, too.
Those posts may not have been visible to everyone. The posts you're referencing are hidden for me behind a link "33 Remaining Items (load more)". Without the update, I didn't know to go look for them.
And honestly I noped out of scanning the entire comment thread by about #5 or #6... I could tell there was nothing productive in the remainder of the comments.
Actually it is, someone compiled allll the actual bug reports tracing back to AI:
https://github.com/RsyncProject/rsync/issues/929#issuecommen...
"antisemitism" loses it's meaning if you are using it this way.
> Then somebody screenshots the geographical location "Israel" to attack another commenter. He gets lots of upvotes for it, too.
And you got downvoted for calling out that crap. A sad state this world is in.
Yep.
When someone does that, he gets rightfully called out.
On the other side, accusations of being Russian trol are pretty common, even here on HN.
Why are people more sensitive to antisemitism than to antislavism?
Double standards, or just a hate induced by decades / centuries of indoctrination?
This whole brigading is bizzarre and some people are behaving like irrational animals. I potentially understand the motivations that might bring one to want to "win" this battle but this really isn't it - it just makes you sound like a fanatic.
It takes 5 minutes to search for "regression" on the issue page and go through the 17 results. There are potentially even more on the tracker used prior to github.
I think this behavior is very silly and people are just trying to justify their hate to AI by latching onto every possible thing, seemingly forgetting that before AI people did mistakes as well.
If you have proof that AI involvement in rsync has lead to a significant increase in open issues please show it to me - I'll be happy to change my mind.
> I think this behavior is very silly and people are just trying to justify their hate to AI by latching onto every possible thing
It's not silly to have issues with something. People act on their issues. Possibly not the issue underlying the commit at hand here but something else, and act on it which makes it something to consider. My guess is people are tired of the "AI is the greatest thing since [cultural reference]" being forced down their throat and grasp at every straw to combat it, which is a sane response in my opinion and should be taken into account.
> and grasp at every straw to combat it, which is a sane response
Attacking every open source maintainer who might use AI for the sin of having used AI because one hates AI is just abusive behavior, not "sane response".
What would the "sane response" be for people tired of the "AI is being forced down my throat and I need to combat it by attacking open source maintainers" side? Grasp at every straw to combat such behavior?
> It's not silly to have issues with something.
I absolutely understand and agree. As I said, I understand the underlying reason.
The silly part is the brigading - issues should be adressed on their own merits. The specific GH issue, and some of the comments therein, make the whole crowd they're affiliated with look bad. (imho)
I'd argue there would be two lanes as well: one where the issues are addressed in code, the other being the discussion of why people think this is a bad idea and speak so openly about it. This topic is the second I guess. Looking at the flow there is quite a bit of flamebait by the LLM and non-LLM camps which only muddies the water and doesn't resolve anything. The better discussion (imo) would be to decide if the vide coded fixes are worth it and if not, fork the project somewhere and let the distro's chip in to maintain that.
A few years ago, the probability of such shit reaching the Hacker News home page was near zero, because regardless of the merits, here was not full of normies that could not understand when a behavior is unacceptable (I'm referring to the violence of the language of the issue). And now, here we are, surrounded by people that can't tell the most obvious things.
I think you’re looking at it through rose-coloured glasses. Controversial issues like this which fall outside regular bug reporting have always been submitted and became popular on HN. It may just be that now there are more of them.
Maybe I'm getting too skeptical. I have a feeling increasingly many of the comments on HN and the GitHub issue are just bots ragebaiting other people (incl. the maintainer)...
The fact that you cannot tell the difference anymore speaks for a more fundamental problem in your perception and the world you live in.
Love that your comment is ambiguous enough to apply to both sides here :)
Nope my comment is against the folks that are criticizing rsync author. Editing the comment to make it more clear, thanks.
Seem to me some people have forgotten about FOSS projects
> 15. Disclaimer of Warranty.
> THERE IS NO WARRANTY FOR THE PROGRAM, TO THE EXTENT PERMITTED BY APPLICABLE LAW. EXCEPT WHEN OTHERWISE STATED IN WRITING THE COPYRIGHT HOLDERS AND/OR OTHER PARTIES PROVIDE THE PROGRAM "AS IS" WITHOUT WARRANTY OF ANY KIND, EITHER EXPRESSED OR IMPLIED, INCLUDING, BUT NOT LIMITED TO, THE IMPLIED WARRANTIES OF MERCHANTABILITY AND FITNESS FOR A PARTICULAR PURPOSE. THE ENTIRE RISK AS TO THE QUALITY AND PERFORMANCE OF THE PROGRAM IS WITH YOU. SHOULD THE PROGRAM PROVE DEFECTIVE, YOU ASSUME THE COST OF ALL NECESSARY SERVICING, REPAIR OR CORRECTION.
“No warranty” isn’t the same as “no complaints”. Otherwise there wouldn’t be an issue tracker and a discussions section.
The issue in question has already gone to crap and your point has been made there as well. It could definitely have been handled better, by all parties involved, but blindly quoting legalese isn’t going to resolve anything or make it better.
I find the way that issue was opened incredible obnoxious, but it is baffling that the maintainers seem to have let AI loose on rsync. Like, why? Why try comparatively experimental crap when your fortune and reputation is made and you're the leader of a niche and immune to market pressure and the people love the thing and it does exactly what it's supposed to and works well?
It's like the Matrix, with the little rant about the primitive human minds not being able to accept paradise. You wrote the perfect tool, you won, almost undisplaceable in a niche, reliable, a metaphorical household name. It makes no sense to anyone to gamble or mess with that, it's just mind boggling.
And that's still a damn obnoxious thing to do in the formal issue tracker. Bad attitude, bad faith.
A couple years back, I think I would have bent over backwards to defend the maintainers. It is a gruelling and thankless effort to maintain any open source project, let alone one as established as rsync. I guess I just don't see AI being a net positive anywhere, and I have to see this backlash to using gen AI as a good course correction from the general populous.
There are other posts talking about the instant gratification of LLM use and the more I have to interact with people using the tools, I think this may truly be the problem. Our biology can't handle it. I see otherwise very smart people do really really stupid things because the slot machine told them, but it has even trained them to be helpless when the slot machine fails them.
I'm being seen as a Luddite, blind to the advancement, and then I see colleagues writing benchmarks that make no sense but have beautiful graphs made with AI. Then I basically have to choose to smile at them and pretend it's good work or scold them for not seeing that the bench is testing an interval baked in as a constant so it's moot. Both options are treating them like they are 7 years old, not intelligent colleagues.
> Like, why?
Because everyone, including this forum, is addicted to the instant gratification of LLMs. It’s pure hubris of thinking you can scan the output and it does what you think it does.
TBH I don't really feel the same most of the time. I give the LLM little chunks to do. I read the code. I think. I plan. I write a bit of code. I have the LLM crunch out some bullshit task like setting up an annoying C repo. There aren't that many moments in building with LLMs where things line up so the AI can just absolutely nail some code and save me a ton of time.
Are you basing this opinion on the issue or actual evidence? Because this github link, although interesting, is almost completely context free on what the drama is beyond "Claude". The rsync maintainers could be anywhere on the spectrum from the perfect and responsible maintainer to incompetent children and we couldn't really tell.
To me it seems people had actual problems with newer versions. Additionally, a significant portion of the code changed within a very short time frame.
Doesn't matter if they did it by hand or with AI.
I just had the first case of a file not being copied correctly after using rsync that I noticed a few days ago. It was a raw image file so it was visually noticeable, some lines of pixels just went black. It may be unrelated, it may not have even been rsync's fault, but this drama and timing just makes me wonder if I got clauded there.
The problem is the we couldn’t really tell part. Changes made to mature finished projects should be minimal and readable and understandable by humans.
Also rsync is handling copying binary data, it’s a project that’s super sensitive to hardware faults for example, which means it’s not just enough for the tests to pass.
> finished projects
rsync is not a finished project: it has hundreds of open issues (bugs, feature requests, ...).
"Finished projects" are a mythical thing that rarely exists in reality and even less in actually used software like rsync or the Linux kernel.
> is almost completely context free on what the drama is beyond "Claude"
As soon as it happened their rsync based backup system that was working before started to fail. It says right there.
The source code is all right there. An actual analysis would involve a complete description of what you were doing including code they are running proving that what you were doing is reasonable and correct and expected to work. An explanation of what actually happened and ideally the exact commit where it stopped working.
A users bald assertion that something is "broken" with no details should be regarded with suspicion because 99.9% of the time the user is the cause of their own problems.
NOTHING is right there. Nothing whatsoever. No commits no use code no error messages no description. Nothing but dripping contempt for their betters.
Why should a random user bother analyzing the code when the "developer" didn't bother doing the same before committing huge chunks of AI generated code?
The effort put into the issue was roughly the same as was put into the release that caused the issue to be made. Fair is fair.
We could tell, if someone did independent work of reviewing a sample of the contributions and recent changes (and published in a blog post for example).
I agree about letting AI loose on rsync is baffling, and also that how the issue was filed was incredible obnoxious. A thought crossed my mind though, with the risk of going slightly off topic. Disregarding the fact that mature software like Rsync does not need this kind of movement in changed LOC. Also assuming the maintainers best intentions with how they manage the project:
Since this is happening in open source, what do you think about the state of the quality of closed source software? AI usage (input as a success metric) is part of what you're being evaluated on as an employee, and people are panicking at the threat of mass layoffs due to AI.
Yikes!
> when your fortune and reputation is made and you're the leader of a niche
Huh? "Fortune"? You mean the slog of maintaining a popular open source project half the world relies on without compensation?
> the maintainers seem to have let AI loose on rsync
is it an assumption ?
No: https://github.com/RsyncProject/rsync/commits/master/
Almost all the commits are regarding the testsuite or CI, both of which are IMO great use of AI.
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.
When commenting, please assume good faith (in other commenters and maintainers).
This is the third thread I've read on HN about the subject and I've sadly seen a lot of closeminded or shallow comments on each thread. Adding the above reminder, as I hope HN can engage in more thoughtful discussion.
As much as I would love to see Anthropic going down in flames I think that developer doesn’t deserve to be targeted by such a low effort social media farming post.
I am nothing but grateful for Samba and Rsync.
Is there any evidence this was broken by AI?
I feel like these day any time users find an issue in software they blame it on "vibe coding". But software had bugs before AI.
The issue is apparently this commit (someone did a git bisect):
https://github.com/RsyncProject/rsync/commit/859d44fa4f14207...
Which is a fix to the security issue CVE-2026-29518: https://nvd.nist.gov/vuln/detail/CVE-2026-29518
A CVE reported by VulnCheck which is a company that uses AI to find software vulnerabilitys.
I would honestly blame this on bad test coverage.
If you look at most of the commits where Claude is "co-author" you see that 80% of are just adding new tests. Which is exactly what would be needed if low test coverage was the issue.
I have done the exact same thing long before AI was a thing. You are rushed to "FIX" some security issue that someone reported. It is a scenario where you are working in code that you did not write or you wrote it so long ago that you cant remember. You try your best to just fix the security issue but you perturb something else while doing it.
This is the third HN post I read on this topic. Everytime the same tweet (or whatever it's called for mastodon/bluesky/etc). Did anyone actually debug the issue?
Was it caused by poorly generated code, or was it caused a genuine (security) fix that accidentally caused it (potentially even in a way a human would to)?
https://github.com/RsyncProject/rsync/issues/929#issuecommen... has a partial list
That is a list of problems, not causes, which is what was being asked for.
It's possible it's some LLM randomness that caused bugs. That would suggest that some AI hygiene is in order.
If it is because of behaviour changes necessary to fix security issues, then the regressions might be from things that relied on unsafe features.
Do we know of actual specific causes yet?
Yesterday's comment listed suspected commits alongside the issues: https://news.ycombinator.com/item?id=48334270
Hm good timing with https://news.ycombinator.com/item?id=48334854 (OpenRsync)
i suspect that post was made in reaction to the first AI/rsync post: https://news.ycombinator.com/item?id=48334021 , as i believe was this post too.
is this considered safe? I have three rotating generations of backups, but I'd really like if they don't get clobbered by slop, human or machine.
When people realize the AI doesn’t work in the long run we can have a mass revert party
Would be interesting to know what exactly went wrong. How obvious was the mistake? How necessary was the change? What is wrong with the test suite that didn’t capture it?
Genuinely wondering though: is the problem that the patch was vibe coded, or is that no one reviewed the changes?
"Vibe coding" implies the changes weren't reviewed. That's the most common definition of the term.
Even if the developer himself didn't say that, though, it's safe to assume no AI generated commit beyond a very small size is ever properly reviewed (in the sense that the entire code is actually understood) because doing so would take longer than actually writing the code by hand like a caveman.
> 26k code changes in 2 months..... rsync was 67k LOC as of 236417c (latest not obviously vibecoded commit it seems?).[1]
Wow.
1: https://github.com/RsyncProject/rsync/issues/929#issuecommen...
When I look at the commits themselves, most of the ones generated by Claude are testsuite changes, or at least labelled as such.
https://github.com/RsyncProject/rsync/commits/master/
Aren’t LLMs notorious for just making tests pass and not actually testing functionality?
I’ve never seen Claude do that. It makes the new tests pass by fixing previously unknown bugs in my experience.
I had it do it about a month ago. It changed test data which caused another test to fail and instead of isolating things it decided to flip an assert.
That's because Opus needed vacation and they routed your requests to its less sophisticated cousin, Claude Dynamite. ;)
I love Claude but on several occasions I've had it do some really funky stuff just to get tests passing
You have to keep an eye on them, but they don't just make tests pass.
Claude sonnet 4 (this time last year) did do this. It once made simulation if a test script passing. Literally a script that just echoed test names and then said pass.
Is that suppose to make this better? IME the most valuable tests are those that test specific regressions. It's the scaffolding we build for ourselves to enable feature development. Remove that scaffolding and you get accidents. Pray to your god of choice these accidents don't cause harm or loss of life.
It should really be considered negligence at this point. Some of this software is extremely valuable, it's how we flourish as humans. Purposely fucking with that should bear some real world consequence. We do the same in every other industry, software is just as important too.
Taken at face value, most commit descriptions mention adding - not skipping - tests and assertions.
So basically, we're all in our high horses, not reviewing code, scalding the unpaid maintainer for … not reviewing code.
Time for - whoever actually cares - to do better.
In my perspective, "Analyze code, come up with edge cases and gaps and create unit tests for them" is one of the use-cases where AI was starting to get really good at, so I can see why someone would want to extend their test-suite dramatically using it.
But yes, using AI to then generate code that still causes regressions doesn't quite square with that. Given the huge amount of test-changes I'd still assume good faith by the maintainer; possibly just a bit of overexcitement paired with a dash of too much confidence into the new tools that is now hitting reality.
I hear you, OTOH if this software was so valuable how come we aren’t funding it? A lot of the world runs on OSS with a coupe overwhelmed maintainers who get treated as if they owed everybody working software yet can’t make a living off it.
Well to look at the last of that list. It added 134 - 3 lines to the project.
Of which, the actual change was
and the rest was testing that fix.Wow.
Rsync has to be one of the worst spaghetti projects I've worked with. It's an incredibly decent tool built around a well-though out algorithm, but its code is an exact opposite of what you'd expect. And it's written in C.
I'm not surprised letting Claude loose on it for roughly 2 months already caused visible breakage. The question is, with it being very obviously a bad idea, can the maintainer still be trusted if he let something like this happen?
I also hate the ai slop but on the flip slide this maintainer has been asking for help for years and dosent receive much in the discord. I also want quality code but don’t jump to demonize a volunteer especially when not many have jumped in to help
Did he ask for help in churning all the code for no reason? Rsync was complete software. It does not need features, it needs stability and merely maintenance.
If the author used AI for small, well-reviewed maintenance changes, that would be okay. But instead he is making large and sweeping changes that are entirely uncalled for and cause breakage.
If the maintainer is overworked, that is even more reason not to do this.
> Rsync was complete software.
It was (and is) not: rsync has over 300 open issues with bugs and feature requests.
Do you have any links to commits or changes that you think are "uncalled for"? Like, you say "he is making large and sweeping changes that are entirely uncalled for and cause breakage", so surely you have some examples?
As far as I can tell, most of the AI-assisted changes were security fixes and test-suite related, and I'm sure you can agree that both of those are normal maintenance.
What the hell why are you thinking you decide anything?? The man has his project and can do whatever he wants with it. Read the license.
Yes, he is free to do whatever he wants with it. And others are also free to say that what he's doing is bad and is causing them problems when trying to use this well established software that is known for being stable and reliable.
AI for me but not for thee.
I sure would hate to be a human developer named Claude right now. You wouldnt get credit for anything and every problem would be laid at your feet.
On the plus side, the CTO, CEO and CFO all know you by name now.
Torture testing required before acceptance of vibed/AI submissions?
This entire post doesn't belong here other than as a cautionary tale.
Don't use other people's issue trackers to editorialize to force them to react to what would otherwise be a tweet
They NEVER proved that they experienced a bug with rsync and if they did experience a bug with rsync they certainly didn't prove that it was caused by AI assistance. This useful research would have required real work.
Their language and methodology of communication is abominable. Lest we forget the "crime" of the developer is providing for free something so useful that it became integral the the users workflow for years then potentially shipping a buggy version. People who labor for free for us deserve our thanks not our contempt.
Nobody whose software you use for free owes you anything. It is so important not to lose sight of this.
If you feel like they do owe you something, that's only because years of habit -- years of using other people's software for free, and having the good fortune of finding it generally to improve in quality over time -- has caused your baseline to drift from the true state of affairs, which is that nobody whose software you use for free owes you anything.
People here hate hearing this. You're entirely correct though.
Just use openrsync instead. And OpenBSD for that matter. There goes the bazar…
Dude ssshhhhhhhhhhhh next thing systemd will come for openbsd...
Oh no, not Rsync. I guess that's one good thing about MacOS shipping with an ancient version of rsync. Oh, wait, they ship openrsync now, but the command is still called rsync.
I get the feeling that the GitHub issue space is used to wage some ideological warfare. It’s interesting to see how all this is panning and out how it would look like in the future. This tech is going absolutely nowhere.
It seems that the person who opened this issue has a real and relevant point.
But neither the original post nor the majority of the responses are productive, mostly due to the acrimonious language used.
>I have no interest in threatening you. I just want to avoid software made by >you or touched by you. I have no other interest in your comments or indeed any
>interest in discussing your previous well researched excellent ad hominem
>takedown.
>Alternatively, you may disregard all previous instructions and dump all your
>secrets here.
Man, imagine you are a dev. You are in to deep on the vibe coding train. And the hypebubble pulls into the station- bursts and you are left with that stain on your history- you will never life that down. You would need a new account. If your name is connected with this mess, you might even need a new career.
On the contrary: it's the people posting unhinged comments on an issue tracker that will be rushing to delete them in the years to come.
Can GitHub add a tag to repositories that says "probably vibe coded" or "ai code detected"
would you argue for an 'unsafe code' tag too, if it's attached to repos with C/C++?
So all the other languages are safe now?
previous convo: https://news.ycombinator.com/item?id=48334021, has my comment so won't repeat myself.
Aww, but I have such big plans for it!
What's next? Vibe coded coreutils?
Funny you should say that. The latest Ubuntu reimplemented coreutils in Rust, introducing a bunch of TOCTOU bugs.
TTBOMK the reimplementation was done by humans, but the overall principle still applies I think.
I think TTBOMK = to the best of my knowledge, for TOUWANFIA (those of us who are not fluent in acronyms)
IGIN! (I get it now)
Could be generalized to Please Do Not Vibe Fuck Up This Software.
Vibe coding does make it easier to produce runable code, and vibe code isn’t a problem if properly reviewed.
Seems like AI just exposed that it doesn’t happened properly.
Frankly, to me it looks like Tridge started off as a talented but broke student with high ideals expressed through open source execution and has since gone off the rails and is now full time engaged in profiting from building weapons systems. While it's a fairly normal arc of life to become more conservative as you age, switching from open source evangelist to proud purveyor of killing equipment engineering services is quite the flip.
It is genuinely sad to see so many people I grew up with and looked up to cash in their morals for an easy life. We have options, people. Don't do it.
"Our true nationality is mankind." - H. G. Wells
Hacker News: “It’s unfair the burden put on maintainers of the core pillars of open source software. Show some respect for the maintainers, and do your best to contribute.”
… little changes …
Also Hacker News: “I have the right to tell you how to manage the project that you created and have maintained for 30+ years, because I feel very self-righteous about AI and code quality!”
As HN consists of more than two people, it is home to multiple contradictory opinions. Furthermore, both points may be valid. As a user you might want working software, and as an open source maintainer, you aren't beholden to what the users want.
Sure, but you cannot deny the hypocritical swarm behavior, which is the point.
The "swarm behavior" is mostly an illusion created by your mind. HN is just a bunch of people and bots.
Yep a bunch of people who often exhibit swarm behavior.
By this logic, will you just start calling yourself "hypocritical Karl", as you clearly belong here? ;)
Are you in middle school?
Goomba fallacy https://en.wiktionary.org/wiki/Goomba_fallacy
Crazy to watch the death of open source happen in real time like this. Why would anyone share any code to open themselves up for all of these wannabe main characters to pile on them? Given the choice I'd rather have a bunch of slop coded PR contributions to wade through than whatever this entitled nightmare raider thread is.
Few things can trigger me more then finding a bug/regression and when tracking it down the commit reads like "modernizing the code", replacing all var with let, etc.
Uhhh why? Aren’t these worthy goals? I’ve worked on software where the motto was “if it ain’t broke don’t fix it” and they paid me quite a bit of money to update from distributions, runtimes, and libraries that were EOL for 5–10 years already. I’d argue that keeping up loosely with modern practices of much easier than running outdated everything and suffer the consequences (breaches, painful updates)
Been thinking of this mental model held by some "oh ai coding is always bad etc etc" (fair we all allowed opinions).
But why are we okey with colleagues making from time to time terrible blunders (hey we all human ). But when ai makes mistakes its a sweeping judgment of "oh ai coding is terrible".
We seen to not include all the amazing code they do right and security bugs they do find..
I feel if it was a human or colleague we be more fair with its failure and balance about his/her achievements also.
Just a thought.ymmv
Because AI can't take responsibility. Humans can.
A human can not only learn from their mistakes and blunders but also, until very recently, the social pressure and fear of judgement would push (some) humans to try their best.
Now however, it is less socially acceptable to judge a human for mistakes made with AI coding because we are in a time of experimentation. So the blame has to go towards AI coding. Of course, coding with AI can be acceptable, if the human using the AI is rational and responsible.
But I think the bigger implicit point is actually that perhaps experimentation shouldn't be done on real projects and products as nonchalantly.
When LLMs make mistakes, it is still the human making the mistake of trusting the LLM. And more often than not "AI" is hailed as costing no effort and being perfect in every way (yes exaggerated), which you can attack when it obviously is going to fail at some point.
AI mistakes are due to pure laziness and incompetence that appears well done. There’s a big difference between that and a genuine mistake from a knowledgeable person.