WSL2
微软推出的在Windows系统内运行完整Linux内核的技术，没有图形界面，程序员常用于运行开发工具链
核心事实
时间轴 (近 90 天)
捆绑运行时的主流实现方式包括嵌入轻量级容器引擎（如Podman无守护进程模式）、使用WebAssembly沙箱、或依赖平台原生虚拟化能力（如macOS的Virtualization.framework或Windows的WSL2）
ODS在Windows上通过WSL2支持NVIDIA和AMD，在macOS上原生支持Apple Silicon（走Metal）
WSL2 DXG 桥接方案通过 DirectX Graphics 内核桥接层访问 GPU，无需依赖传统的 /dev/kfd 设备节点
Windows 用户如果需要 Claude Code 的完整沙盒，最好在 WSL2 里运行
WSL2的DXG桥接允许Windows Subsystem for Linux通过DirectX驱动访问宿主机GPU，绕过传统ROCm依赖/dev/kfd字符设备的路径
新版本新增了包含Unsloth Studio和JupyterLab的AMD ROCm Docker镜像，且ROCm镜像可通过WSL2的DXG桥接访问GPU
新增了带有 Unsloth Studio 和 JupyterLab 的 AMD ROCm Docker 镜像
在Windows上，Docker通过WSL2或Hyper-V来运行Linux容器
更新改进了WSL2（Windows子系统）环境下的截图粘贴功能
一位Reddit用户在8GB显存的RTX 5060移动版显卡上，通过WSL2环境本地运行了Flux图像生成和Wan 2.2视频生成
还有 9 条时间轴事件
全部知识事实 (20)
Docker Desktop选择基于WSL2运行
80%已验证WSL2与WSL1不同，它运行完整的Linux内核，底层由Hyper-V轻量虚拟机驱动
80%待验证Magentic-UI部署需要Python 3.10+（推荐3.12）和Docker Desktop，Windows用户需配置WSL2
95%待验证WSL2安装需要Windows 10版本2004及以上或Windows 11
95%待验证WSL2的每个Linux发行版以ext4格式的虚拟硬盘文件（.vhdx）存储在Windows文件系统中，默认路径位于C盘的%LOCALAPPDATA%\Packages目录下
90%待验证Claude Code要求Node.js 18及以上版本，支持macOS和Linux操作系统，Windows用户需使用WSL2
90%待验证微软与英伟达合作开发了WDDM GPU虚拟化技术，允许WSL2内的Linux进程直接访问宿主机的GPU资源
85%待验证新版本新增了包含Unsloth Studio和JupyterLab的AMD ROCm Docker镜像，且ROCm镜像可通过WSL2的DXG桥接访问GPU
70%待验证WSL2的文件系统性能相比WSL1提升了20倍以上
70%待验证WSL2基于轻量级Hyper-V虚拟机实现，GPU虚拟化性能损耗通常低于5%
70%待验证捆绑运行时的主流实现方式包括嵌入轻量级容器引擎（如Podman无守护进程模式）、使用WebAssembly沙箱、或依赖平台原生虚拟化能力（如macOS的Virtualization.framework或Windows的WSL2）
50%待验证ODS在Windows上通过WSL2支持NVIDIA和AMD，在macOS上原生支持Apple Silicon（走Metal）
50%待验证WSL2 DXG 桥接方案通过 DirectX Graphics 内核桥接层访问 GPU，无需依赖传统的 /dev/kfd 设备节点
50%待验证Windows 用户如果需要 Claude Code 的完整沙盒，最好在 WSL2 里运行
50%待验证WSL2的DXG桥接允许Windows Subsystem for Linux通过DirectX驱动访问宿主机GPU，绕过传统ROCm依赖/dev/kfd字符设备的路径
50%待验证在Windows上，Docker通过WSL2或Hyper-V来运行Linux容器
50%待验证更新改进了WSL2（Windows子系统）环境下的截图粘贴功能
50%待验证WSL1 在 Windows NT 内核中实现 lxss.sys 和 lxcore.sys 内核驱动，将约 300 多个 Linux 系统调用翻译为 NT 内核操作，后因维护成本和兼容性问题 WSL2 转向完整虚拟机方案
50%待验证该Reddit用户表示WSL2对其工作流也不够可靠
50%待验证在深度依赖开源代码的ML研究场景中，原生Linux（Ubuntu）比Windows或WSL2更可靠
50%