Gregory M. Kurtzer, best known as the founder of CentOS and Rocky Linux, has published Ginux, an experimental kernel written in Rust that implements the Linux application binary interface (ABI) and can run unmodified Linux programs, all the way to booting Rocky Linux 10’s systemd. What makes it stand out is how it was built: according to the repository, a single OpenAI Codex task using the GPT-5.6 Sol model produced about 139,000 lines of implementation and test code in eleven days, under Kurtzer’s direction. The author is clear that it is a research prototype, not a Linux replacement.
Ginux in 20 seconds
- What it is: an independent x86-64 kernel in Rust that boots through UEFI and exposes the Linux ABI to programs with no Linux kernel underneath.
- What runs today: selected Alpine (musl and BusyBox) and Rocky Linux (glibc) programs, plus a Rocky Linux 10 systemd boot to multi-user.target.
- How it was made: an AI agent wrote, tested and fixed the system over eleven days; a human set the architecture, constraints and acceptance criteria.
- Its limits: it is only validated on a QEMU virtual machine, just 82 of 375 Linux system calls are complete, and there is no security audit.
Linux on the outside, a different kernel inside
Ginux is neither a distribution nor a compatibility layer running on Linux. It is an operating system of its own that boots straight from UEFI as a single image, GINUX.EFI, with its own memory management, scheduler, process model, virtual file system, networking and device support. What it does is present programs with the same interface the Linux kernel does, so an Alpine or Rocky Linux binary believes it is running on Linux. Small assembly boundaries handle entering and leaving UEFI, installing interrupt and system call entries and switching privilege levels; everything else is Rust.
Its central concept is the domain: a kernel object that owns processes, address spaces, file systems, devices, resources and permissions, and acts as the isolation boundary. By design, domains are a stronger boundary than OCI containers or Linux namespaces. OCI images are used only to deliver and assemble the initial file system: Ginux pulls, verifies and assembles an Alpine or Rocky image, for example, and runs it inside a domain. A single domain can look like a whole computer, with systemd as PID 1.
Administration is handled by a controller embedded in the image that runs in ring 3, as an ordinary process, rather than inside the kernel. From its own shell you create domains, assign them an image and memory, start them and attach to their console. It can delegate or revoke the authority it receives at boot, but it cannot create new kernel authority.
Eleven days, one agent and 1,097 commits
According to the repository, Ginux was built to test whether a coding agent, directed by someone with systems experience, could construct an independent kernel able to run existing Linux userspace. Kurtzer calls the method Human-Directed Agentic Engineering: the human sets the architecture, constraints, milestones, acceptance criteria and stopping point, and the agent implements, boots, tests, diagnoses and revises the code against executable gates. The history has 1,097 commits, and the work is documented in a technical report on Zenodo that evaluates the code as of October 23, 2026.
The headline number deserves context. The 139,000 lines include retained implementation and test code, not just the kernel. The author also acknowledges that at the evaluated checkpoint the full test suite does not pass: a lifecycle probe of the system supervisor after execve() still fails, and he records it rather than hiding it. He likewise warns that his performance comparison is very narrow, a single virtual CPU in QEMU running the same sysbench binary, not a general kernel benchmark. The name, by the way, is a joke: it blends Linux, GPT and Greg, and the README says the G officially stands for GPT.
Ginux vs. the Linux kernel
Setting it next to today’s Linux kernel puts the scale in perspective. The Linux figures refer to version 7.4, whose merge window has just set a record for commits:
| Ginux | Linux kernel | |
|---|---|---|
| Language | Rust, with small assembly parts | Mostly C, with Rust now a permanent part |
| Size | About 139,000 lines (implementation and tests) | About 41.6 million lines in the tree (31.4 million of code) before 7.4-rc1 |
| Development | 1,097 commits in 11 days, one agent directed by one person | 19,671 commits in the 7.4 merge window alone; continuous development since 1991 with thousands of contributors |
| Architectures | x86-64 only | Around twenty, from x86 and Arm to RISC-V, PowerPC and s390 |
| System calls | Of Linux 6.12 x86-64’s 375: 82 complete, 245 partial, 48 denied by policy | The reference: all implemented |
| Hardware | Validated on QEMU (Q35, OVMF, virtio, VT-d); no GPU, NVMe or physical machines | Support for an enormous range of physical hardware |
| Isolation | Native domains with revocable capabilities | Namespaces, cgroups and security modules |
| Boot | Single UEFI image with a ring-3 controller | Kernel and initramfs loaded by a boot loader |
| License | Apache 2.0 | GPLv2 |
| Intended use | Research and testing | Production, from phones to supercomputers |
Ginux’s 139,000 lines amount to roughly 0.3% of the Linux tree. The comparison is not entirely fair, because much of Linux is drivers for hardware Ginux does not even try to support, but it shows what is missing: broad compatibility, drivers, peer review, a vendor ecosystem and long-term maintenance. The repository says as much: Ginux shows that deep systems software can be built very quickly, not that a Linux alternative already exists.
Why it matters to system administrators
Nobody is going to run Ginux on a production server, and its author is the first to advise against it. What is interesting is what it points to. On one hand, it confirms that the Linux ABI has become a contract other kernels can offer, an idea already explored by projects such as gVisor or FreeBSD’s Linux compatibility layer, and one that fits with efforts like Multikernel that rethink how hardware and isolation are shared on a server. On the other, it arrives just as Rust has become a permanent part of the Linux kernel and as AI starts to change the pace of kernel development itself.
It also raises a practical question: if an agent can generate 139,000 lines of systems code in eleven days, the bottleneck shifts to reviewing, auditing and maintaining them. In a kernel, where a single bug can mean a root escalation, that is what separates an experiment from something you can trust. It remains to be seen whether the project attracts other developers, gets tested on real hardware and has its security model audited.
Frequently asked questions
What is Ginux?
An experimental x86-64 kernel and operating system written in Rust that implements the Linux ABI to run unmodified Linux programs. It was published by Gregory M. Kurtzer under the Apache 2.0 license.
Was it really written by AI?
According to the repository, an OpenAI Codex task using GPT-5.6 Sol produced about 139,000 lines of implementation and test code in eleven days. Kurtzer defined the architecture, constraints and acceptance criteria.
Can it replace Linux?
No. It is only validated on a QEMU virtual machine, fully implements 82 of Linux’s 375 system calls, lacks broad physical hardware support and has no security audit. The author presents it as a research project.
Which distributions can it run?
Selected Alpine and Rocky Linux programs, and a Rocky Linux 10 systemd boot to multi-user.target. The author notes this does not guarantee that any arbitrary binary or distribution will work.
Source: Ginux repository on GitHub and Gregory M. Kurtzer’s technical report on Zenodo