Gregory Kurtzer, fundador de CentOS y creador de Rocky Linux, ha presentado Ginux, un núcleo de sistema operativo escrito desde cero. No es una bifurcación de Linux, pero sí es compatible con él: arranca Rocky Linux 10 hasta systemd y ejecuta programas de Linux sin modificarlos. Lo llamativo es el método. Según su autor, lo desarrolló en solo 11 días y buena parte del código lo escribió un agente de inteligencia artificial, bajo su dirección. El resultado son unas 139 000 líneas de código y más de mil confirmaciones en el repositorio. Eso sí, hablamos de un prototipo de investigación. Solo funciona en una máquina virtual QEMU, no tiene soporte para hardware real y no ha pasado ninguna auditoría de seguridad. Repasamos qué es Ginux, cómo se hizo y qué lecciones deja.

Quién está detrás

Kurtzer no es un recién llegado. Creó CentOS y, cuando Red Hat cambió el rumbo de esa distribución, lanzó Rocky Linux como sustituto comunitario. Hoy dirige CIQ, una empresa que ofrece soporte empresarial en torno a Rocky.

Por eso su nuevo proyecto sorprende. No es otra distribución reconstruida a partir de código de Red Hat. Es un núcleo completo, con todo lo que eso implica, y lo ha construido con un agente de IA que trabajó durante once días seguidos.

Kurtzer lo anunció el 27 de octubre de 2026 en X. La noticia se difundió rápido, y It’s FOSS la resumió aquí con detalles útiles sobre el alcance real del proyecto.

Qué es Ginux

Ginux es un núcleo independiente para procesadores x86-64, escrito principalmente en Rust. Tiene su propia gestión de memoria, su planificador, su modelo de procesos, sus sistemas de archivos, su pila de red y su soporte de dispositivos. Todo está escrito desde cero.

Su rasgo más curioso es la compatibilidad. Ginux implementa la ABI de Linux, es decir, la interfaz binaria que usan los programas compilados para hablar con el núcleo. Gracias a ello, los binarios de Linux existentes funcionan sin cambios. El propio proyecto lo plantea así: Linux es una «personalidad» que ofrece Ginux, no el núcleo que corre por debajo.

El nombre podría sugerir una mezcla de GNU y Linux, pero no es el caso. La G alude a GPT, el modelo que escribió el código. El código está publicado con licencia Apache 2.0  y cualquiera puede revisarlo.

Cómo funciona por dentro

Ginux se compila en una única imagen, GINUX.EFI, que arranca directamente mediante UEFI. No necesita ningún núcleo Linux anfitrión. Es un detalle técnico importante, porque demuestra que no hay Linux «escondido» debajo.

El sistema reparte el trabajo en dominios aislados. Cada dominio tiene sus propios procesos, su espacio de direcciones, su sistema de archivos y su ciclo de vida. Según el proyecto, las fronteras entre dominios son más fuertes que las de los contenedores OCI o los espacios de nombres de Linux. Es una afirmación que habría que validar con una auditoría independiente.

Además, Ginux puede descargar y verificar imágenes de contenedor OCI y usarlas para montar el sistema de archivos raíz de un dominio. Así consigue arrancar Rocky Linux 10 hasta el objetivo multi-user.target de systemd. También ejecuta programas seleccionados de Alpine Linux, como musl y BusyBox.

Que una distribución empresarial completa llegue hasta ese punto es una prueba exigente. Un arranque de systemd toca memoria, procesos, señales, sistemas de archivos y red a la vez.

El método: ingeniería agéntica dirigida por humanos

Lo más interesante no es el núcleo, sino cómo se hizo. Kurtzer llama al método HDAE, siglas de Human-Directed Agentic Engineering.

El reparto es claro. La persona decide la arquitectura, las restricciones, los hitos, los criterios de aceptación y el momento de parar. El agente se ocupa del bucle de implementación: escribe código, lo arranca, lo prueba, diagnostica los fallos, corrige y repite, siempre contra comprobaciones ejecutables.

En este caso fue una sola tarea persistente de OpenAI Codex, con el modelo GPT-5.6 Sol, durante once días. El resultado fueron unas 139 000 líneas de implementación y pruebas. Si se reparten entre los once días, salen más de 12 000 líneas diarias. Y con más de mil confirmaciones, el ritmo ronda las 90 al día.

Dos elementos mantuvieron el rumbo. Los documentos de arquitectura evitaron que el agente se desviara. Y los entornos de usuario reales, como Rocky Linux, detectaron errores que las pruebas sintéticas no veían. Es una lección útil: un sistema operativo real es el mejor banco de pruebas.

Lo que Ginux todavía no es

Conviene rebajar las expectativas. Ginux solo corre en QEMU. No tiene perfil para hardware físico, ni soporte de GPU, ni de NVMe. Tampoco ha pasado una auditoría de seguridad independiente.

Su autor lo presenta como prototipo de investigación y no como sustituto de Linux. Él mismo reconoce que la generación de código complejo con IA ya es posible, pero que la compatibilidad, la seguridad, el soporte de hardware, los estándares, la comunidad y el mantenimiento a largo plazo siguen siendo el verdadero foso defensivo.

Es una valoración sensata. El núcleo Linux acumula décadas de controladores, revisiones de código y casos límite que ningún proyecto nuevo ha visto. Un arranque correcto en una máquina virtual es un primer paso, no una meta.

Reflexiones adicionales

Ginux no amenaza a Linux, y su autor no lo plantea así. Lo que sí muestra es la velocidad a la que puede avanzar una persona con experiencia cuando dirige a un agente de IA. Un trabajo que antes habría requerido un equipo y varios años se ha convertido en un proyecto de dos semanas, al menos como prototipo.

Esto tiene matices. El agente no trabajó solo. Kurtzer lleva décadas en sistemas y sabía qué pedir, cómo comprobarlo y cuándo parar. Sin esa experiencia, el resultado habría sido muy distinto. La IA multiplica la capacidad de quien ya sabe, pero no sustituye ese conocimiento.

También queda una pregunta abierta sobre la calidad. Escribir 139 000 líneas es una cosa y mantenerlas durante años es otra. La seguridad de un núcleo escrito casi por completo por un modelo solo se podrá juzgar con revisión externa, y de momento no la hay.

Aun así, el experimento merece seguimiento. Si el método HDAE se confirma en otros proyectos, cambiará la forma de plantear prototipos de software de sistemas. Y para quienes trabajamos con Linux a diario, es un buen recordatorio de que los estándares abiertos, como la ABI, permiten que aparezcan alternativas sin romper el ecosistema.