以前一直是在 VMware 里的 Ubuntu 环境下做 Linux 开发。刚开始觉得这样比较“完整”：有独立的桌面系统、有完整的 Linux 环境，和真实机器也比较接近。但用久了之后就会发现，它在日常开发流程里其实有不少让人头疼的地方。最明显的问题就是文件流转很麻烦。开发过程中经常需要在 Windows、Ubuntu 虚拟机和开发板之间来回拷贝文件。虽然 VMware 支持共享目录，但实际用起来并不总是稳定：有时候权限不对，有时候目录挂载异常，有时候文件同步不及时，偶尔还会遇到编码、换行符或者软链接处理不一致的问题。明明只是想改个文件、编个程序，结果一大半时间花在了“文件怎么传过去”上。其次是硬件设备接入不够顺滑。比如连接 USB 串口、调试器、U 盘、摄像头或者其他外设时，VMware 需要在 Windows 主机和 Ubuntu 虚拟机之间手动切换设备归属。设备一多，或者频繁插拔，就很容易出现识别失败、驱动冲突、串口丢失等问题。对嵌入式开发来说，这种体验尤其折磨，因为调试板子本来就需要频繁烧录、查看串口日志、连接调试工具。再比如图形性能和 GPU 加速 也比较尴尬。VMware 虽然能提供一定的 3D 加速，但想让 Ubuntu 虚拟机真正高效地使用主机 GPU，配置起来并不轻松，效果也有限。遇到需要图形界面、OpenGL、CUDA、深度学习环境或者图形渲染相关任务时，虚拟机里的 Ubuntu 往往不如直接在 Windows 或 WSL 环境下方便。还有一个很影响体验的点是 Windows 和 Ubuntu 之间的来回切换成本太高。开发时经常一边查资料、一边写代码、一边用串口工具、一边跑 Linux 命令。如果 Ubuntu 在 VMware 里，就不得不在虚拟机窗口和 Windows 桌面之间来回切。复制粘贴、窗口切换、快捷键冲突、输入焦点丢失，这些小问题单独看不大，但每天高频出现，就会非常影响开发节奏。开发工具方面也有不少细节问题。比如 Ubuntu 里的 VS Code 版本、插件兼容性和整体体验，有时不如 Windows 版本来得及时和稳定。虽然也可以在 Ubuntu VM 里安装 VS Code，但更新、字体、输入法、插件、终端集成等配置都可能需要额外折腾。尤其是中文输入法，看起来是小事，实际非常烦：Ubuntu 里装好了中文输入法，不代表 VS Code 里就一定能正常输入中文；有时候系统里能用，浏览器里能用，但偏偏 VS Code 里不行。除此之外，VMware Ubuntu 还会带来明显的资源占用问题。虚拟机需要单独分配 CPU、内存、磁盘空间和显存。开机慢、占内存、占磁盘，后台挂着还会拖慢 Windows 主机。如果项目稍微大一点，再开几个浏览器、IDE、串口工具和文档，整台电脑就容易变得卡顿。相比之下，WSL 更像是直接嵌入在 Windows 里的 Linux 环境，不需要完整启动一个桌面系统，资源消耗通常更轻。磁盘空间管理也比较麻烦。VMware 的虚拟磁盘文件往往会越用越大，清理起来不直观。Ubuntu 里删了文件，并不一定能立刻释放 Windows 上对应的磁盘空间。时间一长，一个虚拟机镜像动不动几十 GB 甚至上百 GB，备份、迁移、压缩都很麻烦。网络方面同样容易踩坑。VMware 常见的 NAT、桥接、仅主机模式虽然功能强，但配置复杂。虚拟机访问外网、Windows 访问虚拟机、开发板访问虚拟机，三者之间的网络关系经常需要手动调整。IP 变化、防火墙、端口转发、DNS 异常，都可能影响 SSH、Web 服务调试、交叉编译环境访问等工作。用VMWare装Ubuntu只是为了那套交叉编译工具，虽然生态体验远不如Windows，但是Ubuntu的终端shell无比强大，非常适合开发自动化，哪怕现在Windows有Windows Terminal了也无法与之匹敌，因为他们根本就是两种设计维的OS。当然有，那就是WSL Ubuntu + VSCODE + WSL插件 + Codex插件 + OpenOCD，实现AI编码、烧写、验证、调试、迭代的一站式方案。WSL本身并不算新鲜，但是要把环境做得好用还是需要对工具进行编排和调校。下面以DR1的Linux开发为例来介绍这种开发环境的搭建流程。 LTS版本WINDOWS安装WSL
1. 以管理员身份打开 PowerShellwsl --install --no-distribution
这一步只是安装WSL，不装系统，避免下载失败。
装完后更新一下WSL：
然后再来装ubuntu
WSL 安装 Codex CLI
curl -o- https://raw.githubusercontent.com/nvm-sh/nvm/master/install.sh | bash
nvm install --ltsnvm use--lts
npm install -g @openai/codex
echo 'export OPENAI_API_KEY="你的_API_Key"' >> ~/.bashrcsource ~/.bashrc
如果能看到你的 Key，说明 WSL 里已经配置成功。注意：不要把 API Key 写进项目代码、.env 后提交到 Git。这个坑很常见，且很贵。VSCODE安装插件, 实现文件交互和终端交互自由也可以按下面操作直接打开WSL Ubuntu的文件目录，把里面的文件拷出来或放进去，Ubuntu相当于一个共享网盘。安装好后需要执行CTRL+SHIFT+P来打开codex侧边栏然后如果你在ubuntu中已登入了codex cli，则插件会自动登录到这一步你会发现，你会发现在 WSL Ubuntu 里，事情会自然很多。Linux 命令行可以直接在 Windows Terminal 里打开，项目文件可以直接配合 Windows 版 VS Code 使用，Windows 和 Linux 之间的文件访问也更直接。需要编辑代码时，用 Windows 上最新版本的 VS Code；需要跑 Linux 命令时，直接打开 WSL 终端；需要和 Windows 工具配合时，也不需要在两个系统桌面之间来回跳。所以，现在再回头看，VMware Ubuntu 更适合需要完整 Linux 桌面、独立系统环境、内核级实验或者复杂虚拟化场景的情况。但如果主要是做日常 Linux 开发、交叉编译、脚本调试、服务端程序开发，或者嵌入式开发中的大部分命令行工作，WSL Ubuntu 的体验通常更轻、更顺，也更贴近 Windows 用户的日常工作流。简单来说，VMware Ubuntu 不是不能用，而是它把很多本该专注在开发上的精力，消耗在了虚拟机维护、文件同步、设备连接、网络配置、输入法和窗口切换这些琐碎问题上。相比之下，WSL Ubuntu 更像是把 Linux 能力直接塞进了 Windows 工作台里，用起来少了很多“系统之间打架”的感觉，开发流程自然也顺畅不少。sudo apt-get updatesudo apt-get install make gcc g++ flex bison u-boot-tools liblz4-tool libncurses5-devapt-get install -y cpio bzip2
[2026-05-19 19:59:15] Error: Running build_buildroot failed![2026-05-19 19:59:15] Error: exit code 2 from line 738:2026-05-19 19:59:15] Error:make -C $BUILDROOT_DIR O=$TOP DIR/$TARGET_BUILDROOT_OUTPUT_DIR - j$ANLOGIC _JOBS
原因是 WSL 会把 Windows 的 PATH 带进来，其中有 /mnt/c/Program Files... 这种带空格的路径；Buildroot 会直接拒绝带空格/TAB/换行的 PATH，所以 VMware Ubuntu 能过，WSL 不过。function sanitize_path_for_buildroot(){ local path_entry local clean_path= local removed=0 while IFS= read -r -d ':' path_entry; do case "$path_entry" in *[[:space:]]*) removed=1 ;; *) if [ -z "$clean_path" ]; then clean_path="$path_entry" else clean_path="$clean_path:$path_entry" fi ;; esac done < <(printf '%s:' "$PATH") if [ "$removed" -ne 0 ]; then export PATH="$clean_path" log_message -w "Sanitized PATH for Buildroot by removing entries that contain whitespace" fi}
sanitize_path_for_buildroot
WSL + VS Code相比于在VMWare运行VS Code要流畅很多，编译速度也比VMWare下快很多，更多优点待发现！OpenOCD配合VS Code实现下载调试的操作，下次有时间再说吧。
10个月宝宝每天需要喝多少奶粉？
