CentOS founder writes 139,000-line Ginux kernel in 11 days with Codex, capable of booting Rocky Linux 10

“Even if you give the model unlimited tokens, it still can't build anything at the operating-system level.” For the past few years, this has been close to the tech community's consensus on the upper limit of AI capability.

But now Gregory Kurtzer has answered that doubt in his own way. The name is familiar to people in the Linux world: he is one of the founders of CentOS, and the man who, after Red Hat decided to end CentOS Linux, single-handedly launched Rocky Linux.

On October 27, 2026, Kurtzer announced on X: in 11 days, using “Human-Directed Agentic Engineering” (HDAE), he wrote about 139,000 lines of code and built a brand-new Linux-compatible kernel capable of booting Rocky Linux 10 and running systemd.

The project is called Ginux, an independently developed, Rust-centric x86-64 kernel. In other words, it is not forked from the Linux kernel.

Ginux has its own memory management, scheduler, process model, file system, networking and device support, all written from scratch.

The most interesting part is that although Ginux is not Linux, it is compatible with Linux. It implements the Linux ABI, the binary interface that compiled programs use to communicate with the kernel, so existing Linux binaries can run directly on Ginux without modification.

1 A C compiler gave him confidence, the kernel gave him a question mark

Kurtzer's project has a reference point: Anthropic's Nicholas Carlini once used 16 Claude agents running in parallel to build a C compiler from scratch. That experiment took nearly 2,000 sessions and about $20,000, and produced about 100,000 lines of Rust code capable of compiling a large amount of software, including most of the Linux kernel build process. Compiler test suites and reference tools provided strong evidence for validating the results.

The task Ginux faces is harder to validate: build a kernel from scratch, then get unmodified Linux user-space programs to run on it. Whether Linux programs can run and whether systemd can start are the checkpoints that test whether the system actually works.

In his technical report, Kurtzer broke the research goals into three questions: In terms of capability, can HDAE produce an independent kernel that boots and runs some unmodified Linux distribution workloads? In terms of method, what documentation, guidance, executable checkpoints and feedback loops are needed to keep this work moving forward? In terms of result quality, how are the compatibility and performance of the final system? What scope do these conclusions apply to?

Kurtzer has taken part in building Caos Linux, CentOS and Rocky Linux, and also has experience with Singularity/Apptainer, Warewulf, Perceus and production infrastructure operations. These experiences shaped Ginux's boot process and acceptance criteria.

2 One agent, 11 days, 139,000 lines, and the key is guidance by a “domain expert”

Almost all the work for this implementation was done in a single continuously running Codex task, using GPT-5.6 Sol. In his words: “The author was responsible for setting the architecture, system operations, interpreting results, and making the final acceptance decisions.”

The human role lies in two mutually cooperating loops of HDAE:

HDAE outer guidance loop: vision → architecture and constraints → acceptance checkpoints → human review of observed behavior → correction, reprioritization or acceptance.

HDAE inner agent loop, which does not depend on human observation: implement → build and run in QEMU → measure and analyze failures → revise → regression test.

In other words, Kurtzer was responsible for providing goals, architecture, Linux compatibility targets, the operating model, failure interpretation and stop decisions. Codex shortened the distance from technical decisions to runnable code.

And Kurtzer's domain knowledge provided the vision, priorities and success criteria. He said, “The project required domain knowledge to choose Linux user-space contracts, distinguish OCI transport from runtime isolation, identify broken fork/exec behavior, define domain ownership, interpret systemd failures, and judge whether plausible-looking output matched expectations.”

systemd was chosen as the acceptance checkpoint because it depends on a large number of system components and is also the core process for booting and running the entire system. However, it is also picky about the environment when started in a container, so Ginux first implemented “domains” and then handled containers.

On X, someone also asked him why he chose Codex. Kurtzer said it wastes fewer tokens on side branches. But even so, he still has to frequently pull it back on track. There were some large chunks of code he wasn't satisfied with, yet he deliberately forced himself not to edit them by hand — “I even turned off the IDE and forced myself not to open it. That way, when the AI gets something wrong, I can only give it new guidance; and many times, it will delete the code it wrote incorrectly.” The other person pressed further: how exactly do you pull it back on track — by listing a set of prohibitions, or by watching the output and yanking it back whenever it drifts? Kurtzer's answer was simple: set up a lot of checkpoints.

This is exactly what he emphasized: “Vibe coding without guidance is not suitable for this project.”

“Many failures produce plausible-looking output that violates Linux semantics, isolation requirements, or lifecycle behavior… and you end up with code that appears to run but is structurally weak, often called ‘AI slop.’”

“AI can also let less experienced engineers participate faster in bounded real work, such as exploring unfamiliar code, generating tests, comparing interfaces, and implementing reviewed changes. But experience remains crucial when choosing abstractions, identifying whether results are complete, and judging whether a local success could create system-level risk.”

One agent plus one human expert with sufficient experience goes further than a bunch of unsupervised agents.

Over 11 days, the project left about 139,000 lines of retained code, with a cumulative 1,037 commits, including 261 tracked files and 63 Rust source files.

Ultimately, Ginux can be built as a GINUX.EFI image that boots directly via UEFI without relying on a Linux host kernel.

It can run mutually isolated “domains,” each with its own processes, address space, file system, and lifecycle. The project claims this isolation boundary is stronger than OCI containers or Linux namespaces.

Ginux can also pull and verify OCI container images and use the images to assemble a domain's root file system. With this capability, it can boot Rocky Linux 10 and run up to systemd's multi-user.target. Some Alpine Linux programs can also run, such as musl and BusyBox.

On performance, the project did a comparative test against Rocky Linux. The conditions were virtual machine emulation on an Apple Silicon Mac, with only 1 CPU core and 2 GiB of memory, running the same test program on both sides. For boot, Ginux brought Rocky Linux 10 to a login-ready state in 12.9 seconds, while the Linux kernel took 42.6 seconds. The former is about 3.3 times faster. However, Ginux does not need to load a kernel at boot, and the file system is already cached, so this number can only be taken as a reference. What is truly comparable is the benchmark: a three-second sysbench test, nine runs per system taking the median, with results as follows:

Ginux is already very close to Linux on these three tests — slightly higher on CPU and threads, slightly lower on memory, with gaps ranging from single digits to a dozen or so percentage points.

The API call cost for this experiment was about $8,000, and the code is licensed under Apache 2.0 and hosted on GitHub.

3 Closing thoughts: code is not the moat

After Ginux was released, Kurtzer wrote a line in the technical report: “The more important takeaway is that AI can generate complex system software, but compatibility, security, hardware support, standards, community, and long-term maintenance still constitute the real moat.”

Building a small working kernel is not inherently difficult; maintaining a production-grade kernel is another matter — you have to support various hardware and workloads, keep interfaces stable, fix bugs, coordinate contributors and vendors, and have a reliable release cadence. What is truly difficult is workflow, compatibility, maintenance, and community.

The competitive pressure brought by AI-generated software may first land on middleware and orchestration layers, because swapping software at these layers does not require moving the entire hardware and system ecosystem along with it. Infrastructure software can of course also be rewritten, but whether a set of infrastructure can be adopted depends on standards, interfaces, certifications, hardware adaptation, community continuity, and commercial support.

He emphasized, “Without an ecosystem, innovation itself has limited value.”

Linux is the clearest example. Its value far exceeds the source code needed to boot a shell — it provides stable expectations for different processors, devices, file systems, virtual machines, distributions, vendors, and applications. Ginux does not yet have a comparable hardware matrix, standards body, or community, and cannot promise that a program running today will still run tomorrow. AI can create technical components; but for these components to be truly adopted, multiple independent organizations still need to jointly support the same set of contracts.

At the end of this 13-page technical report, Kurtzer wrote: AI can already write code deep in the system stack. But the core value of infrastructure comes from compatibility, hardware support, review, community trust, and long-term responsibility. Linux accumulated these qualities across a vast range of workloads through decades of human engineering practice.

Reference links:

This article is from the WeChat public account “InfoQ” (ID: infoqchina), author: Tina, published by 36Kr with authorization.