CentOS Co-Founder Used GPT-5.6 Sol to Drive Codex to Write the Rust Kernel Ginux in 11 Days
CentOS co-founder Gregory Kurtzer has announced a new kernel project, Ginux, in which memory management, process scheduling, file systems, and networking are all written from scratch in Rust, and existing programs can run without modification by emulating the Linux ABI. The project is driven by a continuously running OpenAI Codex task using GPT-5.6 Sol, which generated approximately 139,000 lines of code and test content and completed more than 1,000 commits within 11 days. Using the x86-64 interface of Linux 6.12 as a reference, of 375 system calls only 82 are fully implemented, 245 are partially available, and 48 are unavailable; it currently runs only in QEMU virtual machines, does not yet support booting on physical hardware, GPUs, or NVMe, and has not undergone an independent security audit.
Why read this
AI score 67
The original article provides the proportion of system calls implemented and the development approach, so readers can judge the practical boundaries of AI agents writing system software.
Topics
Body · AI translation
Kurtzer first announced the Ginux project last week on the social platform X, and the related code has also been uploaded to GitHub under the Apache 2.0 open source license. The name Ginux combines three elements: Linux, GPT, and Greg. The project introduction even jokes that, to prevent the author from becoming too self-important, the letter G should be interpreted as GPT.
Ginux is not a fork of Linux, nor does it copy kernel components from existing Linux code. Its memory management, process scheduling, file system, and networking functions are all written from scratch, mainly in the Rust language. What it truly shares with Linux is the application binary interface (ABI); that is, Ginux emulates the system interfaces that Linux provides to software, enabling programs originally written for Linux to run without code modifications.
The project developers describe this design as follows: Linux is not just a kernel implementation, but can also be viewed as a "personality" or compatibility environment that the kernel presents to application software. Currently Ginux implements only Linux compatibility mode, but in the future it does not rule out the possibility of adding a BSD compatibility mode.
However, Ginux is still quite far from full Linux compatibility. According to the project documentation, using the x86-64 interface of Linux 6.12 as a reference, of its 375 system calls, only 82 are currently fully implemented, another 245 work only partially, and the remaining 48 are intentionally set as unavailable. This means that although it can already run some existing Linux software, it cannot yet be regarded as a mature general-purpose Linux replacement.
Ginux also introduces an isolation mechanism called "Domains." Software runs in environments isolated from one another, and each domain has its own independent processes, memory space, and file system. The project hopes this mechanism can provide stronger isolation boundaries than traditional containers. However, Ginux can still use standard OCI container images to build the file systems of each domain. It is precisely in this way that it has been able to load Rocky Linux 10 and advance system startup to systemd's multi-user target.
The most notable aspect of this development work is the role artificial intelligence plays in it. In his technical report, Kurtzer calls his method "Human-Directed Agentic Engineering." He is responsible for determining the overall architecture, defining development stages and acceptance criteria, while AI agents undertake most of the subsequent execution work, including writing code, booting the kernel, running tests, and modifying code after problems are discovered.
The entire process was completed by a continuously running OpenAI Codex task, using the GPT-5.6 Sol model. Over 11 days, the AI generated a cumulative total of about 139,000 lines of code and test content and completed more than 1,000 code commits. During development, the real distribution Rocky Linux also played an important role: during actual booting and running, it exposed some problems that manually constructed test cases had failed to find.
However, Kurtzer has not packaged Ginux as an operating system ready for production environments. The project currently still runs entirely in QEMU virtual machines, does not yet support booting directly on physical hardware, and has no GPU or NVMe storage device support. More importantly, Ginux has not yet undergone an independent security audit, so its security cannot be fully verified.
Kurtzer believes that artificial intelligence now has the ability to write complex system software, but the truly difficult parts have not disappeared as a result. Software compatibility, security, and long-term maintainability remain the key barriers determining whether an operating system can truly succeed. In other words, AI can significantly shorten the process of creating code from nothing, but it cannot automatically guarantee that the code is reliable enough, nor can it replace long-term engineering validation.
Meanwhile, the Linux kernel development community is also gradually trying to introduce AI tools. Last month, Linux founder Linus Torvalds used Claude Code to write a set of experimental page cache patches, but reviewers subsequently found race conditions in them, so the related code is still under review. Around the same time, Linux kernel maintainers also agreed to no longer require contributors to disclose whether code was written with AI assistance.
The significance of Ginux may not lie in its ability to immediately replace Linux, but in the fact that it demonstrates a new software engineering model: humans are responsible for goals, architecture, and key decisions, while AI agents handle a large amount of concrete implementation and testing work. Complex systems that once took years to begin taking shape may now be able to obtain a working prototype in a very short time. However, moving from a prototype to a truly reliable operating system that can adapt to a wide range of hardware and be maintained over the long term is still a long engineering road.