nsl porta l'idea di WSL su Linux: cos'è e perché è interessante

Tenere il sistema Linux principale il più pulito possibile, senza rinunciare a toolchain, compilatori, librerie e distribuzioni differenti, è un problema concreto soprattutto sulle distribuzioni atomiche o image-based. Fedora Silverblue, Kinoite, openSUSE MicroOS e progetti analoghi hanno reso popolare un modello in cui il sistema operativo di base resta il più possibile separato dai software usati per sviluppo e test: compilatori, librerie, SDK e dipendenze sono installati in ambienti dedicati, anziché modificare direttamente l’host. nsl, acronimo di NSpawn Subsystem for Linux, prova ad affrontare proprio questa esigenza con un’idea immediatamente comprensibile a chi conosce Windows Subsystem for Linux: creare “macchine Linux” persistenti, richiamabili da terminale quando servono, senza installare pacchetti direttamente sull’host.

nsl punta a offrire un’esperienza simile a WSL sul piano operativo: si entra nell’ambiente con un comando, si lavora sugli stessi file del sistema principale, si eseguono programmi e server locali, quindi si esce lasciando intatti pacchetti, configurazioni e dati per la sessione successiva. La realizzazione tecnica, però, è profondamente Linux: il progetto combina systemd-nspawn, una macchina virtuale QEMU/KVM, virtiofs, SSH su vsock e, per le applicazioni grafiche, Waypipe.

nsl porta su Linux un’idea simile a WSL, ma con un’architettura diversa

Il modo più semplice per capire nsl è partire dal comando di uso quotidiano. Dopo avere creato, ad esempio, una macchina Debian, basta digitare nsl dalla directory del progetto per ottenere una shell all’interno dell’ambiente Linux configurato. Il comando nsl run make test consente invece di eseguire direttamente un programma nella macchina e riportarne all’host anche il codice di uscita.

nsl non implementa un sottosistema Linux sopra un kernel differente, come avviene invece nel caso di WSL: l’host è già Linux e il progetto sfrutta una piccola VM avviata con systemd-vmspawn e QEMU/KVM. Dentro quella VM vengono eseguiti uno o più container systemd-nspawn.

Le ì”macchine” nsl non corrispondono ciascuna a una VM completa: diverse distribuzioni Linux possono convivere dentro una singola VM condivisa, utilizzando lo stesso kernel. Debian, Ubuntu, Fedora o Arch rimangono separate per quanto riguarda root filesystem, pacchetti, servizi e configurazioni, mentre CPU e memoria appartengono al livello virtuale comune.

Secondo la documentazione sull’architettura, la VM può utilizzare per impostazione predefinita fino a metà della memoria dell’host e tutte le CPU disponibili; i limiti sono modificabili attraverso nsl.conf. Aggiungere un’altra macchina nsl non implica quindi riservare la RAM che richiederebbe una seconda VM tradizionale.

Perché inserire una VM tra Linux e i container

A prima vista potrebbe sembrare un giro inutilmente lungo: Linux sa già eseguire container in modo nativo, quindi perché mettere QEMU/KVM nel mezzo? nsl vuole separare l’ambiente di sviluppo dal sistema principale senza rinunciare a un’integrazione molto stretta con i file dell’utente.

La VM crea una frontiera netta fra il kernel dell’host e quello sul quale girano i container. All’interno, systemd-nspawn può poi offrire ambienti relativamente leggeri, veloci da avviare e persistenti. Il progetto finisce così in una zona intermedia fra Toolbox o Distrobox, che lavorano essenzialmente con container, e una collezione di VM complete gestite singolarmente.

Uno degli aspetti più importanti per l’esperienza quotidiana riguarda l’accesso ai file: nsl rende disponibili la home dell’utente, /run/media/USER e /mnt sotto il percorso /mnt/host della macchina.

Il collegamento passa attraverso virtiofs, tecnologia progettata specificamente per condividere alberi di directory tra host e macchine virtuali con semantiche più vicine a quelle di un filesystem locale rispetto ad altre soluzioni storiche. Virtiofs utilizza FUSE come base e trasporta le richieste attraverso dispositivi VIRTIO; nel caso di nsl, virtiofsd realizza il collegamento fra filesystem dell’host e VM.

Sette distribuzioni pronte e immagini verificate

nsl dichiara il supporto a sette famiglie di distribuzioni: Debian, Ubuntu, Fedora, CentOS Stream, Arch Linux, openSUSE Tumbleweed e openSUSE Leap. Le immagini pubblicate dal progetto vengono ricostruite settimanalmente.

Il progetto è ancora giovane. La documentazione lo descrive esplicitamente come pre-release e, per il momento, non ci troviamo quindi davanti a un sostituto maturo e universale di Docker, Distrobox, Toolbox o delle macchine virtuali tradizionali; l’obiettivo è diverso e, sotto diversi aspetti, piuttosto interessante.

nsl non si limita ai programmi da terminale. Su un host Wayland può eseguire applicazioni grafiche nella macchina e visualizzarne le finestre sul desktop principale tramite Waypipe.

Per chi utilizza una distribuzione atomica, oppure vuole semplicemente evitare di installare decine di SDK e dipendenze direttamente sul proprio sistema Linux, l’idea merita comunque attenzione. nsl prende un’esigenza che WSL ha reso familiare sul versante Windows e la reinterpreta usando strumenti nativi del mondo Linux. Non è “WSL per Linux” in senso tecnico; come modello di utilizzo, però, la definizione scelta dagli sviluppatori centra abbastanza bene il punto.