Грегори Курцер (Gregory Kurtzer), один из создателей CentOS и основатель Rocky Linux, показал Ginux — независимое ядро операционной системы на Rust, способное запускать программы Linux без использования самого ядра Linux. На разработку прототипа ушло 11 дней, практически весь код создал текст ИИ‑агент OpenAI Codex с моделью GPT-5.6 Sol. Курцер оценил затраты на обращения к модели примерно в $8000.

Инициатива уже способен запускать приложения Alpine Linux и скачивать пользовательское окружение Rocky Linux 10 с systemd до состояния multi-user.target. При этом речь не о модификации Linux и не о привычном дистрибутиве: Ginux самостоятельно реализует управление памятью, планировщик, процессы, файловые системы, сетевой стек и оболочку совместимости с Linux. Исходный код обнародован на GitHub под лицензией Apache 2.0.

В своём объявлении Курцер объяснил, что главным результатом считает не само ядро, а проверку нового подхода к разработке:

Настоящим экспериментом были способ разработки и проверка того, способен ли ИИ выполнить такую работу.

Почему Rust

Ginux создавался с нуля, и автор выбрал Rust как основной язык системного программирования. Это не было попыткой переписать исходники Linux: совместимость реализуется на уровне Linux ABI, а внутреннее устройство ядра определяется собственной архитектурой Ginux.

В техническом отношении Rust подходит для такой задачи по нескольким причинам. Его схема владения памятью позволяет предотвращать многие ошибки работы с указателями и временем жизни объектов ещё на этапе компиляции. Язык не требует сборщика мусора, обеспечивает низкоуровневый доступ к памяти и оборудованию и позволяет создавать исходник, работающий без стандартной библиотеки операционной системы.

Для разработки с участием ИИ это особенно интересно: компилятор способен обнаруживать целые классы ошибок в сгенерированном коде ещё до запуска тестов. Однако Rust не гарантирует правильности архитектуры, логики планировщика или реализации системных вызовов. В ядре неизбежно присутствуют низкоуровневые участки с unsafe и ассемблером, где обычные гарантии безопасности Rust ограничены.

Сам Курцер не приводит контролируемого сравнения Rust с C или C++ в этом эксперименте. Поэтому преимущества Rust здесь следует рассматривать как техническое обоснование выбора языка, а не как доказанный результат отдельного исследования.

Ginux использует Rust для большей части механизмов ядра и пользовательского контроллера. Небольшие ассемблерные участки отвечают за переходы между режимами процессора, обработку прерываний и системных вызовов. Платформа собирается в единый образ GINUX.EFI и загружается непосредственно через UEFI.

Почему именно GPT-5.6 Sol

В техническом отчёте Курцер отдельно объяснил выбор модели. Он использовал флагманскую GPT-5.6 Sol в настольном приложении Codex, причём решение было основано на практическом опыте, а не на сравнительном тестировании.

По наблюдениям автора, в предыдущих проектах продвинутые модели Claude чаще тратили контекст и токены на технически интересные побочные направления, результаты которых затем приходилось переделывать или отменять. Codex, напротив, лучше придерживался текущего этапа разработки и позволял с меньшим вмешательством повторять цикл: модификация кода, сборка, загрузка QEMU, диагностика ошибки и исправление.

Курцер специально оговаривает, что не проводил эксперимента с одинаковыми промптами, слепой оценкой результатов или точным сравнением расхода токенов между провайдерами. Следовательно, его наблюдения объясняют выбор GPT-5.6 Sol, но не доказывают её превосходства над Claude или другими моделями.

Разработка велась в рамках подхода Human‑Directed Agentic Engineering (HDAE). Курцер определял архитектуру, ограничения, этапы работ и критерии приёмки. Codex самостоятельно писал исходник, компилировал его, запускал виртуальную машину, анализировал логи, создавал тесты и исправлял обнаруженные проблемы.

Это не был один промпт с просьбой написать операционную систему. Работа выполнялась в одной длительной задаче Codex, но с постоянным участием человека, который проверял результаты и корректировал направление разработки. Архитектурные решения фиксировались в документации, а критерии готовности — в исполняемых тестах.

В отдельной хронологии решений автор подробно разграничил собственный вклад и работу агента. В частности, Курцер потребовал использовать изолированные домены как полноценные объекты ядра, а Codex предложил конкретные механизмы управления полномочиями, памятью и жизненным циклом этих доменов.

По итогам 11 дней исследовательская версия содержала 138 790 строк сохранённого кода реализации и тестов без учёта генерируемых данных, 261 отслеживаемый файл и 1037 коммитов. Эти цифры относятся к зафиксированной версии от 23 октября 2026 года, а не обязательно к текущему состоянию репозитория.

Весь эксперимент, по оценке Курцера, обошёлся около в $8000 расходов на api. Точные информация об использовании токенов не были сохранены, поэтому сумма остаётся авторской оценкой, а не независимо проверенным финансовым результатом.

Насколько серьёзным получилось ядро

Главное достижение Ginux — не отдельный работающий загрузчик или демонстрационный Hello World. Прототип способен выполнить в достаточной степени длинную последовательность операций, необходимых для запуска реального Linux userspace.

Система загружает OCI‑образы, проверяет их содержимое, формирует корневую файловую систему и запускает пользовательские процессы в собственных изолированных доменах. Эти домены управляют процессами, адресными пространствами, файловыми системами, полномочиями и жизненным циклом. OCI здесь используется для доставки файлов, а не как среда исполнения контейнеров.

В частности, Ginux запускает отдельные программы Alpine Linux с musl и BusyBox, приложения Rocky Linux с glibc и systemd из образа rockylinux/rockylinux:10-ubi-init. Новейший способен дойти до multi-user.target, то есть пройти существенную часть процедуры инициализации системы.

Для этого потребовалось реализовать значительную часть интерфейсов Linux. В соответствии с опубликованной матрице совместимости, из 375 системных вызовов Linux 6.12 для x86-64 целиком реализованы 82, частично — 245, ещё 48 отклоняются политиками проекта. При этом даже наличие обработчика системного вызова не означает полного соответствия его поведению в Linux.

Интересно, что реальное пользовательское окружение стало одним из основных инструментов проверки ИИ. В частности, первоначально Alpine могла запускать оболочку, но не могла нормально выводить содержимое корневого каталога. Позже запуск второго домена обнаружил некорректное использование глобального состояния. А systemd выявил недостающую семантику procfs, монтирования, сокетов, таймеров, учётных данных и терминалов.

В отчёте о методологии Курцер предупреждает, что без предметной экспертизы такие убедительно выглядящие, но неполные результаты легко принять за законченную работу. Именно следовательно он противопоставляет HDAE бесконтрольному vibe coding.

Что показали тесты производительности

Курцер не ограничился проверкой загрузки системы. Он также попытался сравнить выполнение одинакового бинарного файла sysbench в Rocky Linux на обычном ядре Linux и на Ginux.

Первые результаты оказались неудовлетворительными. В тесте памяти Ginux обеспечивал только 48,39 МиБ/с против 679,51 МиБ/с у Linux. В тесте потоков разница была ещё заметнее: 0,078 против 306,129 событий в секунду.

После профилирования Codex обнаружил проблемы в переключении потоков и обслуживании времени. В частности, частые системные вызовы для получения времени создавали существенные накладные расходы, поскольку в Ginux ещё отсутствовал механизм vDSO. После исправлений скорость теста памяти выросла до 620,58 МиБ/с, а поточного теста — до 309,732 событий в секунду.

В документации по производительности и техническом отчёте автор подробно описал последовательность этих оптимизаций.

Впрочем, результаты нельзя считать доказательством сопоставимой производительности двух ядер. Измерения выполнялись с одним виртуальным процессором под QEMU TCG на Mac с Apple Silicon. Окружения, наборы служб и пути загрузки различались, а тесты были короткими. Полученные цифры прежде всего показывают, что агент смог обнаружить серьёзные проблемы реализации и существенно сократить отставание на конкретных нагрузках.

Почему Ginux пока не заменит Linux

Вопреки работоспособный прототип, ограничений у проекта немало. Основной испытательной платформой остаётся QEMU Q35 с OVMF и virtio. Нет полноценной поддержки физического оборудования, GPU, NVMe, широкого набора файловых систем и стабильного интерфейса сторонних драйверов. Совместимость с Linux неполная, независимый аудит безопасности не проводился.

Кроме того, не все тесты проходят успешно. В зафиксированной исследовательской версии make check и отдельные проверки запуска Rocky Linux выполнялись успешно, но общий make test завершался ошибкой в проверке жизненного цикла системного супервизора после execve().

Курцер не скрывает этих проблем и не позиционирует Ginux как готовую к эксплуатации операционную систему. В отчёте он признаёт, что для практического продукта разумнее было бы начать с существующего Linux: тогда авторы сразу получили бы поддержку оборудования, файловых систем, механизмов изоляции и огромную базу проверенного кода.

Но для исследования требовалось другое — проверить, способен ли ИИ‑агент под управлением опытного инженера собрать сложную системную программу с нуля.

В заключении Курцер формулирует важное различие: написать код сравнительно легко; гораздо сложнее обеспечить совместимость, сопровождение и сообщество вокруг него. Ginux пока далёк от полноценного Linux, тем не менее показывает, что создание в достаточной степени сложного и работоспособного прототипа ядра уже может занимать не годы, а дни — при условии, что архитектуру, критерии правильности и проверку результатов контролирует специалист.

Код доступен на GitHub, исследование опубликовано на Zenodo, а исходники технического отчёта, тесты и история инженерных решений позволяют самостоятельно изучить ход эксперимента.