Ginux: A New Kernel Runs Linux Userspace, Made via Human-Directed AI Engineering
zenodo.org
zenodo.org
> Ginux is available under the Apache License 2.0. See LICENSE and NOTICE.
Zarya of the Dawn concludes that human direction and selection is not enough to produce a copyrightable work from AI generated content. Without copyright, there is no legal basis to offer a license. The code is public domain or worse, mislicensed, AI washed GPL or BSD.
This isn't settled yet, and while the license may ultimately be meaningless, it lets people compile and use the code without risking copyright law violation.
I do agree about AI washing though, ethically any code you generate using AI should be licensed as similarly to the source material as possible.
I'm not a lawyer, but I don't think the law is simple.
For example, if I take a public domain file and incorporate it into my GPL project, if you make a derivative of the project as a whole, you still need to follow the GPL. But you can also take that file and use it with no regard for the project's license, since the file itself is public domain.
I am of the opinion that there is very little humans can do that other reasonably competent humans cannot also do. So the entire idea of IPR is a joke, but the idea has been with us for a few centuries and might stay on for one more.
That said, human direction is critical in so many things. A camera can be operated by any monkey; all you need to do is click a button. But knowing how to focus, what to focus on, and so may of those tiny decisions is what makes photography an art form. There are hundreds of such fields where the actual human effort involves providing direction to an otherwise mechanical process.
1. Prepare one item that works with 〇〇 2. Make it work with ×× 3. Return to (1) until it is deemed sufficient 4. Prepare 100 items that work with 〇〇 5. Measure performance with ×× 6. Measure performance with 〇〇 7. Consider several performance improvement measures 8. Implement improvement measures while verifying that compatibility is not compromised 9. Return to (4) until it is determined that performance has improved sufficiently 10. Completion of ××, which is sufficiently compatible with 〇〇 and not inferior in performance
Apparently they got fixed by now.
There it is said that Ginux does not implement mutual exclusion in the right way for a multiprocessor.
To implement this correctly and in a way that ensures high performance even on CPUs with hundreds of cores is one of the most difficult parts of an operating system kernel, much more difficult than just implementing the system call interfaces, to enable a user program to run.
Other point is that Ginux is vulnerable to some races caused by interrupts, which is again something difficult to get right in an operating system kernel, unless you copy exactly the corresponding code from the Linux kernel.
From a practical point of view, Ginux cannot be called anything else except a toy operating system kernel, at the level that previously could have been a home project for one student at an OSes course.
Of course, despite being a toy, Ginux is an impressive accomplishment by being good enough to run an unmodified Linux user program, and its implementation with an LLM has required at least an order of magnitude less time than a human student would have needed.
Still, there is a very long way from a demo like this to seeing an LLM that can generate autonomously a real operating system kernel, without further interaction with a human after the initial specification.
It should be remembered that the main purpose of an operating system kernel is not implementing the API of the system calls used by the user programs, which is the trivial part of its functions. The kernel is the manager of the shared resources of a computer system, like CPU time, memory, peripherals, which allocates them to user programs and ensures that their usage is maximally efficient and that the user processes cannot use the shared resources otherwise than as decided by the kernel. This is something that Ginux has not accomplished at all, based on the description from the link provided above.
And as a test case they built a Linux-compatibe thing in Rust!
Al of this is cool to me, but what I read here in the comments: slop, stealing, evil people, no trust, etc.
Linux is open source: the license says that it can be used for any purpose, which includes training an LLM.
LLMs have made developers more powerful (like IDEs did, or CI/CD did, or better programming languages did, or Github did, or ...), but all I hear is nagging.
We don't want or need hundreds of LLM generated Unix-clones which are merely slight variations on the Linux source code.
Good news, you don't have to use them. People want to build them, to learn, to explore, to feel good.
Apparently there's someone who wants them... The programmer who made it.
Funny how we're all for freedom and free expression, until we find someone not properly investing their time /s
The licence says that you have to distribute the modified sources under the same licence. IMHO the least Ginux could do is licence their work as GPLv2.
https://x.com/gmkurtzer/status/2114958282481910115
> Ginux is a research prototype, not a production kernel or Linux replacement. The larger lesson is that AI can generate complex systems software, but compatibility, security, hardware support, standards, community, and long-term maintenance remain the real moat.
Because the bigger the project, the more unlikely it is for a human to review all the code. And in this case we're talking about re-making the Linux kernel.
- AI slop is clearly negative. "Lacking in effort", "low quality".
- Vibecoding, I believe, tends to mean "letting the AI do it without putting much effort into it". So vibecoding produces AI slop.
- HDAE, that this article tries to define, is "a method for building complex software by combining human-defined architecture, constraints, milestones, acceptance criteria, and stopping points with an autonomous implementation, execution, diagnosis, and revision loop".
In other words, they say "it is actually possible to put a lot of effort into producing code with AI". And I personally don't disagree with that.
Now of course, it feels like marketing, a bit. "I will present you how I built this kernel as an effort to make you accept it as "not slop", by trying to convince you that I put a lot of effort into producing it".
IMO, it does not really matter. Whether code is written by a random person on the Internet, vibecoded by a random person on the Internet or HDAE-ed by a random person on the Internet, it should not be trusted unless audited. If it happens that vibecoded code is good, I don't see a reason not to use it. If HDAE-ed code is bad, it should not be used.
For one, LLMs tend to waffle and produce code that works but is much more extensive and/or unintuitively organized than code that a human writes. The bigger thing however is testing. LLM code tends to test itself, whereas a domain expert human tends to have many more domain-specific edge cases in mind.
Does it matter if it comes from a human you don't know or an AI you don't know? If it's difficult to review for the maintainers, then the maintainers should not merge it.
Let me put it this way: if a random contributor opens a PR as a human, then the maintainers will do what they were doing before AI, right? Now if a random contributor opens a PR pretending to be written manually, but actually written with the help of an AI, what will the maintainers do? Exactly the same, right? Try to read and understand the contribution, and merge it if they want to take responsibility of it.
The difference, really, is that everyone and their dog can now open a PR that looks evolved, and for maintainers it's difficult because it adds noise.
Sure. But I'd trust someone whom I know to be a domain expert and a good coder much more than some random github account. And once I see anything like "co-authored-by: claude"... oh hell no I'll go over that with a fine toothed comb because I have zero idea what the user prompted into the LLM, which in turn means I don't know what edge cases the author (and by extension the LLM) even knew about.
As a maintainer, if it's easier for me to ask an AI to do it, then I will do that. Now depends on what "easier" is. Maybe a question of trust (if I don't trust a random contributor, I may as well do it myself), maybe a question of testing it (if a contributor can show me that it works on their 5 devices I don't own, it may have value).
But the fact that it was written by AI is not the biggest factor, IMO. Proven by the fact that if the AI writes exactly what I wanted, then I will be happy to merge it.
the last part is tricky on these kinds of projects.
Just look at the bugs coming out in Linux or other kernels. Often they are very subtle errors based in very subtle misunderstandings.
This is why you'd want a lot of different people involved who in their combined knowledge have a good chance to understand enough to make such a project a success, even IF all they do is review the AI code.
I'd like to address this specifically. Introducing a very subtle bug can be an adversarial move, right? Say I want to introduce an exploit into a project, I can try to do that. And it is a risk in any open source project where contributions come from "random people on the Internet".
Now my question: as a maintainer, is it better for me to try to convince myself that all those contributions I receive from random people are well intentioned (and maybe miss subtle bugs that were introduced on purpose), or is it better to have an AI replace those contributors?
I don't have an answer, but I think it is an interesting question. As a maintainer, my bottleneck has generally been more around reproducing, understanding the bug and testing. Less around producing the code. And an AI can produce the code I ask it to produce, copying my style, and I can ask it to start over as often as I want.
Not sure if that naming choice would have been a good idea though. :)
But that does not in fact seem to be what this is. In fact I can discern no architectural decisions that would differentiate this from Linux in any way. So what is it? We vibecoded an OPEN SOURCE piece of software??? Genuinely so confused by this...
JFC... The world does not have enough psychiatrists to fix the current catastrophe.
So vibe coded then.
A token prediction system that has built a multi-dimensional model of all tokens on the Internet should be good at generating a bunch of algorithm combinations. Then it is about a loop to test, find out other combinations, find a winner.