Грегори Куртцер, сооснователь CentOS и основатель Rocky Linux, представил экспериментальное ядро Ginux, созданное преимущественно на Rust при участии ИИ за 11 дней. Оно самостоятельно загружается через UEFI и запускает отдельные неизменённые Linux-программы, включая приложения Alpine Linux и Rocky Linux. Исходный код доступен по лицензии Apache 2.0; проект предназначен для исследований и пока не готов к использованию в рабочих системах.
Самостоятельное ядро с совместимостью с Linux
Ginux – самостоятельное ядро и прототип операционной системы для x86-64. В нём реализованы собственные управление памятью, планировщик задач, модель процессов, виртуальная файловая система, сетевой стек, поддержка устройств и слой совместимости с Linux ABI. Большинство механизмов написано на Rust, а для низкоуровневых переходов, обработки прерываний и системных вызовов используются небольшие участки ассемблерного кода.
Совместимость позволяет выполнять выбранные готовые программы из Linux-дистрибутивов поверх ядра Ginux. Автор сообщает о запуске приложений Alpine Linux с musl и BusyBox, а также программ Rocky Linux с glibc. В проверенной версии пользовательское окружение Rocky Linux 10 с systemd достигает multi-user.target – этапа загрузки многопользовательской системы.
Linux ABI – двоичный интерфейс между готовыми Linux-программами и ядром: системные вызовы, структуры данных и ожидаемое поведение системных механизмов. Запуск нескольких приложений подтверждает совместимость с проверенными сценариями, но не со всем программным обеспечением Linux.
В матрице совместимости учтены 375 номеров системных вызовов Linux 6.12 для x86-64. Их состояние распределено следующим образом:
| Статус | Количество | Что означает |
|---|---|---|
| Полностью реализованы | 82 | По оценке проекта, соответствуют выбранному контракту Linux и проверены тестами, включая ошибки и граничные случаи |
| Реализованы частично | 245 | Обрабатываются и полезны в отдельных сценариях, но имеют ограничения либо ещё не доказано соответствие поведению Linux |
| Запрещены политикой | 48 | Распознаются и отклоняются как привилегированные операции; это не считается полноценной поддержкой |
| Не имеют обработчика | 0 | Ни один вызов выбранной таблицы не попадает в обработчик по умолчанию, возвращающий ENOSYS |
| Всего | 375 | Базовый интерфейс Linux 6.12 x86-64; варианты x32 и i386 не входят в область совместимости |
Таким образом, наличие обработчика для каждого номера не означает полной реализации всех вызовов. Ограничения сохраняются в загрузке программ, процессах и потоках, сигналах, сетевых интерфейсах, псевдофайловых системах, пространствах имён и cgroups.
Как Куртцер организовал разработку с Codex
В техническом отчёте Куртцер описывает один длительный сеанс работы OpenAI Codex с моделью GPT-5.6 Sol. За 11 календарных дней в проекте осталось 138 790 строк реализации и тестов, или около 139 тысяч. Это объём сохранённого кода после доработок, а не число строк исключительно ядра.
Автор называет подход Human-Directed Agentic Engineering, или HDAE. Он определял архитектуру, требования, ограничения, этапы и критерии приёмки. Codex с GPT-5.6 Sol реализовывал компоненты, собирал и загружал систему, запускал тесты, изучал ошибки и вносил исправления. Архитектурные решения и текущие цели сохранялись в документах проекта.
Куртцер проверял поведение системы и уточнял задания по результатам работы с ней. Например, запуск второго домена выявлял общее состояние, которое требовалось разделить, а systemd обнаруживал пробелы в системных интерфейсах. По оценке автора, расходы составили около 8 000 $; выгрузка расхода токенов от провайдера не сохранена. Описанный в отчёте результат зафиксирован в коммите d11c126a048a51fe7eb9c4105f31760add1027ea от 23 октября 2026 года.
Домены, образы OCI и встроенный контроллер
Нагрузки в Ginux организованы в домены. Каждый домен имеет собственное состояние процессов, адресных пространств, корневой файловой системы, монтирований, полномочий и жизненного цикла. Несколько доменов используют одно ядро Ginux; внутри домена можно запускать пользовательское окружение дистрибутива с systemd в роли PID 1.
Домен Ginux – объект ядра, который задаёт границы владения ресурсами, выполнения и изоляции нагрузки. Образ OCI поставляет начальное содержимое файловой системы, а выполнение процессов и разграничение доступа обеспечивает Ginux.
Система умеет загружать, проверять, кэшировать и распаковывать образы OCI, собирая из их слоёв корневую файловую систему домена. Конфигурация контроллера, определения доменов и кэш образов сохраняются между перезагрузками. Записываемые слои доменов в исследованной версии остаются временными: сохранность конфигурации не означает сохранность всех изменений внутри нагрузки.
Ядро, необходимые загрузочные компоненты и контроллер администрирования упакованы в единый образ GINUX.EFI. При загрузке ядро запускает контроллер как обычный процесс пользовательского пространства, в ring 3. Контроллер управляет устройствами, сетью, хранилищем, образами и доменами; привилегированные операции проходят через проверяемый ядром интерфейс управления.
Что работает и какие ограничения остаются
Основная проверенная конфигурация – виртуальная машина QEMU x86-64 Q35 с прошивкой OVMF, Intel IOMMU и устройствами virtio. На подходящем компьютере с Linux и процессором x86-64 используется KVM, а на Mac с Apple Silicon – эмуляция x86-64 через QEMU TCG.
| Область | Продемонстрировано | Ограничения |
|---|---|---|
| Загрузка | Единый UEFI-образ x86-64 в Q35/OVMF | Нет готовых для эксплуатации механизмов подписания, восстановления и проверенного профиля физического оборудования |
| Управление | Встроенный контроллер в пользовательском пространстве | Нет готовой системы удалённого администрирования |
| Домены | Несколько доменов с раздельным состоянием процессов, памяти, файловых систем и полномочий | Изоляция устройств и принудительное соблюдение ограничений ресурсов реализованы не во всех путях |
| Linux-программы | Выбранные приложения Alpine и Rocky; загрузка Rocky с systemd до multi-user.target | Совместимость с дистрибутивами целиком не заявлена |
| Хранение данных | Сохранение конфигурации и проверенного кэша слоёв OCI | Постоянное хранение записываемых данных доменов и восстановление после сбоев не завершены |
| Сеть | DHCP и DNS хоста, настройка виртуальных связей, loopback и проверка жизненного цикла | Независимые сетевые пути и аренда адресов для каждого домена не завершены |
| Устройства | Блочные и сетевые устройства QEMU virtio, MSI-X, механизмы VT-d | Нет поддержки GPU, NVMe, широкого набора оборудования и стабильного ABI сторонних драйверов |
| Производительность | Узкое сравнение в QEMU с одним виртуальным процессором и одинаковым исполняемым файлом sysbench | Замеры не характеризуют общее быстродействие ядра, работу на физическом оборудовании или многоядерные нагрузки |
| Безопасность | Тесты механизмов полномочий и защиты от повторного использования устаревших идентификаторов | Независимый аудит не проведён; готовность к защищённой эксплуатации не заявлена |
В исследованной версии также не проходит весь общий набор make test: остаётся известный сбой проверки жизненного цикла системного супервизора после execve(). Успешные отдельные проверки, включая загрузку Rocky с systemd, не означают, что весь набор тестов проходит без ошибок.
Сам эксперимент представляет собой один описанный автором случай. В нём нет сопоставимого проекта, выполненного только людьми, испытания другой модели в тех же условиях или независимого воспроизведения. Срок разработки и число строк кода поэтому не измеряют качество системы или выигрыш относительно обычной разработки.
Как собрать и попробовать Ginux
Согласно текущему README, для сборки требуются Rust 1.99.0 через rustup, Clang с поддержкой целевой платформы x86_64-none-elf, QEMU с x86-64 и OVMF, а также GNU Make. В каталоге исходного кода проверка окружения и запуск выполняются командами:
make doctor make run
Сборка создаёт загрузочный файл build/esp/EFI/BOOT/BOOTX64.EFI. Команда make run также создаёт разреженный файл тома build/qemu/volume.raw. Команда make reset-storage удаляет этот том; при следующей загрузке система создаёт чистый.
В приглашении ginux> можно создать домен Alpine Linux и открыть его оболочку:
domain new alpine domain set alpine image=alpine:latest init=/bin/sh domain start alpine --attach
Сочетание Control-] отключает консоль домена и возвращает к контроллеру. Повторное подключение и запуск дополнительных процессов доступны командами:
domain attach alpine domain exec alpine /bin/echo hello domain exec alpine --interactive /bin/sh
Для проверенного сценария Rocky Linux 10 с systemd README приводит отдельный образ с init и настройку памяти 2048 МиБ:
domain new rocky domain set rocky image=rockylinux/rockylinux:10-ubi-init init=/sbin/init memory-mib=2048 domain start rocky --attach
Базовый образ rockylinux/rockylinux:10 не содержит systemd. Команда domain start ставит запуск в очередь; состояние можно посмотреть через domain list и domain status NAME. Эти примеры предназначены для экспериментов с прототипом в описанной виртуальной машине.
Вывод
Ginux даёт разработчикам открытый пример того, как сочетать архитектурные решения человека, работу ИИ-агента и исполняемые проверки при создании системного ПО. Изучать его имеет смысл как исследовательский проект: результаты запуска приложений относятся к конкретным проверенным сценариям, а дальнейшая работа требует расширения совместимости, аппаратной поддержки и проверки надёжности.
