Що сталося

Автор проєкту щодня працює на атомарному 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, файли й порти хоста, підписи образів і окрема ізоляція для недовіреного коду.