Опубликован первый публичный выпуск проекта Nitro, развивающего минималистичную систему инициализации c функциями контроля над выполнением процессов. Проект развивает Лия Нойкирхен (Leah Neukirchen), одна из сопровождающих пакеты в дистрибутиве Void Linux. Код написан на языке Си и распространяется под лицензий 0BSD.

Nitro может применяться как в качестве init-процесса (pid 1), так и в форме непривилегированного процесса, контролирующего бесперебойное выполнение приложений в пространстве пользователя и перезапускающего задачи в случае сбоев. Поддерживается работа в Linux и FreeBSD, возможно применение в окружениях на базе стандартной Си-библиотеки Musl. В качестве областей применения упоминаются встраиваемые системы, образы ram-дисков (initramfs), контейнеры (Docker/Podman/LXC/Kubernetes), а также рабочие станции и серверные системы. Для управления работой сервисов и взаимодействия с init-процессом поставляется утилита командной строки nitroctl.

Вместо составных скриптов инициализации в Nitro применяется модель на основе выноса каждой функции в отдельный скрипт. Для каждого сервиса в иерархии /etc/nitro создаётся подкалог, в котором могут размещаться следующие скрипты: setup - содержит команды, выполняемые до запуска сервиса; run - определяет сценарий запуска сервиса; finish - включает команды, выполняемые после завершения сервиса. Для организации ведения лога применяется символическая ссылка с именем log, указывающая на другой сервис, которому будет перенаправлен вывод. Для отключения автозапуска сервиса достаточно создать в его каталоге файл с именем "down", а для игнорирования сервиса следует добавить символ "@" к имени каталога.

Автором проекта отмечаются следующие достоинства Nitro по сравнению с другими системами инициализации:

• Всё состояние хранятся в ОЗУ, что упрощает работу в окружениях c дисковыми разделами в режиме только для чтения.
• Архитектура на основе обработки событий, не использующая опрос в режиме полинга (polling).
• Отсутствие операций выделения памяти во время работы (все буферы выделяются при запуске).
• Ограниченное использование файловых дескрипторов во время работы.
• Поставка в форме одного самодостаточного исполняемого файла и утилиты для управления системой.
• Отсутствие стадий компиляции конфигурации - работу сервиса определяют простые скрипты в связанном с сервисом каталоге.
• Наличие функции перезапуска сервисов после сбоя.
• Наличие механизма ведения логов, которые могут включаться как по умолчанию, так и выборочно для отдельных сервисов.
• Возможность построения цепочки обработки лога, охватывающей несколько сервисов.
• Работа не зависит от точности выставления системных часов.
• Поддержка запуска во FreeBSD через /etc/ttys.
• Возможность сборки в форме миниатюрного статически скомпилированного исполняемого файла при использовании musl libc.