Hacker News new | ask | show | jobs
by thevinter 20 days ago
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.

7 comments

> I think this behavior is very silly and people are just trying to justify their hate to AI by latching onto every possible thing

It's not silly to have issues with something. People act on their issues. Possibly not the issue underlying the commit at hand here but something else, and act on it which makes it something to consider. My guess is people are tired of the "AI is the greatest thing since [cultural reference]" being forced down their throat and grasp at every straw to combat it, which is a sane response in my opinion and should be taken into account.

> and grasp at every straw to combat it, which is a sane response

Attacking every open source maintainer who might use AI for the sin of having used AI because one hates AI is just abusive behavior, not "sane response".

What would the "sane response" be for people tired of the "AI is being forced down my throat and I need to combat it by attacking open source maintainers" side? Grasp at every straw to combat such behavior?

It looks like they’re being attacked because their mission critical software is suddenly experiencing regressions, and the evidence suggests those regressions are in part caused by AI.

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”.

Their mission critical software has bugs in it - security issues, which the rsync maintainer is trying to fix. In his attempt, he introduced regressions*(maybe - because some of the reported regressions list exactly the security issue that is being fixed as their use case...). This happens every day to thousands and thousands of software projects. This is why we have pinned versions, release schedules, different release philosophies...none of this is new.

I don't understand what novel problem you think you've uncovered here.

I thunk you are right. This is just the same old stuff. I think people are reacting because AI is doing something, and that something seems to be accelerating the process of software development. So what people are seeing is the same issues we have always had compressed into tiny time frames.

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.

> 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".

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 absolute bulk of the LOC introduced are docs and a unit test system. Let's not just make stuff up now.
> It's not silly to have issues with something.

I absolutely understand and agree. As I said, I understand the underlying reason.

The silly part is the brigading - issues should be adressed on their own merits. The specific GH issue, and some of the comments therein, make the whole crowd they're affiliated with look bad. (imho)

I'd argue there would be two lanes as well: one where the issues are addressed in code, the other being the discussion of why people think this is a bad idea and speak so openly about it. This topic is the second I guess. Looking at the flow there is quite a bit of flamebait by the LLM and non-LLM camps which only muddies the water and doesn't resolve anything. The better discussion (imo) would be to decide if the vide coded fixes are worth it and if not, fork the project somewhere and let the distro's chip in to maintain that.
idk maybe LLM people should only commit what they actually understand, only in bite-size (maximum few lines in few files) and with at least 1~5 tests that shows the edge cases

drive-by 20-file pull-requests that ultimately end up costing maintainer's burden seems to hit hard here.

They’re just picking easy targets to bully. 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.
> There is undoubtedly AI-written code in the Linux kernel now

You can grep commit logs by “Assisted-By” these days and there sure is a whole bunch of LLMs.

> 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.

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.

> this is just a regression that occurred during regular software development

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.

>regression happens

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?

What does your strawman argument about a hypothetical regression in SQLite have to do with this? What would a regression in the Windows Calculator have to do with this? What does your whataboutism prove here? Nothing.

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.

> positive collaborative environment

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

> It's not silly to have issues with something.

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.)

The way it is done with meme pictures is bizarre. The language used is the same that Tridgell knows from the LKML, so that is not the primary concern.

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?

yes, you should, you have no say in how people develop their software.

submit a bug report if you like, but keep your opinion away from issue trackers.

I agree. Like everything else open source, fork it if you’ve got a problem with it. Vote with your code.

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.

How are the maintainers supposed to know that the users don’t trust VS Code if no one voices their concerns like a rabid mob? Seriously why should the maintainer care what users think about how they produce code?

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 only thing AI and VS Code have in common is that they are both tools. But thats where it stops.

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.

If you look through that thread, it’s very clearly an online hate mob whipped into a frenzy by someone on mastodon. They should all go back to mastodon and reddit and stop bothering people who actually work on important things.

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.

AI has become a partisan political issue with all of the attendant consequences. At this point you may as well complain about the sun rising in the east :(
I'm not sure how partisan it is but it's certainly politicized. Regular people also weren't the ones that politicized it. These AI companies knew the risks they were taking on when they donated to Trump, bought out local city boards, heavily invested in lobbying campaigns, etc. They are betting that the federal government will protect them from the consequences of their meddling by positioning themselves as a geopolitical priority. Claude has already been used to plan and prioritize targets in Iran

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.

And all this has nothing to do with whether Claude+Tridge is better than Tridge alone at writing code for rsync.
Clearly it does. Look at the thread we're in.
I haven't decided where I land on this idea of pointing llms at mature, human-crafted software projects (again, assuming they are moderately mature projects).

It's clearly a win for 1-man projects and greenfield projects, but maybe not for what's described above ...__yet__.

I think people are very justifiably angry that a very stable, well trusted tool, has started to immediately go downhill. The Linux Mint Timeshift tool has an issue open documenting a number of regressions that are currently open on the rsync issues page, that were only introduced post-vibecoding (https://github.com/linuxmint/timeshift/issues/548), one of those links goes to a larger aggregate of bugs reported downstream (https://github.com/void-linux/void-packages/issues/60825). I think it is incredibly rational and sane, given the reputation of vibecoded software as-such (where every professional who loves it is saying "you have to hold it in this very specific way so it doesn't cause bugs, and also you should probably only use it for version 0s so you can map out the domain"), for people to be angry that their load-bearing industry standard backup tool that is very, very well respected is suddenly pulling the rug out from under them because the maintainer wants to "add more features" and is doing it in what is clearly an unsafe way. Also from the timeshift thread:

> 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.

> The Linux Mint Timeshift tool has an issue open documenting a number of regressions that are currently open on the rsync issues page, that were only introduced post-vibecoding (https://github.com/linuxmint/timeshift/issues/548)

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.

https://en.wikipedia.org/wiki/Brandolini's_law

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.

I don't know how deeply you read into it, but people pointed out that Claude rewrote the entire testing stack in Python. Worse than that but it rolled its own unique framework. Every test file will randomly redefine its own `_run_and_capture` function

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...

If the 7 issues three are the same underlying issue. Another two at least relate to the same commit and probably the same underlying code. One is not related to a Claude assisted commit. That leaves three that are.

Adding that to the two in the issues further up, that makes a total of five bugs in AI assisted commits.

> I think people are very justifiably angry

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. )

> The Linux Mint Timeshift tool has an issue open documenting a number of regressions that are currently open on the rsync issues page, that were only introduced post-vibecoding

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?

Exactly this. The most salient comment basically said that AI use has increased the cadence of commits beyond reliable testing capacity for what was a stable product in equilibrium. It isn't an issue specific complaint so it wouldn't make sense to only flag one specific issue. In fact you'd fall behind trying to chase the AI moving head. This has everything to do with AI, and isn't a normal issue reporting situation. The other camp seems highly defensive, which reeks of indefensibility.
Would you know anything about stable forks for rsync that are not affected by performance quality degradations?
> seemingly forgetting that before AI people did mistakes as well.

It's just that they now have the chance to do them 1000% faster and not even realize

Averse behavioral ai syndrome