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?
As several comments in the issue mention, it's up to the developers that contribute to an open source package to decide how they do it. Complaining on an issue tracker (apparently without proof) about AI ruining a piece of software is a form of "Open Source contributor abuse" discussed frequently on Hacker News [1]
> The issue tracker is not a place for you to farm viral social media posts. Either report an actionable bug or fork it yourself. Venting about the developers choices is not productive.
> @II-Paulus-II Stop. You know nothing. You have shipped 0 features by hand. No one has ever depended on your code. You are a finger-wagging "AI wrote this" type in an era where you hide in plain sight coasting on the moral high ground of writing toy projects and scripts from scratch. Can't ship, can't adapt, can't even realize that an issue tracker is not the place for this kind of attitude.
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.
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.
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?
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.
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)...
I'm not sure how to interpret your comment. It could be
- a response to my comment saying that I am "illiterate" and cannot differentiate LLM output vs actual human comments (in that case I'm not sure what you're adding to the discussion here beyond a personal attack)
- a general comment saying it's getting harder for people in a position similar to us (i.e. tech / tech-adjacent who interact a lot with others who write with LLM assistance or via LLMs) to differentiate human/AI output.
I'll assume good faith and you mean the second. In that case maybe you can explain the "fundamental problem" you're referring to?
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. And developers are capable of such language, we have a reputation for being rude and even used to have a poster boy for it. Blaming this on “normies” (itself typically a dismissive word) is ignoring the problem has always been there and our responsibility in it.
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.
I'm with you. I don't understand why it affects some people more than others. To me, using AI triggered my sense for drugs and addiction after a while: when your first association for an engineering product is "it feels _great_!" then run, it's just cocaine with extra components.
A tool should not make you feel good, just accomplish the task.
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.
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.
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?
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);
"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.
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.
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.
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.
Then I have bad news for you about a large chunk of both open and closed source development today.
We also don’t know if it was “unleashed”. Claude will add a co-author line to your commit even if you just ask it to author or touch up your commit message or clean up your branch’s commit history or any of a number of things that result in the creation of a commit, even if it touched none of the code. This functionality actually saves me a ton of time and results in higher quality commit structure and messages.
Has this specific issue actually been tied to misuse of Claude?
Comments in Github were usually horrible, but the AI stuff brought extra divisiveness. yt-dlp stops supporting bun because they call the rust rewrite a risk -> hate comments. rsync fixes security issues and gets some help from AI -> someone finds a bug and... hate comments. Poor maintainers.
The comments are definitely not worth reading. It’s a very sad thread, you literally had to go through all of them to find one that wasn’t about hate and stating some facts about the issues of the code.
I found them worth reading for the following set of thoughts came up:
- programmers had problems with delivering quality long before LLM’s
- very much research and tools went into that, bringing us {Git, libraries, VSCode, reviews, …,} but the human factor stayed the same (and more pronounced imho than in other fields of engineering)
- LLMs democratized programming, enhancing a few, dropping the bottom to no skill programming
- the tools and practices created for the quality problems from the past turn out to be wholly incapable of maintaining quality in the present
The main problem behind this is that those delivering the QA tools of the past are central in the AI race. Old school engineering would separate these concerns.
People are saying they detect a lot of "hate" in these comments which I don't see or agree with at all. People clearly have negative opinions about this and they're expressing them rather openly but to confuse this with actual "personal hate" seems like an equally overcharged response.
When you do anything publicly, even something that's considered a 'public good' like contributing to open source, you are opening yourself to the full tide of humanity for better or for worse. The overwhelming majority of the time it's for the better, occasionally, and in response to unpopular decisions, it's for worse.
What you shouldn't do is take any of this personally. It's open source. You have permission to take a break, you have permission to directly ignore issues and users, you have permission to do whatever makes _you_ happy.
If your goal is to receive unremitting love and adoration from a crowd of strangers then you're going to be bitterly disappointed... no matter how you occupy yourself.
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.
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.
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?
As several comments in the issue mention, it's up to the developers that contribute to an open source package to decide how they do it. Complaining on an issue tracker (apparently without proof) about AI ruining a piece of software is a form of "Open Source contributor abuse" discussed frequently on Hacker News [1]
https://github.com/RsyncProject/rsync/issues/929#issuecommen...
> The issue tracker is not a place for you to farm viral social media posts. Either report an actionable bug or fork it yourself. Venting about the developers choices is not productive.
https://github.com/RsyncProject/rsync/issues/929#issuecommen...
> @II-Paulus-II Stop. You know nothing. You have shipped 0 features by hand. No one has ever depended on your code. You are a finger-wagging "AI wrote this" type in an era where you hide in plain sight coasting on the moral high ground of writing toy projects and scripts from scratch. Can't ship, can't adapt, can't even realize that an issue tracker is not the place for this kind of attitude.
[1] https://news.ycombinator.com/item?id=43077833
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
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/
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.
For the same reason as some people would rewrite it in Rust.
Rewrites brings new bugs regardless of the language.
That is different from AI where the calculus seems to be that if AI isn't involved, it aien't relevant.
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.
AI psychosis is a real thing and an actual mental health issue.
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?
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.
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.
Of course I know that some people can just becoming psychotic out of nowhere. But why would I assume it?
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.
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.
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.
https://github.com/RsyncProject/rsync/issues/929#issuecommen...
And you got downvoted for calling out that crap. A sad state this world is in.
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?
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.
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.
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.
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)
- a response to my comment saying that I am "illiterate" and cannot differentiate LLM output vs actual human comments (in that case I'm not sure what you're adding to the discussion here beyond a personal attack)
- a general comment saying it's getting harder for people in a position similar to us (i.e. tech / tech-adjacent who interact a lot with others who write with LLM assistance or via LLMs) to differentiate human/AI output.
I'll assume good faith and you mean the second. In that case maybe you can explain the "fundamental problem" you're referring to?
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.
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.
I'm with you. I don't understand why it affects some people more than others. To me, using AI triggered my sense for drugs and addiction after a while: when your first association for an engineering product is "it feels _great_!" then run, it's just cocaine with extra components.
A tool should not make you feel good, just accomplish the task.
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.
Doesn't matter if they did it by hand or with AI.
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.
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.
As soon as it happened their rsync based backup system that was working before started to fail. It says right there.
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.
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.
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!
Huh? "Fortune"? You mean the slog of maintaining a popular open source project half the world relies on without compensation?
is it an assumption ?
> 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.
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.
The actual Claude "churn" is mainly test suite enhancement.
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.
I am nothing but grateful for Samba and Rsync.
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.
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.
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)?
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?
Wow.
1: https://github.com/RsyncProject/rsync/issues/929#issuecommen...
https://github.com/RsyncProject/rsync/commits/master/
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.
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.
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.
Of which, the actual change was
and the rest was testing that fix.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.
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?
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.
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.
It was (and is) not: rsync has over 300 open issues with bugs and feature requests.
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.
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.
But neither the original post nor the majority of the responses are productive, mostly due to the acrimonious language used.
>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.
… 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!”
TTBOMK the reimplementation was done by humans, but the overall principle still applies I think.
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.
In any case, I hate rsync owing to how easy it is to accidentally deleting everything. From my pov I don't care if it disappears.
We also don’t know if it was “unleashed”. Claude will add a co-author line to your commit even if you just ask it to author or touch up your commit message or clean up your branch’s commit history or any of a number of things that result in the creation of a commit, even if it touched none of the code. This functionality actually saves me a ton of time and results in higher quality commit structure and messages.
Has this specific issue actually been tied to misuse of Claude?
I think you are being too entitled.
Crazy.
The amount of drive-by hate being thrown at project maintainers of an open source project is depressing.
- programmers had problems with delivering quality long before LLM’s
- very much research and tools went into that, bringing us {Git, libraries, VSCode, reviews, …,} but the human factor stayed the same (and more pronounced imho than in other fields of engineering)
- LLMs democratized programming, enhancing a few, dropping the bottom to no skill programming
- the tools and practices created for the quality problems from the past turn out to be wholly incapable of maintaining quality in the present
The main problem behind this is that those delivering the QA tools of the past are central in the AI race. Old school engineering would separate these concerns.
When you do anything publicly, even something that's considered a 'public good' like contributing to open source, you are opening yourself to the full tide of humanity for better or for worse. The overwhelming majority of the time it's for the better, occasionally, and in response to unpopular decisions, it's for worse.
What you shouldn't do is take any of this personally. It's open source. You have permission to take a break, you have permission to directly ignore issues and users, you have permission to do whatever makes _you_ happy.
If your goal is to receive unremitting love and adoration from a crowd of strangers then you're going to be bitterly disappointed... no matter how you occupy yourself.
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
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
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.