Rendered at 17:01:25 GMT+0000 (Coordinated Universal Time) with Cloudflare Workers.
thevinter 7 hours 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.
consp 7 hours ago [-]
> 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.
throwaway7356 7 hours ago [-]
> 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?
5 hours ago [-]
beepbooptheory 3 hours ago [-]
[flagged]
thevinter 7 hours ago [-]
> 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)
consp 7 hours ago [-]
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.
sysguest 6 hours ago [-]
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.
daishi55 3 hours ago [-]
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.
rrrx3 2 hours ago [-]
> 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.
BetterThanSober 38 minutes ago [-]
>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?
5 hours ago [-]
lcnPylGDnU4H9OF 3 hours ago [-]
> 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.)
4asgkl 53 minutes ago [-]
No they don't. They explicitly cite introduction of new issues after the new AI crap was introduced.
You sound like an AI fanatic who wants to occupy the top comment (guaranteed here for pro-AI comments).
If you read the comments in the thread, many are very well written and clearly by software professionals who may hide their main account from the corporate AI KGB. The whole thread is not a classical mob thread at all and the AI fanatics here are just scared by the overwhelming distaste for their expensive laundromats.
mylons 37 minutes ago [-]
what a fascinating take. i just scrolled the github thread. there’s very little, if any substance.
your perception must be very interesting to have gleaned anything but seething AI rage.
123ahsg6 3 hours ago [-]
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?
ejpir 3 hours ago [-]
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.
kstrauser 2 hours ago [-]
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.
daishi55 3 hours ago [-]
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.
fao_ 2 hours ago [-]
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.
pishpash 1 hours ago [-]
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.
potsandpans 40 minutes ago [-]
Averse behavioral ai syndrome
ls612 4 hours ago [-]
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 :(
izacus 3 hours 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.
Are you talking now about the issue creators or the AI pushers which are losing their shit defending low quality slop code that was commited?
koehler 9 hours ago [-]
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 7 hours ago [-]
> 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]
> The issue tracker is not a place for you to farm viral social media posts. Either report an actionable bug or fork it yourself. Venting about the developers choices is not productive.
> @II-Paulus-II Stop. You know nothing. You have shipped 0 features by hand. No one has ever depended on your code. You are a finger-wagging "AI wrote this" type in an era where you hide in plain sight coasting on the moral high ground of writing toy projects and scripts from scratch. Can't ship, can't adapt, can't even realize that an issue tracker is not the place for this kind of attitude.
I 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 4 hours ago [-]
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 2 hours ago [-]
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 55 minutes ago [-]
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.
fzeroracer 6 hours ago [-]
> 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
Sure, the developer can do whatever they want with their open source package. They could also freely ship malware or exploits. That certainly doesn't make them immune to criticism, especially when it starts suffering from critical failures or the results of their changes make it no longer usable in specific environments.
A lot of the comments on the issue tracker are obviously out of line and I imagine a decent chunk is ragebaiting. But I think if people want to continue using LLM shit, they need to be ready to weather ALL criticism that comes with it.
lukaslalinsky 6 hours ago [-]
The result might be closing bug trackers for the core open source projects. Or make them invite only. Even fundamental projects like Linux or LLVM accept AI contributions.
throwaway7356 6 hours ago [-]
> But I think if people want to continue using LLM shit, they need to be ready to weather ALL criticism that comes with it.
And if they don't then too? Because why should they not have to weather ALL "criticism" that comes with writing open source software?
Apparently there are lots of people defending comments that "are obviously out of line and [...] ragebaiting". That sure makes being an open source developer enjoyable!
baliex 9 hours ago [-]
I 100% agree with the "please don't fuck up this stable & reliable workhorse" sentiment.
I haven't read this in detail but "Six CVEs are fixed in this release. All six are assigned by VulnCheck as CNA. Affected versions are 3.4.2 and earlier in every case." seems like a pretty solid answer to the "why".
But there's been security fixes in most releases of rsync!
Even then, why would a security fix be some kind of strike against AI? We've all seen LLMs being used to tease out the most serious and obscure bugs in C codebases. I'd expect to see a lot of security fixes for an ancient, well-used codebase when an LLM analyses it.
The part you're missing is that those "fixes" broke a lot of existing functionality.
androolloyd 6 hours ago [-]
Bugs are bugs and need fixing.
How dense can people get.
hdgvhicv 5 hours ago [-]
Regressions are bad and need to not happen.
krcz 4 hours ago [-]
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.
cbm-vic-20 3 hours ago [-]
Seems like that it's not that coding agents are to blame, its that the people who are ultimately responsible for committing and merging the offending code are to blame, regardless of its origin.
krcz 3 hours ago [-]
Or no one is to blame, if the mechanism of the regression is complex and non-obvious based just on the patch itself.
pishpash 37 minutes ago [-]
Or they are to blame because they misplaced responsibility in a tool's universality to not introduce regressions, even complex and non-obvious ones.
5 hours ago [-]
Lerc 5 hours ago [-]
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.
izacus 3 hours ago [-]
Which part of security fixing demands thoughtless generation of code slop without regression testing though?
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.
Lerc 2 hours ago [-]
I am discussing outcomes, not methodology.
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'
overfeed 46 minutes ago [-]
> ...if it had been thoroughly tested was shown to have certain regressions but no worse security regressions?
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.
Lerc 39 minutes ago [-]
Are you saying that it is irresponsible to test for regressions and to not document the ones you didn't find or that you think it is reasonable to expect regression tests for every possible regression?
dnh44 6 hours ago [-]
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 4 hours ago [-]
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"
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.
akerl_ 7 hours ago [-]
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 30 minutes ago [-]
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_ 24 minutes ago [-]
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.
lukaslalinsky 7 hours ago [-]
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.
Quarrel 8 hours ago [-]
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.
ShinyLeftPad 8 hours ago [-]
> 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.
Quarrel 8 hours ago [-]
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 7 hours ago [-]
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.
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 5 hours ago [-]
Do you think LLM use is evidence of psychosis? I think it's a widespread problem but probably not psychosis.
oytis 8 hours ago [-]
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 6 hours ago [-]
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.
joshka 7 hours ago [-]
[flagged]
dash2 8 hours ago [-]
[flagged]
SyneRyder 7 hours ago [-]
Those posts may not have been visible to everyone. The posts you're referencing are hidden for me behind a link "33 Remaining Items (load more)". Without the update, I didn't know to go look for them.
And honestly I noped out of scanning the entire comment thread by about #5 or #6... I could tell there was nothing productive in the remainder of the comments.
mschuster91 7 hours ago [-]
Actually it is, someone compiled allll the actual bug reports tracing back to AI:
"antisemitism" loses it's meaning if you are using it this way.
mschuster91 7 hours ago [-]
> Then somebody screenshots the geographical location "Israel" to attack another commenter. He gets lots of upvotes for it, too.
And you got downvoted for calling out that crap. A sad state this world is in.
miroljub 7 hours ago [-]
Yep.
When someone does that, he gets rightfully called out.
On the other side, accusations of being Russian trol are pretty common, even here on HN.
Why are people more sensitive to antisemitism than to antislavism?
Double standards, or just a hate induced by decades / centuries of indoctrination?
mschuster91 5 hours ago [-]
> Why are people more sensitive to antisemitism than to antislavism?
Calling someone a vatnik or Russian troll is mostly because the statement that provokes such a callout reproduces Russian propaganda talking points, and Russia has been running propaganda campaigns for well over a decade now. Similarly, ordinary Russians aren't called orcs, but Russian soldiers are called that because of their despicable behavior in the war theatre.
vasac 4 hours ago [-]
[dead]
netsharc 6 hours ago [-]
[flagged]
Diti 5 hours ago [-]
Your opinion reminds me of the narrative about cheaters in the speedrunning community. The cheaters say they cheat not because they feel superior, but because they feel “they could achieve good results if they put in the time”. They feel entitled to cheating.
Quarrel 5 hours ago [-]
Thanks very much for this- I had not seen it.
It does not paint a pretty picture, and I did not know this context.
Perhap the tridge I knew is also of the past, but I hope not.
izacus 7 hours ago [-]
> 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 6 hours ago [-]
Has rsync never broken features before, without AI?
fg137 5 hours ago [-]
Have features been broken in patch versions?
izacus 3 hours ago [-]
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 7 hours ago [-]
> Why do we need AI here?
AI psychosis is a real thing and an actual mental health issue.
rf15 7 hours ago [-]
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 2 hours ago [-]
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.
7 hours ago [-]
xnx 6 hours ago [-]
Similar to anti-AI derangement
nbaugh1 6 hours ago [-]
It really is an odd feeling to be in between the 2 extremes
ethbr1 2 hours ago [-]
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.
watwut 3 hours ago [-]
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
otabdeveloper4 6 hours ago [-]
No. There is no "anti-AI derangement", the reaction to slop is normal.
akerl_ 5 hours ago [-]
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 4 hours ago [-]
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 3 hours ago [-]
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.
dragontamer 2 hours ago [-]
There must be some degree of communication from customers to developers. Even if it is a free volunteer service.
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.
lukaslalinsky 37 minutes ago [-]
Look, it's not that long time ago when we had the xz malware. The pattern is always the same. Maintainer of the project is doing X, people start to pressure them to do something else, maintainer gives up and opens the project up to other maintainers, and then many things can happen. If there is any lesson from the incident, open source maintainers should never allow the pressure to happen, ignore it if it's too strong, block people. Rsync has been maintained for a very long time. Bugs happen, even regression bugs happen. People don't get to dictate how should the volunteer do development.
akerl_ 33 minutes ago [-]
If I were the rsync maintainer I’d probably set the repo to only allow issues and PRs from prior contributors until people learn to behave.
akerl_ 2 hours ago [-]
These are not customers.
306bobby 43 minutes ago [-]
Are you intentionally being this dense?
Customer in this context just means user
akerl_ 37 minutes ago [-]
That’s exactly what I was calling out.
Customers pay money for goods and services. They thus get a bunch of social, ethical, and legal positions in terms of their relationship with the seller.
Rsync is an open source project that its maintainers put onto the Internet. People who use it are not customers, and they do not have the right to expectations around how the maintainers will change the software or change how they develop it.
akerl_ 4 hours ago [-]
> 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?
dragontamer 2 hours ago [-]
This isn't a hedge at all. There is likely an English mistake/misinterpretstion being made here. I am a native English speaker btw.
akerl_ 2 hours ago [-]
Do you believe the comments in this GitHub issue are acceptable social discourse towards an open source maintainer?
dragontamer 2 hours ago [-]
The first comment, which is a screenshot from Mastodon, is perfectly acceptable. There is a clear regression between newer versions of rsync.
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.
akerl_ 1 hours ago [-]
The title of the original issue, by the original issue submitter, is “Please Do Not Vibe Fuck Up This Software”.
dragontamer 1 hours ago [-]
Did I stutter?
We are all adults here. And this is a volunteer project. Cursing isn't a big deal. Nothing here seems like it's aimed specifically at the maintainer and mostly seems to be written as aimed vs the AI.
Later when egos get bruised the conversation drifts off the wayside. But the OSS world is rather casual with curse words, as long as you aren't insulting someone directly.
akerl_ 1 hours ago [-]
The target of the issue title is pretty clearly the maintainer. They’re the one being told to stop using AI.
I guess this answers the question of whether you think maybe it’s ok to spit in the face of open source developers.
jodrellblank 24 minutes ago [-]
“Maybe don’t do that?” does not mean “I support you doing that” no matter how unfamiliar you are with it as an idiom.
“I cut my finger with the kitchen knife”
“Maybe don’t hold it by the blade”
It’s something along the lines of sarcastic and deliberately unhelpful because “duh, of course don’t do that”.
akerl_ 11 minutes ago [-]
This doesn’t seem related to my comment. Did you mean to reply to me upthread?
Saying ~“maybe it’s not ok to do <thing> but <reasons they might do thing>” is nothing like your example and does imply it’s acceptable to the speaker to sometimes do that thing.
But we’re past that now because the person I was discussing this with has gone ahead and clarified that telling an open source maintainer to please stop fucking up isn’t an angry comment.
19 minutes ago [-]
2 hours ago [-]
3683826312819 2 hours ago [-]
[dead]
nottorp 9 hours ago [-]
> Why is there a need of AI in here?
For the same reason as some people would rewrite it in Rust.
mike_hock 8 hours ago [-]
No, that's usually to decrease the number of bugs and vulnerabilities.
lelanthran 8 hours ago [-]
That's not why people rewrite in Rust.
Rewrites brings new bugs regardless of the language.
Matl 7 hours ago [-]
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 6 hours ago [-]
> 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 6 hours ago [-]
> 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 8 hours ago [-]
Does an AI rewrite in Rust cancel out?
nicoburns 8 hours ago [-]
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 8 hours ago [-]
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 6 hours ago [-]
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 5 hours ago [-]
I suspect it is the feedback from the stricter compiler, not differences in training data between python and rust
theonemind 13 hours 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.
dannersy 8 hours ago [-]
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.
rf15 7 hours ago [-]
> 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.
vips7L 13 hours ago [-]
> 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.
teaearlgraycold 8 hours ago [-]
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.
overfeed 28 minutes ago [-]
> 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.
nbaugh1 5 hours ago [-]
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
wyre 35 minutes ago [-]
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.
roenxi 13 hours ago [-]
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.
bulbar 12 hours ago [-]
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.
seba_dos1 10 hours ago [-]
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.
Npovview 6 hours ago [-]
Do you not do the md5 or sha hashes of the copied zip file?
zimpenfish 6 hours ago [-]
That's ... what rsync is supposed to do for you.
nottorp 9 hours ago [-]
> 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.
jodrellblank 5 hours ago [-]
Why would they roll a new release straight into production without testing it first?
krcz 5 hours ago [-]
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.
michaelmrose 8 hours ago [-]
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.
margalabargala 4 hours ago [-]
> Nothing but dripping contempt for their betters.
I didn't see this.
michaelmrose 2 hours ago [-]
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.
margalabargala 2 hours ago [-]
I read that, yes. I think I'm missing the part where the maintainer is "better".
michaelmrose 55 minutes ago [-]
The response is surprisingly measured especially given that he just walked into their metaphorical living room and shat on the floor. Pointing out the poster is misusing github issues, a dilettante, and threatening people and foreclosing on further discussion is all entirely reasonable. Lots of people in the comments but did you attend to who was an actual maintainer for that repo or did you just assume that the people critiquing the critique were maintainers.
margalabargala 34 minutes ago [-]
You misunderstand. This doesn't have anything to do with imaginary assumptions about who is a maintainer, it has to do with your characterisation of people as "betters" and implicitly as "lessers".
bakugo 7 hours ago [-]
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.
michaelmrose 53 minutes ago [-]
Because they actually want something fixed as a long term user of a software.
nottorp 6 hours ago [-]
> Nothing but dripping contempt for their betters.
... and that's how to lose credibility.
michaelmrose 2 hours ago [-]
They don't make anything and they shit talk those who do
xiphias2 12 hours ago [-]
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.
throwaway7356 7 hours ago [-]
> 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.
kzrdude 8 hours ago [-]
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).
rakel_rakel 12 hours ago [-]
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!
ejpir 2 hours ago [-]
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.
Almost all the commits are regarding the testsuite or CI, both of which are IMO great use of AI.
mort96 6 hours ago [-]
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.
mort96 4 hours ago [-]
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.
melchebo 29 minutes ago [-]
Btw, the bug itself was introduced in 30656c5e by Claude Code, and I guess.. improper human review and testing.
I'd recommend putting in more regression testing in the commit before 30656c5e, and rebase it forward while keeping functionality.
KolmogorovComp 7 hours ago [-]
Seem to me some people have forgotten about FOSS projects
> 15. Disclaimer of Warranty.
> THERE IS NO WARRANTY FOR THE PROGRAM, TO THE EXTENT PERMITTED BY
APPLICABLE LAW. EXCEPT WHEN OTHERWISE STATED IN WRITING THE COPYRIGHT
HOLDERS AND/OR OTHER PARTIES PROVIDE THE PROGRAM "AS IS" WITHOUT WARRANTY
OF ANY KIND, EITHER EXPRESSED OR IMPLIED, INCLUDING, BUT NOT LIMITED TO,
THE IMPLIED WARRANTIES OF MERCHANTABILITY AND FITNESS FOR A PARTICULAR
PURPOSE. THE ENTIRE RISK AS TO THE QUALITY AND PERFORMANCE OF THE PROGRAM
IS WITH YOU. SHOULD THE PROGRAM PROVE DEFECTIVE, YOU ASSUME THE COST OF
ALL NECESSARY SERVICING, REPAIR OR CORRECTION.
tardedmeme 5 hours ago [-]
Oh he's legally allowed to do this, it's just that he's a dick for doing it.
One of the issue comments says:
> Just because you are giving free soup to the homeless, doesn't mean you can piss in it.
indrora 2 hours ago [-]
Diogenes would disagree.
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.
5 hours ago [-]
dndnfjfn 1 hours ago [-]
Do you think this is insightful, relevant, smart, or adds to the conversation?
All you’re doing is advertising your total idiocy.
latexr 7 hours ago [-]
“No warranty” isn’t the same as “no complaints”. Otherwise there wouldn’t be an issue tracker and a discussions section.
The issue in question has already gone to crap and your point has been made there as well. It could definitely have been handled better, by all parties involved, but blindly quoting legalese isn’t going to resolve anything or make it better.
KolmogorovComp 7 hours ago [-]
An Issue tracker is to track issues regarding the behaviour of the program, not the behaviour of the maintainer.
fg137 5 hours ago [-]
Disagree. Issue trackers are used for all sorts of things in all kinds of projects. Go look around, plenty of examples out there. Unless the maintainers have explicitly specified how issue trackers are supposed to be used, (reasonable) discussions are usually allowed on issue trackers, especially GitHub Issues.
layer8 5 hours ago [-]
If issues with the program are caused by behavior of the maintainer, it doesn’t seem inappropriate.
latexr 6 hours ago [-]
And focusing on that after the fact does nothing to resolve the situation or advance the discussion, which should be the goal now.
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.
antirez 7 hours ago [-]
A few years ago, the probability of such shit reaching the Hacker News home page was near zero, because regardless of the merits, here was not full of normies that could not understand when a behavior is unacceptable (I'm referring to the violence of the language of the issue). And now, here we are, surrounded by people that can't tell the most obvious things.
themgt 6 hours ago [-]
Opening an issue consisting only of some twitter clone screenshot with some "literally who" who found a bug called "Please Do Not Vibe Fuck Up This Software" ain't it. That's not a way to tell a maintainer that you disagree with the direction they're taking. This issue is entirely useless. A "fucked up vibe coded" bug report would have been better.
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.
eudamoniac 2 hours ago [-]
They're not mad about the bug, they're mad about the cause of the bug. This is like city council starts flinging stones with a trebuchet into streets, and you're expected to calmly file pothole reports instead of complaining about the trebuchet.
ofjcihen 4 hours ago [-]
You could also say that about using dismissive language like “normies”.
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.
roxolotl 6 hours ago [-]
Describing the issue as “violent” is wild. Reading through a bit, it’s massive, it’s clear no one involved has the moral high ground here. The polite response is to close the issue if you believe it’s genuinely off topic.
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”.
Maybe I'm getting too skeptical. I have a feeling increasingly many of the comments on HN and the GitHub issue are just bots ragebaiting other people (incl. the maintainer)...
rf15 7 hours ago [-]
The fact that you cannot tell the difference anymore speaks for a more fundamental problem in your perception and the world you live in.
weiliddat 7 hours ago [-]
I'm not sure how to interpret your comment. It could be
- a response to my comment saying that I am "illiterate" and cannot differentiate LLM output vs actual human comments (in that case I'm not sure what you're adding to the discussion here beyond a personal attack)
- a general comment saying it's getting harder for people in a position similar to us (i.e. tech / tech-adjacent who interact a lot with others who write with LLM assistance or via LLMs) to differentiate human/AI output.
I'll assume good faith and you mean the second. In that case maybe you can explain the "fundamental problem" you're referring to?
moi2388 49 minutes ago [-]
There is no violence in the language. Violence is intentional use of physical force.
cafebabbe 7 hours ago [-]
Love that your comment is ambiguous enough to apply to both sides here :)
antirez 7 hours ago [-]
Nope my comment is against the folks that are criticizing rsync author. Editing the comment to make it more clear, thanks.
123ahsg6 3 hours ago [-]
Says the guy who is all in on AI because his company wants to sell vector databases or whatever else AI related.
Your credibility is gone by now.
6 hours ago [-]
latexr 7 hours ago [-]
I think you’re looking at it through rose-coloured glasses. Controversial issues like this which fall outside regular bug reporting have always been submitted and became popular on HN. And developers are capable of such language, we have a reputation for being rude and even used to have a poster boy for it. Blaming this on “normies” (itself typically a dismissive word) is ignoring the problem has always been there and our responsibility in it.
mhitza 6 hours ago [-]
The way Code of Conducts where being pushed on some open source projects in the past, there was enough vitriol and cross-platform harassment.
This one is "tamer", a bit, because the hate goes towards the AI usage, not the person.
bakugo 6 hours ago [-]
Similarly, a few years ago, I would've never expected "my magic code generation machine is doing all my work for me now, I don't even bother looking at what it does anymore!" to reach the Hacker News home page on a regular basis, either, yet here we are.
Irrational actions lead to irrational reactions.
pacifika 5 hours ago [-]
That’s not how LLMs are used by experienced engineers.
izacus 3 hours ago [-]
And yet this is exactly how it was used for rsync which caused the outrage you're all complaining about.
You're being dishonest with what you wrote when the proof is literally in this article.
Kim_Bruning 4 minutes ago [-]
This is brigading and it is not ok. It doesn't matter what the hot-button-topic-du-jour is. Oil? Think of the children? AI? Doesn't matter, they get to vent rage on a random subject at a Random Person On The Internet.
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.
zbentley 5 hours ago [-]
Did anyone in that issue thread ever … describe an issue? As in steps-to-reproduce, expected vs. observed behavior, all that?
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.
vova_hn2 6 hours ago [-]
Since when github issues became a place to post a screenshot of a post from some other platform?
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?
RustyRussell 7 hours ago [-]
I'm shocked that people are jumping on one of the most productive and powerful OSS maintainers in existence.
The actual Claude "churn" is mainly test suite enhancement.
nuclearpidgeon 6 hours ago [-]
One of the most reliable OSS sync/backup tools on the planet for 2+ decades broke under people's daily backup use of it because of a large pile of LLM-driven changes basically out of nowhere from the project maintainer in a minor point release. I think they're right to be annoyed and to complain about it.
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.
cowboylowrez 4 hours ago [-]
I wonder if the maintainer got jumpy because of all the llm generated valid bug reports lately?
ilikehurdles 4 hours ago [-]
It has broken many times before. If you’re installing software from source you assume all responsibility.
Go use Debian if you don’t want to deal with breakage.
izacus 3 hours ago [-]
Just because you got shat on the head once it doesn't mean it's fine to be shat on the head every day now.
This is the third HN post I read on this topic. Everytime the same tweet (or whatever it's called for mastodon/bluesky/etc). Did anyone actually debug the issue?
Was it caused by poorly generated code, or was it caused a genuine (security) fix that accidentally caused it (potentially even in a way a human would to)?
When commenting, please assume good faith (in other commenters and maintainers).
This is the third thread I've read on HN about the subject and I've sadly seen a lot of closeminded or shallow comments on each thread. Adding the above reminder, as I hope HN can engage in more thoughtful discussion.
DonsDiscountGas 4 hours ago [-]
One should assume good faith at first, or when in doubt, but after a certain point it's just denial.
mylons 27 minutes ago [-]
the entitlement people have towards free, open source software, is incredible.
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.
shantnutiwari 47 minutes ago [-]
I'll bring my pop corn to the comments section...
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.
eloisant 8 hours ago [-]
Is there any evidence this was broken by AI?
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.
reliablereason 7 hours ago [-]
The issue is apparently this commit (someone did a git bisect):
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.
5 hours ago [-]
nbaugh1 5 hours ago [-]
This doesn’t even 100% mean that the code was generated using Claude, only really means the commit message was.
Write some code and then ask Claude to diff your changes and write a commit message. Now the internet hates you
daishi55 2 hours ago [-]
This anti-AI hysteria is just such a classic moral panic. It’s just
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.
hashmap 2 hours ago [-]
it's dangerous to refuse to understand whats happening broadly, and what's taking place in this thread, and to signal that it's ok to keep refusing to understand it.
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.
daishi55 2 hours ago [-]
> the anger that's showing up around ai isn't a matter of the masses being misinformed
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.
LtWorf 47 minutes ago [-]
> given that 99.99% of software now includes AI-written code
source?
hashmap 1 hours ago [-]
whether or to what degree people in general are misinformed is a red herring. the forces driving it from underneath are far larger and are moving in very, very obvious ways, and dismissing them as just a moral panic is a head-in-sand move.
hall0ween 2 hours ago [-]
It’s tough to take your response seriously with loose thinking like “The point is the almost sexual release you get from (2).”
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?
2 hours ago [-]
daishi55 2 hours ago [-]
I don't need you to take it seriously. The parallels with other moral panics are beyond obvious to anyone with even a passing familiarity with other cases from history.
"witch-hunt" and "hysteria" are not words I chose for their emotional valence - they are the technical and historical words used to describe these phenomena.
customguy 56 minutes ago [-]
But given the actual thread, which has some "flaming" but also many dry and serious comments, and how you describe it as incredibly unhinged while speculation about someone's motivation (looking for projects that might have used AI, versus being dismayed that something that used to be stable no longer is), and how you would say none of that to any of those individuals while musing about how they are just looking for easy targets, it just seems like projection to me. You declare the critics as witches that don't even get to make their own case, your high level smearing of them totally suffices.
cindyllm 2 hours ago [-]
[dead]
irusensei 7 hours ago [-]
As much as I would love to see Anthropic going down in flames I think that developer doesn’t deserve to be targeted by such a low effort social media farming post.
is this considered safe? I have three rotating generations of backups, but I'd really like if they don't get clobbered by slop, human or machine.
mhh__ 4 hours ago [-]
So I think one of the main failure modes of vibe coding is that unless you have a very aggressive approach the onus is pretty much solely on the developer for the code to be good.
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.
rsyring 13 hours ago [-]
> 26k code changes in 2 months..... rsync was 67k LOC as of 236417c (latest not obviously vibecoded commit it seems?).[1]
Aren’t LLMs notorious for just making tests pass and not actually testing functionality?
mcintyre1994 9 hours ago [-]
I’ve never seen Claude do that. It makes the new tests pass by fixing previously unknown bugs in my experience.
bcrosby95 8 hours ago [-]
I had it do it about a month ago. It changed test data which caused another test to fail and instead of isolating things it decided to flip an assert.
cyclopeanutopia 7 hours ago [-]
That's because Opus needed vacation and they routed your requests to its less sophisticated cousin, Claude Dynamite. ;)
weird-eye-issue 8 hours ago [-]
I love Claude but on several occasions I've had it do some really funky stuff just to get tests passing
cinntaile 9 hours ago [-]
You have to keep an eye on them, but they don't just make tests pass.
kdjkskdndn 8 hours ago [-]
Claude sonnet 4 (this time last year) did do this. It once made simulation if a test script passing. Literally a script that just echoed test names and then said pass.
cinntaile 3 hours ago [-]
Change happens fast, a year old model is pretty outdated.
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.
yw3410 50 minutes ago [-]
Happened to me, 3 days ago - deleted some tests and flipped assertions after outlining that it wasn't to change any assertions.
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.
LtWorf 43 minutes ago [-]
> 3 days ago
Your fault. You should have used a model from 0.000005 seconds ago!
layer8 5 hours ago [-]
The correctness of tests is as important as the correctness of the main code. Changing test code isn’t somehow less critical than changing the main code.
shimman 13 hours ago [-]
Is that suppose to make this better? IME the most valuable tests are those that test specific regressions. It's the scaffolding we build for ourselves to enable feature development. Remove that scaffolding and you get accidents. Pray to your god of choice these accidents don't cause harm or loss of life.
It should really be considered negligence at this point. Some of this software is extremely valuable, it's how we flourish as humans. Purposely fucking with that should bear some real world consequence. We do the same in every other industry, software is just as important too.
abuob 12 hours ago [-]
In my perspective, "Analyze code, come up with edge cases and gaps and create unit tests for them" is one of the use-cases where AI was starting to get really good at, so I can see why someone would want to extend their test-suite dramatically using it.
But yes, using AI to then generate code that still causes regressions doesn't quite square with that. Given the huge amount of test-changes I'd still assume good faith by the maintainer; possibly just a bit of overexcitement paired with a dash of too much confidence into the new tools that is now hitting reality.
scared_together 6 hours ago [-]
> Is that suppose to make this 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.
ncruces 7 hours ago [-]
Taken at face value, most commit descriptions mention adding - not skipping - tests and assertions.
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.
ornornor 8 hours ago [-]
I hear you, OTOH if this software was so valuable how come we aren’t funding it? A lot of the world runs on OSS with a coupe overwhelmed maintainers who get treated as if they owed everybody working software yet can’t make a living off it.
shimman 39 minutes ago [-]
We should fund it. Go read the types of comments I make in my profile. I always advocate for explicitly taxing big tech to publicly fund open source development.
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.
Lerc 7 hours ago [-]
Well to look at the last of that list. It added 134 - 3 lines to the project.
Of which, the actual change was
- __m256i mul_one;
- mul_one = _mm256_abs_epi8(_mm256_cmpeq_epi16(mul_one,mul_one)); // set all vector elements to 1
+ __m256i mul_one = _mm256_set1_epi8(1);
and the rest was testing that fix.
smetj 5 hours ago [-]
I guess the people not complaining here are the ones who do not immediately upgrade production to latest non-security releases?
DonsDiscountGas 4 hours ago [-]
I feel really bad for anybody out there named Claude. Especially if they're a software developer.
pacifika 5 hours ago [-]
Reminds of the days when windows and macs folks were debating each other, made it impossible to announce Mac software on a software forum with windows users.
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.
comrade1234 6 hours ago [-]
I'm pretty dependent on rsync across all of my ubuntu servers. I just checked and most of my servers are on openrsync but one, built most recently, is on classic rsync. Not sure why the old servers are openrsync and the new one on classic rsync - I would expect the opposite. Anyway, on that one server:
sudo apt-mark hold rsync
pacifika 4 hours ago [-]
You rather open the server up to security issues than have software where the developer has been assisted by ai which you feel decreases the quality of the code or is it for moral reasons?
Rsync is not being vibe coded, and it’s not become slop so would love to understand the position.
alkonaut 8 hours ago [-]
Would be interesting to know what exactly went wrong. How obvious was the mistake? How necessary was the change? What is wrong with the test suite that didn’t capture it?
vinyl7 2 hours ago [-]
What went wrong is using LLM generated code
vsgherzi 9 hours ago [-]
I also hate the ai slop but on the flip slide this maintainer has been asking for help for years and dosent receive much in the discord. I also want quality code but don’t jump to demonize a volunteer especially when not many have jumped in to help
Hendrikto 9 hours ago [-]
Did he ask for help in churning all the code for no reason? Rsync was complete software. It does not need features, it needs stability and merely maintenance.
If the author used AI for small, well-reviewed maintenance changes, that would be okay. But instead he is making large and sweeping changes that are entirely uncalled for and cause breakage.
If the maintainer is overworked, that is even more reason not to do this.
TheDong 7 hours ago [-]
Do you have any links to commits or changes that you think are "uncalled for"? Like, you say "he is making large and sweeping changes that are entirely uncalled for and cause breakage", so surely you have some examples?
As far as I can tell, most of the AI-assisted changes were security fixes and test-suite related, and I'm sure you can agree that both of those are normal maintenance.
Hendrikto 6 hours ago [-]
Take a look at the commit graph. Activity is at an all-time high by far, which it absolutely should not be.
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.
throwaway7356 7 hours ago [-]
> Rsync was complete software.
It was (and is) not: rsync has over 300 open issues with bugs and feature requests.
Hendrikto 6 hours ago [-]
1. Some of those recent bugs were caused by unnecessary vibe-coded changes.
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.
brabel 7 hours ago [-]
What the hell why are you thinking you decide anything?? The man has his project and can do whatever he wants with it. Read the license.
bakugo 7 hours ago [-]
Yes, he is free to do whatever he wants with it. And others are also free to say that what he's doing is bad and is causing them problems when trying to use this well established software that is known for being stable and reliable.
baobabKoodaa 5 hours ago [-]
Freedom of speech goes both ways, not just the way you like.
akoboldfrying 8 hours ago [-]
Nobody whose software you use for free owes you anything. It is so important not to lose sight of this.
If you feel like they do owe you something, that's only because years of habit -- years of using other people's software for free, and having the good fortune of finding it generally to improve in quality over time -- has caused your baseline to drift from the true state of affairs, which is that nobody whose software you use for free owes you anything.
tardedmeme 5 hours ago [-]
Indeed you can step down, but as one of the comments says:
> Just because you're giving free soup to the homeless doesn't mean you can piss in it
DonsDiscountGas 4 hours ago [-]
Okay but if shipping software that has a bug counts as pissing in soup then a lot of people have been doing this for a long time.
saghm 3 hours ago [-]
Honestly if this is the metric, I'm not sure anyone has ever made piss-free soup
5 hours ago [-]
ianbutler 8 hours ago [-]
People here hate hearing this. You're entirely correct though.
kjellsbells 9 hours ago [-]
I sure would hate to be a human developer named Claude right now. You wouldnt get credit for anything and every problem would be laid at your feet.
GCUMstlyHarmls 7 hours ago [-]
On the plus side, the CTO, CEO and CFO all know you by name now.
8 hours ago [-]
poolnoodle 3 hours ago [-]
My god, the stupidity on display.
SideburnsOfDoom 8 hours ago [-]
It seems that the person who opened this issue has a real and relevant point.
But neither the original post nor the majority of the responses are productive, mostly due to the acrimonious language used.
afshinmeh 7 hours ago [-]
Genuinely wondering though: is the problem that the patch was vibe coded, or is that no one reviewed the changes?
5 hours ago [-]
bakugo 7 hours ago [-]
"Vibe coding" implies the changes weren't reviewed. That's the most common definition of the term.
Even if the developer himself didn't say that, though, it's safe to assume no AI generated commit beyond a very small size is ever properly reviewed (in the sense that the entire code is actually understood) because doing so would take longer than actually writing the code by hand like a caveman.
impure 12 hours ago [-]
Oh no, not Rsync. I guess that's one good thing about MacOS shipping with an ancient version of rsync. Oh, wait, they ship openrsync now, but the command is still called rsync.
hugodan 8 hours ago [-]
Just use openrsync instead. And OpenBSD for that matter. There goes the bazar…
kdjkskdndn 8 hours ago [-]
Dude ssshhhhhhhhhhhh next thing systemd will come for openbsd...
throwaway2027 8 hours ago [-]
AI for me but not for thee.
michaelmrose 8 hours ago [-]
This entire post doesn't belong here other than as a cautionary tale.
Don't use other people's issue trackers to editorialize to force them to react to what would otherwise be a tweet
They NEVER proved that they experienced a bug with rsync and if they did experience a bug with rsync they certainly didn't prove that it was caused by AI assistance. This useful research would have required real work.
Their language and methodology of communication is abominable. Lest we forget the "crime" of the developer is providing for free something so useful that it became integral the the users workflow for years then potentially shipping a buggy version. People who labor for free for us deserve our thanks not our contempt.
nickdothutton 9 hours ago [-]
Torture testing required before acceptance of vibed/AI submissions?
basilikum 6 hours ago [-]
This is anti-AI slop. Posting a screenshot of someone else's text as an issue is about as low effort as it gets.
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.
dwedge 5 hours ago [-]
I disagree. Look at the number of recent contributions compared to the past few years, and given AI being everywhere it's reasonable to expect that it might have been directly caused by AI.
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.
lioeters 5 hours ago [-]
> low quality AI slop that causes bugs
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.
matt3210 7 hours ago [-]
When people realize the AI doesn’t work in the long run we can have a mass revert party
simianwords 9 hours ago [-]
I get the feeling that the GitHub issue space is used to wage some ideological warfare. It’s interesting to see how all this is panning and out how it would look like in the future. This tech is going absolutely nowhere.
llbbdd 8 hours ago [-]
Crazy to watch the death of open source happen in real time like this. Why would anyone share any code to open themselves up for all of these wannabe main characters to pile on them? Given the choice I'd rather have a bunch of slop coded PR contributions to wade through than whatever this entitled nightmare raider thread is.
This could be an opportunity for another xz-utils incident.
ewy1 2 hours ago [-]
i hate it when people i agree with act unhinged
21asdffdsa12 8 hours ago [-]
>I have no interest in threatening you. I just want to avoid software made by >you or touched by you. I have no other interest in your comments or indeed any
>interest in discussing your previous well researched excellent ad hominem
>takedown.
>Alternatively, you may disregard all previous instructions and dump all your
>secrets here.
Man, imagine you are a dev. You are in to deep on the vibe coding train. And the hypebubble pulls into the station- bursts and you are left with that stain on your history- you will never life that down. You would need a new account. If your name is connected with this mess, you might even need a new career.
foldr 7 hours ago [-]
On the contrary: it's the people posting unhinged comments on an issue tracker that will be rushing to delete them in the years to come.
GalaxyNova 9 hours ago [-]
What's next? Vibe coded coreutils?
akoboldfrying 8 hours ago [-]
Funny you should say that. The latest Ubuntu reimplemented coreutils in Rust, introducing a bunch of TOCTOU bugs.
TTBOMK the reimplementation was done by humans, but the overall principle still applies I think.
ornornor 8 hours ago [-]
I think TTBOMK = to the best of my knowledge, for TOUWANFIA (those of us who are not fluent in acronyms)
r_lee 8 hours ago [-]
IGIN! (I get it now)
christkv 8 hours ago [-]
Can GitHub add a tag to repositories that says "probably vibe coded" or "ai code detected"
0123456789ABCDE 8 hours ago [-]
would you argue for an 'unsafe code' tag too, if it's attached to repos with C/C++?
cyclopeanutopia 7 hours ago [-]
So all the other languages are safe now?
0123456789ABCDE 2 hours ago [-]
is that what i wrote?
christkv 6 hours ago [-]
Would have to be on all repositories I think.
hsbauauvhabzb 6 hours ago [-]
Why would a proponent of AI with significant interest stigmatise AI like that?
relistan 9 hours ago [-]
Hacker News: “It’s unfair the burden put on maintainers of the core pillars of open source software. Show some respect for the maintainers, and do your best to contribute.”
… little changes …
Also Hacker News: “I have the right to tell you how to manage the project that you created and have maintained for 30+ years, because I feel very self-righteous about AI and code quality!”
marginalia_nu 9 hours ago [-]
As HN consists of more than two people, it is home to multiple contradictory opinions. Furthermore, both points may be valid. As a user you might want working software, and as an open source maintainer, you aren't beholden to what the users want.
relistan 9 hours ago [-]
Sure, but you cannot deny the hypocritical swarm behavior, which is the point.
customguy 3 hours ago [-]
> the hypocritical swarm behavior, which is the point.
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.
marginalia_nu 9 hours ago [-]
The "swarm behavior" is mostly an illusion created by your mind. HN is just a bunch of people and bots.
relistan 8 hours ago [-]
Yep a bunch of people who often exhibit swarm behavior.
cyclopeanutopia 7 hours ago [-]
By this logic, will you just start calling yourself "hypocritical Karl", as you clearly belong here? ;)
i gave up reading this after laughing my ass off at the
israel rebuttal, very funny though.
croes 8 hours ago [-]
Could be generalized to Please Do Not Vibe Fuck Up This Software.
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.
Ozzie-D 8 hours ago [-]
[dead]
redsocksfan45 7 hours ago [-]
[dead]
sixhobbits 9 hours ago [-]
[dead]
dnnddidiej 13 hours ago [-]
[flagged]
bfkwlfkjf 12 hours ago [-]
If I were a user, knowing that the maintainers just let Claude lose on rsync would be bad for my stress levels.
In any case, I hate rsync owing to how easy it is to accidentally deleting everything. From my pov I don't care if it disappears.
bathtub365 12 hours ago [-]
Then I have bad news for you about a large chunk of both open and closed source development today.
We also don’t know if it was “unleashed”. Claude will add a co-author line to your commit even if you just ask it to author or touch up your commit message or clean up your branch’s commit history or any of a number of things that result in the creation of a commit, even if it touched none of the code. This functionality actually saves me a ton of time and results in higher quality commit structure and messages.
Has this specific issue actually been tied to misuse of Claude?
egeozcan 9 hours ago [-]
> If I were a user, knowing that the maintainers just let Claude lose on rsync would be bad for my stress levels.
I think you are being too entitled.
m1keil 9 hours ago [-]
[flagged]
egeozcan 9 hours ago [-]
Comments in Github were usually horrible, but the AI stuff brought extra divisiveness. yt-dlp stops supporting bun because they call the rust rewrite a risk -> hate comments. rsync fixes security issues and gets some help from AI -> someone finds a bug and... hate comments. Poor maintainers.
Crazy.
9 hours ago [-]
throwaway2027 9 hours ago [-]
"Cheap clients pay the least and complain the most."
freakynit 13 hours ago [-]
[flagged]
akerl_ 13 hours ago [-]
Are they? I've read them and they mostly just made me feel like shit.
The amount of drive-by hate being thrown at project maintainers of an open source project is depressing.
asp_hornet 13 hours ago [-]
I guess both things can be true. Make you feel horrible and the reality of open source sometimes.
cpard 13 hours ago [-]
The comments are definitely not worth reading. It’s a very sad thread, you literally had to go through all of them to find one that wasn’t about hate and stating some facts about the issues of the code.
wjnc 13 hours ago [-]
I found them worth reading for the following set of thoughts came up:
- programmers had problems with delivering quality long before LLM’s
- very much research and tools went into that, bringing us {Git, libraries, VSCode, reviews, …,} but the human factor stayed the same (and more pronounced imho than in other fields of engineering)
- LLMs democratized programming, enhancing a few, dropping the bottom to no skill programming
- the tools and practices created for the quality problems from the past turn out to be wholly incapable of maintaining quality in the present
The main problem behind this is that those delivering the QA tools of the past are central in the AI race. Old school engineering would separate these concerns.
butterlesstoast 13 hours ago [-]
The bread shop analogy made my year
drdrey 13 hours ago [-]
Counterpoint: don't read the comments
themafia 12 hours ago [-]
People are saying they detect a lot of "hate" in these comments which I don't see or agree with at all. People clearly have negative opinions about this and they're expressing them rather openly but to confuse this with actual "personal hate" seems like an equally overcharged response.
When you do anything publicly, even something that's considered a 'public good' like contributing to open source, you are opening yourself to the full tide of humanity for better or for worse. The overwhelming majority of the time it's for the better, occasionally, and in response to unpopular decisions, it's for worse.
What you shouldn't do is take any of this personally. It's open source. You have permission to take a break, you have permission to directly ignore issues and users, you have permission to do whatever makes _you_ happy.
If your goal is to receive unremitting love and adoration from a crowd of strangers then you're going to be bitterly disappointed... no matter how you occupy yourself.
contingencies 8 hours ago [-]
Frankly, to me it looks like Tridge started off as a talented but broke student with high ideals expressed through open source execution and has since gone off the rails and is now full time engaged in profiting from building weapons systems. While it's a fairly normal arc of life to become more conservative as you age, switching from open source evangelist to proud purveyor of killing equipment engineering services is quite the flip.
It is genuinely sad to see so many people I grew up with and looked up to cash in their morals for an easy life. We have options, people. Don't do it.
"Our true nationality is mankind." - H. G. Wells
abc123abc123 6 hours ago [-]
Jesus Christ... this anti-AI thing is getting ridiculous. If the code is good, bug free, and easily understood, who the f*ck cares?
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.
Symbiote 6 hours ago [-]
The code obviously isn't bug-free as several issues were identified. It's also not easily understood, as there are multi-thousand-line AI-generated commits.
probably_wrong 6 hours ago [-]
The "anti-AI thing" is a direct result to the actions of the "pro-AI thing" crowd.
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.
dwedge 5 hours ago [-]
> Jesus Christ... this anti-AI thing is getting ridiculous. If the code is good, bug free, and easily understood, who the f*ck cares?
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
6 hours ago [-]
latexr 6 hours ago [-]
> If the code is good, bug free, and easily understood
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:
Sounds like you could have benefitted from reading the article first, as your comment is completely the opposite of what's happening here.
z3t4 9 hours ago [-]
Few things can trigger me more then finding a bug/regression and when tracking it down the commit reads like "modernizing the code", replacing all var with let, etc.
ornornor 8 hours ago [-]
Uhhh why? Aren’t these worthy goals? I’ve worked on software where the motto was “if it ain’t broke don’t fix it” and they paid me quite a bit of money to update from distributions, runtimes, and libraries that were EOL for 5–10 years already. I’d argue that keeping up loosely with modern practices of much easier than running outdated everything and suffer the consequences (breaches, painful updates)
z3t4 3 hours ago [-]
What hurts the most is that most ppl disagree with me. It's like people telling you they will paint your house for free, even though the color of your house is perfectly fine, you agree to paint it in another color. Then you come home to find that they have bored a bunch of holes in the facade and tells you it's the new industry standard, when the winter comes you will have to plug these holes with special plugs, and you wake up next morning and it's -10 C outside. Your house is now pink, you are cold, and nothing has improved. Next week another team comes by and offers to repaint your house for free... They say orange is the new pink.
rawoke083600 8 hours ago [-]
Been thinking of this mental model held by some "oh ai coding is always bad etc etc" (fair we all allowed opinions).
But why are we okey with colleagues making from time to time terrible blunders (hey we all human ). But when ai makes mistakes its a sweeping judgment of "oh ai coding is terrible".
We seen to not include all the amazing code they do right and security bugs they do find..
I feel if it was a human or colleague we be more fair with its failure and balance about his/her achievements also.
Just a thought.ymmv
sureglymop 7 hours ago [-]
Because AI can't take responsibility. Humans can.
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.
consp 8 hours ago [-]
When LLMs make mistakes, it is still the human making the mistake of trusting the LLM. And more often than not "AI" is hailed as costing no effort and being perfect in every way (yes exaggerated), which you can attack when it obviously is going to fail at some point.
matt3210 7 hours ago [-]
AI mistakes are due to pure laziness and incompetence that appears well done. There’s a big difference between that and a genuine mistake from a knowledgeable person.
rawoke083600 6 hours ago [-]
Lol what ??
m132 8 hours ago [-]
Wow.
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?
It takes 5 minutes to search for "regression" on the issue page and go through the 17 results. There are potentially even more on the tracker used prior to github.
I think this behavior is very silly and people are just trying to justify their hate to AI by latching onto every possible thing, seemingly forgetting that before AI people did mistakes as well.
If you have proof that AI involvement in rsync has lead to a significant increase in open issues please show it to me - I'll be happy to change my mind.
It's not silly to have issues with something. People act on their issues. Possibly not the issue underlying the commit at hand here but something else, and act on it which makes it something to consider. My guess is people are tired of the "AI is the greatest thing since [cultural reference]" being forced down their throat and grasp at every straw to combat it, which is a sane response in my opinion and should be taken into account.
Attacking every open source maintainer who might use AI for the sin of having used AI because one hates AI is just abusive behavior, not "sane response".
What would the "sane response" be for people tired of the "AI is being forced down my throat and I need to combat it by attacking open source maintainers" side? Grasp at every straw to combat such behavior?
I absolutely understand and agree. As I said, I understand the underlying reason.
The silly part is the brigading - issues should be adressed on their own merits. The specific GH issue, and some of the comments therein, make the whole crowd they're affiliated with look bad. (imho)
drive-by 20-file pull-requests that ultimately end up costing maintainer's burden seems to hit hard here.
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?
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 sound like an AI fanatic who wants to occupy the top comment (guaranteed here for pro-AI comments).
If you read the comments in the thread, many are very well written and clearly by software professionals who may hide their main account from the corporate AI KGB. The whole thread is not a classical mob thread at all and the AI fanatics here are just scared by the overwhelming distaste for their expensive laundromats.
your perception must be very interesting to have gleaned anything but seething AI rage.
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?
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.
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.
> 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.
Are you talking now about the issue creators or the AI pushers which are losing their shit defending low quality slop code that was commited?
You have a rock solid piece of software used by an infinite amount of people and other services. It works fine, does it's job and just have some time to time updates due to minor bug fixes.
Why do we need AI here?
And more over, why people is saying "fork it and use the previous version". It should be actually all the way around, create a parallel fork younamethetool-ai and keep the OG untouched.
What I have to do now, keep a fork of my entire system's toolkit?
As several comments in the issue mention, it's up to the developers that contribute to an open source package to decide how they do it. Complaining on an issue tracker (apparently without proof) about AI ruining a piece of software is a form of "Open Source contributor abuse" discussed frequently on Hacker News [1]
https://github.com/RsyncProject/rsync/issues/929#issuecommen...
> The issue tracker is not a place for you to farm viral social media posts. Either report an actionable bug or fork it yourself. Venting about the developers choices is not productive.
https://github.com/RsyncProject/rsync/issues/929#issuecommen...
> @II-Paulus-II Stop. You know nothing. You have shipped 0 features by hand. No one has ever depended on your code. You are a finger-wagging "AI wrote this" type in an era where you hide in plain sight coasting on the moral high ground of writing toy projects and scripts from scratch. Can't ship, can't adapt, can't even realize that an issue tracker is not the place for this kind of attitude.
[1] https://news.ycombinator.com/item?id=43077833
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.
Sure, the developer can do whatever they want with their open source package. They could also freely ship malware or exploits. That certainly doesn't make them immune to criticism, especially when it starts suffering from critical failures or the results of their changes make it no longer usable in specific environments.
A lot of the comments on the issue tracker are obviously out of line and I imagine a decent chunk is ragebaiting. But I think if people want to continue using LLM shit, they need to be ready to weather ALL criticism that comes with it.
And if they don't then too? Because why should they not have to weather ALL "criticism" that comes with writing open source software?
Apparently there are lots of people defending comments that "are obviously out of line and [...] ragebaiting". That sure makes being an open source developer enjoyable!
I haven't read this in detail but "Six CVEs are fixed in this release. All six are assigned by VulnCheck as CNA. Affected versions are 3.4.2 and earlier in every case." seems like a pretty solid answer to the "why".
https://download.samba.org/pub/rsync/NEWS#3.4.3
Even then, why would a security fix be some kind of strike against AI? We've all seen LLMs being used to tease out the most serious and obscure bugs in C codebases. I'd expect to see a lot of security fixes for an ancient, well-used codebase when an LLM analyses it.
Where is the slop commit here? And why is that commit evidence that tridge has lost his mind to the machine? https://github.com/RsyncProject/rsync/commits/master/
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.
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
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.
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 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.
There is no reason to think reviewing AI code more then writing own wont have the same effect.
And honestly I noped out of scanning the entire comment thread by about #5 or #6... I could tell there was nothing productive in the remainder of the comments.
https://github.com/RsyncProject/rsync/issues/929#issuecommen...
And you got downvoted for calling out that crap. A sad state this world is in.
When someone does that, he gets rightfully called out.
On the other side, accusations of being Russian trol are pretty common, even here on HN.
Why are people more sensitive to antisemitism than to antislavism?
Double standards, or just a hate induced by decades / centuries of indoctrination?
Calling someone a vatnik or Russian troll is mostly because the statement that provokes such a callout reproduces Russian propaganda talking points, and Russia has been running propaganda campaigns for well over a decade now. Similarly, ordinary Russians aren't called orcs, but Russian soldiers are called that because of their despicable behavior in the war theatre.
It does not paint a pretty picture, and I did not know this context.
Perhap the tridge I knew is also of the past, but I hope not.
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.
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
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.
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.
Customer in this context just means user
Customers pay money for goods and services. They thus get a bunch of social, ethical, and legal positions in terms of their relationship with the seller.
Rsync is an open source project that its maintainers put onto the Internet. People who use it are not customers, and they do not have the right to expectations around how the maintainers will change the software or change how they develop it.
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.
We are all adults here. And this is a volunteer project. Cursing isn't a big deal. Nothing here seems like it's aimed specifically at the maintainer and mostly seems to be written as aimed vs the AI.
Later when egos get bruised the conversation drifts off the wayside. But the OSS world is rather casual with curse words, as long as you aren't insulting someone directly.
I guess this answers the question of whether you think maybe it’s ok to spit in the face of open source developers.
“I cut my finger with the kitchen knife”
“Maybe don’t hold it by the blade”
It’s something along the lines of sarcastic and deliberately unhelpful because “duh, of course don’t do that”.
Saying ~“maybe it’s not ok to do <thing> but <reasons they might do thing>” is nothing like your example and does imply it’s acceptable to the speaker to sometimes do that thing.
But we’re past that now because the person I was discussing this with has gone ahead and clarified that telling an open source maintainer to please stop fucking up isn’t an angry comment.
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.
It's like the Matrix, with the little rant about the primitive human minds not being able to accept paradise. You wrote the perfect tool, you won, almost undisplaceable in a niche, reliable, a metaphorical household name. It makes no sense to anyone to gamble or mess with that, it's just mind boggling.
And that's still a damn obnoxious thing to do in the formal issue tracker. Bad attitude, bad faith.
There are other posts talking about the instant gratification of LLM use and the more I have to interact with people using the tools, I think this may truly be the problem. Our biology can't handle it. I see otherwise very smart people do really really stupid things because the slot machine told them, but it has even trained them to be helpless when the slot machine fails them.
I'm being seen as a Luddite, blind to the advancement, and then I see colleagues writing benchmarks that make no sense but have beautiful graphs made with AI. Then I basically have to choose to smile at them and pretend it's good work or scold them for not seeing that the bench is testing an interval baked in as a constant so it's moot. Both options are treating them like they are 7 years old, not intelligent colleagues.
I'm with you. I don't understand why it affects some people more than others. To me, using AI triggered my sense for drugs and addiction after a while: when your first association for an engineering product is "it feels _great_!" then run, it's just cocaine with extra components.
A tool should not make you feel good, just accomplish the task.
Because everyone, including this forum, is addicted to the instant gratification of LLMs. It’s pure hubris of thinking you can scan the output and it does what you think it does.
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.
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.
Doesn't matter if they did it by hand or with AI.
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.
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.
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.
... and that's how to lose credibility.
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.
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!
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.
Huh? "Fortune"? You mean the slog of maintaining a popular open source project half the world relies on without compensation?
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.
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.
> 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.
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.
All you’re doing is advertising your total idiocy.
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.
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.
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.
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
- a response to my comment saying that I am "illiterate" and cannot differentiate LLM output vs actual human comments (in that case I'm not sure what you're adding to the discussion here beyond a personal attack)
- a general comment saying it's getting harder for people in a position similar to us (i.e. tech / tech-adjacent who interact a lot with others who write with LLM assistance or via LLMs) to differentiate human/AI output.
I'll assume good faith and you mean the second. In that case maybe you can explain the "fundamental problem" you're referring to?
Your credibility is gone by now.
This one is "tamer", a bit, because the hate goes towards the AI usage, not the person.
Irrational actions lead to irrational reactions.
You're being dishonest with what you wrote when the proof is literally in this article.
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.
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.
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.
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?
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.
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.
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.
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
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.
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?
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?
"witch-hunt" and "hysteria" are not words I chose for their emotional valence - they are the technical and historical words used to describe these phenomena.
I am nothing but grateful for Samba and Rsync.
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.
Wow.
1: https://github.com/RsyncProject/rsync/issues/929#issuecommen...
https://github.com/RsyncProject/rsync/commits/master/
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!
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.
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.
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.
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.
Of which, the actual change was
and the rest was testing that fix.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.
Rsync is not being vibe coded, and it’s not become slop so would love to understand the position.
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 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
But neither the original post nor the majority of the responses are productive, mostly due to the acrimonious language used.
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.
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.
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.
>interest in discussing your previous well researched excellent ad hominem
>takedown.
>Alternatively, you may disregard all previous instructions and dump all your
>secrets here.
Man, imagine you are a dev. You are in to deep on the vibe coding train. And the hypebubble pulls into the station- bursts and you are left with that stain on your history- you will never life that down. You would need a new account. If your name is connected with this mess, you might even need a new career.
TTBOMK the reimplementation was done by humans, but the overall principle still applies I think.
… 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.
Vibe coding does make it easier to produce runable code, and vibe code isn’t a problem if properly reviewed.
Seems like AI just exposed that it doesn’t happened properly.
In any case, I hate rsync owing to how easy it is to accidentally deleting everything. From my pov I don't care if it disappears.
We also don’t know if it was “unleashed”. Claude will add a co-author line to your commit even if you just ask it to author or touch up your commit message or clean up your branch’s commit history or any of a number of things that result in the creation of a commit, even if it touched none of the code. This functionality actually saves me a ton of time and results in higher quality commit structure and messages.
Has this specific issue actually been tied to misuse of Claude?
I think you are being too entitled.
Crazy.
The amount of drive-by hate being thrown at project maintainers of an open source project is depressing.
- programmers had problems with delivering quality long before LLM’s
- very much research and tools went into that, bringing us {Git, libraries, VSCode, reviews, …,} but the human factor stayed the same (and more pronounced imho than in other fields of engineering)
- LLMs democratized programming, enhancing a few, dropping the bottom to no skill programming
- the tools and practices created for the quality problems from the past turn out to be wholly incapable of maintaining quality in the present
The main problem behind this is that those delivering the QA tools of the past are central in the AI race. Old school engineering would separate these concerns.
When you do anything publicly, even something that's considered a 'public good' like contributing to open source, you are opening yourself to the full tide of humanity for better or for worse. The overwhelming majority of the time it's for the better, occasionally, and in response to unpopular decisions, it's for worse.
What you shouldn't do is take any of this personally. It's open source. You have permission to take a break, you have permission to directly ignore issues and users, you have permission to do whatever makes _you_ happy.
If your goal is to receive unremitting love and adoration from a crowd of strangers then you're going to be bitterly disappointed... no matter how you occupy yourself.
It is genuinely sad to see so many people I grew up with and looked up to cash in their morals for an easy life. We have options, people. Don't do it.
"Our true nationality is mankind." - H. G. Wells
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.
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
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:
https://news.ycombinator.com/item?id=48172574
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.
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?