Gregory Kurtzer just did something that sounds almost absurd on paper.
In only eleven days, the man who created CentOS and later founded Rocky Linux directed an AI agent to build an entirely new operating system kernel from scratch. The result is called Ginux. It is not a fork of Linux. It is not a modified Linux kernel. It is an independent, Rust-first x86-64 kernel that still manages to boot a full Rocky Linux 10 userspace all the way to systemd’s multi-user target.
The project has quickly become one of the most discussed topics in the free and open-source software community this week. Some people are calling it a historic milestone. Others are treating it with heavy skepticism. Both reactions make sense.
This article explains what Ginux actually is, how it was built, what it can and cannot do right now, and why the story matters far beyond the hype.
Who Is Gregory Kurtzer and Why Does This Matter?
Gregory Kurtzer is not a random developer experimenting with AI for the first time. He has spent more than two decades building critical infrastructure in the Linux and high-performance computing world. He co-founded CentOS, one of the most important enterprise Linux distributions of the 2000s and 2010s. When Red Hat effectively killed the traditional CentOS model in late 2020, Kurtzer responded by launching Rocky Linux as a community-driven drop-in replacement. He also created the Singularity container system (now Apptainer) and has deep experience with cluster provisioning tools.
In short, he understands what it takes to keep large, production-grade Linux systems running. That background is important. Ginux was not built by someone who just discovered large language models last year. It was directed by someone who has lived inside the Linux ecosystem for a very long time.
What Exactly Is Ginux?
Ginux is an independent kernel written primarily in Rust. It has its own:
- Memory management
- Scheduler
- Process model
- Virtual file system
- Networking stack
- Device support
- Boot process (UEFI)
It is not based on the Linux source code. Kurtzer has been very clear about this point. Ginux is not a fork, not a rebrand, and not a set of patches on top of Linux.
What makes it interesting is the compatibility layer. Ginux implements enough of the Linux ABI (Application Binary Interface) that many existing Linux programs can run on it without recompilation. In the project’s own words, Linux is treated as a “personality” that Ginux can present to userspace programs. The actual kernel underneath is completely different.
The most impressive demonstration so far is that Ginux can boot a Rocky Linux 10 image and reach systemd’s multi-user.target. That is not a trivial achievement. Reaching multi-user.target means the system has successfully initialized a large portion of the userspace stack that enterprise Linux distributions rely on.
How Was It Built in Only 11 Days?
Kurtzer did not sit down and type 139,000 lines of kernel code by hand. Instead, he used a method he calls Human-Directed Agentic Engineering (HDAE).
In this approach, the human (Kurtzer) defined:
- The overall architecture
- Hard constraints
- Milestones
- Acceptance criteria
- Stopping points
An AI agent (a persistent OpenAI Codex task running GPT-5.6 Sol) then handled the bulk of the implementation, testing, diagnosis, and iterative fixes. The agent worked continuously for eleven days and produced approximately 139,000 retained lines of implementation and test code across more than 1,000 commits.
Architecture documents and clear gates kept the agent aligned. Real userspace software, including Rocky Linux itself, was used as a living test suite. Bugs that synthetic tests missed often showed up when actual programs tried to run.
This is a very different workflow from the classic “prompt an AI and hope for the best” style of coding. Kurtzer remained in the driver’s seat for high-level decisions while the agent did the heavy lifting of writing and refining code.
Current Limitations (And Kurtzer Is Honest About Them)
It is important to be clear about what Ginux is not.
Right now, Ginux is a research prototype. It runs primarily inside QEMU. It does not have meaningful support for real hardware. There is no GPU support, no proper NVMe support, and no serious security audit. Linux ABI coverage is still incomplete. Many syscalls and edge cases are missing. Performance numbers are only exploratory and were measured under narrow conditions.
Kurtzer has repeatedly stated that Ginux is not intended to replace Linux and should not be treated as production-ready software. The Apache 2.0 licensed code is public, but the project is still very early.
In his own words, the bigger lesson is this: AI can now generate complex systems software at impressive speed, but the real long-term advantages of a mature kernel still come from compatibility, hardware support, security review, standards compliance, community trust, and sustained maintenance. Those things cannot be generated in eleven days.
Why the FOSS Community Is Paying Attention
There are several reasons this project has generated so much discussion.
First, the speed is genuinely striking. Building a kernel that can boot a modern enterprise Linux distribution to multi-user mode has historically taken years of work by experienced teams. Compressing even a narrow version of that achievement into eleven days forces people to reconsider what is now possible.
Second, the choice of Rocky Linux as the test userspace carries symbolic weight. Kurtzer is effectively using his own distribution as the proving ground. That gives the demonstration more credibility than if he had only shown a minimal BusyBox environment.
Third, the method itself is interesting. Human-Directed Agentic Engineering is one of the cleaner real-world examples of a skilled engineer pairing deep domain knowledge with an autonomous coding agent. It is neither pure human coding nor fully autonomous AI development. It sits in the middle, and many developers are watching to see how far this style of work can go.
At the same time, experienced kernel developers are right to remain cautious. Reaching multi-user.target in QEMU is a meaningful milestone, but it is still a long distance from supporting the enormous range of hardware, workloads, and edge cases that Linux handles every day.
What This Does (and Does Not) Mean for the Future of Kernels
Ginux does not prove that AI will replace Linux next year. It does not prove that traditional kernel engineering is obsolete. What it does show is that the cost and time required to prototype certain kinds of systems software have dropped dramatically when a knowledgeable human directs a capable agent.
For research, experimentation, and specialized environments, this style of development could become increasingly common. For general-purpose operating systems that need to run on millions of different machines with strong security and reliability guarantees, the traditional strengths of Linux remain very difficult to replicate quickly.
Kurtzer’s own conclusion is measured and realistic. AI can build deep technical pieces. The institutional and social layers that turn those pieces into trusted infrastructure still require human judgment, long-term commitment, and community.
Final Thoughts
Ginux is one of the more interesting systems experiments of 2026 so far. It sits at the intersection of several major trends: the maturation of agentic coding tools, the continued importance of Linux compatibility, and the ongoing search for new ways to build complex software faster.
Whether Ginux itself grows into something more substantial or remains a research prototype is still unknown. What is already clear is that the combination of experienced human direction and persistent AI agents can now produce results that would have seemed unrealistic only a couple of years ago.
For anyone working in systems software, infrastructure, or AI-assisted development, this project is worth watching — not because it is ready to replace Linux, but because it shows how the process of building foundational software is starting to change.
The code and technical report are publicly available for those who want to examine the details themselves. As with most early-stage systems projects, the real test will be what happens in the months after the initial announcement, not just the impressive numbers from the first eleven days.