Live data from Hacker News

Did Claude increase bugs in rsync?

alexispurslane.github.io

191–200 of 611 posts

Re: Did Claude increase bugs in rsync?

#191

Smokescreen of highly-contingent analysis and appeals to authority over a premotivated-conclusion.

[flagged]

> My fucking wife? That's me a) being really proud I married such a baddie

Good for you. I really mean that. I think people are winding you up in this thread, but keep your cool, and I admire publicly crediting and being proud of your wife. That’s a healthy relationship. Good for you.

Re: Did Claude increase bugs in rsync?

#192

Earlier quoted context omitted.

Let's start with most outright alarming error - the claude statistics are taken out of whole 2 data points

The interpretations of the p-value is also alarming. One of the first thing they teach you in statistics class is: “an absence of evidence is not evidence of absence” . This analysis showed that there is indeed an absence of evidence, but it concludes there is evidence of absence. Traditional p-hacking is done by oversampling and overtesting. If you do 20 analysis on average one will show p p > 0.05

> This analysis showed that there is indeed an absence of evidence, but it concludes there is evidence of absence.

I tried pretty hard to avoid saying that, can you point me at how to rephrase? The point I'm trying to make is just that there is absolutely no evidence at all for what people are saying with such absolutism and claimed objectivity (that Claude made rsync worse), and thus it doesn't justify the outrage.

> Under-sampling, and concluding with p > 0.05

How would I avoid under-sampling here? And if you're going to say it's because I only have 2 data points, well, the side making the positive claim — that Claude made rsync worse — only had two as well, and unremarkable ones at that, as I've tried very hard to show.

Re: Did Claude increase bugs in rsync?

#193

Earlier quoted context omitted.

That's sort of the point. There isn't enough data to extrapolate, and yet that's exactly what those outraged about AI were doing, and when you do do the very minimal types of analyses (permutation tests, and looking at distributions, mostly) that are actually valid, safe, standard, and useful to do on such low amounts of date, again, no evidence for the outrage shows up, and the two releases look so normal that it so…

I know you’re defending your work here but this behavior does absolutely nothing to help your point.

Fair point. Let me edit (if I still can) to tone it down.

Re: Did Claude increase bugs in rsync?

#194
post #189

Earlier quoted context omitted.

Nope. It cannot be assumed at all. Maintainer could just as easily tell Claude to review the hand written code you sent instead of spending any effort on it. Maintainer could sit on the patch for months on end only to swoop in later and rewrite it instead of engaging with you, thereby erasing your contribution and attribution. Maintainer could just ignore you entirely despite the pervasive "patches welcome" attitude.…

I'm referring to the fact that "open source" quite literally means "readable by humans [and machines]", and anything beyond that is a subject of debate. There are more users than readers in nearly all cases, but being able to read the code as a user is a significant benefit at times, and it's one of the reasons it's such a large ecosystem in terms of both users and contributors. (it usually being free is another big…

I see. That depends on how much I care about the project. My favorite ones get weeks of review and refinement, to the point I still consider them to be more or less hand written. Not all projects get to be that important.

Re: Did Claude increase bugs in rsync?

#195

Earlier quoted context omitted.

The interpretations of the p-value is also alarming. One of the first thing they teach you in statistics class is: “an absence of evidence is not evidence of absence” . This analysis showed that there is indeed an absence of evidence, but it concludes there is evidence of absence. Traditional p-hacking is done by oversampling and overtesting. If you do 20 analysis on average one will show p p > 0.05

> This analysis showed that there is indeed an absence of evidence, but it concludes there is evidence of absence. I tried pretty hard to avoid saying that, can you point me at how to rephrase? The point I'm trying to make is just that there is absolutely no evidence at all for what people are saying with such absolutism and claimed objectivity (that Claude made rsync worse), and thus it doesn't justify the outrage.…

You are interpreting the p-values on their own merit rather then using them to test a null-hypothesis. Quotes like:

> With a p-value of 74%, the answer is a decisive no. The odds ratio is 1.06 — essentially 1:1. Claude releases are no more likely to be above the median than any other releases.

are problematic in this context as the correct conclusion here is you just don‘t have enough data conclude whether or not you are more likely to encounter a bug after a Claude commit.

> How would I avoid under-sampling here?

You don‘t. You admit that you don’t have enough data and move on. What you are trying to do here is prove a negative, which is extremely hard to do. In your discussion you claim that the users complaining had no right to, however nothing in your analysis showed they were wrong. We simply don‘t have enough data (yet) to say either way. When we have enough data they may be proven right or wrong, but until then, we cannot conclude either way.

If you insist still, I recommend looking into bayesian analysis. Theoretically at least the posterior distribution from a bayesian analysis can be interpreted directly and analyses on its own merits. However I suspect your posterior will have way too much uncertainty to reach any conclusions.

Re: Did Claude increase bugs in rsync?

#196
post #170

Is there a non vibe coded fork of rsync?

There is openrsync, which the OpenBSD re-implementation of rsync It's not a fork, but it's 8 years old, and is already shipped by default in OpenBSD and macOS.

It's also not feature-equivalent to rsync. But if it meets your needs, it's an option.

Re: Did Claude increase bugs in rsync?

#197

Earlier quoted context omitted.

> You’re just going to make people disable Claude attribution on their commits to avoid drama. People should be doing this regardless of drama. No reason to provide free advertising for trillion dollar corporations. Generated-by trailers are only relevant when contributing to third party projects, in that case disclosure is polite.

The value of the Claude attribution is that you can tell at a glance who used AI. I don't care about the advertising angle. We all know Claude by now. I want some indicator that AI was used.

At my employer, if AI is not used, it shows up on your performance report and you’ll be told if you don’t start using it, you will be dismissed. I work at a medium sized successful YC-backed SaaS. So here, the attribution is meaningless - they look at your Bedrock and LLM API calls as well as Claude Code history.

Re: Did Claude increase bugs in rsync?

#198
post #80

Unfortunately for the people mad about this, I predict the only thing they will accomplish by pressuring the rsync maintainers, is to discourage everyone else from responsibly disclosing their use of AI. You’re just going to make people disable Claude attribution on their commits to avoid drama.

“Don’t get mad at people for doing something unethical or immoral, or they’ll do something unethical or immoral!”

Disabling attribution of LLM-generated code is fraud, because you’re saying you wrote the code.

Of course that fits right in with the use of an LLM to generate code in the first place, since what it’s actually doing is regurgitating its inputs stripped of any license and copyright notice.

Re: Did Claude increase bugs in rsync?

#199
post #29

Ok. $ apt-cache policy rsync | grep Installed Installed: 3.4.1+ds1-7ubuntu0.2 $ sudo apt-mark hold rsync rsync set on hold.

Did you face any actual bugs or regressions? Or are you doing this just because of the bandwagon that's going around right now? Because until you can actually present an argument for why this release is worse than any of the others, which is precisely the subject of my post, then this is not an argument against my post at all. This is just a self-referential appeal to authority.

> Did you face any actual bugs or regressions?

This is a terrible argument; I didn't need to have had secrets exfiltrated before applying row-hammer mitigations. If rsync is the cornerstone of my backup strategy, and has been for years, I need to trust that on its correctness, and for it to not lose my data. If I wait until I "face any actual bugs or regressions" - that will be far too late.

Stability is another issue not discussed. If the error rate holds steady, but number of significant PRs merged per release goes up from 5 to 200, that would be huge net-negative for my use case.

Re: Did Claude increase bugs in rsync?

#200

Earlier quoted context omitted.

The value of the Claude attribution is that you can tell at a glance who used AI. I don't care about the advertising angle. We all know Claude by now. I want some indicator that AI was used.

And why do you want to know that? So you can call our projects slop? Ostracize us?

So we can know which commits will be infringing others’ copyright.
Post reply on HN