Hacker News Board Hacker News, browsed like a classic message board
Live data from Hacker News

Did Claude increase bugs in rsync?

alexispurslane.github.io

Post reply on HN
Print view View original

481–490 of 611 posts

Re: Did Claude increase bugs in rsync?

#481

Post by wzdd »

runarberg wrote: post #357
logicprog wrote: post #215

Earlier quoted context omitted.

Edited that claim, and made several clarifications elsewhere. The whole point of this analysis is that outrage is unjustified on the basis of two totally statistically unremarkable releases that no one would have remarked on pre-AI (my further proof of this is that there was a pre-AI remarkably broken release, and no one did comment!) and zero positive evidence outside cherry-picked anecdotes for any negative impact.…

There is a lot more context to the outrage which is missing from your analysis. People have multiple reasons to be mad at AI usage, you mention some of them in your introduction, and you put a (statistically insignificant) measure on only one of them. In your analysis you have shown that exactly one of these reasons is anecdotal. That does not mean they are wrong, and it especially does not mean they are unjustified.…

> In your analysis you have shown that exactly one of these reasons is anecdotal.

This was actually the convincing one for me though. “Did AI increase the rsync bug rate? Dunno, can’t tell yet” seems like a fine conclusion to me. Plenty of people in this thread and previous ones on the topic seem convinced one way or another, so it’s nice to see actual numbers.

Re: Did Claude increase bugs in rsync?

#482

Post by wang_li »

nl wrote: post #464
Eufrat wrote: post #397

Earlier quoted context omitted.

I just cannot understand this logic, can you explain why there is no responsibility whatsoever on the part of a maintainer towards the users? Selling a toaster has an implicit warranty of merchantability. Society expects that if you sell me something, it should have certain promises. Yes, there’s no monetary exchange here, the work is given gratis, but there’s still a relationship and an interaction here and I think…

> Selling a toaster has an implicit warranty of merchantability. Society expects that if you sell me something, it should have certain promises. Yes, there’s no monetary exchange here, the work is given gratis, but there’s still a relationship and an interaction here and I think it is clear some people, like myself, believe that there are implied expectations. No there isn't. Pay money and there's a contract. Anythin…

If you induce someone to expend resources you can have liability even if those resources are not a payment to you. You can’t license your way out liability if you advertised, formally or informally, certain features and functionality that cause people to act on that advertisement. It’s called reliance interest. It’s an actual legal principle with case law supporting it.

Re: Did Claude increase bugs in rsync?

#484

Post by akerl_ »

wang_li wrote: post #482
nl wrote: post #464

Earlier quoted context omitted.

> Selling a toaster has an implicit warranty of merchantability. Society expects that if you sell me something, it should have certain promises. Yes, there’s no monetary exchange here, the work is given gratis, but there’s still a relationship and an interaction here and I think it is clear some people, like myself, believe that there are implied expectations. No there isn't. Pay money and there's a contract. Anythin…

If you induce someone to expend resources you can have liability even if those resources are not a payment to you. You can’t license your way out liability if you advertised, formally or informally, certain features and functionality that cause people to act on that advertisement. It’s called reliance interest. It’s an actual legal principle with case law supporting it.

Can you cite the case law about an open source project having a reliance interest?

Re: Did Claude increase bugs in rsync?

#485

Post by Leynos »

eschaton wrote: post #198
thorum wrote: 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.

Outside of situations where it is required by contract, attributing AI usage is a courtesy, nothing more.

Re: Did Claude increase bugs in rsync?

#486

Post by ekidd »

kelnos wrote: post #435
ekidd wrote: post #358

Earlier quoted context omitted.

Calloc is generally hardening, because it zeros out any stale memory contents left over from previous uses of the memory. You can avoid this overhead if you use a language that forbids reading from uninitialized memory, but C is not that language.

Uninitialized memory is not a problem (the OS is never going to give a program memory that has data in it from another program). The problem is memory that you allocated in the past, have freed, but hasn't been returned to the OS[0]. It might have key material or other sensitive data in it[1]. Or it might just have random garbage in it that could be misinterpreted by the code that's about to use it, if it hasn't been…

> The problem is memory that you allocated in the past, have freed, but hasn't been returned to the OS[0].

There are at least two different ways in which memory might be semantically "uninitialized":

1. The memory was provided by the OS. On modern desktop and mobile OSes, this memory will normally be zeroed automatically. 2. The memory was provided by the language's allocator. This may contain a mix of data used by previous allocations and memory that has never been touched (perhaps because previous allocations reserved it as end-of-array "capacity" that never got used). From the perspective of a language like Rust, this memory is considered uninitialized, and safe code should never be able to read it without first setting it.

In ancient C code, it makes a fair bit of sense to preemptively calloc everything. Or better, to wrap the allocator with one that zeroes on free. Though even there, you need to be careful not to expose recycled heap block headers in the middle of newly allocated objects.

My opinion for the last 30+ years has been that C is unfit for purpose, and that using it almost inevitably introduces large numbers of dire security holes. But until the last 10-15 years, there hasn't been any seriously viable alternatives.

Re: Did Claude increase bugs in rsync?

#487

Post by jodrellblank »

kelnos wrote: post #423
Eufrat wrote: post #397

Earlier quoted context omitted.

I just cannot understand this logic, can you explain why there is no responsibility whatsoever on the part of a maintainer towards the users? Selling a toaster has an implicit warranty of merchantability. Society expects that if you sell me something, it should have certain promises. Yes, there’s no monetary exchange here, the work is given gratis, but there’s still a relationship and an interaction here and I think…

> can you explain why there is no responsibility whatsoever on the part of a maintainer towards the users? Because I don't. It's that simple. There is nothing that says I have a responsibility, and the license I release under even makes it clear and explicit that I have no responsibility. So I don't. If you are going to claim that I do have a responsibility, then the onus is on you to present some solid, convincing,…

> “solid, convincing, extraordinary evidence or argumentation to support that.”

Just ordinary evidence. If there was a charity event which asked for a volunteer to organise drinks, and you volunteered, and then there were no drinks, and you said “I don’t owe you anything stop being entitled, if you want an event with drinks you can fork the idea and organise your own”, people would be unhappy and reasonably so. It’s not that you had a legal obligation to do that work, it’s that you told everyone you would and that stopped other people from doing it.

If rsync had no maintainer and someone publicly offered to take it on and maintain it, that would also block other people taking that spot. It stops people investing time effort and money into a fork or replacement to an abandoned project. If the volunteer then either didn’t do anything or wrecked it and said “I don’t owe you anything etc.” that would be bad in a similar way.

If you want to be able to tell people you are the maintainer, that the thing is maintained, and you get to control what happens to a widely used project, you can’t really stand by the position “why did people expect me to maintain it? I only told them I would maintain it, why would they believe me, that’s not fair”.

Make it clear that it’s abandonware and has no maintainer, and you can totally uphold the “not my problem, says so in the license, deal with it” position. But if your thing becomes popular then you should expect a company like RedHat to fork it into ‘redsync’ and run it their way as their project, not look to you as ‘upstream’ and sideline you completely. Which is what a lot of open source people say they want but don’t behave as if they want that. Probably because there actually is some prestige and power and status and reputation involved, even though people try to claim there isn’t.

Re: Did Claude increase bugs in rsync?

#489

Post by tptacek »

Eufrat wrote: post #397
tptacek wrote: post #387

Earlier quoted context omitted.

No there isn't.

I just cannot understand this logic, can you explain why there is no responsibility whatsoever on the part of a maintainer towards the users? Selling a toaster has an implicit warranty of merchantability. Society expects that if you sell me something, it should have certain promises. Yes, there’s no monetary exchange here, the work is given gratis, but there’s still a relationship and an interaction here and I think…

You don't have the impression that project managers should "be allowed" to run projects "as they see fit"?

Re: Did Claude increase bugs in rsync?

#490

Post by UebVar »

eschaton wrote: post #222
UebVar wrote: post #211

Earlier quoted context omitted.

I'm very certain that this is not fraud, across multiple legal systems, both roman and common law. In both cases fraud requires a person is deprived of a material good. Neither the defrauded person or their material loss is present in this case. Maybe there is a oddball legal system somewhere in the world where fraud is something entirely different, but i doubt it. "Fraud", just like "Decorator Pattern" is a well est…

It is misrepresentation for gain, that gain does not need to be monetary to be material. For example, it can be reputational. It also is copyright infringement, because what the LLM “generates” are actually portions of its training set, which were covered by copyright. Just passing through an LLM does not remove that copyright from that work.

No, you are wrong.

In German and French (roman) legal systems this is a "Vermögensdelikt", and explicitly about material damage and gain. Yes, common law can be more broad (in canada it isn't really, it just also includes service, btw.), and yet it clearly does not meet the definition, as there is a damaged/defraued party and fraudulent/gaining party. We are not talking about somebody usurping somebody else reputation, after all.

You misuse a technical term that is well established since antiquity.

You do not know what this word means. If you want to argue about semantics, look up the definition. This works especially well for legal terms as laws define them.

(That said, IANAL and there are very many different legal systems and I am not ruling out there exists one that is competently different - laws can be changed a will, after all.)

It is also obviously not copyright infringement, because this is simply not how copyright works, at all. I cannot and will explain of all copyright here. Instead I will point this out: Every code produced by a human who read copyrighted code would fall under your definition.

Post reply on HN