Show HN: NSL – Linux 版 WSL

原文 ↗ Hacker News 讨论 ↗

一个名为 NSL 的新工具旨在通过运行一个轻量级 VM 来托管多个 systemd-nspawn 容器，为 Linux 带来类似 WSL2 的体验，从而在不污染宿主系统的前提下提供隔离的“宠物”开发环境。评论者将它与 Distrobox、toolbx、LXC/Incus 以及普通 VM 等现有方案进行比较，讨论了隔离性、性能、宿主集成和易用性之间的取舍。有人称赞这种工作流在 UX 和打包上更易用，也有人质疑再加一层的必要性，并对项目明显依赖 AI 生成文档表示不安。

架构与方法

  • NSL 旨在为 Linux 带来类似 WSL2 的体验：一个单一的“主机” VM，运行多个 systemd-nspawn 容器。
  • 该 VM 通过 systemd-vmspawn 启动；在其内部，实例是 systemd-nspawn 容器，而不是 Docker/Podman 或 LXC。
  • 这被定位为带有限但便利的宿主集成的“宠物” VM/实例，而不是一次性容器。

与现有工具的比较（Distrobox、toolbx、LXC/Incus、VM 等）

  • Distrobox/toolbx：通常会挂载宿主的 $HOME，并被设计为宿主环境上的叠加层；NSL 刻意不这样做，倾向于隔离 dotfiles、PATH 和系统库。
  • LXC/Incus：提供基于容器的“完整系统”，而不需要 VM；NSL 增加了一层 VM，以获得更强的隔离以及使用不同内核的选项。
  • 传统 VM（qemu/multipass/Vagrant）：NSL 被定位为更轻量，默认无头，在需要时共享宿主的 Wayland 会话，而不是运行完整桌面。
  • 有些人认为鉴于现有工具，它是多余的；也有人认为主要区别在于 UX 和打包，而不是原始能力。

用例与动机

  • 主要目标：让宿主 OS 远离开发依赖和实验，避免那些会悄悄破坏系统的东西污染主机。
  • 常见用例：在与宿主不同的发行版中运行 IDE 或开发工具链，同时能方便地访问终端和文件，但不污染宿主环境。
  • 一些用户提到，他们用它来安全地让 AI agent 安装系统级依赖。

安全性与隔离

  • 多条评论强调，容器是比 VM 更弱的安全边界；VM 层被视为更强的隔离，尽管并不完美。
  • 有人担心 NSL 的宿主集成（文件、端口、窗口）在没有额外隔离标志的情况下仍可能导致逃逸，而这又可能损害 UX。

性能与实际使用

  • 有人询问相较原生或纯容器的性能影响；帖中没有给出具体基准。
  • 通过共享 Wayland 支持图形界面被视为一个优点。
  • 也有人要求演示，并在主页上更清楚地说明 NSL 与 Docker/Distrobox 的区别，以及它独特解决了什么问题。

文档、命名与生态

  • 多条评论提到网站/README 中大量使用了 LLM；反馈从“令人难以忍受的 Claudisms”到“考虑到用了 LLM，出乎意料地好”不等。
  • 讨论了命名（NSL/WSL）以及“Windows Subsystem for X”的历史，主要是些趣闻。
  • 也有人担心工具进一步碎片化，而不是采用现有的容器/开发环境方案（Nix、mise 等）。