Having links to backup what you claim is always a good thing, so thank you for this. I have blocked X/Twitter, but do not care about the political statements anyway. So no need to lookup for me.
For the false information on the technical explanation, well I can't confirm what it is, because I never really understood Monads. Now that does not mean his his approach to how software should be thought off is wrong. But I understand why someone is careful after such statements (if its plain and simply wrong). The thing is, everyone makes mistakes and false statements at some time. It depends on how often this happens and how the situation is handled, if the person admits it and learns from the mistakes.
Therefore I wouldn't just say his books are dumpster fires. I personally didn't read his books, but there are people who seem to like it. The best is someone reads it themselves and finds out if its for them or not; provided its not false information.
I’ve read two of his books (clean code and clean coder), and there are things I agree with, absolutely. There are also things I vehemently disagree with.
That's why people should read! I don't get this how lot of people say one should not read his books, even though the person asking is interested and is unsure if this is the right approach. Read and make up your own decision is the best thing.
I say, its worth investing in and learning. Not necessary to force you to do this, but to see it from this view and if its any good. Sometimes drastically different views can change how you program, without completely getting lost into it. In example, a Python or JavaScript programmer who tries out Haskell and learns how it works, does not mean will completely convert to Haskell. But it might give the person good habits reason about future Python and JavaScript code, and prepare and handle it differently.
I think that's because Linus subverted all expectations by those people, which comes at a shock. They were expecting Linus to be against Ai. Especially because in the past he was bashing and not taking Ai seriously. So he changed his mind, while the audience (who do not work on the Linux Kernel) stayed with the same opinion.
The problem is, LLMs (Ai) isn't just another tool. Even if the code is reviewed well and not slop at all, there are inherent uncertainties using such tools to generate code. We don't know how the future of code generated by Ai can be licensed and used; it does not even provide the original license of the code it was trained on. This is not just ideological, there are unsolved risks. And this is the best case scenario, as we assume the developers aren't slopping around.
Mind you, I'm critical about Ai, especially the online tools. But I'm not entirely against it, yet. I can however understand why people are against using Ai in Linux is a critical issue, for the reasons I described above. For myself I just play around with local Ai (on my 8gb VRAM+32gb RAM btw), so you see I'm not entirely against it.
The quoted laws do not say that generated code is automatically public domain, that is an interpretation of the law by some organization (here ScieActive). The laws just say, that a person using a prompt cannot take ownership and copyright of the generated code. It does not state it becomes public domain for everyone. Besides that, this is only in the US, not universal. And its not even tested in court yet. Its like saying in Brazil (or the EU in example) exist a law that does not allow Ai, therefore its the law for everyone. This is not universal.
This is just an interpretation of one organization, not an universal law.
Ai is trained on different licensed code. It does not automatically become public domain just because the Ai processes it. There is also no guarantee that the output is free of licensed code that already exists.
They won’t be able to kick every vibecoded project off, but it gives them a rule to point to when they do find and remove slop.
Exactly. This eliminates discussions over and over again with developers, maintainers and users, for every application, if and why they remove it. And it makes it clear and signalizes to such devs before they upload.
Is it though? There is no law that says that, so its just an interpretation of someone. I argue Ai generated code CAN be public domain if it does not contain any licensed code. Therefore we cannot assume the code being public domain without checking.
You realize that there are lots of lines of code erased and updated too? So comparing the size of the entire base does not tell you how many lines are written. Lines of code was always a bad metric, especially using it like this.
In some previous statements Torvalds said that all Ai based CVEs are handled differently and need to be disclosed publicly immediately. His argument was that if someone found a vulnerability or an issue with a LLM, then others will probably too. So hiding it just caused multiple reports of the same issue, because usually CVEs are hidden until they are solved. That might explain why all of them are dumped immediately.
You can also just directly use a rolling release distro. Debian Unstable isn’t as bad as it sounds. Unstable doesn’t mean unreliable or prone to breakages. Unstable just means that the bugs deal with will constantly be changing, instead of dealing with the same bugs all the time.
"Unstable" is one of the terms in the IT, that has multiple meanings. Those who don't know, might confuse the term "unstable" with "broken", when it actually means "Changing" (at a high level spoken). Its not about the bugs changing, but more about compatibility and changes that drastically could alter a system. Regardless of the model, security issues and often bugs are still being patched. For a "stable" distribution, this would be all it does.
OpenSuse’s solution, a rolling release that delays package updates to test and iron out bugs before pushing updated versions out.
Kind of what Manjaro does with the Arch base. Could be called slowroll too, as it is a rolling release with packages holding back and releasing them at once after some time. The idea is to test them before release, but I'm not sure if the Manjaro team does or did a great job at this in the past (years ago when I used it). The big problem with Manjaro was if you used the AUR, which always expected the current and newest packages without holding back. I guess OpenSUSE does not have such a problem, right?
Debian is its own project with their own maintainers and policy.