Top
Best
New

Posted by simonpure 4 days ago

Linux eliminates the strncpy API after six years of work, 360 patches(www.phoronix.com)
https://git.kernel.org/pub/scm/linux/kernel/git/torvalds/lin...
298 points | 324 commentspage 3
pjmlp 3 days ago|
Now lets put that work into money, to assert what was the cost impact of replacing strncpy().
Trialog 2 days ago||
[dead]
qarl 4 days ago||
Am I going to be the first person to ask this after five hours? Really?

Wouldn't this work be extremely easy to implement with an LLM coder?

qustio 4 days ago||
I don't think the bottleneck was that it took six years to Ctrl-F strncpy and type in new code for each file.
qarl2 3 days ago|||
I looked at the git history. The first three years were wasted waiting for a human to pick it up. He then very slowly submitted patches over 2 years.

Claude Code doesn't need to be interested to work.

qarl 4 days ago||||
It's a shame you're misrepresenting what is actually going on.

In another comment here I explained that I have run a test: asking Claude Code to add a substantial feature to 270 different C programs.

Despite your beliefs - it went extremely well.

qustio 4 days ago|||
Huh, are you confusing me with someone else? I don't doubt Claude Code did that, I do the same for refactors all the time.

But xscreensaver theme tweaks for personal use have a much lower standard for quality control, regression testing, side effects, etc than a kernel used by billions of devices with thousands of interconnected drivers and subsystems.

Not to mention the coordination problem to get every maintainer on board and patches approved for each specific area when working on a project of that scale, even for a relatively narrow change.

Claude Code doesn't really help with that so don't see why the expectation would be a significant speed up (and doing it all in a single patch would definitely be rejected).

qarl 4 days ago||
Yes, I understand the difference in rigor.

I refuse to believe the six year delay here was getting people to test a patch.

Which, actually, Claude Code will also do quite well.

qustio 4 days ago||
Not sure why you'd refuse to believe that when a single, simple patch in Linux can take months to make it into a kernel release. Here we're looking at 300 patches scattered throughout a kernel with millions of LoC. That's going to translate to a lot of mailing list back and forth even if every change was accepted on the first try without a fuss.
qarl 4 days ago||
The lag there is not due to the review time. How many maintainers were involved? 300? Because I'm still finding it hard to understand how the work of 300 people handling 300 commits cannot be parallelized into months (per your own stat.)
qustio 4 days ago||
To be clear my original statement was that the bottleneck was most likely not mechanical code changes (where CC would have the most direct speedup) but everything else involved in the process (testing, discussion/approval, inclination towards caution, deliberately narrowly scoped changes, etc).

Not that the Linux kernel approval procedures couldn't be streamlined, work couldn't be parallelized, or anything else like that, which would be a different discussion entirely.

You stated that Claude Code could have significantly sped up the process, so the burden of evidence here should be on how specifically these patches would have benefited/time saved from using LLMs. Hand wavingly saying "LLMs = faster" is too vague/broad of a claim without providing any evidence (and also unfalsifiable).

qarl 4 days ago||
Right.

And what I'm saying is I refuse to believe the Linux kernel approval procedures are that inefficient. Therefore, your belief "bottleneck was most likely not mechanical code changes" is most likely incorrect.

It would be interesting to get the actual answer to this question.

EDIT: Substantially changing your argument after posting isn't nice. But to answer your charge - no - I never made that claim.

qustio 4 days ago||
Sorry, I didn't feel like this thread needed to be dragged out any longer since it's going in circles at this point and expanded my comment, but I didn't realize you had already replied.
qarl 3 days ago||
Well - not really a circle. I keep saying the same thing over and over and you keep throwing arguments at it, unsuccessfully.
NetMageSCW 3 days ago||
I don’t think it’s the arguments that are unsuccessful.
qarl 3 days ago||
If you have an actual criticism of my argument you'll need to be more clear to be understood.
lelanthran 3 days ago|||
> In another comment here I explained that I have run a test: asking Claude Code to add a substantial feature to 270 different C programs.

That's a different scenario, though.

Would Claude have performed adequately if it had to add a specific feature to 270 programs buried in a set of 270m program, each of which may or may not have a dependency on one or more of the others, with virtually unbounded results to test?

In terms of tokens alone, that would have been cost-prohibitive. But lets assume that you had the money to do this: it still might not even be possible.

You're confusing "I have these 270 independent programs and want to make this change to all of them" with "I have these 270m lines of code, of which only 270 needs to be changed".

qarl2 3 days ago|||
HackerNews is now censoring my replies. I did the math - all of these patches would have cost around $100.

Let's see if they'll let this account through.

lelanthran 3 days ago||
It's like you are not even reading what is being said to you. You can't find the downstream effects using grep!

You can find the "strncpy"s with grep, but you cannot find all the downstream effect of those changes, especially if something downstream is relying on the broken behaviour!

qarl2 3 days ago||
Right. I am not claiming Claude Code creates perfect software. I am refuting your claim that using it would be cost prohibitive.

I took the 10 most difficult patches from the git history - the ones that took the most back-and-forth to fix. I asked Claude to write them. Would you like to see the work?

If you believe a human performs better at finding downstream effects - you need to prove that. I see no reason why it should be true.

lelanthran 3 days ago||
> If you believe a human performs better at finding downstream effects

Once gain, you are not reading what is being said - no one made that claim!

No claim was made in fact: it was a refutation. Specifically, the refutation is "this is why it took so many years".

qarl2 3 days ago||
> no one made that claim!

You did not literally make that claim but your cost argument hinges on it.

Without it, then Claude does about the same as a human and only costs $100.

Apparently I'm reading your comments more thoroughly than you are.

qarl 3 days ago|||
[dead]
qarl 3 days ago||||
[dead]
qarl 3 days ago|||
[flagged]
Animats 4 days ago||
This is a job for Claude!

What happens if you turn a job like that over to Claude Code? A mess? Good results? Code bloat? Worth trying on existing C programs.

qarl 4 days ago|
I ran a test where I added a "light" mode to xscreensaver: unique changes to over 270 different C programs.

It mostly did an amazing job in a short period of time.

EDIT: Of course I get downvoted for saying this. HN isn't interested in reality any more.

krupan 4 days ago|||
These stories with no details and no proof are not interesting or helpful.
qarl 4 days ago||
My apologies. I did not want to be downvoted for promoting my own material.

https://github.com/qarl/qscreensaver

Animats 4 days ago||
A diff.[1]

[1] https://github.com/qarl/qscreensaver/commit/2843caba683495d5...

ninjin 4 days ago|||
> Of course I get downvoted for saying this. HN isn't interested in reality any more.

I suspect that rather many of us are simply just tired of Claude and friends getting shoehorned into any conversation about programming at this point. It is about as fun as the Rust Brigade entering any discussion about C. It adds nothing new to the discussion and it is frankly tiring since we pretty much at any time have a handful of conversations on the front page already covering "AI" topics anyway (counting four at the time of writing this).

qarl 4 days ago||
Well - except in this conversation it's incredibly relevant. It took six years to do this work when the work is likely mostly mechanical and could have been done much more quickly and safely with an automated system.

I thought automation would be interesting to HN - given the context and the fact it was not used.

krupan 4 days ago|||
An LLM is not a mechanical automated system. A deterministic search and replace would be a mechanical automated system. Clearly it wasn't that simple of a problem though.
qarl 4 days ago||
> An LLM is not a mechanical automated system.

Pretty sure that's exactly what LLMs in coding harnesses are.

krupan 3 days ago||
Still not deterministic
qarl2 2 days ago||
You understand that computer programs are deterministic unless someone explicitly injects non-determinism in them, right?

Even when they implement LLMs.

qarl2 1 day ago||
To the people downvoting me - I'm sorry, but it's true.

I know ChatGPT seems like it's non-deterministic - but that just a user preference.

The only real issue is if you have many people on the same server, the GPU contention can be non-deterministic in rare cases.

LLMs can be deterministic if you need them to be - it's just that most people prefer the human-like interface.

Animats 3 days ago|||
Right. Six years of work on a grunt job. That's what automation is for.
larodi 4 days ago|
Wonder when is someone going to brave and fork the linux kernel and try to ffwd it with automatic programming.
fragmede 4 days ago||
why would you start there instead of creating something from scratch ?if you can port drivers just as easily meaning you don't especially give a shit about hardware you're running on in the first place, why even deal with linux? The battle tested LRU cache system?
convolvatron 4 days ago|||
I've seen several workalike kernels in various stages of completion. at least one of them was able to run some pretty substantial applications (Postgres, nginx, that kind of thing), and that is still I guess around 250kloc. but it only really has drivers to support hypervisor devices.

unfortunately as time goes by, the linux api surface gets larger and more convoluted. so there's going to be some coverage you're just never going to get.

but in the abstract, definitely. linux is so bloated at this point that its not clear that it can ever be 'made safe'.

larodi 3 days ago||
Some if not most coverage will be off, indeed, but then the important stuff can get you lots of benefits. This makes sense even today for selectively patching the kernel. I’m sure many people been odd by the complexity of it while now it is doable albeit with agents…
literalAardvark 4 days ago||||
It's much easier to use something with all the edge cases already handled as a starting point.
larodi 3 days ago|||
Well in reality if you want a custom OS perhaps scavenging parts is a thing to do indeed. I just speculated whether Linux can be further improved by automatic programming and still keep the handmade parts.
bigstrat2003 3 days ago||
Going fast is only good if you're going the right direction. And with LLMs, more often than not you're going off a cliff.