Gregory M. Kurtzer — veterano da infraestrutura de código aberto responsável pela criação do CentOS, do Rocky Linux, do Singularity/Apptainer e atual CEO da CIQ — apresentou publicamente o Ginux, um protótipo experimental de kernel e sistema operacional para arquitetura x86-64 escrito prioritariamente em Rust.

Ao contrário de distribuições customizadas ou forks de árvore principal, o Ginux não compartilha código-fonte com o kernel Linux. Ele implementa do zero seu próprio gerenciador de memória, escalonador de processos (scheduler), sistema de arquivos virtual (VFS), pilha de rede, suporte a dispositivos virtio e controle de privilégios, expondo a ABI do Linux (Application Binary Interface) como uma camada de "personalidade" capaz de executar binários inalterados do Alpine Linux (musl/BusyBox) e inicializar o Rocky Linux 10 (glibc) com systemd até o estágio multi-user.target.

O projeto foi construído ao longo de 11 dias como um experimento formal de engenharia de sistemas assistida por agentes — batizado por Kurtzer de Human-Directed Agentic Engineering (HDAE) — resultando em aproximadamente 139.000 linhas retidas de código e testes automatizados sob licença Apache 2.0.

Linux como "personalidade", não como kernel hospedeiro

Na arquitetura clássica de contêineres em Linux, ferramentas como Docker, Podman ou containerd dependem de primitivas do próprio kernel hospedeiro (namespaces, cgroups e seccomp) para fatiar a visão de um único sistema operacional. O Ginux inverte essa premissa: não há uma distribuição hospedeira por baixo.

O sistema é compilado como uma única imagem unificada GINUX.EFI (build/esp/EFI/BOOT/BOOTX64.EFI), carregada diretamente pelo firmware UEFI em máquinas virtuais QEMU Q35/OVMF (com suporte a aceleração KVM em hosts Linux x86-64 e tradução dinâmica TCG em Macs com Apple Silicon).

O Ginux inicializa diretamente via UEFI e sobe o userspace completo do Rocky Linux 10 com systemd atuando como PID 1 dentro de um domínio nativo.

Assim que as pequenas fronteiras em Assembly configuram as tabelas de páginas, interrupções, exceções e entradas de syscall, o kernel em Rust mapeia um controlador de administração estático diretamente no espaço de usuário (ring 3). Essa decisão arquitetural evita que o plano de controle rode com privilégios de ring 0:

  • Envelope de boot selado: O controlador em ring 3 descobre o estado do hardware, gerencia o armazenamento persistente, mantém um cache de imagens OCI verificado por digest criptográfico (SHA-256) e administra o ciclo de vida das cargas de trabalho;
  • Fronteira de autoridade estrita: O controlador utiliza chamadas normais da ABI Linux para operações comuns e recorre a uma interface ioctl versionada e validada pelo kernel para operações administrativas, podendo delegar ou revogar permissões sem jamais fabricar nova autoridade de ring 0;
  • OCI apenas como transporte: Imagens de contêiner padrão (como alpine:latest ou rockylinux/rockylinux:10-ubi-init) são baixadas e montadas em sistemas de arquivos locais para cada domínio, mas o isolamento não usa runc nem namespaces do Linux.

Domínios nativos e capacidades com controle de geração

A unidade fundamental de isolamento no Ginux é o Domínio (domain), um objeto nativo de primeira classe dentro do kernel. Cada domínio é proprietário exclusivo de:

  1. Sua própria árvore de processos, threads e espaços de endereçamento;
  2. Uma tabela de capacidades marcada por geração (generation-tagged capability table), que garante a revogação limpa de recursos caso um serviço ou domínio falhe ou seja reiniciado;
  3. Raízes de sistema de arquivos independentes (combinando camadas OCI imutáveis em cache, um overlay gravável e implementações próprias de tmpfs, procfs e devfs);
  4. Políticas individuais de CPU, memória, objetos de IPC, endpoints de rede e concessões de DMA isoladas via Intel IOMMU (VT-d) e interrupções MSI-X.
Interação com o controlador ring-3 do Ginux (prompt ginux>) para provisionamento e execução de domínios isolados a partir de imagens OCI.

No prompt interativo ginux>, criar e subir uma instância completa do Rocky Linux 10 com systemd exige apenas três instruções:

domain new rocky
domain set rocky image=rockylinux/rockylinux:10-ubi-init init=/sbin/init memory-mib=2048
domain start rocky --attach

Para suportar esse ecossistema sem o kernel Linux, o Ginux mapeia explicitamente todas as 375 chamadas de sistema (syscalls) da tabela do Linux 6.12 x86-64: no estágio atual do projeto, 82 syscalls possuem implementação completa, 245 possuem implementação parcial focada nos fluxos reais de glibc/musl/systemd, e 48 são negadas por política de segurança (como chamadas que violariam o isolamento entre domínios).

Otimizações de baixo nível: do boot de 15s para 4s e vDSO próprio

Um dos aspectos mais reveladores da documentação técnica do Ginux (docs/PERFORMANCE.md) é a investigação das anomalias de desempenho encontradas ao colocar um userspace corporativo real (systemd + glibc) sobre um kernel recém-escrito.

Na primeira vez em que o Ginux conseguiu levar o Rocky Linux 10 até o console de login sob emulação QEMU TCG em Apple Silicon, o processo levou 15.344 ms. Ao instrumentar o kernel com um profiler próprio (make profile-rocky-systemd), foram identificados e corrigidos três gargalos clássicos de sistemas operacionais:

  • Inversão de espera em sockets Unix aninhados: Durante o boot do systemd, um processo filho ficava em busy-spin aguardando um socket Unix pertencente ao próprio processo pai suspenso, esgotando timeouts de 1 e 5 segundos. Fazer o escalonador ceder a CPU imediatamente quando o par bloqueado pertence ao processo pai eliminou cerca de 6 segundos do tempo de inicialização;
  • Cache de páginas imutáveis por domínio: O kernel inicialmente duplicava páginas somente-leitura e executáveis do rootfs a cada fork()/execve() e realizava varreduras quadráticas de referências de frames, alocando cerca de 172.000 frames de arquivo durante o boot. Com a introdução de índices exatos e compartilhamento Copy-on-Write (CoW) para páginas imutáveis, o consumo caiu para 10.400 frames, reduzindo a mediana do boot para 4.082 ms (queda de 73,4%);
  • Implementação de vDSO e vvar compatíveis com Linux: No benchmark de memória de 1 KiB do sysbench, o Ginux atingia inicialmente modestos 48,39 MiB/s. Ao implementar uma página vDSO (virtual dynamic shared object) e uma página vvar somente-leitura com conversão TSC em ponto fixo sem divisão por leitura, a taxa saltou para 620,58 MiB/s (próxima aos 679,51 MiB/s do próprio Rocky Linux rodando sobre o kernel Linux no mesmo perfil).

Como funcionou a Engenharia Agêntica Dirigida por Humanos (HDAE)

O código do Ginux foi produzido em uma tarefa persistente de 11 dias utilizando o agente OpenAI Codex equipado com o modelo GPT-5.6 Sol, sob direção arquitetural contínua de Gregory Kurtzer. O processo completo foi documentado no relatório técnico publicado no Zenodo (DOI: 10.5281/zenodo.23682548) e no registro de proveniência de decisões (STEERING-PROVENANCE.md).

Relatório técnico publicado por Gregory M. Kurtzer no Zenodo detalhando a metodologia Human-Directed Agentic Engineering (HDAE) e os artefatos de validação.

Em vez de pedir genericamente para a IA "escrever um kernel", o método HDAE estruturou uma divisão rígida de responsabilidades:

  • Direção humana (Kurtzer): Definiu a arquitetura de domínios nativos, a exigência de empacotamento único em GINUX.EFI, o isolamento do controlador em ring 3, os critérios de aceitação e a proibição de atalhos que mascarassem falhas reais;
  • Execução agêntica (Codex): Escreveu as estruturas de dados em Rust e as pontes em Assembly, inicializou o sistema via QEMU, executou baterias de testes automatizados (make test-linux-runtime, make test-alpine, make test-rocky-systemd), diagnosticou kernel panics e iterou sobre mais de mil commits;
  • Correção guiada por cargas reais: Testes sintéticos de ABI frequentemente passavam enquanto o systemd ou o glibc travavam em casos de borda envolvendo sinais, futex, pseudo-terminais (pty) ou descritores no procfs, forçando revisões arquiteturais completas.

Limitações declaradas e o verdadeiro "fosso" do Linux

Tanto no anúncio oficial quanto no artigo técnico, Kurtzer faz questão de enfatizar o que o Ginux não é: o projeto é um protótipo de pesquisa e não substitui o kernel Linux em produção.

Atualmente, o sistema opera em uma única vCPU virtualizada no perfil QEMU Q35 (sem suporte a multiprocessamento simétrico SMP multicore real), não possui suporte a placas de vídeo (GPU), discos NVMe físicos ou matriz ampla de hardware, e o próprio repositório mantém registrado de forma transparente que uma das sondas de ciclo de vida pós-execve() ainda falha na suíte agregada make test.

"A lição maior é que a IA já consegue gerar software de sistemas de altíssima complexidade, mas compatibilidade ampla, segurança auditada, habilitação de hardware físico, padrões, comunidade e manutenção de longo prazo continuam sendo o verdadeiro fosso competitivo." — Gregory M. Kurtzer, criador do CentOS, Rocky Linux e Ginux

O código-fonte completo, os scripts de compilação para QEMU e os logs brutos de benchmark podem ser inspecionados gratuitamente no GitHub: