www.it-connect.fr
Ginux: CentOS Founder Builds a Linux-Compatible Rust Kernel in 11 Days with AI
Eleven days, a single task handed to an AI agent, and around 139,000 lines of code left standing at the end of the work. And above all, Ginux: a Rust-written kernel capable of running Linux programs... without a Linux kernel. Behind the project is Gregory Kurtzer, the founder of CentOS and Rocky Linux.
Does the name Gregory Kurtzer ring a bell? And yet, he is behind two flagship Linux distributions: CentOS, and then Rocky Linux, launched after Red Hat decided to end CentOS Linux. Now part of CIQ, he introduced Ginux on X.
Here is how Ginux was built. Gregory Kurtzer defined the architecture, constraints, milestones, and acceptance criteria. Then he launched a persistent task with OpenAI Codex to carry out this mission based on the GPT-5.6 Sol model. The AI therefore handled a set of tasks: implementation, compilation, booting, testing, diagnosis, and fixes. According to him, this is what he calls the Human-Directed Agentic Engineering (HDAE) method, presented in a 13-page technical report published on Zenodo.
So why the name Ginux, if there is no link to the Linux kernel? Ginux combines Linux, GPT, and Greg. That’s all. Ginux presents itself as a kernel written in Rust, with a total of 139,000 lines of code.
Ginux, an independent kernel that speaks the language of Linux
Ginux is not just another Linux distribution. It is an independent kernel for the x86-64 architecture, which boots directly via UEFI and provides its own core building blocks: memory management, scheduler, process model, virtual file system, network stack, and device support. Here, Linux is only a “personality” exposed to applications.
Here are a few characteristics of the current Ginux prototype:
- A single image: the kernel, the management controller, and the boot components are bundled into one
GINUX.EFIfile. The controller runs in user space (ring 3). - Unmodified Linux applications: some Alpine Linux programs (musl and BusyBox) and Rocky Linux programs (glibc) run as-is. Ginux can even boot a Rocky Linux 10 user space with systemd, including
multi-user.target. - Partial compatibility: out of the 375 system calls in the Linux 6.12 x86-64 interface, 82 are fully implemented, 245 are partially implemented, and 48 are deliberately rejected.
- Isolated domains: workloads run in “domains,” each with its own processes, address spaces, file systems, and capabilities. OCI images are used only to provide the file system, while execution and isolation are handled by Ginux.
For now, testing is done in a QEMU virtual machine, via KVM on a Linux x86-64 host or in emulation on an Apple Silicon Mac. The code is available under the Apache 2.0 license on GitHub. The Linux compatibility matrix is explained in detail on this page.
A research prototype, not a replacement for Linux
We are still far from the goal, and it is important to be clear that this is a prototype. Ginux can only run part of Linux programs, and it has only been validated in a virtual machine. The project is honest about this, especially since not all tests are passing yet.
On the performance side, there is still some interesting information published in a benchmark document comparing Ginux and Rocky Linux. The tests were performed under the same conditions: a QEMU virtual machine (1 vCPU and 2 GiB of RAM), in emulation on an Apple Silicon Mac, with the same sysbench binary.
At boot, Rocky Linux 10 on Ginux reaches multi-user.target in 12.9 seconds (median), compared with 42.6 seconds with the Linux kernel, which is 3.3 times faster. The catch is that Ginux loads neither a second kernel nor initramfs and restores a file system that is already cached: the comparison is not fair. Under sysbench, the results are close: 15.2% better for Ginux on CPU, 8.7% less memory usage, and 1.2% better on threads. And it has come a long way.
Still, before talking about performance, Gregory Kurtzer believes these measurements will need to be redone on a Linux x86-64 host with KVM, multiplied, and expanded with network, storage, and IPC tests. And with a more mature version as well.
He also points out that Linux’s value lies less in its code than in its ecosystem. “The code is relatively easy. What is hard is the workflows, compatibility, maintenance, and community.”, he writes. Gregory Kurtzer clearly had fun, and he estimates the cost of this experiment at around $8,000 in API calls. But for now, it remains only a demonstration: stay tuned!
What do you think?
