Юникернелы были сложными, но ИИ-агенты это меняют, считает автор блога

Автор блога (его имя в доступном тексте не указано) пересказывает разговор с Justin Cormack, который когда-то работал над MirageOS и Unikernel Systems. Cormack ведёт для своей рассылки серию бесед о юникернелах, и автор стал в ней первым собеседником. Разговор шёл с паба; обсуждали Mirage, Orleans, Haskell, Nix и многое другое. Отредактированная расшифровка опубликована у Cormack, на Ignore Previous Directions.

Главный тезис: юникернелы были сложными, но ключевое слово «были». Юникернел, это когда приложение само является операционной системой: пользовательского пространства нет, и веб-сервер, DNS или отправку почты нельзя запустить отдельным процессом, их нужно писать как библиотеки внутри приложения. Именно в этом, по словам автора, была главная трудность. Cormack вспоминает, что при создании Mirage были стек TCP и стек HTTPS, но почти не было ничего для хранения данных, а драйверы приходилось вытаскивать из NetBSD, чтобы запускать их в пользовательском пространстве. Теперь, считает автор, сложные концепции (Nix, Bazel, юникернелы) уже есть в весах моделей, и остаётся лишь избавиться от догмы, что это трудно.

Второй тезис: операционная система, это долг дизайна. Автор объясняет, что многопользовательская ОС появилась сорок лет назад, потому что перед ней сидел оператор-человек, а приложение поставили сверху. Приложения взламывают и без ИИ, а полученная оболочка (shell) становится для атакующего удобным каналом для кражи данных. У юникернела поверхность атаки гораздо меньше: нет оболочки и интерпретатора, значит, «следующего шага» у атакующего нет. По мнению автора, это превращает массовую атаку (взять RCE недели в популярном фреймворке) в целевую, для которой нужен исходный код. Cormack возразил: люди слишком расплывчато говорят об уменьшении поверхности атаки; даже в контейнере без оболочки обычно есть что-то вроде интерпретатора, можно выполнить новую программу без записываемой файловой системы, а безопасность памяти и «гаджеты» никуда не деваются. Автор согласен, но напоминает, что отрасль двадцать шесть лет уменьшает поверхность атаки по частям (отдельные контейнеры для сборки и продакшена, затем Chainguard), вместо того чтобы убрать её совсем.

Третий тезис: недостающие библиотеки теперь можно портировать. Классическое возражение «нужен клиент Stripe, а на OCaml его нет» автор снимает запуском цикла агента, который портирует библиотеку с Go на OCaml. Cormack привёл похожий пример: при сборке минимальных образов Linux для устройств ему понадобилась файловая система XFS, и вместо xfsprogs он поручил агенту написать mkfs.xfs на Rust с побайтно идентичным результатом и поддержкой всех флагов. Агент по очереди восстанавливал форматы на диске, тесты прогонялись на разных размерах блока; всё заняло несколько часов. Это работает, потому что исходный инструмент служит эталоном (golden oracle): можно создать файловые системы обеими реализациями и сравнить их. Для хранения автор советует подход turbopuffer: S3 как основное неограниченно растущее хранилище с локальным кэшем на NVMe и LRU для горячих данных; Cormack тоже сторонник «S3 для всего».

Про Nix автор пишет, что сам язык ему не нравится, зато Nixpkgs хорош, а машинные тесты NixOS позволяют поднять парк машин и проверить взаимодействие сетевых правил с приложением. Сломанную зависимость или проблему цепочки поставок можно закрыть оверлеем (overlay). Агентам нужно менять мир как исходный код первой стороны, а не как чужие готовые бинарники.

По безопасности автор видит два выбора: для спутников в космосе, seL4, формально верифицированная ОС, а всем остальным стоит всерьёз рассмотреть юникернелы, а не укреплять то, что легко взломать. Критику про единый уровень привилегий у ранних юникернелов он парирует: в 2026 году разделение по кольцам привилегий «одним запросом» к модели. Он напоминает, что от ядра Linux теперь ждут еженедельного обновления, а на неделе записи разговора кто-то взломал KVM (по описанию автора, по сути Firecracker) и получил $50 000 от Vercel и нескольких других вендоров.

В третьей части автор рассказывает о собственном опыте: около семи месяцев назад он глубоко изучил юникернелы, чтобы проверить свою ментальную модель, и собрал папку Mirage с нужной функциональностью: NTP-клиент (портированный с другого языка) и NTP-сервер на основе RADclock, сетевой стек, DNS, HTTP-клиенты и серверы, структурированное логирование, OTel, клиенты Anthropic и OpenAI, платежи через Airwallex, универсальную библиотеку повторов для обратного давления (back pressure) и обёртку для персональных данных на границе логирования. Самая «безумная» вещь, Spaceleans: Microsoft Orleans, портированная на OCaml и работающая как юникернел. Это распределённая система акторов с транзакциями, объединяющая множество машин в одну адресуемую кучу. Cormack назвал её «Erlang-подобной». По словам автора, он сделал всё за неделю, вероятно, никогда её не выпустит, но она опровергла идею, что юникернелы трудны.

Далее автор рассуждает об «сэмплировании истории»: идеи существовали ещё в восьмидесятых, модели читали статьи, а не хватает людского любопытства и амбиций. Остальные тем временем будут укреплять своё приложение на Ruby on Rails с помощью Chainguard и управлять AWS силами пятидесяти сертифицированных инженеров, когда хватило бы двоих с Nix и Hetzner; в конечном счёте всё решают деньги и эффективность.

В последнем доступном разделе обсуждаются OCaml, Rust и Haskell. Для агентов, по мнению автора, OCaml хорош: функторы, файлы .mli как компактный контекст, быстрая компиляция; причин выбирать F# он не видит. Cormack в основном пишет на Rust, где агенты сильны, но время компиляции, «налог на обратное давление»: модели галлюцинируют, а при медленной сборке каждая галлюцинация дорога. Его клон S3, около миллиона строк на Rust, и при четырёх одновременно компилирующих агентах они борются за диск и процессор, так что на быстрые машины уходит больше, чем на токены. Haskell автор считает сильным по системе типов, но не готов запускать его в продакшене из-за утечек пространства (space leaks), проявляющихся только там. Текст в доступной версии обрывается на разделе о Zig.

Ключевые факты

Автор блога пересказывает разговор с Justin Cormack (раньше работал над MirageOS и Unikernel Systems) о возвращении интереса к юникернелам.
Тезис: главное трение юникернелов, отсутствие библиотек, снимается тем, что ИИ-агент портирует их циклом; Cormack за несколько часов получил с агентом mkfs.xfs на Rust с побайтно идентичным результатом.
Автор считает операционную систему долгом дизайна: без оболочки и интерпретатора массовая атака превращается в целевую, но Cormack возражает, что о сокращении поверхности атаки говорят слишком расплывчато.
Автор собрал за неделю Spaceleans (Microsoft Orleans на OCaml как юникернел), но, вероятно, не выпустит его.
Это эссе от первого лица: бенчмарков и независимых подтверждений превосходства юникернелов в безопасности или скорости в нём нет.

Почему это важно

Эссе пересказывает довод, который сейчас часто звучит в инженерной среде: многое из того, что считалось «слишком сложным» (юникернелы, Nix, Bazel), упиралось в объём ручной работы, а ИИ-агенты эту работу удешевляют. Автор доводит мысль до конца: если писать библиотеки и порты почти ничего не стоит, то аргумент «в юникернеле нет нужных библиотек» слабеет, а привычная связка «приложение плюс универсальная ОС» оказывается унаследованным решением, а не необходимостью. Это взгляд автора и его собеседника, а не установленный факт, но сам сдвиг вопроса с «возможно ли» на «стоит ли», то, ради чего текст и написан.

Кому это важно

Инженерам инфраструктуры и платформ, специалистам по безопасности, тем, кто пишет на OCaml, Rust или Haskell и следит за идеями вокруг MirageOS, Nix и минимальных образов систем. Для тех, кто просто пользуется облаком или готовыми контейнерами, текст скорее повод присмотреться к альтернативе, чем практическое руководство.

Как это применить

Конкретные приёмы, которые называет автор: поручить агенту портировать нужную библиотеку (например, клиент Stripe с Go на OCaml) и использовать исходный инструмент как эталон для сравнения результатов и переноса тестов, как это сделал Cormack с mkfs.xfs; для хранения данных взять S3 как основное хранилище с локальным кэшем на NVMe и LRU для горячих данных; проверять взаимодействие сетевых правил и приложения машинными тестами NixOS; закрывать проблемы зависимостей оверлеями. Готового инструмента или релиза в тексте нет: Spaceleans автор, по его словам, вероятно, не выпустит.

Можно ли доверять

Это личное эссе от первого лица, пересказывающее разговор, а не исследование. Тезисы о том, что юникернелы безопаснее или что ИИ делает их лёгкими, не подкреплены замерами или независимыми данными. Подкреплены лишь отдельные эпизоды, которые описывает сам автор: mkfs.xfs у Cormack и Spaceleans за неделю (проверить второе нельзя, код не опубликован). Эпизод со взломом KVM и суммой $50 000 в тексте не расшифрован: ни имён, ни идентификатора уязвимости. Cormack в пересказе скорее возражает автору по поводу поверхности атаки, чем соглашается с общими выводами. В доступной версии текст обрывается на разделе про Haskell и Zig.

Риски и подводные камни

Сам Cormack, по словам автора, напомнил, что без оболочки поверхность атаки не исчезает: остаются интерпретаторы или их аналоги, исполнение новой программы без записываемой файловой системы, безопасность памяти и «гаджеты». Ранние юникернелы работали на одном уровне привилегий; автор считает, что это исправимо запросом к модели, но это его оценка. Порт, созданный агентом, нужно проверять на эталоне: подход с mkfs.xfs работает потому, что есть исходный инструмент для сравнения вывода, а такого эталона может не быть. Время компиляции становится ограничением: у Cormack на клон S3 около миллиона строк на Rust, и четыре агента, компилирующие одновременно, упираются в диск и процессор, так что расходы на быстрые машины превышают расходы на токены. Haskell автор не рискует запускать в продакшене из-за утечек пространства, видимых только там.

«Юникернелы были сложными. Ключевое слово: были.»

— автор поста на ghuntley.com