Hacker News new | ask | show | jobs
by theonemind 26 days ago
I find the way that issue was opened incredible obnoxious, but it is baffling that the maintainers seem to have let AI loose on rsync. Like, why? Why try comparatively experimental crap when your fortune and reputation is made and you're the leader of a niche and immune to market pressure and the people love the thing and it does exactly what it's supposed to and works well?

It's like the Matrix, with the little rant about the primitive human minds not being able to accept paradise. You wrote the perfect tool, you won, almost undisplaceable in a niche, reliable, a metaphorical household name. It makes no sense to anyone to gamble or mess with that, it's just mind boggling.

And that's still a damn obnoxious thing to do in the formal issue tracker. Bad attitude, bad faith.

7 comments

A couple years back, I think I would have bent over backwards to defend the maintainers. It is a gruelling and thankless effort to maintain any open source project, let alone one as established as rsync. I guess I just don't see AI being a net positive anywhere, and I have to see this backlash to using gen AI as a good course correction from the general populous.

There are other posts talking about the instant gratification of LLM use and the more I have to interact with people using the tools, I think this may truly be the problem. Our biology can't handle it. I see otherwise very smart people do really really stupid things because the slot machine told them, but it has even trained them to be helpless when the slot machine fails them.

I'm being seen as a Luddite, blind to the advancement, and then I see colleagues writing benchmarks that make no sense but have beautiful graphs made with AI. Then I basically have to choose to smile at them and pretend it's good work or scold them for not seeing that the bench is testing an interval baked in as a constant so it's moot. Both options are treating them like they are 7 years old, not intelligent colleagues.

> instant gratification

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.

ADHD might be in play, and I think it‘s undiagnosed by more people than we assume. And it‘s fine, because as long as you can deal with it, it‘s not an issue. I can imagine that the addiction to LLM hits the same areas as addiction to, say, gambling, binge eating or shopping. I wrote a small thing about it here:

https://news.ycombinator.com/item?id=48081469

So is ADHD also to blame for "being addicted" to driving instead of walking?

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 was giving OP an answer to their question, as to why the "instant gratification" loop from AI is triggered by some people more than others. It's not about the grin, it's about the "not being in control, and not being able to stop". And if it's only the grin - yeah, hyperfocus is also something that neurodiverse brains have. Not sure what triggered your reply specifically, but I think it is worth stating that there is nothing bad about it, as long as it doesn't become an issue. Different brains work differently. It's just a fact we should accept.
on "a tool should not make you feel good"

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?

> I'm being seen as a Luddite, blind to the advancement

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

That's exactly what it is. It's gambling. Like pulling the arm of a slot machine.

[0] https://neuromatch.social/@jonny/116657411750038515

> I guess I just don't see AI being a net positive anywhere

well, at least you're being honest about your non-empirical biases...

> Like, why?

Because everyone, including this forum, is addicted to the instant gratification of LLMs. It’s pure hubris of thinking you can scan the output and it does what you think it does.

TBH I don't really feel the same most of the time. I give the LLM little chunks to do. I read the code. I think. I plan. I write a bit of code. I have the LLM crunch out some bullshit task like setting up an annoying C repo. There aren't that many moments in building with LLMs where things line up so the AI can just absolutely nail some code and save me a ton of time.
I think a lot of people have a sort of “slot machine” experience with it at some point. You just start firing off prompts on some new project, wait a few seconds, see what prize you got. Then you start doing that over and over just letting the LLM code and code and not even review what it’s doing. It really is like getting hooked on gambling. You’re getting a thrill from anticipation, not the actual results.

This is what I personally consider “vibe coding”, not simply using LLMs or agents or whatever in your workflow

I’m confused by the people that “don’t even look at the code anymore”. I’m looking at the code Opus generates. And I’m glad that I am, because it needs revision.
Absolutely, vibecoding is addictive, agents being able to do all of these hard things that would otherwise take days or weeks to figure out how to do by hand.

It's just another avenue of dopamine addiction, not unlike scrolling TikTok, Reddit, or wherever except vibecoding is disguised as being productive.

> There aren't that many moments in building with LLMs where things line up so the AI can just absolutely nail some code and save me a ton of time.

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.

You know what nearly-mindless, time-consuming task it can probably do better than anyone and free you up to keep on coding?

Deploying and watching CI and looping until it passes.

Are you basing this opinion on the issue or actual evidence? Because this github link, although interesting, is almost completely context free on what the drama is beyond "Claude". The rsync maintainers could be anywhere on the spectrum from the perfect and responsible maintainer to incompetent children and we couldn't really tell.
To me it seems people had actual problems with newer versions. Additionally, a significant portion of the code changed within a very short time frame.

Doesn't matter if they did it by hand or with AI.

I just had the first case of a file not being copied correctly after using rsync that I noticed a few days ago. It was a raw image file so it was visually noticeable, some lines of pixels just went black. It may be unrelated, it may not have even been rsync's fault, but this drama and timing just makes me wonder if I got clauded there.
Related: I'm writing a file-format validator whose first focus is on image data.

https://validate.pics

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.

Do you not do the md5 or sha hashes of the copied zip file?
That's ... what rsync is supposed to do for you.
zip file?...

I was syncing photos from my phone.

> is almost completely context free on what the drama is beyond "Claude"

As soon as it happened their rsync based backup system that was working before started to fail. It says right there.

Why would they roll a new release straight into production without testing it first?
The source code is all right there. An actual analysis would involve a complete description of what you were doing including code they are running proving that what you were doing is reasonable and correct and expected to work. An explanation of what actually happened and ideally the exact commit where it stopped working.

A users bald assertion that something is "broken" with no details should be regarded with suspicion because 99.9% of the time the user is the cause of their own problems.

NOTHING is right there. Nothing whatsoever. No commits no use code no error messages no description. Nothing but dripping contempt for their betters.

Why should a random user bother analyzing the code when the "developer" didn't bother doing the same before committing huge chunks of AI generated code?

The effort put into the issue was roughly the same as was put into the release that caused the issue to be made. Fair is fair.

>the "developer" didn't bother doing the same before committing huge chunks of AI generated code?

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?

I'm sorry, but you're calling the kettle black here. You made up a scenario in your head in which the developer decided to save time by using AI to generate thousands of lines of code instead of writing it themselves, but then also decided to spend time carefully reviewing and understanding said code to look for issues before committing, even though it's a well known fact that properly reviewing such large amounts of code written by others can sometimes be a more daunting task than just writing it yourself.

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.

Fair is fair implies that the user for their no money is somehow based entirely on fantasy to anything at all. They literally aren't entitled to the maintainer reading their email let alone a fix.

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.

Because they actually want something fixed as a long term user of a software.
> Nothing but dripping contempt for their betters.

I didn't see this.

From the comments by original poster on the same thread for instance

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

I read that, yes. I think I'm missing the part where the maintainer is "better".
> Nothing but dripping contempt for their betters.

... and that's how to lose credibility.

They don't make anything and they shit talk those who do
They shit talk those who also don't make but use AI to destroy.
I believe your point is not that it has never failed for anyone in the last few years after upgrade? Then, if the claim is that breakage is considerably worse than it used to be before using coding agents: it is possible, but I think it requires more evidence than a few anecdotes.
The problem is the we couldn’t really tell part. Changes made to mature finished projects should be minimal and readable and understandable by humans.

Also rsync is handling copying binary data, it’s a project that’s super sensitive to hardware faults for example, which means it’s not just enough for the tests to pass.

> finished projects

rsync is not a finished project: it has hundreds of open issues (bugs, feature requests, ...).

"Finished projects" are a mythical thing that rarely exists in reality and even less in actually used software like rsync or the Linux kernel.

We could tell, if someone did independent work of reviewing a sample of the contributions and recent changes (and published in a blog post for example).
I agree about letting AI loose on rsync is baffling, and also that how the issue was filed was incredible obnoxious. A thought crossed my mind though, with the risk of going slightly off topic. Disregarding the fact that mature software like Rsync does not need this kind of movement in changed LOC. Also assuming the maintainers best intentions with how they manage the project:

Since this is happening in open source, what do you think about the state of the quality of closed source software? AI usage (input as a success metric) is part of what you're being evaluated on as an employee, and people are panicking at the threat of mass layoffs due to AI.

Yikes!

you know what is baffling? you commenting about letting loose AI on rsync, where you, and me included, have absolutely zero insight in how he used Claude.

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.

> when your fortune and reputation is made and you're the leader of a niche

Huh? "Fortune"? You mean the slog of maintaining a popular open source project half the world relies on without compensation?

> the maintainers seem to have let AI loose on rsync

is it an assumption ?

Almost all the commits are regarding the testsuite or CI, both of which are IMO great use of AI.
I think that’s misleading. Yes, almost all commits co-authored by Claude lately are about test suite and CI, but that’s just because almost all commits lately are about test suite and CI. The commits which aren’t test suite and CI are also co-authored by Claude. Go a bit further back in the commit history (April 29 onwards) you still see a sea of non-CI/testsuite Claude commits.
Oh and another thing I just learned: it seems like the reason there are so many test suite commits recently is ... Tridge got Claude to rewrite all the tests in Python and delete the old shell test suite: https://github.com/RsyncProject/rsync/pull/903/

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.