Please Do Not Vibe Fuck Up This Software
github.com
github.com
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.
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.
Doesn't matter if they did it by hand or with AI.
I was syncing photos from my phone.
Also related: I'm using LLM assistance to write it, but I also have a test suite that proves it's working (I call it the "shotgun" suite: given a good image file, it first flips a random bit ("sniper"), then a random byte ("boltgun") and then a random 4096 byte segment which is the typical sector size ("shotgun"); each time it tries to validate the file by decoding it fully, and records what percentage of time it is detected at each scope, and it collects statistics about this over hundreds of times.)
The point of it is to detect things like corrupt data and bitrot... across 240+ different filetypes so far... since no other tool really exists yet in this space to do that.
Note that some formats, notably Apple's HEIC, are so data-dense that corruption only results in undetectable image corruption (well, a human would notice it, but an algorithm cannot!) So I have ANOTHER app coming to help with that which does detection AND repair (to a point). ;)
The CLI will be free and open-source, but I'm also writing a for-sale-in-future private-source GUI for it.
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.
This is something that you assume, not something that you have any proof of. To put it a bit more strongly, this is something that you (and hundreds of other people in that github thread) made up in your head. The maintainer is a very experienced OS developer and there's no reason to suspect they didn't review the committed code.
Bugs happen, and the mere existence of bugs is not a proof that someone is doing a poor job. Assuming those bugs even exist. I am inclined to believe they do, but the issue does a poor job of reporting them. Instead of factually reporting regressions, the "issue" is a screenshot of a viral tweet.
Your vicious reaction is not justified, and you should do better in the future.
>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.
It is not fair. The rsync maintainer does not owe you anything. You owe them for using their software. How much did you donate to rsync this year?
We both know what the more likely scenario is here. We both know that AI fanatics have spent the last year bragging about how many thousands of lines of code they can pump out per hour. Do not claim otherwise, because to do so would be an insult to my intelligence. And from a quick look at the developer's Github profile, it's clear they've gone all in on the hype, as I cannot find a single significant commit made this year that is not signed by Claude. Even the most experienced developers are not immune to AI psychosis.
> You owe them for using their software. How much did you donate to rsync this year?
I don't remember reading this in the license. Could you point it out for me? I can't find any such clause.
Any request that doesn't come with a promise of payment is panhandling. We have become so accustomed to overwhelming generosity and a cup that runeth over that instead of being grateful that our free hot soup comes a condo and a masseuse that we are spiteful when it isn't to our taste.
The random user should spend time analyzing the code because helping someone help you is part of the social contract that comes with having someone whose time would cost $400 - $1000 an hour as a contractor personally gift his time to you.
If ungrateful folks forget this we might find this resource increasingly scarce.
... and that's how to lose credibility.
So given the rsync author did not make anything in the first place, they also cannot go destroy rsync as there is nothing to destroy.
But well done defending abuse.
I'm not interested in that. So I'll ignore your demands. Find yourself a different target.
I didn't see this.
>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.
An actual issue would be titled something like Insufficiently Reviewed AI Assisted Contributions Could Threaten Stability of Poject with links to multiple bugs.
Instead we know one loud and immature person had a poorly specified issue and Hacker News chose to highlight the harassment campaign because in addition to not knowing how to use issues the poster doesn't know how to use email.
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.
This is what I personally consider “vibe coding”, not simply using LLMs or agents or whatever in your workflow
It's just another avenue of dopamine addiction, not unlike scrolling TikTok, Reddit, or wherever except vibecoding is disguised as being productive.
Your workflow is similar to mine, and not "agentic". The proponents of Agentic workflows would have you handover the bulk of the edits to AI, and you'd hand-hold/course-corrrect its approach via chat while it does the thinking.
I tried the agentic approach for code-gen once, and found it mentally draining. Its like pairing with an over-enthusiastic junior on cocaine that can also type 2000 wpm.
Chunking small changes is great because you don't need the latest and greatest models, Flash variants are more than enough.
Deploying and watching CI and looping until it passes.
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?
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.
What about using a sewing machine instead of hand-sewing?
Washing machines instead of hand-washing? (Some people still swear by air-drying instead of using a dryer, but there aren't that many "hand-washing is just better" holdouts, even if it might be true!)
Note that in all of these cases, you ALWAYS grin when you first use the more automated thing after having done the manual thing, and you ALWAYS lose something by going the faster/less-laborious route. If people are simply hyperfocusing on what is lost when you lean on LLM for coding, then they're simply going to miss the train (yet another invention that superseded walking and horseback-riding, with its own set of tradeoffs!)
We all know a walk is good on its own terms even if a car is faster, but if your goal is to get from point A to B in less than a certain amount of time, sometimes only a car will do. Hand-washing probably is less wear-and-tear on the clothes and lets you focus on dirty spots. Air-drying leads to fresher-smelling clothes that don't shrink. And hand-coding leads to a more curated solution than an LLM ever could... All of these at a comparatively extreme extra time or labor cost.
I never thought I'd actually see an anti-joy argument being used in all seriousness, but welcome to 2026!
https://news.ycombinator.com/item?id=48413983
Thoughts on that, then?
Note that the Luddite movement was actually not opposed to the technology itself, but how it would negatively impact workers' rights and textile quality[1]. Many Luddites were actually highly-skilled machine operators.
Any of that sound familiar?
[1]: https://www.smithsonianmag.com/history/what-the-luddites-rea...
well, at least you're being honest about your non-empirical biases...
is it an assumption ?
That's ballsy. I feel like if I used Claude heavily for a piece of code, an existing test suite would be something I would want to rely on to catch mistakes.
What https://github.com/RsyncProject/rsync/issues/929#issuecommen... shows is that it no longer works on older Darwin and Linux < 5.6, which has been deprecated in 2020. Plus some other bugs as well.
You cannot expect maintainers to support old systems and know the impact their changes have. Whether its done by AI or hand.
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.
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)
drive-by 20-file pull-requests that ultimately end up costing maintainer's burden seems to hit hard here.
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?
That's not what happened, and I think you know it. The number of LOC introduced in the last 2 versions of rsync is off the charts. And there are bugs. I've been in a situation like the author of that issue. Upgrade a package and things fall apart and it would be very, very expensive to debug it to file the appropriate bug reports... so I roll back to a known good version.
Yes, the language the person used wasn't the greatest.
IMO, this is a litmus test for how you feel about AI. For the people that hate it, it's just a big pile on and "I told you so" ... we don't have enough info about the author to know if they are anti-AI. We know they are against using AI in a BAD WAY.
The regressions are the issue. If the software was working as expected, no one would be coming after them for “the sin of using AI”.
I don't understand what novel problem you think you've uncovered here.
But there is good news, at least I think. AI is also moving processes ideas and safety guards along at a faster rate. The only real downside is right now, at least, the amount of code being created outside of our safeguards has accelerated much much faster. This has happened in the past with software, so I am not too worried.
Note this is not what OP called silly. It's possible to take legitimate issue with something, then act silly about it. People are free to their opinions but not necessarily to (as an extreme example) write their opinions on the wall with their excrement. Regardless of any veracity behind the opinion, some decorum is expected in its expression. (I guess unless one is explicitly doing away with decorum but that's when violence takes its place.)
You can grep commit logs by “Assisted-By” these days and there sure is a whole bunch of LLMs.
Let's engage in some parallelism then
This happens with literally everything in our society. Right now, every single food product seems to be infused with protein. In the past, they've had GMOs removed, MSG removed, been Fiber-infused... the list goes on and on.
We don't see people bullying and threatening grocery store clerks and managers over clear hype-cycle bullshit. Why? Because every rational person knows this is pure nonsense.
This behavior is NOT sane.
As many others have pointed out, this is just a regression that occurred during regular software development. There's nothing remarkable here that makes it AI-specific, other than that the contributions were AI-assisted. Regressions in software happen. You roll back to a stable version and make a bug report. You don't shit your diaper and sling it at the maintainer.
Acting like a giant fucking douche is NOT NORMAL BEHAVIOR.
Yes, but some should absolutely be caught with a robust test suite, especially if it is not an edge case.
When was the last time there was a breaking regression in SQLite again?
A mistake was made. There are well worn paths for fixing the mistake. Acting like a giant fucking petulant pissbaby is not the critical path to getting things fixed and is deeply corrosive to the positive collaborative environment we’ve all spent decades building within shared, community software.
Get the fuck over yourself.
Yeah for human, by humans
For some critical software, open-source or not, a regression could literally kills, that's why I put SQLite as an example. A simple miss should NOT pass into stable, if it's an edge case due then yeah learn from it and built a test suite for that if possible
rsync is highly popular tools and a lot of people depends on them, whether you like it or not. At a certain point (I don't know what point, 10k, 20k, 500k users?) maintainers should respect the user expectations over their own ego and convenience
This is a problem for OSS in general, people treats their project like a hobby because it didn't pay enough, or corporates uses it without contributing back
From a cursory look, it looks like a security fix in response to a CVE surfaced a coding error which (as far as i bothered to check) has been present in the code since 2007.
This is so banal that it's actually hilarious to see people lose their shit over it. But of course nobody is talking about the actual issue but about the _hypothetical potential for issue_ introduced by potential use of AI. It's so meta i don't even know how to make sense of it.
https://www.washingtonpost.com/technology/2026/03/04/anthrop...
> As planning for a potential strike in Iran was underway, Maven, powered by Claude, suggested hundreds of targets, issued precise location coordinates, and prioritized those targets according to importance, said two of the people. The pairing of Maven and Claude has created a tool that is speeding the pace of the campaign, reducing Iran’s ability to counterstrike and turning weeks-long battle planning into real-time operations, said one of the people. The AI tools also evaluate a strike after it is initiated, the person said.
> The Pentagon began to integrate Anthropic’s Claude chatbot into Maven in late 2024, according to public announcements. The system has been used to generate proposed targets, to track logistics and provide summaries of intelligence coming in from the field. The Trump administration has vastly expanded the use of Maven into many other parts of the military, with over 20,000 military personnel using it as of last May.
How are maintainers supposed to know that users don't trust AI if no one voices that concern? rsync was very stable. Should people silently move to Openrsync and never say anything?
They’re also all completely disingenuous (“I’ll have to stop using rsync now”) given that 99.99% of software now includes AI-written code, whether it’s known or not.
submit a bug report if you like, but keep your opinion away from issue trackers.
The author shared the code with the world. No part of that gives the world a vote in how the author chooses to maintain it.
Bugs happen, regressions happen regardless of whether it’s human or AI written. The only valid criticism is that he’s moving too fast for quality code review by others. That said, I bet if you search through the issues you’ll find multiple places where users have complained about their bug staying open for too long without being addressed.
The workflow is totally different, even though the output might look the same. When coding "by hand", thinking and reasoning is mandatory. When using LLMs its optional.
> not sure if this is just me, but after updating rsync, my cpu usage got so bad during my daily backups that i had to stop timeshift from running forever
Or, phrased differently - People are frustrated and annoyed that the tool they trusted with their backups and data are seeing a huge number of regressions and new bugs that break their entire backup infrastructure, all because the main dev is vibecoding that software. Vibecoding experts like Simon Wilson explicitly state that vibecoding is 'viable' in the sense of "only if you hold the tool in a specific way", and this person is either not doing that, or that statement is untruthful. If you actually read the thread in question and just skim over the argument two people are having, there are multiple reports from users in industrial and government settings that now have to go through whole processes to update this software, simply because the software has become immediately untrustworthy in a way that directly harms users and defeats the entire point of the software in question.
I think I would also be mad if I relied on this software for my 500gb+ backups, and I wonder how many more issues have been introduced that we simply won't learn about until a company has a $10 million dollar data loss because they were not testing their backups consistently.
That may or may not be true, people are justifiably (or not justifiably) angry about a lot of things all the time.
But this was very obviously a brigading attempt. It's a form of online bullying. If it had been about whether the maintainer liked striped socks, nothing else about this would have changed.
Later on the brigade can claim "oh we had a justifiable grievance" to sooth their souls, but what actually happened is what actually happened.
It's all a bit silly and childish.
(To be sure: the balance of fao_'s statement is well reasoned. It's the brigade who are being childish, and I don't think they should be rewarded for that. )
There are four actual regressions there. The commits that introduced two of them have been identified, and neither neither of those mentions Claude (or another LLM).
If you look at the actual commits that credit Claude, they are not huge commits (many are a few lines), most are tests and config. This is not vibe-coding.
> there are multiple reports from users in industrial and government settings that now have to go through whole processes to update this software
If people are handling such critical data with it they will be testing upgrades before deploying to production right?
> I wonder how many more issues have been introduced that we simply won't learn about until a company has a $10 million dollar data loss because they were not testing their backups consistently.
If a backup failure would cause a $10mn loss then its grossly irresponsible to not test your backups.
I don’t think people really care about rsync or the nuance. They just want to make an insta-reaction, rant about AI, then move on to the next story that raises their blood pressure.
How could we even check if either human or robot code is working properly if we're not even sure the test suite works?
Also, another user[1] compiled a nonexhaustive list of 7 issues they found introduced because of the changes.
[1] https://github.com/RsyncProject/rsync/issues/929#issuecommen...
Adding that to the two in the issues further up, that makes a total of five bugs in AI assisted commits.
Hi fao, the issue you linked starts with:
> Rsync 3.4.3 and newer is AI slop, and currently has several open security vulnerabilities and other critical bugs (including some link-related ones) caused by said AI slop:
It then proceeds to link to multiple functional regressions caused by (theoretically) fixes to security vulnerabilities.
This took me about 10 mins to review. It seems that the person who created the issue did not bother to spend 10 minutes to check his own work. Is this "vibe reporting"? What should we say about the irony of employing "human slop" to trash "AI slop"?
Further ironically, the "aggregate of bugs" in void-linux included an issue that was not even about rsync. More "human slop" that you are happy with?
It's just that they now have the chance to do them 1000% faster and not even realize
It's clearly a win for 1-man projects and greenfield projects, but maybe not for what's described above ...__yet__.
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?
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.
I don't believe that anymore - if that were true, the large portion of code now being rewritten in Rust wouldn't be vibe-coded slop.
I'd be more willing to believe that "quality" was the reason if those doing the rewrite weren't fucking vibing everything!
There may be some recency bias with the whole Bun fiasco, but Bun is after all owned by Anthorpic.
The wast majority of software in Rust that's actually used is not vibe coded as far as I know. There may be a large number of vibe coded Rust projects on GitHub but that's a poor metric to judge by given how easy it is to publish a new repo.
Is a large portion of in use Rust code vibecoded? I don't believe so.
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.
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".
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/
Regressions should be fixed expediently, but if you apply the criteria "need to not happen" they are literally blocking issues. They could then block security fixes.
I worked on major OSS projects and we never just blindly pushed out untested poor quality code for security fixes since that adds WORSE security regressions.
The methodology describes the effort you may be putting into something, The outcomes are about what results are you prepared to accept.
Would you ship an update with a security fix if it had been thoroughly tested was shown to have certain regressions but no worse security regressions? Would you refuse to fix the security issue until you could do so without any degradation?
It's clear that people can and do accept regressions for security updates. Spectre mitigations cause performance regressions. SharedArrayBuffer got taken away for a while. Being absolutist about things seldom helps.
I agree due care should be taken where possible, but I'm also prepared to accept that mistakes can happen even when people have worked diligently to find issues.
Since you have worked on major OSS projects. Have any of them shipped regressions unintentionally? Right now that is the only thing we have to go on, that these things happened. The degree of care taken is an unknown, as is the degree of LLM involvement. We might know more in a week or two.
If you want to condemn something based upon what might have happened you can specifically state what you think shouldn't happen, and that will stand regardless of whether or not it applies to the current incident.
Obviously "Thoughtless generation of code slop without regression testing" is unacceptable, but that is because the conclusion is written into the statement by saying "thoughtless" "slop" and "without regression testing"
If tridge says 'I gave it thought, I don't agree that it is slop, and I did regression testing' then you have nothing further to complain about, because the incident does not fall under the criteria you specified.
It's saying 'things that are bad, are bad'. The defence is to say 'well, this isn't bad'
You'd have to test to know this, and there is no evidence that tridge did this regression testing - or ask Claude to find possible regressions caused by proposed changes. If tridge did test for regressions, but chose not to document the regression, then it's still negligence, regardless of the tools pr processes involved.
> there is no evidence that tridge did this regression testing
What evidence would you be looking for? New tests, like the ones added in the AI-assisted commits? What other evidence?
> If tridge did test for regressions, but chose not to document the regression
Presumably you weren't trying to imply here that tridge found a regression and decided to ship the code anyway; so parent went to a natural assumption - do you think testing for regressions finds all regressions?
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.
A change in the sys calls that are used. That's pretty sensitive in general I think; I can see if it were introduced by an LLM why people would be upset if they experienced data loss from it.
I still have no idea what on earth why or is Gas Town. Also, he facilitated a crypto rug pull around it because he claimed the money to help support Gas Town was too good to pass up. People have lost their minds with this.
This is just a tool and it’s making people have brain damage. I don’t want this reality. It’s too stupid.
There is no reason to think reviewing AI code more then writing own wont have the same effect.
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.
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?
What matters is when the stimulus presented exceeds their resistance.
Extended AI use is a highly attractive stimulus that exceeds most people's resistance, especially when sycophantically interacted with in an echo chamber (human-AI, with no other humans in the room).
So yes, it's dangerous in the same way that cigarettes and social media are.
Just because some people can avoid slipping into it, doesn't mean we should ignore population-as-a-whole outcomes.
I think it's normal to be pissed at lost data. Maybe it's not socially acceptable to spit in the face of a volunteer but it's 100% human to feel annoyed by an obvious drop in code quality.
Why are you hedging this? Do you think maybe it is socially acceptable?
Then egos got bruised and things leave the realm of reason soon after. But coming with a request saying "Version X worked while version Y doesn't", with maybe some degree of annoyance, is fine.
1) they stop volunteering
2) they will ignore you
In neither of that is your issue solved. So maybe it's better to deal with the frustration on your own and then file a bug report.
Poor communication results in professionals firing the customer as well. None of this is exclusive to OSS of volunteer effort. But the communication in general is necessary.
This is just product management and communication issues. There is an perceived problem and the problem MUST be communicated.
Problems aren't solved by shutting up and ignoring things. And based on the discussion in this topic, it's clear there's a lot of people who are worried about rsync code quality here.
This doesn't seem egregious enough to fire the customer.
This is somebody spending their free time on code they enjoy and then putting the result online.
The reason businesses are careful about which customers they fire is because they want to keep having customers. Open source maintainers have no reason to deal with that shit.
Again: we are talking about rsync here. This new methodology being used this year seems to be associated with a regression (ie: Data loss since this is rsync after all....) that likely wouldn't have happened any other year.
Or at least: the regressions at play are consisting of thousands of lines of changes that was only navigated by Claude later down in the discussion.
We are reaching the point of AI developed code that requires AI itself to analyze. One step at a time. It's right for the open source customers who are used to understanding changes and smaller patches than this.
Otherwise, you're just a beggar. And beggars don't get to choose.
That's not why the comments are angry. The anger is directed at the slop approach to code review.
I guarantee you the same anti-AI people wouldn't give a shit if the author used an AI-enabled IDE and personally vetted all commits.
The internet/apps of the last 20 years have not exactly boosted people's ability to think critically and set aside their passions though.
Much easier to keep eyeballs glued and sell them ads if you encourage their baser impulses.
X-derangement thing is not used in reference to people whobare wrong or lying, but in reference to people who are making correct observations
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.
I don’t, but let’s assume for a moment.
It’s still up to the current maintainer to pick additional or replacement maintainers, and it would be bonkers to expect the new maintainer to fork the repo to implement their changes.
Open source projects change their maintainers all the time.
The thing that makes a project die is if the maintainers all leave. Users don’t make a project exist. They make it popular.
If the user community all up and left, rsync would still exist and continue as long as its maintainers choose to work on it.
By contrast, if all the maintainers leave because they’re tired of dealing with assholes, the project dies.
It's quite some value judgment and worldview to divide open source into autistic maintainers who do even if no one uses and asshole users who do not and cannot do.
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.
People coming in "I encountered a bug, I don't know what the bug is but I thought about it for a second and it's obviously your descision to do xyz".
As a maintainer, what are you supposed to do? It's not more useful than a ticket "somethings wrong idk what" which is useless enough to close without further action. But it puts the burden on the maintainer to a) figure out what's wrong based on basically no data whatsoever, then b) if they find it out figure out why then c), and that's the tiring part, review their process and create a defense for their approach, or admit that that thing that random user felt after trying out your software for 10 minutes is right, and that you were what? stupid to even think this would ever work? They never asked for any of this, and they're already doing so much work for free.
If the rsync maintainer reads this: You're doing incredible work and humanity appreciates your obviously incredibly competence in it, and not everyone feels the way these people do.
Moving to agentic workflows is obviously the right step and it already provides enough benefits to do it already. And mistakes are bound to happen (if the issue is even a mistake!) and there will always be people who cannot comprehend the power of agents and who will point the finger saying "I know it from the start! I've worked with these tools for 2 hours already and I can see they don't work! Idk why you think they do!". They're wrong. But mistakes will happen that otherwise wouldn't have - but that's the learning experience.
As far as I know, nobody with data claims that vibe coding doesn’t affect reliability negatively.
People will connect these two things.
Many times, when reliability doesn’t plummet really. For example, there were huge negative news about a Samsung phone a few years back, that it easily causes fires. Sales were affected by this. Interestingly, next year, they released basically the same thing under different name, and complains were never that loud again. And as far as I know, when they were loud, there was nothing special about that particular model regarding this. So it’s possible that outrage is not validated at all.
They will also connect these, when reliability plummets, but it’s not because of vibe coding.
And they will connect, when it is the real culprit in general, but their problems are not affected by vibe coding.
And of course also when vibe coding really causes their problems.
In any case, the original statements will be true. Do we really want to make a product less reliable to implement features and bugs which we deemed not that important before? Especially with a stable product?
Of course, these on the maintainers, but it’s interesting that forcing AI and their consequences on us - like how Microsoft, Google, etc do - is the default, and not the other way around according to many in this thread and others.
And the maintainer can then choose to use that feedback to incorporate it into the workflow, on their own time. If they so choose (which I'm sure they will, unless they get burnt by the community right now).
I think we agree.
Here's a recent sample, paraphrased for brevity:
Them: this is broken.
Me: no, it's not broken.
Them (a few days later): "I think I must not have tried all the combinations", followed with two pages of transcripts.
Me: "I've just checked the code, and you're right [...] I'm extremely sorry I wasted your time."
Them: "Heh, it's all good. I'm am chuffed you're taking the time to give thoughtful responses with me"
But I was referring more to the initial use of strong words coming from frustration.
Just because you deal with it well doesn’t mean you should have to deal with it in the first place, especially when it comes to volunteer work.
Is AI the problem, or that it had a regression? Is the regression actually caused by AI?
https://github.com/RsyncProject/rsync/commit/30656c5e
Someone using AI to bisect recent rsync. https://github.com/themgt/rsync-compare-link-dest-341-343-re...
Someone trying to fix it with more Claude Code: https://github.com/RsyncProject/rsync/pull/930
Related ticket: https://github.com/RsyncProject/rsync/issues/915
I'd recommend putting in more regression testing in the commit before 30656c5e, and rebase it forward while keeping functionality.
This wasn't "unwanted new features". Tridge was fixing a security issue, related to a bug report. I sympathise - we are all getting slammed with security issues. Fixing them isn't optional. I can't say I enjoy returning to decade old software to do it - so colour me impressed that tridge is putting in the effort.
I'm also guilty of using LLMs to help me get past this mess. I dunno what tridge is doing - but I check every line of code it spits out. Nonetheless, I have no doubt bugs slipping through is a real danger. I haven't looked at the code in a long while, I'm not as familiar with it as I once was. So a bug slipping through is not a big surprise.
Which brings us to the one odd thing about the blow up. The original complainer seems very protective of his backup system - yet tridge's commit was only 2 weeks ago. I know tridge is good - but surely you treat this as alpha software. What was he thinking? Maybe he has a bit to learn about building reliable systems himself.
Irrational actions lead to irrational reactions.
You're being dishonest with what you wrote when the proof is literally in this article.
Still not quite sure what you mean by obvious because to me “Stop. You know nothing. You have shipped 0 features by hand. No one has ever depended on your code.” Is much more violent than “please do not vibe fuckup this software”.
Embarassing nonetheless
This nailed it. None of the bug reports even attempt to document the claimed "--compare-dest=" regression. I did ctrl-f and I didn't even see anyone mention "compare-dest" again? The people posting worthless AI rage comments could have asked Opus 4.8 to spin up rysnc 3.4.3 vs. 3.4.1, thoroughly document the regression and git bisect the commit that broke it and filed a 1000x more professional and useful bug report.
If you want society to value your human work more than AI work, try to avoid acting like a uniquely human bozo.
These bugs did not exist in human code. They were introduced by AI.
> thinks that if only we didn't use AI there would never be any bugs
Strawman. These bugs would not exist if not introduced by AI.
It's really baffling to see so many people in this thread maintain the position that somehow software was clean and pristine until AI touched it with its evil.
Please try to at least put some sort of constructive argument forward, for example - I don't like AI because it might introduce more bugs than a careful human reviewer. Then we could discuss why a single maintainer is responsible for rsync and how they should handle the pressure of keeping it up to date - should they just stop making further changes, should they look for tools that might help them?
(By the way, if your position is that rsync was perfect before AI got its hands on it, you have a clear solution to all your problems - simply do not update to any newer versions)
Either way, move away from this absolutist nonsense that has no bearing to reality.
Nobody maintains this position. Again, it's a strawman you made up, because it's easier to dismiss such "absolutist nonsense" than it is to just admit that these specific bugs were introduced as a direct result of careless AI usage.
If the developer is overwhelmed by the maintenance burden (they aren't, judging by how many AI commits they've been making to a large number of repositories), then that's an entirely different problem that deserves a good faith discussion, but delegating the work to AI is not the correct solution.
> By the way, if your position is that rsync was perfect before AI got its hands on it
Again, strawman, nobody said this either. In fact, quite the opposite - we want rsync to continue to be maintained by a human. If the current developer isn't interested in or capable of maintaining the project anymore, they should just say so instead of quietly letting AI take over, because then the likelihood of someone else stepping up to contribute would be much higher.
This one is "tamer", a bit, because the hate goes towards the AI usage, not the person.
Regarding it reaching the front page: is it possible that’s because others feel the same way about a software they might use daily for important work?
Trite as the gh issue is and surely this is thankless work, the bottom line and reality is that rsync is a cornerstone for a lot of sensitive pipelines.
Maybe don't piss off the maintainer then?
That’s stupid and inefficient.
Like, this was posted on an issue tracker. “Your commit messages reference Claude and some guy on bluesky thinks some unspecified issue he had is related to those commits” is not an actionable issue. All the rest of the discussion aside, if this were my project I would close and lock with “not enough info to reproduce”. There are better places for general discussion about AI and forking and emitting rage.
* People with linux < 5.6 can't build this from GitHub. This to me seems like a fairly minor regression: people using maintained versions of 5.6 (mostly extended security) will have distro maintainers pick up that the build is failing, allowing for it to be corrected in a timely manner.
* Hardening against path-traversals causes failures for users with: no chroot; using the native rsync protocol. Ironically: chroot = no is deeply discouraged; you shouldn't really be using native rsync in an automated manner (and perhaps it seems I wouldn't advise using it at all); the CVEs the commits fix apply exactly to this use case.
https://www.cve.org/CVERecord?id=CVE-2026-29518
Requires daemon + no chroot. " daemon runs with elevated privileges. This vulnerability can only be triggered if the chroot setting is false."
So the workflows affected are those which are the most vulnerable, and yet people are recommending that people revert versions.
* Furthermore, if a regression test picked this up, it would've been written previously.
> 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.
During an emergency situation where an issue is running out of control, the priority is to evaluate and contain the problem then address it, it is not the time to assign blame and quote regulations which weren’t followed. That’s for later, when everything is stable, together with understanding why the rules weren’t followed and if you can improve that process for the future.
One of the issue comments says:
> Just because you are giving free soup to the homeless, doesn't mean you can piss in it.
But I also think Diogenes would look at this whole situation and start flinging his own shit at people only to say "What, I'm participating in the same way you are" when called on it.
I RESERVE THE RIGHT TO COMPLAIN, WHINGE, CRITIQUE, GET MAD AT, OR OTHERWISE COMMENT ON ANY AND DECISIONS, COMMITS, PATCHES, MARKETING, OR OTHER DECISIONS MADE BY THE PROJECT. THESE COMMENTS COME WTH NO WARRANTY FOR FITNESS FOR ANY PURPOSE, INCLUDING THE IMPLIED WARRANTY OF BEING CORRECT, USEFUL, OR KIND. SHOULD MY COMMENTS PROVE UNWANTED, YOU RESERVE THE RIGHT TO STICK IT WHERE THE SUN DON'T SHINE.
Feel free to print out this disclaimer so you have a copy to reference whenever you come across unwanted criticism of a foss project.
I really don't get how people don't realize that this "they can do whatever they want" stance cuts both ways. Users can do whatever they want as well. If they don't like something, they can express 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?
And yes, I debugged one of the issues. I made the second comment in one of them. Markus Mayer did some debugging, too.
Then I had to deal with something completely unrelated to computers for the rest of that day and several days thereafter, and came back to this.
The problem with compiling code that used new kernel features was a bit poorly done. Anyone with any experience knows that a simple #if defined(__linux__) , which is a platform test, does not cut it for feature testing. M. Mayer went with an autotools test, which is what I'd have done too.
The problem with the on-the-wire protocol is a tricky one, and caused by suddenly being conservative in what rsync accepts apparently without much testing of what out-of-range stuff in-the-wild rsync sends.
I've seen this behavior before only in places where people post memes and other entertainment content.
No actionable bug report/feature request. No text version. Not even a link to the original post.
Did the person who posted this mistake GitHub Issues for their personal Twitter account?
The actual Claude "churn" is mainly test suite enhancement.
Whilst a lot of the Claude changes are test related, there were still other changes that obviously broke things for people - and who's to say that some of the testing changes may not have thinned out the testing too given one commit "rewrote all shell tests in python" with over 4000 lines added and removed at once. And even after all that Claude churn on the testing, these breaking changes obviously weren't caught by tests, so it's not exactly an "enhancement" from the end user perspective.
Go use Debian if you don’t want to deal with breakage.
This happens frequently when there are fixes for CVEs, since regression tests can't catch many things which incremental rollouts can. It happened for example in 2025. People are right to imply the reaction is totally outsized here, and it's almost certainly the case that people are overreacting to AI (rather than the somewhat weak idea that it's because of the frequency of these issues).
What's really funny is that the people opposing AI here are showing far less literacy than those who wrote the code. People claiming to be affected by this bug severely are likely exposing themselves: * One bug is for Linux < 5.6, where it didn't hit distributions. This is a low severity bug where it can't build, where distribution maintainers may be reasonably expected to fix it themselves (although rsync will also fix it eventually too).
* The other bug affects precisely the people impacted by the CVE https://github.com/RsyncProject/rsync/issues/897
You probably don't want to revert in this scenario. If someone is hit by this bug and is running rsync in an automated manner, it is highly likely they're ignoring very many security practices: you're usually not supposed to run native rsync in an automated manner (the main use case is for public users, where you can't SSH etc; since it's unencrypted, you're supposed to check a checksum against a website etc); these cases are hit with chroot false, which is deeply discouraged and leads to far larger attack surfaces.
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.
> Just because you're giving free soup to the homeless doesn't mean you can piss in it
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.
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 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.
Write some code and then ask Claude to diff your changes and write a commit message. Now the internet hates you
I am nothing but grateful for Samba and Rsync.
Wow.
1: https://github.com/RsyncProject/rsync/issues/929#issuecommen...
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.
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.
Also it's why we need to pass things like medicare for all and universal childcare to give workers some breathing room if they want to change jobs/industries without condemning them to death or poverty.
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.
When I first saw the 26k changes statistic I was shocked. It made me think a large chunk of code running on people’s machines was AI-generated.
But the knowledge that a lot of the changes might be testsuite changes made me change my perspective. If for instance 25k of the changes were test changes and only 1k of the changes actually affected the .so and other artifacts used downstream, that would be a lot less dramatic.
I haven’t reviewed the code, only the messages, so I don’t know if these changes were removing or adding test cases. And there are a minority of Claude-assisted changes which are not listed as tests.
I'm sure it can happen, hence why I said to keep an eye out. Its main mode of operation is not to cook the tests however.
Our team was doing a similar task to move between test frameworks, and I had to do a git diff of hundreds of thousands of lines to try and work out where a test had disappeared to.
Your fault. You should have used a model from 0.000005 seconds ago!
What change? That you should not fake the results of a test because that defeats the whole purpose of a test has been known before there were computers.
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 is not being vibe coded, and it’s not become slop so would love to understand the position.
A backup tool that doesn't do backups properly is less useful than one with a CVE that might be exploited if the stars align.
They should post the text directly rather than a picture of the text, and it (and the issue title) should describe what is not working in the correct details (in this case, they do provide a few details; it says incremental backups are not working correctly when using multiple --compare-dest= arguments, and it mentions which version does work).
If they are also opposed to using AI/LLMs to program this, then they can mention that as well, but by itself it is not a proper bug report; they have to indicate what (if anything) is wrong with it (whether or not they used AI/LLMs to program it).
But I'm not a sure a human on their own would've done better. There aren't enough resources to make the changes required.
The volume of code, addiction to said volume of code, and fact that the vibe coder may not have read it basically makes review impossible both logistically and in that IME it seems to upset the vibe coder to even suggest that it's fine to take a bit longer and do something good as opposed to some overfit mess.
It might be that we look back on this as like trying to review the assembly output of a compiler but I don't see it that way at the moment.
1) identify something as AI-produced
2) attack and ostracize anyone who might be involved in that production
And as with all moral panics, whether (1) is factual is totally beside the point. The point is the almost sexual release you get from (2).
I know in this case there is AI-produced code in rsync (as there is with most useful software by now), but you see the witch-hunts every day online and as with all witch-hunts it really doesn’t matter whether the accusation is true. The hysteria is the point.
Upon further reading, you use emotional language too - “witch-hunt” and “hysteria”.
Are these witch-hunts? And can you tell if people over the internet are nearing sexual release?
Are you responding to emotional language and other’s loose thinking with your own?
the anger that's showing up around ai isn't a matter of the masses being misinformed, or the messaging around it, it's a matter of physics. you have this one thing that is being used as an excuse to lay people off en masse, you have tech ceos near daily saying they're gonna come for everyone else's job too, and you have the hyperscalers taking up every bit of oxygen in the room. not even gaming has been safe.
taking the attitude that it's "just such a classic moral panic" is figuring out which way the ocean is receding and running headlong toward it.
Isn't it though? let me quote my other comments in this thread:
> There is undoubtedly AI-written code in the Linux kernel now, but are they out there harassing those maintainers? No. rsync GitHub is easier to brigade.
> They’re also all completely disingenuous (“I’ll have to stop using rsync now”) given that 99.99% of software now includes AI-written code
This is why I call it a moral panic and hysteria. It's not reasoned, considered opposition to AI. The people on that github thread are totally disconnected from reality - it doesn't matter to them whether the accusations are true, it matters that the accusations have been made, and against an easy target that they don't expect fight-back from.
If they really just had a considered moral opposition to AI-generated code, they would be out there harassing Linus Torvalds himself. Are they? No. Because it's just a moral panic.
source?
I hear these complaints multiple times per day. Not just "nearly daily". The backlash has long since drowned out the original source. The ad nauseam anguish has been steadily increasing for months.
I almost prefer to listen to asshole CEOs at this point. At least they have more to say than just repeating these same points.
Being dismissive of AI panic is healthy. What you're engaging in is not.
But neither the original post nor the majority of the responses are productive, mostly due to the acrimonious language used.
It's also just a completely random accusation. I experienced a bug; the software contains some amount of AI code; that must be the reason. Because there is no other way bugs are ever made. Bugs only came to life in 2023 with ChatGPT. No need to look at the actual code, see if the bug is in an AI generated part, judge the quality of the code, whether it's just large chunks of AI generated code taken as is or small parts of carefully chosen and moderated code where the AI only does busywork but the maintainer outlines the structure and understands every part of the code.
By all means, if rsync is full of low quality AI slop that causes bugs that would otherwise not exist, give some actual evidence for that and criticize it. But that is not <edit>~~what's happening~~ what people are doing</edit> here.
In the thread someone found the bug and it was AI generated. But even if in this case it wasn't, if the introduction of AI and bugs are correlated it's a problem even if not every bug is caused by this. Stability everywhere seems to be getting worse, we have supply chain attacks everywhere, and if the bar for stopping this is throwing out 40,000 lines of generated code and shouting "show me the evidence" for each instability, then it's time to wonder what "maintainer" means if they are no longer the ones responsible for it.
Of course the report was engagement bait, but it's useful. Before this I was not aware that I need to wonder about rsync updates and now I am. It was one of my most trusted pieces of software, and now it's not.
That's exactly what's happening here. The tone of the issue was immature, but there is a legitimate problem that cannot be brushed away as "anti-AI". The real issue is the irresponsible use of buggy machine-generated code in a project that many people depend on. Users are pissed and rightly so.
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.
As an example, the entire test suite was recently vibe-replaced. An essential component for reliability and stability. And you can already see the results in the decreased stability and increased defect count.
It was (and is) not: rsync has over 300 open issues with bugs and feature requests.
2. Of course bugs should be fixed. I even say so in the comment you replied to. You are attacking a strawman.
3. People will always make feature requests. Some want rsync to be able to make a sandwich. That is not really in-scope for the project though.
I think the GNU coreutils are doing this largely right. New features are almost never added. ls, for example, is pretty much complete, and too foundational to mess around with. If you need fancy new features, use something like eza.
If you think that fixing security issues is "unnecessary changes", maybe.
Though maybe security is not "in-scope" for you?
> That is not really in-scope for the project though.
Why do you decide what is in scope for the rsync project and what not?
Apparently the maintainer disagrees and also wants to fix existing security issues.
> Why do you decide what is in scope for the rsync project and what not?
If you are arguing for making sandwiches being in scope for rsync, you proved that you are just a troll. We have reached the end of reasonable discussion.
Perhaps there's people that don't consider it complete software; they can bear the burden of the new releases while you stay on the old and complete one. This has been normal software release and use practice for decades. Whole Linux distributions are built around different philosophies on software releases.
And yet you're making an argument as if this is something novel...
Until then: It's interesting to see curl vs rsync in this space.
Both have been hit by AI bots (or attempts to write/debug code by llm or raise llm bugs), but its interesting to see how the curl maintainer handled this vs how rsync is being affected.
The significant thing that will result from this is private issue lists and disabling open PRs. and then you’re worse off as an ai sceptic.
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.
this isn’t even a “new” problem. if you were around in the early 00s or before you probably worked with a BOfH sys admin that didn’t let you update system packages. that person cared deeply about system integrity and enforced it with policies around package managers.
having outsourced all of that stuff over the years to the cloud, it seems like people forgot this reality existed and can still exist.
the mob freak out is really a projection of a skill issue and it’s sad.
I don't know what sets this kind of thing off, maybe it's not predictable, but it's never ok.
I'd like to hope in a few years those people will look back on their participation in this particular brigade sheepishly; but sadly it's more likely they'll have forgotten about it by morning.
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.
Ah yes, we couldn't write bug-free software so now instead we take on the much harder challenge of reviewing code instead. That will surely work out.
If a maintainer just accepts any code, without review or control, humans, just as well as "AI:s" can submit crappy code.
I can only conclude that this is some kind of misplaced frustration due to job protection and feelings of insecurity that makes people this polarized and religious.
The whole point here is that it wasn’t. That’s the whole reason the submission exists, that allegedly bugs were introduced where it was previously working.
> I can only conclude that this is some kind of misplaced frustration due to job protection and feelings of insecurity that makes people this polarized and religious.
Be careful with assumptions. You are basically expressing that the people you disagree with have petty negative reasons to think how they do. That’s not empathetic and it’s colossally misinformed. I recommend you attempt a good faith search of the myriad reasons people may be against LLMs. Here’s a good faith question on HN to start:
The current ones I see are: * Can't build on Linux < 5.6. But people aren't complaining strongly about this, since it requires a build from source / isn't a result of an update from a distribution (and people can wait for updates / implement them themselves). * An issue hit with chroot false + daemon. People running this in an automated manner (as some claims suggest) are already using it in a way fairly likely to be insecure, chroot false is strongly discouraged here, and the whole point of these commits was that they fixed CVEs impacting precisely these people.
Personally I don't think it's any more ridiculous that the amount of money currently being burned to convince me that I should use more AI in every aspect of my life.
Nobody. And in that hypothetical situation that post wouldn't have been written, wouldn't have been posted to hackernews and you wouldn't have had anywhere to write this comment.
> I can only conclude that this is some kind of misplaced frustration due to job protection and feelings of insecurity that makes people this polarized and religious.
LLMs are statistical machines and revert to the mean. I suspect that people's general opinion of how good AI is at a task mostly depends on whether or not that person's ability at the same task was around average
but i think you meant: tag all code repos as unsafe, because you assume all code is unsafe, and 1. i don't fully agree with that, and 2. that's half of my argument. 1. historically most languages bootstrapped their compilers with one of those, some eventually reaching the selfhosted milestone (ex: https://go.dev/doc/go1.5#implementation). 2. tagging repos with `unsafe code`, or if you prefer to stay with original `maybe vibes` tag, implies you have some level of confidence in the tag you are applying, and that you also can back that tag with some common understanding of its meaning. i do not think we have established what `vibed` or `ai coded` actually means. some know what their personal definition is, but it is not a shared understanding of the definition.
as matter of non-exhaustive sampling we currently have vibe coded and ai code, ai co-authored and ai completions/suggestions, and ai aided. which one should be picked? nevermind the term ai is fuzzy, but how do you even begin the process of classification? a process that by it self, is likely to use more of the dreaded ai technology. where would github draw the line for this tag, such that it avoids backlash from users?
pick your broad strokes: llm generated with no human revision; llm generated with human revision; llm wrote large parts of the change set, but a human made adjustments; lm generated small snippets — implying the contributor accepted the suggestions, llm aided with codebase understanding (RAG); lm picked symbol completion and types; ml model used for refactoring suggestions.
for github the question† is: what is important for a user that sees this tag? what does the user care for? how does that affect their decision process when considering using, or participating in a project.
there are much more interesting questions, than wether a repo accepts vibe coded contributions, still not easily answered. show me: total lines of code, or a ranking per language (only a percentage is currently displayed), code complexity stats, code churn, merged pull-requests vs total pull-requests, avg reviewers per pull-request, merge pull-request non-members vs members, mtt member reply on issues, mtt member reply/action on pull-requests, or split that between merged and non-merged pull-requests
† also github has been absorbed into a large proponent of ai, microsoft
You are perfectly capable of saying "No, I like the color of my house already". Just pin rsync's version. This isn't some esoteric mechanism, it's standard practice.
If you were actually willing to charitably engage, tidge was working on fixing security bugs - your house had holes in it already! Your choice was to say I'm fine with the existing holes, or yeah please try to fix them. Unfortunately while fixing them he introduced some new ones, but hey, that's the nature of software development - sometimes you introduce new bugs when fixing old ones.
Again, this isn't some esoteric happenstance. It's so banal it must happen thousands of times per day across many other maintained projects.
Very bad advice these days.
… 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!”
That's exactly why that "point" is inherently nonsense. It's right there, you just wrote it yourself. If you lump people together "as a group", and some of them have different opinions on something, that doesn't make any of them a hypocrite. And the group can't be hypocritical either, because it's just your abstraction, not an actual group that communicates and coordinates and decides what "official" stance to take on certain issues.
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.
Tools are wielded
If you make a mistake wielding a tool, it is your mistake
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?