Live data from Hacker News

Did Claude increase bugs in rsync?

alexispurslane.github.io

501–510 of 611 posts

Re: Did Claude increase bugs in rsync?

#501
post #272

For those commenting, I suggest you read the post linked by the rsync author: https://medium.com/@tridge60/rsync-and-outrage-d9849599e5a0 (Disclosure: while I haven't talked with him in years, Tridge was my colleague and mentor for many years. I feel it is worth considering his view before joining a crusade)

I think that's an extremely well done response on his part.

[deleted]

Re: Did Claude increase bugs in rsync?

#502
post #295

For those commenting, I suggest you read the post linked by the rsync author: https://medium.com/@tridge60/rsync-and-outrage-d9849599e5a0 (Disclosure: while I haven't talked with him in years, Tridge was my colleague and mentor for many years. I feel it is worth considering his view before joining a crusade)

> I thought it would be a good idea to do the core structure for the new test suite in public on master first though given all the rage that has generated maybe that was a bad idea. I don't entirely understand what this is saying. People wouldn't have been outraged if only the tests had been updated and/or he pushed solely on master - but he pushed breaking changes onto the release branch(es) too. Breaking workflows…

"yes, there were regressions in some use cases of rsync in the 3.4.3 release. I quite deliberately tried to err on the side of fixing security issues for that release, and there were some valid (but unusual) use cases that got caught up in the changes"

Re: Did Claude increase bugs in rsync?

#503

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.

If it's decent code, but attributed to AI, how does that change things? What real-world impacts does that have? That's what I can't for the life of me figure out. Bad code is bad code regardless of who is writing it. Adding a disclaimer about how it was written is meaningless. Hell, it could say "Written by the Easter bunny" and that would have 0 impact on it's utility.

Not the commenter you replied to:

I think many people in this camp have political or ethical concerns and want to avoid contributing to or supporting the companies behind frontier-AI tools. Or they have moral or technical concerns and want to boycott usage to maintain their principles.

It should be fairly widely known at this point.

Re: Did Claude increase bugs in rsync?

#504

Earlier quoted context omitted.

Your let's redo this in Rust made me wonder if generative AI will also be susceptible to software fads. One LLM writes a few blog posts extoling a new framework/lanaguge. Other agentics read these and get 'influenced'. Then they start clamoring for 'lets redo this in X!'. Can't wait to see it. /g

You can get 80% there with rust which is what is impressive. Then you have a reference implementation that you can always check against. If a Rust library have 0 unsafe, i dont care if it is written by a dog, it still have 0 UB.

UB is especially bad but also not as big as all other concerns combined. Two of the most reliable software ever to exist, curl and SQLite, are C/C++. There are also cases in system programming, drivers etc where the unsafe is necessary and then your code is only as good as the boundary, and lots of bugs can seep in. Another issue with Rust is ecosystem - the dependency trees required to do fairly basic things are often deep and vast, meaning other risks.

That said if something like rsync was written today, I still think Rust may be a better choice. Mainly because a 95 percentile skilled Rust programmer is less dangerous than for C. The people that are skilled enough to be trusted with C are few and diminishing every year.

Re: Did Claude increase bugs in rsync?

#505
post #500

This article is a rant disguised as data analysis. I don't know how to word this in a non-confrontational, respectful way, but this article just feels like ammo for your next "debate with your anti-AI ennemies" where you get to say "look, I proved with data that those people had a disproportionate reaction and have double standards, therefore anyone who dislikes LLMs or their impact are the same!". Like, sorry, I kno…

Why is the guy being rigorous worthy of criticism, but the guys being idiots aren't? Did you post any similar calm-down comments in either of the HN threads on the original attacks?

Re: Did Claude increase bugs in rsync?

#506

Earlier quoted context omitted.

This should be the top comment. I think it's pretty sad that he even had to write it. Quite a lot of judgement from people who aren't paying his bills.

Yeah a big reason you see so much pushback on clanker slop is that it's having (and there was certainly the expectation of it having) a negative impact on the ability of plenty of people to pay their bills.

also people calling all AI is shite, might not have used top tier models. They put $20, tried Sonnet, got sloppy code and called it a day.

Re: Did Claude increase bugs in rsync?

#507
post #469

Earlier quoted context omitted.

I'll change your mind: If you pass NULL as the destination pointer, it doesn't write any string. If you combine this with %n at the end of the format string, you can get the exact length that the output string would be. Then you allocate that, then you print again, into the actual destination buffer this time.

If anything I just got entrenched in my opinion. The second best option, maybe, would be to not accept any destination pointers and have the default and only possible behavior just like what you describe.

I agree. I tend to use the gnu "asprintf" which simply returns a properly allocated char buffer with the formatted string in it. And on platforms that don't feature asprintf (windows) you can build your own using sprintf!

Re: Did Claude increase bugs in rsync?

#508
post #327

Earlier quoted context omitted.

I think Tridge is simultaneously trying to be proactive and kinda giving too much credit to marketing. Anthropic has not been able to really give numbers or actual values on what Mythos can really do. It just waved Mythos in front of the public like a boogeyman screaming that AI is going to cause a security nightmare (and it has, but mostly through vibe coded trash from what I’ve noticed); I’m hard pressed to find th…

> “I’d rather be out sailing than working on rsync security issues, so I have reached for several AI tools to help with what needs to be done,” Well, then maybe it's already overdue to find a new maintainer for the project and let someone else continue it? The tool will not get better from someone working on it who doesn't want to.

He explicitly addresses that in the article.

> Luckily I’ve been joined by some other very good developers with great systems development skills and security knowledge... Watch out for some credits for some great new rsync developers in the next release.

Re: Did Claude increase bugs in rsync?

#509

Earlier quoted context omitted.

Don't think calling a PR written by AI is the same thing as using a "tool". If code is largely generated by AI means that AI was an author and not you with some tool.

At what point does it cease to be AI generated and become my own work? If LLM generates some code but I edit it, does it become my own work? How much editing must be done? How large is "largely" ? Exactly how many bits of information must come from my fingers tapping the keyboard in order for me to qualify for authorship? Be precise. If I write something but the LLM polishes it up a bit, is it still my work? Or is it…

I don't have an answer about the stage when something should be considered authored by AI - we are in an uncharted territory on this.

There are some precedents and rulings related to copyright and AI, so we have at least some rubric by which "authorship" can be determined. But when it comes to AI doing polishing of existing code - that is less certain.

Re: Did Claude increase bugs in rsync?

#510
post #338

There's a meta-level of irony here that's important to note. TFA is defending the use of AI, and it very clearly (to me) used AI to analyze the data and present the results. In doing so, the author used statistics in a way they do not appear to understand, and ended up making numerous false claims (you can see the thread discussing these here https://news.ycombinator.com/item?id=48417626 ) In short, the study doesn't…

AI is so much like a religion. There is nothing you can say to a believer that will make them question their believes. Or more generally, you cannot reason anyone out of something that they want to believe.

AI is nothing like religion. People behave similarly to AI when debating their favorite sports team, or for Java coders, Checked vs Runtime exceptions.

Religion is about faith and what people feel and sense as much as believe.

Post reply on HN