Jason Hall

So in case you missed it... I created an x86 operating system kernel that is compatible with Linux user-space using HDAE and AI in 11 days. And after about a week I killed it. That sounds more dramatic than it actually is, but that is the gist. The point of this wasn't to create a production Linux compatible or competitive kernel (that would be silly), the point was different... We all know what Vibe Coding is at this point. I define it slightly different then maybe others, as I think of it as someone who doesn't know the subject matter well, asking AI to do something, and they "vibe" (or maybe more accurately, stumble) it into existence. While people are talking about it, being capable of replacing developers and knowledgeable and skilled humans, I don't believe the output is great. But, when AI is led by somebody who really understands what they are doing, amazing results can be achieved! I've seen this first hand myself, as well as with others, and the results are outstanding, so I wanted to put my process to the test. I call this process Human-Directed Agentic Engineering (HDAE), and I decided to try to implement a crazy task with it... Something I'm familiar with, something that can be easily tested and iterated on something that no-sane person would take on by themselves.... Building an operating system kernel capable of running Linux. And thus Ginux was born. github.com/gmkurtzer/ginux To reiterate, the point of the research was NOT to create a kernel or to compete with the works of many thousands of developers, programmers, community members, and companies... The point was to prove a concept, and I did that. Then what happened is attention, a LOT of attention, in the form of news, articles, podcasts, videos, ad-hoc code reviews, and activity on the GitHub project. That is great, right?!? But no, that was't my intention. I debated not taking any of the PRs, but this gave me a chance to test something else... I've been working on formalizing a release of the HDAE skills, so others can more easily leverage this process. github.com/gmkurtzer/hdae So I wanted to test these skills and process for also maintaining code and contributions. And while it's not completely done, I wanted to test ingestion of ideas, fixes, reviews, issues, and PRs using this model. TL;DR, there is more tuning I need to do for this, but it did great! I was able to run automatic reviews on almost 80 PRs and 70 issues, many of which created HDAE gates automatically and built the fixes automatically. But maintaining Ginux wasn't what I set out to do... I tested a process, and it was a success, so I started considering lessons learned. One of the things I did different in Ginux was I approached multi-operating system support as a first tier capability layer that I called "domains". You can think of domains as a way to completely separate and isolate user space environments above containers. In Ginux I had a kernel included controller process but it ran in ring 3 in user space, rather than a kernel thread. It was interactive and allowed the user to configure the user space. So for example, you can configure a "domain" to boot a Rocky Linux 10 container, and it would manage separation more like a virtual machine then a container. Domains can be scheduled differently for each, and against each other, with harder boundaries then containers. They also maintain the concept of operating system "personalities" like Linux, or BSD, or Darwin, or maybe even Windows (note: the only one that was done and tested was Linux). So... My next test for Ginux is a user space kernel shim, that sits between the kernel and user space to provide more control over the user space than the kernel will accomplish. This is because the kernel guarantees user space compatibility, nothing is dropped, stability is paramount. So I asked a question, what if we dropped, broke, or monitored some things on purpose. What could we do? So there are some projects that already do parts of this, gVisor, user-mode Linux, among others, but what I'm thinking was a bit different... What if in each "domain" you can control what kernel interfaces are exposed, and what the running user space was allowed to do in that environment. What could we control, and do we end up with a more secure environment? The beauty of this is that it still leverages all of the same capabilities and security of the Linux kernel as it exists now, and then it gives the user the ability to provide very custom and specific locked down environments, all in user space. So Ginux has pivoted to now research this idea. I honestly have no idea how it will turn out, but thanks to AI and HDAE, I have a feeling in a few days, I'll have a lot more to report back on. The Ginux repo above, has already been pivoted to the user space kernel, and it is documented within the project. The previous full kernel implementation is archived there in a branch for anyone who wants to see or use it. Oh, and one other thing, it is pronounced: Jin-uks.