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.
Many of us don't criticize the use of AI, but the MISUSE/ABUSE of it. It's one perfectly valid use case to let it generate code, and do a manual code review to make sure all of it is solid. It's the lowest of the low as a developer to ask it for a complex program, do a superficial review, and ship it claiming you did it.
And no, those of us boycotting projects using LLMs don't have an immediate solution to everything under our feet, including our jobs, adopting LLMs.
What reply did you expect? That we apologize for being wrong and that we recognize that in hindsight, the AI boosters were right all along? We still don't want these polluting data centers next to our homes so they can feel more productive and play with their costly toy. Hell, even if they are useful / the productivity boost is real, actually we still don't want those shit datacenters, this wreckless scraping, the major economic crisis that the AI companies may cause through their wreckless behavior and more generally all the badness attached to LLMs.
In comparison the US is a baby, and the Linux kernel barely an embryo.
Depending on how you count, Rome lasted 1229 years (from founding to fall of the western empire) or 2206 years (from founding to the fall of the Byzantine empire, which was the eastern part).
Twelve hundred years! Two thousand years! I hope we dig our graves as slowly as the Romans did.
Civilizations have collapsed and mostly to reasons they could have avoided, not my area but sounds like a strange point to make a stand on
What is the game plan? Use an OS version older than 2023? Stop using tech?
A lot of us are discussing the best pre-slop kernels to use, and tech has ceased to be an exciting passion so yes to both.
I was one of those people. Weren't we all?
It isn't perfect, but it's certainly useful.
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.
Why are you saying it will be way better when American companies asked their government to hit the breaks?
Yeah, I don't believe you.
Nothing like the 2k loc people tend to commit with LLMs.
One can work with commits and MRs like that.
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.
> This is wrong.
Has this actually been litigated? It seems to one of those things where two camps think the answer is obvious, they’ve got it, but they disagree.
I would love to see the opinion of a copyright lawyer that would be willing to bring an LLM output copyright case to the Supreme Court, their opinion must be absolutely wild.
This whole thing was most recently affirmed in the 9th Circuit case Naruto v. Slater, where a monkey used a photographer's camera to take a selfie, and the photographer claimed he owned the Copyright because it was his camera, and then attempted to extort the Wikimedia Foundation. Monkeys are clearly intelligent and actually alive (unlike LLMs) yet that still did not alter the opinion of the Judges based on the current interpretation of the Copyright Act (which clearly states only humans can hold Copyright) and all the decades of case law proceeding this case.
As for specifically GenAI, the case involving Théâtre D'opéra Spatial also moved in this exact direction: it is a Midjourney manufactured image that the prompt-giver attempted to Copyright, and the USCO rejected the application and the USCO Review Board also rejected it, however the prompt-giver has not elected to sue the USCO over this.
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.
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.
[1]: https://github.com/torvalds/linux/blob/v2.6.12/include/asm-i...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.
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.
> be prepared to see a whole lot of ‘Linus using vibe code Linux going to crash lololol’ type of posts
I mean, we see a lot of this in the developer community as well, already.
> 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 ? ;)
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 ! ;)
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.
(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...)
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.
https://lkml.iu.edu/2610.1/13146.html
https://mirrors.hust.edu.cn/git/linux.git/commit/?id=4c0f369...
I can see how you could use AI to design and implement some 100,000 line codebase, full of nothing but that, stamped out over and over in exactly the same pattern and never read a single line of the code.
> therefore anyone can
_Absolutely_ anyone can. If you want proof of this just download the latest kernel tree and ask Claude to write a new module for you (whether it's a driver, a new syscall, or anything really) and see how far you get. Within an hour (sometimes less) you'll have a perfectly working kernel component.