Rocky Linux Creator Builds a New Operating System Kernel in 11 Days With AI

Building an operating system kernel from scratch is one of the most demanding challenges in software engineering. It requires deep knowledge of computer architecture, memory management, process scheduling, filesystems, networking, device drivers and security.

Traditionally, this kind of work takes experienced engineering teams considerable time. But a new experimental project from Gregory Kurtzer, the creator of Rocky Linux and a co-founder of CentOS, is drawing attention to how AI coding agents could change the development process.

Kurtzer says he built a new Linux-compatible operating system kernel called Ginux in just 11 days, with an AI coding agent handling most of the implementation.

The project reportedly produced approximately 139,000 lines of implementation and test code across more than 1,000 commits. More significantly, Ginux has demonstrated that it can boot Rocky Linux 10 and reach the system's systemd multi-user target.

That is an impressive technical milestone. However, Ginux is still an experimental research project, and its achievement should not be confused with building a production-ready replacement for Linux.

What exactly is Ginux?

Ginux is an independent, Rust-first operating system kernel designed to run Linux applications without using the Linux kernel underneath.

That distinction is important.

Ginux is not another Linux distribution, nor is it a modified version of the existing Linux kernel. Its developer describes it as a new kernel with its own memory management, scheduler, process model, virtual filesystem, networking components and device support.

The project instead aims to provide compatibility with the Linux application environment through the Linux Application Binary Interface, commonly known as the Linux ABI.

An application binary interface defines how compiled programs interact with the operating system. By implementing the interfaces that Linux applications expect, Ginux can run selected existing Linux programs without requiring them to be rewritten specifically for the new kernel.

The project's repository documents successful tests involving selected Alpine Linux programs and Rocky Linux 10, including a systemd boot reaching the multi-user target.

In practical terms, the ambition is to support familiar Linux software while using a completely different kernel architecture underneath.

The project is written primarily in Rust, a programming language increasingly used in systems programming because of its emphasis on memory safety and performance.

How AI helped build a kernel in 11 days

The most interesting part of the Ginux story is not simply that a new kernel was created. It is the development process behind it.

Kurtzer calls the approach Human-Directed Agentic Engineering (HDAE).

Under this model, the human developer establishes the architecture, technical constraints, development milestones, acceptance criteria and boundaries. An AI coding agent then works through the implementation process, writing code, running tests, diagnosing failures and revising its work.

For Ginux, the reported development effort used a single persistent OpenAI Codex task powered by GPT-5.6 Sol.

According to the project's technical documentation, the agent produced approximately 139,000 retained lines of implementation and test code over 11 days. The work was tracked across more than 1,000 commits.

This was not simply a case of giving an AI assistant a one-line instruction to create an operating system. The developer provided architectural direction and structured technical requirements, then used executable tests and real operating-system workloads to evaluate the agent's progress.

That distinction matters.

Complex systems software cannot be judged by how much code an AI model generates. It must be judged by whether the software behaves correctly under demanding conditions, whether its interfaces work as expected and whether failures can be detected and handled.

The Ginux experiment offers an example of an AI agent participating in a sustained engineering workflow rather than merely completing isolated programming tasks.

What can Ginux actually do?

The project's current repository describes several demonstrated capabilities.

1. It boots independently through UEFI

Ginux can build into a bootable EFI image and start without relying on a Linux host kernel. This is a fundamental part of its goal to operate as an independent operating system.

2. It runs selected Linux applications

The kernel implements parts of the Linux ABI, allowing selected unmodified Linux programs to execute. The project has tested workloads involving Alpine Linux and Rocky Linux.

3. It supports isolated execution environments

Ginux uses a concept called domains. Each domain has its own processes, address spaces, filesystem views, capabilities and lifecycle state.

The project uses these domains as its primary isolation boundary. OCI container images can provide the filesystem contents, but the Ginux kernel manages execution and isolation.

4. It has booted Rocky Linux 10 with systemd

One of the project's most notable demonstrations is its ability to boot Rocky Linux 10 to systemd's multi-user target. This exercises several important operating-system interfaces, including process management, dynamic linking, filesystems and related system services.

These capabilities make Ginux an interesting systems-programming experiment. They do not establish full Linux compatibility.

Why Rust is an important part of the project

Ginux is primarily written in Rust, a language that has become increasingly relevant to operating-system development.

Systems programming often involves working directly with memory, hardware interfaces and low-level execution mechanisms. Mistakes in these areas can create serious security vulnerabilities or cause entire systems to fail.

Rust provides memory-safety features designed to prevent many common classes of programming errors, including certain memory-access and concurrency problems.

This does not automatically make every Rust application secure. Developers still need to consider architecture, unsafe code, permissions, dependencies and system-level design.

Nevertheless, Rust's approach to memory safety makes it an interesting choice for a project attempting to build a new operating-system kernel.

Ginux also illustrates how AI coding agents can work with a systems-oriented language to produce and revise substantial amounts of low-level code under human supervision.

The limitations: Ginux is not ready to replace Linux

The headline about building a kernel in 11 days is impressive, but the project's limitations are just as important as its achievements.

Ginux currently supports only a subset of the Linux interfaces applications expect. Its repository documents incomplete ABI coverage, unfinished hardware support, and areas of networking, filesystems and resource enforcement that still need work.

Its demonstrated hardware environment is also limited. The project has primarily been validated in a QEMU virtual-machine configuration. Broad physical-hardware support, GPU support and NVMe support remain unfinished.

Security is another major consideration. The project has not undergone an independent security audit, and its documentation does not make a production-security claim.

The repository also records a failing aggregate test at the evaluated development checkpoint, despite narrower individual tests passing. This is a useful reminder that successful demonstrations do not necessarily mean an entire operating system has passed every test.

Linux has decades of development behind it, including extensive hardware support, security review, performance tuning, developer contributions and a large ecosystem of software vendors and maintainers.

Reproducing that level of reliability and compatibility is a much larger challenge than getting a prototype to boot a Linux distribution.

Kurtzer's project is therefore best understood as a research demonstration, not a replacement for Linux.

What this means for the future of software development

The larger question raised by Ginux is whether AI coding agents can meaningfully reduce the time and effort required to build complex software.

For years, AI coding assistants have been most visible in everyday development tasks: generating functions, explaining code, writing tests, fixing bugs and helping developers work through unfamiliar frameworks.

Ginux points toward a more ambitious use case.

An AI agent can potentially participate in a longer engineering process involving architecture documents, implementation, automated testing, debugging and repeated revisions. When a knowledgeable developer provides clear requirements and reliable ways to evaluate the output, the agent can take on a substantial portion of the implementation workload.

That does not eliminate the need for experienced engineers. In fact, the project demonstrates why expertise remains important.

Someone still needs to understand the underlying system, make architectural decisions, identify incorrect assumptions, evaluate test results and decide whether the final implementation is acceptable.

AI can accelerate implementation, but speed alone does not establish correctness, security or maintainability.

The bigger lesson for developers and technology companies

Ginux is an important example of how software development is evolving.

It suggests that the boundary between projects an individual developer can realistically attempt and projects that traditionally require larger engineering teams may be changing.

However, businesses should not interpret this as a reason to abandon engineering discipline or assume that AI-generated software is automatically production-ready.

The most useful approach is to combine AI-assisted implementation with experienced technical leadership, clear specifications, automated testing, security reviews and human approval at critical stages.

For software development companies, the opportunity is not simply to generate more code. It is to deliver better software more efficiently while maintaining the quality, reliability and security customers expect.

Ginux may not replace Linux, but its development offers a compelling demonstration of what can happen when deep systems-engineering knowledge is combined with an increasingly capable AI coding agent.

The next major shift in software development may not be AI writing individual functions faster. It may be AI agents helping experienced engineers build, test and maintain entire systems.