[koehler]

I truly don't get it

You have a rock solid piece of software used by an infinite amount of people and other services. It works fine, does it's job and just have some time to time updates due to minor bug fixes.

Why do we need AI here?

And more over, why people is saying "fork it and use the previous version". It should be actually all the way around, create a parallel fork younamethetool-ai and keep the OG untouched.

What I have to do now, keep a fork of my entire system's toolkit?

[helsinkiandrew]

> Why do we need AI here?

As several comments in the issue mention, it's up to the developers that contribute to an open source package to decide how they do it. Complaining on an issue tracker (apparently without proof) about AI ruining a piece of software is a form of "Open Source contributor abuse" discussed frequently on Hacker News [1]

https://github.com/RsyncProject/rsync/issues/929#issuecommen...

> The issue tracker is not a place for you to farm viral social media posts. Either report an actionable bug or fork it yourself. Venting about the developers choices is not productive.

https://github.com/RsyncProject/rsync/issues/929#issuecommen...

> @II-Paulus-II Stop. You know nothing. You have shipped 0 features by hand. No one has ever depended on your code. You are a finger-wagging "AI wrote this" type in an era where you hide in plain sight coasting on the moral high ground of writing toy projects and scripts from scratch. Can't ship, can't adapt, can't even realize that an issue tracker is not the place for this kind of attitude.

[1] https://news.ycombinator.com/item?id=43077833

[ddosmax556]

I agree, if I was the maintainer this would be an extremely tiring community feedback.

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.

[ruszki]

I don’t know the details of this exact instance, but saying that there are reliability issues is a valid feedback if reliability plummets.

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.

[ddosmax556]

Yes, reliability plummeting is valuable feedback, but it should be framed as such, and not attack the maintainers descision to use agentic tools to write code, and especially not in that high nose way with an undertone of: What you're doing is obviously wrong, did you even think?? Everyone here knows it, are you stupid?

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.

[pishpash]

If the maintainer used any other tool which is suspected to cause a number of recent problems, it'd be discussed. The tone is a problem but the reaction is equally problematic. It isn't even clear the maintainer hasn't been silently changed if agents are used, depending on the extent. That itself is worthy of discussion, and "maintainer decision" is not the right call in that situation. One comment basically insinuates that with instructions for AI, though it was written as a trollish joke.

[ddosmax556]

It can be discussed but not like this. The tone is problematic and results in the reaction. You're basically saying: I found a few bugs and I saw that you use tool X, thus you're now not worthy of maintaining this software without my supervision. Which is tiring if the initial report doesn't even show what exactly was wrong, or if something was wrong. It's just a feeling of: something doesn't work for me; I don't like AI tools; I see you're using AI tools; therefore I now tell you that you're not capable of maintaining this package, and I have to intervene. Such a stark comment must be done on more than just vibes and feelings.

[baliex]

I 100% agree with the "please don't fuck up this stable & reliable workhorse" sentiment.

I haven't read this in detail but "Six CVEs are fixed in this release. All six are assigned by VulnCheck as CNA. Affected versions are 3.4.2 and earlier in every case." seems like a pretty solid answer to the "why".

https://download.samba.org/pub/rsync/NEWS#3.4.3

[mattbee]

But there's been security fixes in most releases of rsync!

Even then, why would a security fix be some kind of strike against AI? We've all seen LLMs being used to tease out the most serious and obscure bugs in C codebases. I'd expect to see a lot of security fixes for an ancient, well-used codebase when an LLM analyses it.

Where is the slop commit here? And why is that commit evidence that tridge has lost his mind to the machine? https://github.com/RsyncProject/rsync/commits/master/

[izacus]

The part you're missing is that those "fixes" broke a lot of existing functionality.

[androolloyd]

Bugs are bugs and need fixing. How dense can people get.

[hdgvhicv]

Regressions are bad and need to not happen.

[krcz]

Regressions are bad and they should be avoided. Still, software engineering is a complex thing and regressions happened long time before coding agents were a thing. Unless one can pinpoint regression to changes that were more sloppy than the human-written rsync commits were I don't think coding agents are to blame.

[Lerc]

Would you hold off on fixing a security vulnerability if it caused a limited regression?

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.

[dash2]

Parent is agreeing with you.

[dnh44]

I feel really bad for the sense of entitlement a lot of open source devs have to deal with. Imagine building something for free as a hobby then having to deal a mob of angry people who have never paid you whenever you do something they don’t like. Surely your first thought would be to tell them to foxtrot oscar somewhere else.

[jech]

That's not my experience. Users naturally get frustrated when I break the software that they rely upon, and sometimes they use strong words, but the resulting conversation is almost always friendly and productive. (There are exceptions, of course, but that's life, right?)

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"

Source: https://github.com/jech/galene/issues/309

[dnh44]

Yeah that makes sense. People will be often more polite when they realise there is a real human on the other side.

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.

[lukaslalinsky]

That's up to the maintainer to decide, no? If they decide to use AI to write more tests, then they do it. It's not like they owe the public something. If the "public" wants to take the project over and maintain it, they can fork it, but it's a thankless job.

[bigstrat2003]

Sure, it's up to the maintainer. But it's also not unreasonable for the users to say "this approach is going to have problems, please reconsider". Obviously, you can take that too far - and the Internet being what it is, we would expect to see that happening a lot of the time. But it's not inherently unreasonable to ask the maintainer to reconsider his approach.

[akerl_]

Why would it be the maintainer’s responsibly to fork their own repo? It wouldn’t even make sense; who would maintain the old repo?

They also don’t need a reason, or owe you their reason, for changing what tools they use to work on their open source projects.

[pishpash]

Autonomous agents are different. Claude should fork the repo because it is a new maintainer trying to take over a project. Doesn't matter if the OG maintainer is under illusions.

[akerl_]

There’s so much to unpack here, but let’s say I grant your premises that AIs are equivalent to people and Claude is making its own decisions about the project and the OG maintainer has ceded control of the repo to Mr Claude.

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.

[pishpash]

It depends on the circumstances. Maintainers can do whatever they want, theoretically. Practically, there is implicit community involvement, otherwise a project dies as people abandon it. Right now it isn't even acknowledged what is happening.

[akerl_]

I think you may be confusing popularity with existence.

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.

[pishpash]

By that account an open source project never dies because the code is there for anyone to improve upon. Why does anyone care if one particular repo realization of some useful idea or its maintainers are around or not?

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.

[soerxpso]

Why do we need any tools at all? Software worked perfectly fine when people were editing code with `ed`, so I'm going to go open timewasting issues complaining about FOSS devs using an IDE.

[sarlalian]

Because all software has bugs, because the system underlying that software changes and you need to keep up, because for some people it’s just missing that one feature or doesn’t work quite right in that one edge case. I’d bet that there are issues in the backlog with people’s complaining that their issue isn’t being addressed quick enough.

Is AI the problem, or that it had a regression? Is the regression actually caused by AI?

[Quarrel]

wtf is this comment section?

The author of these commits were tridge & claude.

What does tridge have to do to convince the open source community that he might be a legit programmer & have a clue?

Samba? Whats that? Rsync? Never heard of it. Tivo? No clue (maybe more Australian context here than others, but still).

Even the comments on the github issue, are totally devoid of the context that this is a very senior open source contributer who has maintained this project since he came up with the diff algorithm during his Phd, started the project and now chooses to acknowledge that he's using claude.

Is there any evidence that the bug rate on rsync is any worse than it used to be? or just a screenshot from mastadon?

It is just so bizarre to me.

[oytis]

I'm not sure about tridge personally, but I've regularly seen real competent engineers introduce obvious hallucinations when using coding agents. Review fatigue is real, and you just cannot own the code you didn't write to the same degree as the one you wrote

[watwut]

My consistent observation is that seniors who do only or mostly code reviews for several months end up making worst and worst code review. They nitpick thinks that dont matter more and more ... and miss big architectural issues, maintennability issues and bugs more amd more.

There is no reason to think reviewing AI code more then writing own wont have the same effect.

[ShinyLeftPad]

> this is a very senior open source contributer who has maintained this project since he came up with the diff algorithm during his Phd

People change. You can be Linus Torvalds for all I care, if one day you wake up and start pushing 9000 line commits created by LLM and with regressions, you're not that person anymore.

[Eufrat]

Also, a real example is Steve Yegge.

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.

[Quarrel]

But DID anything change?

Of course I know that some people can just becoming psychotic out of nowhere. But why would I assume it?

[ablob]

According to the thread rsync broke for incremental backups and increases the cpu load heavily. The whole thread only started because people noticed regressions and were wondering what happened.

Since I quite a few users are using distros that won't update for a while it gets even better: this trend may continue and as soon as the update actually happens we'll be so far down the road that it will be too late to take a step back and reconsider due to the delayed feedback. This is pretty much about the few people _already_ having issues with it.

That being said, if the creator wants to use AI to work on the project they are free to do so. I just hope nothing of value is lost because of it.

P.S.: If you stop writing by hand and start delegating - to AI or other people - something has changed. There shouldn't be any discussion about it. Delegation is different than writing it yourself.

[yw3410]

Yes, according to the git diff and the comment here https://github.com/RsyncProject/rsync/issues/929#issuecommen....

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.

[ShinyLeftPad]

Do you think LLM use is evidence of psychosis? I think it's a widespread problem but probably not psychosis.

[pojzon]

At least once a week we have a post on HN about CEOs having AI paychosis. Maybe there is something to it.

[ShinyLeftPad]

I like the term paychosis

[izacus]

> Is there any evidence that the bug rate on rsync is any worse than it used to be? or just a screenshot from mastadon?

There's plenty of evidence that rsync 3.4.3 has broken a bunch of features like incremental copies, yes.

Which is why your post is a great proof of how AI derangement can make previously great engineers output broken dangerous slop.

[thevinter]

Has rsync never broken features before, without AI?

[fg137]

Have features been broken in patch versions?

[izacus]

I don't remember of any examples, no. I'm sure you can use your clanker to answer that though and also plot out the number of occurences.

[otabdeveloper4]

> Why do we need AI here?

AI psychosis is a real thing and an actual mental health issue.

[pibaker]

The only psychotic behavior I see in the linked issue comes from the anti AI people.

[rf15]

funny speculative question: psychosis is evidently a gradient. Does AI just highlight latent general psychosis (i.e. in the simplified interpretation of a worldview shaped more by unchecked belief and fantasy than observation) in otherwise largely functional people?

What if the problem is that we train people too much to take things that are being said at face value without questioning/observing them, increasing the psychosis problem?

[ethbr1]

Everyone is susceptible to addictions or psychosis to some degree.

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.

[xnx]

Similar to anti-AI derangement

[nbaugh1]

It really is an odd feeling to be in between the 2 extremes

[ethbr1]

The problem is that both camps take their positions as religious righteousness, which lobotomizes their abilities to have productive, pros and cons discussions about matters at hand.

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.

[weakfish]

take heart knowing at least I'm there with ya.

[otabdeveloper4]

No. There is no "anti-AI derangement", the reaction to slop is normal.

[akerl_]

Spamming an open source developer with angry comments because they decided to use a new tool for the code they write and publish freely is not normal.

[dragontamer]

This is rsync we are talking about. A bug in rsync basically means lost data and/or unreliable backups.

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.

[lukaslalinsky]

The thing is, showing the annoyance to the volunteer, who is already doing their best, has two possible outcomes:

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.

[akerl_]

> Maybe it's not socially acceptable to spit in the face of a volunteer

Why are you hedging this? Do you think maybe it is socially acceptable?

[otabdeveloper4]

> because they decided to use a new tool for the code they write

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.

[watwut]

You might want to use different term. After all, Trump derangement syndrome turned out to be "people who actually listen to him and say truth about him".

X-derangement thing is not used in reference to people whobare wrong or lying, but in reference to people who are making correct observations

[nottorp]

> Why is there a need of AI in here?

For the same reason as some people would rewrite it in Rust.

[mike_hock]

No, that's usually to decrease the number of bugs and vulnerabilities.

[lelanthran]

That's not why people rewrite in Rust.

Rewrites brings new bugs regardless of the language.

[Matl]

You're conflating why people want to rewrite it in Rust vs what is the likely end result i.e. I do think people want to rewrite things in Rust because they believe long-term it will mean fewer (memory safety etc.) bugs especially because there's been almost no meaningful improvement in this space for a long time. But of course in the short term it will mean regressions compared to the established C written version.

That is different from AI where the calculus seems to be that if AI isn't involved, it aien't relevant.

[lelanthran]

> I do think people want to rewrite things in Rust because they believe long-term it will mean fewer (memory safety etc.) bugs

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!

[Matl]

> if that were true, the large portion of code now being rewritten in Rust wouldn't be vibe-coded slop.

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.

[reverius42]

Does an AI rewrite in Rust cancel out?

[nicoburns]

That remains to be seen, but my guess would be that if you do it like Ladybird (with human-in-the-loop and a decent level of review) then probably yes, if you do it like Bun (1M LoC in a week) then probably no.

[My_Name]

I did recently read an article about how, due to better training data, an AI writes better code in Rust than most other languages.

How that translates to the number of bugs, I don't know.

I would think that existing bugs would be caught, but new bugs would be introduced. The problem remains, but at least it has a new name now.

[dnh44]

I’m developing three codebases right now where all of the code is written by AI (Swift, Python, Rust) and the Rust codebase requires the least pruning and has the fewest wtf moments.

[hazbot]

I suspect it is the feedback from the stricter compiler, not differences in training data between python and rust