Что произошло

Автор проекта каждое утро работает на атомарном Linux‑дистрибутиве: систему обновляют как целое, а ставить компиляторы, SDK и зависимости «прямо на хост» не хочется. На Windows эту боль закрыл WSL2: отдельная среда разработки, те же файлы проекта, порты на 127.0.0.1. NSL переносит ту же схему на Linux. Одна виртуальная машина держит одну или несколько машин‑контейнеров; они стартуют по запросу и сохраняют пакеты, службы и файлы между сеансами.

Команды повторяют привычный жест. nsl create debian --distro debian:13 поднимает машину и проверяет подпись образа. nsl в каталоге проекта открывает оболочку в машине по умолчанию с теми же файлами. nsl run make test выполняет одну команду и возвращает код выхода на хост. Домашний каталог, /run/media и /mnt видны под /mnt/host, внутри машины — ваш пользователь, идентификаторы пользователя и группы и sudo без пароля. Сервер разработки слушает порт с хоста; графические приложения Wayland могут открыть окно на рабочем столе через Waypipe.

В каталоге семь дистрибутивов: Debian, Ubuntu, Fedora, CentOS Stream, Arch, openSUSE Tumbleweed и Leap. Образы пересобирают еженедельно, перед использованием NSL проверяет, что они пришли из подписанного конвейера публикации Frostyard. Для недоверенного софта есть режим --isolated: отдельная ВМ без доступа к файлам хоста, рабочему столу и действиям на хосте. Сам nsl работает от вашего пользователя и не правит группы, права устройств и sudoers — хост нужно подготовить заранее. Пока это предрелиз: v0.4.0 — первая версия новой схемы; проверенный хост — Snow Linux 13 на x86-64 с конкретными версиями systemd, QEMU и virtiofsd.

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

Атомарные и неизменяемые Linux‑хосты удобны для повседневной машины, но плохо дружат с классическим «поставил всё в систему». Разработчики либо ломают неизменяемость, либо живут в куче ручных контейнеров и виртуалок без единого сценария. NSL пытается дать знакомую модель WSL: среда разработки как меблированная квартира, а хост — постоянный адрес, который вы не заставляете жить чужими пакетами.

Подписанные образы и еженедельная пересборка снижают риск «скачал случайный корневой образ и поехал». Режим изоляции отдельно признаёт, что не каждый эксперимент должен видеть ваш домашний каталог. Для тех, кто уже выучил жесты WSL на Windows и переехал на Linux, это снижает стоимость смены привычки.

На практике

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

1. Проверьте зависимости хоста до установки: nsl сам пакеты и права не настраивает.
2. Создайте первую машину через nsl create … --distro … и убедитесь, что проверка подписи проходит.
3. Держите инструменты сборки и SDK внутри машины, а исходники — на хосте через /mnt/host.
4. Для сомнительных утилит включайте --isolated, чтобы не отдавать им домашний каталог и рабочий стол.
5. Смотрите архитектуру и nsl.conf в документации, прежде чем строить вокруг NSL постоянный рабочий процесс.

Итог

NSL — ответ на простой запрос: оставить Linux‑хост чистым и при этом иметь несколько полноценных сред разработки с UX в духе WSL. Пока инструмент ранний, но модель уже ясна: одна ВМ, контейнеры systemd-nspawn, файлы и порты хоста, подписи образов и отдельная изоляция для недоверенного кода.