LLMs write C for the kernel. He would hate them too if they only outputed C++.

Or, he has a full understanding that, like everything single thing he's ever been involved with in his career, it's a new tech under development and will, as every measure up to now has demonstrated, improve over time. And, as all tech that has ever existed since the beginning of man starts, has somewhat initially limited, but still very practical and real, use in its current state.

Again, he's pragmatic, and has seen countless types and iterations of tech come into existence. The people expecting perfection from the start have no actual experience with the creative process, engineering or design, and and only want progress to stop (because there is, literally, without exception ever existing, no alternative to iteration).

You haven't been banned, but quite a few of your comments have been breaking the site guidelines, and so correctly flagged.

Bummer that you got shadow banned.

I see your comment.

I usually report the bug and leave a link to it in a comment beside the work-around code.

Is your belief that Linus never had a bug caught in code review prior to Claude?

The data race is exactly the kind of subtle bug that even very experienced programmers would make in this circumstance.

The patches that Linus posted are relatively small and self contained and from reading the thread it seems came from a series of in depth conversations with Claude and were carefully reviewed by Linus.

So what we're seeing here is a tricky concurrency bug that even an expert would make. You can't use it as an example of slop

Not quite. My C++ Linux rewrite is already production ready, meaning in theory I no longer need to rely on the Linux kernel devs. This will, in a matter of months I presume, become the norm.

You can usually be pragmatic but entirely emotional about something specific. Famously, Linus is both pragmatic AND emotional about being pragmatic.

The pragmatic ones are excited about where things are going.

The ones complaining about "slop" are the ones going on vibes now.

It's fascinating how far experiences can diverge. I've had fantastic luck with it starting about a year ago, and it's been rapidly improving since.

You sound like a dinosaur looking at a meteorite.

Looks like Linus doesn't agree with you

What he actually said was:

> The kind of expectations I have is that people do their best and I expect people to understand what they are doing.

> But that understanding has very little to do with what tools they use.

> And quite honestly, in my experience, the people I respect and call intelligent are not the ones that shy away from using new and interesting tools.

He’s saying that understanding or competence are more about the person than their AI use. I think that’s a reasonable argument, even though I disagree on the basis that it’s at least a little correlated in the shortcuts in understanding the many devs I’ve seen (not all, but a nontrivial amount) seem to be taking.

As an example, I’m in the process of putting up a patch series to optimize some specific filesystem operations. The amount of boilerplate that has to know to get done is completely unapproachable to an outsider both from the amount of time needed to learn that boilerplate and form it in such a way that maintainers will be happy. Even though I know exactly how the code is working, it bridges that understanding gap but I don’t see how it correlates with incompetence. I may be an outlier but I suspect there’s a huge amount of people who are extremely capable and competent and it’s just that the Linux kernel has so many processes that it’s difficult to onboard into the community without LLM assistance.

Presumably the person who's full-time job is staying on top of proposed changes to the linux source tree knows something about this; what are your credentials on the topic?

Linus himself is actually comically incompetent. He only became famous after the Linux kernel took off... decades ago? Since Git, he has made ZERO code contributions whatsoever (not even to the Linux kernel). He doesn't even review code and has his team of capos do it for him. All in all he's no different than the CEO of some tech company, his thoughts on LLMs are no longer relevant (for more lack of credibility, see his stance on Rust, C++, Go)

how do you feel about his analogy

> Here's a new rule just for you: don't use compilers for any of your kernel submissions.

> Because if you can't show that you really understand what the machine is actually doing by writing your code in assembler, then I don't want to see your code contribution. You clearly aren't competent if you can't write it that way.

Nice rhetorical sleight of hand, trying to paint your opponents as ego-driven and senseless. But LLMs are not compilers. They cannot be relied upon to work correctly, and indeed can be relied upon to introduce bugs that a human would never introduce. The situation is different, therefore the reactions are different.

> AI may not be deterministic, but on small to medium-sized tasks it produces more correct code, more reliably, faster than a human developer does.

That is not remotely true.

> AI may not be deterministic, but on small to medium-sized tasks it produces more correct code, more reliably, faster than a human developer does. By any objective measure, not adopting it is professional irresponsibility.

How do you define correctness for any given task? If you know the correct logical process for any given process, writing it in code is just a matter of typing. The issue is that the human author, even when assisted by AI tools, does not know what is the correct algorithm for the task. In most cases, the output is probable code, not correct code.

I believe we are at a crossroads here. The key question is: Do we want (desire or require) humans to understand the implementation?

If the answer is no, then AI agents producing code faster and "more correct" (in some arguably questionable sense but let's fly with the assumption for a moment) should be embraced fully. Take the humans out of the loop, why review code, if there is a problem later then just ask the next AI agent to fix it. Similar to not looking at generated code by a compiler. Iterate fast, don't look back. Some code bases and some entire companies have adopted this view.

If the answer is yes then we need to keep the human in the loop, ensure they have enough understanding to maintain the thing, review all the code etc. AI is just another tool to produce the code which ultimately the human still owns. Many code bases follow this philosophy.

It seems to me that the discussion always ultimately falls on one of these two sides. They are incompatible but you need to pick one. Depending on which you pick, it is easy to predict how you argue in such discussions.

Yes. If you understand C code well, you have a very good understanding of what will actually happen when the binary is executed.

UB is basically impossible to avoid in practice--that is why the Linux kernel forced GCC to add a bunch of flags to "do what I mean", making UB defined in those cases.

> You must have a very weak understanding on this topic

i work on the codegen for a C compiler i'm pretty sure my understanding is better than yours <shrug>

EDIT: and also you've clearly never read that article

> One of the key attributes of a low-level language is that programmers can easily understand how the language’s abstract machine maps to the underlying physical machine

so you did exactly imply "C is a low level language"