It's interesting that although I guess he reviewed this LLM generated code, the human review found a race condition.
He is now the leader of a cabal of maintainers, and the only coding he does now is minor fixups for branch merging.
I suspect he still codes his own pet projects in his off time though, that's how we got git after all.
Nothing like the 2k loc people tend to commit with LLMs.
One can work with commits and MRs like that.
What is the game plan? Use an OS version older than 2023? Stop using tech?
I was one of those people. Weren't we all?
It isn't perfect, but it's certainly useful.
If he judges that Claude does the best job, it'd be very much like him to use Claude. It would be unlike him to use an open program if he considers it inferior.
I'm fine with DS Flash V4.1 in code bases I have experience in, don't really notice a huge difference other than more steering is needed.
> The code, the test programs, the review behind the list above and the first draft of this text were done with an LLM coding assistant (Claude Code) under my direction. The measurements were run on my machine.
(From the empty commit message put at the top of the draft LLM branch: https://git.kernel.org/pub/scm/linux/kernel/git/torvalds/lin...)
Nobody is really against LLMs producing, for example, exploits for novel security bugs to assist security researchers in patching those bugs. The exploit itself does not need to be Copyrightable nor Open Source. Nor is anybody against LLMs accelerating debugging, and helping find the location and root cause of the bug; again, that is not producing the end product code, thus does not need to be Copyrightable nor Open Source.
This is wrong.
> Nobody is really against LLMs producing [...]
This is also wrong. There are very vocal people against that.
> Nor is anybody against LLMs accelerating debugging [...]
And this too.
Including CC0 works as parts of works licensed in other ways is perfectly fine iirc? It's like WTFPL after all.
...that's not how copyright works. You can't poison an open source project with code that's fully and unreservedly in the public domain, if that precedent stands for much longer and if that precedent is applied to software in a way that's even vaguely analagous to how it's applied to things that judges sorta kinda understand.
> C++ is a horrible language. It's made more horrible by the fact that a lot of substandard programmers use it, to the point where it's much much easier to generate total and utter crap with it. Quite frankly, even if the choice of C were to do nothing but keep the C++ programmers out, that in itself would be a huge reason to use C.
This kind of technically-sound and valid criticism ? ;)
The ai discourse is reasonably fine on HN but as soon as you go outside of actual developer circles keep in mind that my young nephews and their ilk are posting memes and criticisms without real understanding. I hope they’ll catch on soon but for now be prepared to see a whole lot of ‘Linus using vibe code Linux going to crash lololol’ type of posts in the non-developer communities for a while.
I also don't think the C++ thing was out of a stubbornness for the old way of doing things, but had concrete reasons to reject it. I guess it was a little of both maybe 20 years ago.
But there's Rust in the kernel now too.
These people couldn't see the forest. The writing is on the wall, that Slopware is the WORST it will ever be. 1 year ago that was unimaginable. Next year, the quality of the developed software will be way better.
Selling "code" or "apps" is dead. My wife works in Workday and I've told her to sell as much stock as she can, because there will be an "inflection point" where ALL software based companies will collapse. The same way as Silicon Graphics, Sun , DEC and similar companies collapsed (along with a bit of IBM and HP, who pivoted) with the rise of PC power. Salesforce, SAP, Workday and all smaller companies that sell generic software will fall down.
Also, Linus Torvalds wrote long time ago (before v2.6.12) some simple assembly routines in linux/include/asm-i386/string.h [1] which are public domain:
NO Copyright (C) 1991, 1992 Linus Torvalds,
consider these trivial functions to be PD.
A small patch here and there of uncopyrightable code doesn't really matter. Years of small patches, on the other hand, could end up replacing most or all the code.
If you have the policy that all contributions have to be significantly written by a human, and thus copyrightable, you don't have to worry about whether certain files or modules or the entire project are copyrightable in the future.
C++ leads to really really bad design choices. You invariably start using
the "nice" library features of the language like STL and Boost and other
total and utter crap, that may "help" you program, but causes:
- infinite amounts of pain when they don't work (and anybody who tells me
that STL and especially Boost are stable and portable is just so full
of BS that it's not even funny)
- inefficient abstracted programming models where two years down the road
you notice that some abstraction wasn't very efficient, but now all
your code depends on all the nice object models around it, and you
cannot fix it without rewriting your app.Linux also built up inefficient abstractions in C that are used simply because they are easy to use. Linked lists being a go-to default choice being an obvious example.
> LLM is a horrible tool. It's made more horrible by the fact that a lot of substandard programmers use it, to the point where it's much much easier to generate total and utter crap with it. Quite frankly, even if the choice of not allowing LLM were to do nothing but keep the vibe programmers out, that in itself would be a huge reason not to use LLM
That actually sounds right ! ;)