Экспериментальные операционные системы: от поиска уязвимостей до управления данными
По материалу Хабра, экспериментальные ОС могут быть не просто альтернативой привычному системному стеку: одни помогают исследовать поведение процессоров, другие строят работу системы вокруг распределённой базы данных.

Для разработчиков и инфраструктурных команд здесь важен практический вопрос: какие задачи такая архитектура решает и где заканчиваются обещания концепции.
Fractal: отладка на уровне процессора
Большинство ОС общего назначения не рассчитаны на исследование внутренних процессов чипа. В материале Хабра рассказывается о Fractal, специализированном ядре MIT CSAIL для экспериментов с процессорами и поиска аппаратных уязвимостей. Оно работает на x86-64, ARM64 и RISC-V, поддерживает POSIX и содержит более 31 тысячи строк кода.
Одна из возможностей Fractal — переключать уровни привилегий во время эксперимента. Авторы называют свой подход многопривилегированным параллелизмом. Практический результат уже есть: с помощью системы исследователи обнаружили свидетельства того, что Apple M1 подвержен варианту спекуляции Phantom. Ранее его находили на чипах AMD и Intel. По данным публикации, команда сообщила о результатах Apple.
Для инженеров это пример узкой ОС-инструмента: она нужна не для запуска очередного веб-сервиса, а для наблюдения за тем, что обычный системный стек прячет за абстракциями. Если отладка заканчивается на уровне приложения, такой инструмент вряд ли попадёт в повседневный набор. Но для исследований микроархитектуры возможность управлять экспериментом на уровне привилегий принципиальна.
DBOS: состояние системы как данные
Другой проект из материала, DBOS, вырос из проблемы масштабирования планирования задач Spark. В 2020 году Майкл Стоунбрейкер и Матей Захария обсуждали, как справляться с нагрузкой в миллион задач, когда традиционные механизмы ОС становятся узким местом.
Идея DBOS состоит в том, чтобы хранить полное состояние системы в таблицах распределённой базы данных. Там фиксируются задачи, файлы, сетевые соединения и история изменений. Это меняет и подход к восстановлению: если система столкнулась с шифровальщиком, администратор может откатиться к более раннему безопасному состоянию. История событий также позволяет анализировать последствия атак и искать уязвимости SQL-запросами.
Звучит как удобный способ превратить системный аудит в запрос к данным. Но здесь есть важная граница: возможность отката не отменяет необходимости защищать пользовательские файлы и резервные копии. Иначе восстановление тоже окажется частью проблемы. Костыль в виде «у нас всё записано» не заменяет проверку того, что именно можно восстановить.
Что проверить на практике
Оба проекта предлагают не универсальную замену Linux или другой привычной ОС, а специализированный инструмент под конкретный класс задач. Fractal помогает исследовать процессорные механизмы. DBOS предлагает хранить состояние и историю системы в базе данных, делая откат и анализ атак частью архитектуры.
Перед тем как переносить эти идеи в прод, стоит проверить три вещи: какую именно задачу решает новый системный слой, насколько полно он фиксирует состояние и как устроено восстановление после сбоя или атаки. Для DBOS отдельно важна гигиена резервных копий. Для Fractal ключевой вопрос — нужны ли команде эксперименты на уровне процессора, а не только диагностика приложений.
Новая ОС сама по себе не чинит архитектуру. Сначала сценарий отказа, потом проверяемый механизм восстановления. И бэкапы, разумеется.