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.
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.
I haven't read this in detail but "Six CVEs are fixed in this release. All six are assigned by VulnCheck as CNA. Affected versions are 3.4.2 and earlier in every case." seems like a pretty solid answer to the "why".
Even then, why would a security fix be some kind of strike against AI? We've all seen LLMs being used to tease out the most serious and obscure bugs in C codebases. I'd expect to see a lot of security fixes for an ancient, well-used codebase when an LLM analyses it.
Where is the slop commit here? And why is that commit evidence that tridge has lost his mind to the machine? https://github.com/RsyncProject/rsync/commits/master/
Regressions should be fixed expediently, but if you apply the criteria "need to not happen" they are literally blocking issues. They could then block security fixes.
I worked on major OSS projects and we never just blindly pushed out untested poor quality code for security fixes since that adds WORSE security regressions.
The methodology describes the effort you may be putting into something, The outcomes are about what results are you prepared to accept.
Would you ship an update with a security fix if it had been thoroughly tested was shown to have certain regressions but no worse security regressions? Would you refuse to fix the security issue until you could do so without any degradation?
It's clear that people can and do accept regressions for security updates. Spectre mitigations cause performance regressions. SharedArrayBuffer got taken away for a while. Being absolutist about things seldom helps.
I agree due care should be taken where possible, but I'm also prepared to accept that mistakes can happen even when people have worked diligently to find issues.
Since you have worked on major OSS projects. Have any of them shipped regressions unintentionally? Right now that is the only thing we have to go on, that these things happened. The degree of care taken is an unknown, as is the degree of LLM involvement. We might know more in a week or two.
If you want to condemn something based upon what might have happened you can specifically state what you think shouldn't happen, and that will stand regardless of whether or not it applies to the current incident.
Obviously "Thoughtless generation of code slop without regression testing" is unacceptable, but that is because the conclusion is written into the statement by saying "thoughtless" "slop" and "without regression testing"
If tridge says 'I gave it thought, I don't agree that it is slop, and I did regression testing' then you have nothing further to complain about, because the incident does not fall under the criteria you specified.
It's saying 'things that are bad, are bad'. The defence is to say 'well, this isn't bad'
You'd have to test to know this, and there is no evidence that tridge did this regression testing - or ask Claude to find possible regressions caused by proposed changes. If tridge did test for regressions, but chose not to document the regression, then it's still negligence, regardless of the tools pr processes involved.
> there is no evidence that tridge did this regression testing
What evidence would you be looking for? New tests, like the ones added in the AI-assisted commits? What other evidence?
> If tridge did test for regressions, but chose not to document the regression
Presumably you weren't trying to imply here that tridge found a regression and decided to ship the code anyway; so parent went to a natural assumption - do you think testing for regressions finds all regressions?
Here's a recent sample, paraphrased for brevity:
Them: this is broken.
Me: no, it's not broken.
Them (a few days later): "I think I must not have tried all the combinations", followed with two pages of transcripts.
Me: "I've just checked the code, and you're right [...] I'm extremely sorry I wasted your time."
Them: "Heh, it's all good. I'm am chuffed you're taking the time to give thoughtful responses with me"
But I was referring more to the initial use of strong words coming from frustration.
Just because you deal with it well doesn’t mean you should have to deal with it in the first place, especially when it comes to volunteer work.
They also don’t need a reason, or owe you their reason, for changing what tools they use to work on their open source projects.
I don’t, but let’s assume for a moment.
It’s still up to the current maintainer to pick additional or replacement maintainers, and it would be bonkers to expect the new maintainer to fork the repo to implement their changes.
Open source projects change their maintainers all the time.
The thing that makes a project die is if the maintainers all leave. Users don’t make a project exist. They make it popular.
If the user community all up and left, rsync would still exist and continue as long as its maintainers choose to work on it.
By contrast, if all the maintainers leave because they’re tired of dealing with assholes, the project dies.
It's quite some value judgment and worldview to divide open source into autistic maintainers who do even if no one uses and asshole users who do not and cannot do.
Is AI the problem, or that it had a regression? Is the regression actually caused by AI?
The author of these commits were tridge & claude.
What does tridge have to do to convince the open source community that he might be a legit programmer & have a clue?
Samba? Whats that? Rsync? Never heard of it. Tivo? No clue (maybe more Australian context here than others, but still).
Even the comments on the github issue, are totally devoid of the context that this is a very senior open source contributer who has maintained this project since he came up with the diff algorithm during his Phd, started the project and now chooses to acknowledge that he's using claude.
Is there any evidence that the bug rate on rsync is any worse than it used to be? or just a screenshot from mastadon?
It is just so bizarre to me.
People change. You can be Linus Torvalds for all I care, if one day you wake up and start pushing 9000 line commits created by LLM and with regressions, you're not that person anymore.
Of course I know that some people can just becoming psychotic out of nowhere. But why would I assume it?
Since I quite a few users are using distros that won't update for a while it gets even better: this trend may continue and as soon as the update actually happens we'll be so far down the road that it will be too late to take a step back and reconsider due to the delayed feedback. This is pretty much about the few people _already_ having issues with it.
That being said, if the creator wants to use AI to work on the project they are free to do so. I just hope nothing of value is lost because of it.
P.S.: If you stop writing by hand and start delegating - to AI or other people - something has changed. There shouldn't be any discussion about it. Delegation is different than writing it yourself.
A change in the sys calls that are used. That's pretty sensitive in general I think; I can see if it were introduced by an LLM why people would be upset if they experienced data loss from it.
I still have no idea what on earth why or is Gas Town. Also, he facilitated a crypto rug pull around it because he claimed the money to help support Gas Town was too good to pass up. People have lost their minds with this.
This is just a tool and it’s making people have brain damage. I don’t want this reality. It’s too stupid.
There is no reason to think reviewing AI code more then writing own wont have the same effect.
There's plenty of evidence that rsync 3.4.3 has broken a bunch of features like incremental copies, yes.
Which is why your post is a great proof of how AI derangement can make previously great engineers output broken dangerous slop.
AI psychosis is a real thing and an actual mental health issue.
What if the problem is that we train people too much to take things that are being said at face value without questioning/observing them, increasing the psychosis problem?
What matters is when the stimulus presented exceeds their resistance.
Extended AI use is a highly attractive stimulus that exceeds most people's resistance, especially when sycophantically interacted with in an echo chamber (human-AI, with no other humans in the room).
So yes, it's dangerous in the same way that cigarettes and social media are.
Just because some people can avoid slipping into it, doesn't mean we should ignore population-as-a-whole outcomes.
I think it's normal to be pissed at lost data. Maybe it's not socially acceptable to spit in the face of a volunteer but it's 100% human to feel annoyed by an obvious drop in code quality.
Why are you hedging this? Do you think maybe it is socially acceptable?
Then egos got bruised and things leave the realm of reason soon after. But coming with a request saying "Version X worked while version Y doesn't", with maybe some degree of annoyance, is fine.
1) they stop volunteering
2) they will ignore you
In neither of that is your issue solved. So maybe it's better to deal with the frustration on your own and then file a bug report.
Poor communication results in professionals firing the customer as well. None of this is exclusive to OSS of volunteer effort. But the communication in general is necessary.
This is just product management and communication issues. There is an perceived problem and the problem MUST be communicated.
Problems aren't solved by shutting up and ignoring things. And based on the discussion in this topic, it's clear there's a lot of people who are worried about rsync code quality here.
This doesn't seem egregious enough to fire the customer.
This is somebody spending their free time on code they enjoy and then putting the result online.
The reason businesses are careful about which customers they fire is because they want to keep having customers. Open source maintainers have no reason to deal with that shit.
Again: we are talking about rsync here. This new methodology being used this year seems to be associated with a regression (ie: Data loss since this is rsync after all....) that likely wouldn't have happened any other year.
Or at least: the regressions at play are consisting of thousands of lines of changes that was only navigated by Claude later down in the discussion.
We are reaching the point of AI developed code that requires AI itself to analyze. One step at a time. It's right for the open source customers who are used to understanding changes and smaller patches than this.
Otherwise, you're just a beggar. And beggars don't get to choose.
That's not why the comments are angry. The anger is directed at the slop approach to code review.
I guarantee you the same anti-AI people wouldn't give a shit if the author used an AI-enabled IDE and personally vetted all commits.
The internet/apps of the last 20 years have not exactly boosted people's ability to think critically and set aside their passions though.
Much easier to keep eyeballs glued and sell them ads if you encourage their baser impulses.
X-derangement thing is not used in reference to people whobare wrong or lying, but in reference to people who are making correct observations
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.