[roenxi]

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]

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]

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.

[pmarreck]

Related: I'm writing a file-format validator whose first focus is on image data.

https://validate.pics

Also related: I'm using LLM assistance to write it, but I also have a test suite that proves it's working (I call it the "shotgun" suite: given a good image file, it first flips a random bit ("sniper"), then a random byte ("boltgun") and then a random 4096 byte segment which is the typical sector size ("shotgun"); each time it tries to validate the file by decoding it fully, and records what percentage of time it is detected at each scope, and it collects statistics about this over hundreds of times.)

The point of it is to detect things like corrupt data and bitrot... across 240+ different filetypes so far... since no other tool really exists yet in this space to do that.

Note that some formats, notably Apple's HEIC, are so data-dense that corruption only results in undetectable image corruption (well, a human would notice it, but an algorithm cannot!) So I have ANOTHER app coming to help with that which does detection AND repair (to a point). ;)

The CLI will be free and open-source, but I'm also writing a for-sale-in-future private-source GUI for it.

[Npovview]

Do you not do the md5 or sha hashes of the copied zip file?

[zimpenfish]

That's ... what rsync is supposed to do for you.

[seba_dos1]

zip file?...

I was syncing photos from my phone.

[nottorp]

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

Why would they roll a new release straight into production without testing it first?

[michaelmrose]

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.

[bakugo]

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.

[msm_]

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

This is something that you assume, not something that you have any proof of. To put it a bit more strongly, this is something that you (and hundreds of other people in that github thread) made up in your head. The maintainer is a very experienced OS developer and there's no reason to suspect they didn't review the committed code.

Bugs happen, and the mere existence of bugs is not a proof that someone is doing a poor job. Assuming those bugs even exist. I am inclined to believe they do, but the issue does a poor job of reporting them. Instead of factually reporting regressions, the "issue" is a screenshot of a viral tweet.

Your vicious reaction is not justified, and you should do better in the future.

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

It is not fair. The rsync maintainer does not owe you anything. You owe them for using their software. How much did you donate to rsync this year?

[bakugo]

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

We both know what the more likely scenario is here. We both know that AI fanatics have spent the last year bragging about how many thousands of lines of code they can pump out per hour. Do not claim otherwise, because to do so would be an insult to my intelligence. And from a quick look at the developer's Github profile, it's clear they've gone all in on the hype, as I cannot find a single significant commit made this year that is not signed by Claude. Even the most experienced developers are not immune to AI psychosis.

> You owe them for using their software. How much did you donate to rsync this year?

I don't remember reading this in the license. Could you point it out for me? I can't find any such clause.

[michaelmrose]

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

Any request that doesn't come with a promise of payment is panhandling. We have become so accustomed to overwhelming generosity and a cup that runeth over that instead of being grateful that our free hot soup comes a condo and a masseuse that we are spiteful when it isn't to our taste.

The random user should spend time analyzing the code because helping someone help you is part of the social contract that comes with having someone whose time would cost $400 - $1000 an hour as a contractor personally gift his time to you.

If ungrateful folks forget this we might find this resource increasingly scarce.

[michaelmrose]

Because they actually want something fixed as a long term user of a software.

[margalabargala]

> Nothing but dripping contempt for their betters.

I didn't see this.

[michaelmrose]

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]

I read that, yes. I think I'm missing the part where the maintainer is "better".

[michaelmrose]

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.

[nottorp]

> Nothing but dripping contempt for their betters.

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

[michaelmrose]

They don't make anything and they shit talk those who do

[LtWorf]

They shit talk those who also don't make but use AI to destroy.

[throwaway7356]

Which are identical to those who wrote rsync in the first place.

So given the rsync author did not make anything in the first place, they also cannot go destroy rsync as there is nothing to destroy.

But well done defending abuse.

[krcz]

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.

[xiphias2]

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]

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

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