Rsync 3.4.3 might break incremental backups for you. Revert to 3.4.1 and it will work again; "Since 3.4.1, 36 commits by "tridge and claude"". Nothing is safe.

[-]

GenericRedditor12345@reddit

A doctorate in comp sci and pulling shit like this…

[-]

ender-_@reddit

Don't worry, it gets worse:

https://mastodon.social/@Ferdi_Scholten/116656414698174544

Some of these commits are repairing defective generated code with other generated code.....

https://eldritch.cafe/@tati/116656417412838049

looking at the github issues, one might suspect there are no integration tests, or they aren't being run. you shouldn't be able to break this many things at once

[-]

TheG0AT0fAllTime@reddit

I can't even sigh at this. I hate this shit.

[-]

dnuohxof-2@reddit

So do a lot of people, and yet here we are. AI is going to continue to be shoved down our throats by stubborn first adopters who can’t reckon with the fact they’re wrong.

[-]

LLM have made me more productive than ever. Whipping up YAML and simple code changes that would take me hour(s), sometimes purely because it's so fucking boring that I'd jump at any other task, and that would cause context switching.

I don't need to write a configMap helm template or podAffinity rules from scratch, I can do that in my sleep but it soul crushing.

You'll pry away LLM generated busy-work from my cold dead hands.

This is nothing different to when IDE's first came up with intellisense.

[-]

420GB@reddit

"Simple code changes that would take one hours" can often be done by multicursor editing, sed or IDE / LSP features that understand the AST of the code.

[-]

BrainWaveCC@reddit

Surely, you can see the difference between your anecdotal gains, and the aggregate pain that is being inflicted on the greater population?

[-]

fadingcross@reddit

I see LLM's as a net good for people and society in general.

The sewing machine put a lof of seamstresses out of work.

The excavator put a lot of diggers out of work.

Are you gonna argue those didn't turn out as positive things in the end?

[-]

The_Original_Miser@reddit

One does not have to check a properly configured sewing machines work after the fact. That's the difference in my opinion.

[-]

BrainWaveCC@reddit

You're clearly missing the key difference between what is being discussed here vs the examples you have brought up.

No one here is suggesting that there is no value from LLMs. And there is no one here who would care if other people wanted to use LLMs for everything that affected them only.

But that's not what the original post is about. That's not what our broader concerns are about.

The relationship between the rise of sewing machine usage and the prevalence of cheap/shoddy clothing was never as direct as the relationship between the rise of LLM usage and the prevalence of poor code that affects the rest of us.

The scope and scale of the issue being discussed is very, very different from the examples you have provided, your awesome personal experience notwithstanding.

[-]

mangeek@reddit

purely because it's so fucking boring that I'd jump at any other task

Funny thing. A salesperson bro a few weeks ago was like "no more writing parsers. After all, who likes writing parsers, right?" and I was like "I do."

...and my parsers actually adhere to the schema we use, instead of adhering to whatever the LLM imagines the schema is that day.

[-]

dnuohxof-2@reddit

There’s a difference between using LLMs as a tool to assist, not do all the work for you. The sewing machine is a tool to sew, still operated by seamstresses. The digger is operated by experienced diggers, used as a tool to augment the workload of the job. LLMs can do the same.

Except when people let it do their whole job. 30+ commits using agentic-generated code that introduces a profound program breaking flaw is the problem.

I liken LLMs to the answer key to a math quiz, but the quiz you have is a different version. There are those who are smart enough to realize their test is different and the answer key can lead to the correct answer via clever inferencing, or you have those who aren’t, take the answer key as gospel, and get everything wrong.

[-]

FenixR@reddit

The problem its when people try to use it on big projects unsupervised, context window for LLM its so stupid small for these kind of task that lo and behold it perfoms shitly.

[-]

ccsrpsw@reddit

The two I spot checked (since Im not up with Rsync but at least "read good c" LOL):

Replaces a "bytef *buf" to "const bytef *buf". Which, while it may not do much and be a corrected change, wasnt regression tested, and if that code behind it did modify the buf variable, because it had a separate bug, it can't now - which may have unintended consequences. Just marked with a change of 'fixing function definition'.
defines a strlcopy with... nothing? So basically changes a string copy to a NOP. To stop a compile error. Which, without seeing what that line of code does, would mean that when it goes to move data around, it would silently succeed by doing nothing. Great idea.

Both of those changes alone could result in data not moving around. Again without delving into the actual meat of the changes, they are slop "1 line" fixes with no real meat behind WHY they are changed. So this is what we have to look forward too (my post here is longer than the explanations on either of them!).

[-]

AuroraFireflash@reddit

one might suspect there are no integration tests, or they aren't being run

So much this. No tests? No ship.

(I had to fix tests not running on an internal project this week. So many failed tests that were missed during the build pipeline.)

[-]

gered@reddit

Be careful even on 3.2.7 ... The latest updates for that version that we pulled on our various Ubuntu servers (22.04, 24.04 and 26.04) also broke our rsync backups in similar ways to the issues that appear to be affecting 3.4.3. Haven't done a super deep investigation yet, but rolling back to the previous version fixed the issue.

[-]

cvc75@reddit

I think the bugs belong to a security fix, so Debian/Ubuntu backport those to older versions too.

[-]

Kurgan_IT@reddit

It's AI SLOP from now on.

[-]

jimicus@reddit

That's the thing; some of the coding tools are pretty good.

But debugging is invariably ten times harder than writing the code in the first place, and not always something an automated tool is so good at. Where are we when the automated tool does all the entry level work, there haven't been any entry level jobs for ten years and people are starting to retire?

[-]

PineappleOnPizzaWins@reddit

As someone who does a lot of development work.. the tools are fine. They need refinement and have lots of room for improvement, but they're decent enough.

The problem is how people are using them. There is a huge difference between skilled developers who are using AI to speed things up in a product they know really well, and people who no clue saying "CLAUDE GO FIX".

Say you get a bug, an idiot might say "go fix that bug and make it work" and away the AI goes and whatever it thinks will work is how it gets it done. A good developer workflow with AI is more like:

Tell the AI the issue and ask it to track the bug.
Take the results, test, check, confirm yourself.
Ask AI to suggest options for fixing, usually with an idea in mind already.
Read through the suggestions and because you know what you're doing spot any pitfalls etc.
Once you have a good handle on it, either fix yourself or tell AI to do it and CHECK THE CODE.

The latter, combined with an understanding that the AI is your junior dev and needs constant reminders about best practices/idiomatic code and stopping them going down the wrong path? AI can be a genuine productivity tool for developers.

The problem is that's not what people are doing. They're trying to replace developers... and that is currently working out about as well as replacing your builder with a nailgun duct taped to a ladder.

[-]

preparationh67@reddit

Cool story, the dev who produced the slop isnt some unskilled nobody so your entire argument is based on assumptions you didnt actually check out which...yeah that fits with the entire topic of the post.

[-]

ccsrpsw@reddit

Exactly... need a UI mocked up in PowerShell using the WinForm... describe it and 800 lines generated for it super quick. BUT still comb through the code and check it.

Need a "framework" for some code - great.

But please please please, double check the functionality once it starts to manipulate real world things on a system or user data or anything meaningful.

[-]

gruntbuggly@reddit

There are still entry level software engineer jobs out there. In fact, they're making a comeback. I know of one company that is hiring recent college graduates because they're familiar with AI and they hope that will influence their older, more AI-resistant, engineers. And I recently heard of another company that is back to hiring entry level coders because they're cheaper than paying a frontier model's token costs for the grunt work.

Just wait until after the IPOs when the frontier labs need to start showing their investors a profit, and we start to see what real token costs look like.

[-]

Centimane@reddit

Companies have been focused on short term gains for decades.

Make number go up 2 right now, but will go down 10 sometime in the future? They take that every time.

[-]

AndyceeIT@reddit

Stupid question - looking at the commits, am I correct saying it looks like "Tridge and Claude" is Andrew Tridgell using Claude Opus?

[-]

segagamer@reddit (OP)

I'm hoping he doesn't break something in Samba

[-]

TheG0AT0fAllTime@reddit

Yeah

[-]

Izder456@reddit

https://www.openrsync.org/

Non AI devs might need to contribute to this now.

[-]

jmbpiano@reddit

This sort of thing is why I'm generally a-ok with Debian Stable often being a version or two behind upstream on most packages and just backporting security patches.

In this case, though, I'm wondering if it helps or not. Debian's current rsync package reports as 3.4.1 (technically "https://packages.debian.org/stable/rsync"), but since it sounds like the bugs originated in security fixes, does anyone know if the breaking changes might have been backported to Debian's version of 3.4.1 or if it's still safe?

[-]

limeunderground@reddit

I'm not against a bit of LLM assisted development but the output should be tested thoroughly and reviewed for a project like this.

[-]

BrainWaveCC@reddit

For any project...

[-]

Dependent_House7077@reddit

sounds like lack of testing, if you ask me.

ai assistance can help a lot, if it's used carefully.

[-]

MindStalker@reddit

https://github.com/RsyncProject/rsync/issues/915 This is what was fixed. Claude code is not in rsync. Someone is lying to you.

[-]

notR1CH@reddit

https://github.com/RsyncProject/rsync/commits/master/

It's trivial to see that Claude is being used here.

[-]

MindStalker@reddit

Yes, it's being used to check code that a human is submitting.

Likely the security fix broke their process, they had to change how the daemon works to avoid the exploit.

I doubt there is a fix that doesn't break daemons.

[-]

Wenir@reddit

No, it's Co-Authored

[-]

noc-engineer@reddit

I'm not trying to state that you are wrong, but what are you basing that claim on?

[-]

Valmar33@reddit

Stuff like

Co-Authored-By: Claude Opus 4.7 (1M context) noreply@anthropic.com

[-]

noc-engineer@reddit

And I've read a bunch of master degree dissertations where the co-authors didn't write a single character, barely even read the dissertation but the student "had" to include their professor/mentor in it. Even some where the mentor ended up stealing the work for his own publication (and even gave the student a bad grade).

[-]

bingblangblong@reddit

When a commit says co-authored, that means claude code literally wrote the code. If you want claude to check your code, you use it in your IDE like vscode, and ask it there.

[-]

mineriffic@reddit

And no one ever does that but also puts the co-authored by claude in their commit

and all ai code is bad code of course

[-]

Xetrill@reddit

Its not a claim, its the truth. Just read for crying out loud.

[-]

Valmar33@reddit

Yes, it's being used to check code that a human is submitting.

You assume a lot here. For all we know, Claude generated all of it, and it was poorly "checked" or even not at all. Perhaps a human submitted it, but that means nothing.

[-]

Valmar33@reddit

https://github.com/RsyncProject/rsync/issues/915 This is what was fixed. Claude code is not in rsync. Someone is lying to you.

Are you perhaps trying to lie to us and are doing so poorly? Example commit:

https://github.com/RsyncProject/rsync/commit/4f5a5857ce51f2ec0c564f3ed006ed9f7297402b

Co-Authored-By: Claude Opus 4.7 (1M context) noreply@anthropic.com

This can mean anything at all, from merely reviewing to outright generating all of the code. With such vagueness, I just assume it was entirely generated, regardless of what excuses are made. LLM slop is ruining everything.

[-]

loozerr@reddit

So were those commits confirmed to be the root cause?

defines a strlcopy with... nothing? So basically changes a string copy to a NOP. To stop a compile error. Which, without seeing what that line of code does, would mean that when it goes to move data around, it would silently succeed by doing nothing. Great idea.