I wonder how they can reconcile the stricter proposals with the LLM usage in kernel development. That seems totally untenable. I mean it all seems untenable, but with the kernel especially.
Also, what about when you inevitably get a situation where a critical vulnerability is discovered, and the only patch available is LLM generated? Do they have to wait to patch until some person who hasn't seen the LLM-generated patch does a clean room implementation?
I understand the objections to LLMs, but rejecting LLM-generated code really doesn't seem realistic.
Kernel development is excluded from this, because it's covered by "Upstream projects using LLMs for development".
On security, I worry that proposal A's "forbid any contributions to Debian written with the use or assistance of large language models", as written, excludes contributions where the LLM assisted in discovering the vulnerability. That's clearly a bad policy, and they should update their wording to clarify that.
I read the question more as, if AI is working out for the kernel, why not a distro? (This is a question with valid answers, like the kernel having more devs paid to handle things while maintaining quality, but it's a fair question)
The proposals which say no LLM generated code mean just for Debian, if upstream allows it then they will still accept it. It’s just contributions to Debian itself which would prohibit or discourage LLM contributions.
The "G" in AGI stands for "general", so talking about "AGI for software development" makes no sense, and worse than that accepts the AI companies' goalpost-shifting at face value. We shouldn't do that.
But I feel like the point is that, in order to reach AGI, the most important area for AI to be good at first is software development. Because of the feedback loop that could allow.
I think the idea is that you'd have two independently-develooed systems, one LLM decompiling the binary and the other LLM formally verifying. If the verifier disagrees with the decompiler you won't know which tool is right and which is wrong, but if they agree then you'll know the decompiled result is correct, since both tools are unlikely to hallucinate the same thing.
No, the idea is that the verifier is a human-written program, like the many formal-verification tools that already exist, not an LLM. There is zero reason to make this an LLM.
It makes sense to use LLMs for the decompilation and the proof generation, because both arguably require creativity, but a mere proof verifier requires zero creativity, only correctness.
Radxa Rock 5 model B, Turing Pi RK1, Orange Pi 5 (and Plus); there are a few others but those are the models I have purchased and tested. All are more efficient/faster... but also more expensive and less supported. Though RK3599 and 3588 SoCs have both been some of the most widely supported out of Rockchip for Linux applications. They still lack compared to Pi's support though.
The rk3588 is a nice chip, but support just isn't there yet if you want to do anything with the GPU. The "Panthor" GPU driver, which is the FOSS driver which supports its GPU, was just merged in to Linux and mesa this month[1] (yay!) which means you're probably gonna have to build your own kernel if you want it.
The old mali proprietary driver is borderline unusable on anything remotely modern, only really working on Linux 5.10 and special X11 builds with legacy features re-enabled.
It's crazy that the rk3588 has been on the market for many years at this point and is just now starting to be usable on Linux, but it's exciting that things are taking shape.
> They still lack compared to Pi's support though.
This should be the central lesson learned from the Raspberry Pi by open-source projects.
There will be faster, there will be smaller, there will be cheaper. But if the user can go on the web and find the _exact_ thing they're looking to do spelled out, they'll buy that product, every time.
Now imagine if RPi applied their magic to slightly newer hardware so there was no need to mess around with poorly-supported Allwinner/Rockchip/Mediatek boards.
Also, what about when you inevitably get a situation where a critical vulnerability is discovered, and the only patch available is LLM generated? Do they have to wait to patch until some person who hasn't seen the LLM-generated patch does a clean room implementation?
I understand the objections to LLMs, but rejecting LLM-generated code really doesn't seem realistic.