文章摘要
作者习惯使用VS Code编辑器，但在FreeBSD上运行ARM64设备受限，目前缺乏媲美Apple Silicon的ARM64笔记本。他主要开发SvelteKit和Go后端项目，常需远程开发，但现有方案如NFS和SSHFS体验不佳。
文章总结
标题：FreeBSD上的Linuxulator体验如魔法般神奇 | Hayzam
过去几年，我选择的编辑器一直是Visual Studio Code。它虽不完美，也绝非轻量级，但在功能、扩展和性能之间取得了绝佳平衡。
在FreeBSD上运行微软的专有版本并不可行，但开源版本运行良好。既然VS Code已经可用，为何还要写这篇文章？
因为有一个因素始终阻碍我将FreeBSD作为日常主力系统：
必须使用ARM64设备
我必须使用ARM64设备。这一点毋庸置疑。
体验过苹果M1/M2芯片的Mac（此前使用大型x8664台式机）后，回归x8664在性能和续航上都像是一种倒退。遗憾的是，目前没有支持FreeBSD（甚至Linux）的ARM64笔记本能真正匹敌苹果芯片。我真心希望Framework或其他厂商能在未来几年改变这一局面。
生产力杀手：远程开发
在Debian（我最爱的Linux发行版）和macOS上，VS Code体验极佳。但我大多数项目都运行在其他平台：嵌入式Linux系统、OpenWRT设备，以及最近的FreeBSD主机。
这意味着需要依赖NFS挂载、SSHFS等方案。说实话？这些方案糟糕透顶。
我当前的主力技术栈是SvelteKit搭配Go后端，日常工作涉及大量OpenWRT开发。随着项目规模增长，通过NFS或SSHFS编辑代码变得异常痛苦——尤其是同时运行多个LSP服务时，有时打开文件就要5-10分钟。NFS稍好，但遭遇无数权限问题后，我彻底放弃了它。
这已成为影响我工作效率的真正障碍。
VS Code远程SSH的曙光
最近几天，我开始尝试VS Code的Remote SSH扩展。官方支持大多数主流操作系统，但明确不支持基于musl的OpenWRT和FreeBSD。
我仍尝试在OpenWRT上使用。
令人惊讶的是...它竟然开箱即用。
通过SSH连接后，我能直接在设备上流畅编辑文件，性能远超预期。无需任何魔改，就像在本地操作目标设备般神奇。
自然要尝试FreeBSD
当前我正在开发一个大型FreeBSD项目Sylve。由于文件目录数量庞大，通过SSHFS/NFS管理简直是噩梦。
于是，在未深入研究兼容性的情况下，我决定在FreeBSD上尝试Remote SSH。
如预期所见：
不支持的平台：FreeBSD
这很合理。
但放弃前，我搜索发现了一个优秀仓库：vscode-server-freebsd
配置过程简单得令人发笑。实际上，我在初始化FreeBSD时已完成大部分步骤：
service linux enable # 启用Linuxulator模拟层
service linux start
pkg install linux_base-rl9 # 安装Linux基础系统（本例为Rocky 9）
我将Linux专用的PATH放入家目录的.bash_linux文件而非全局环境：
PATH="/compat/linux/usr/local/sbin:/compat/linux/usr/local/bin:/compat/linux/usr/sbin:/compat/linux/usr/bin:/compat/linux/sbin:/compat/linux/bin:/usr/local/sbin:/usr/local/bin:/usr/sbin:/usr/bin:/sbin:/bin"
通过配置sshd接受BASH_ENV变量，确保仅在Linuxulator环境下生效：
sysrc sshd_flags="-o AcceptEnv=BASH_ENV"
客户端SSH配置则设置为：
SetEnv BASH_ENV=".bash_linux"
最终我的FreeBSD主机SSH配置如下（macOS客户端）：
Host sylve-code
Hostname 192.168.72.172
SetEnv BASH_ENV=".bash_linux"
User root
Port 22
IdentityFile ~/.ssh/id_ed25519
IdentitiesOnly yes
ServerAliveInterval 60
ServerAliveCountMax 3
RemoteCommand /compat/linux/bin/bash
然后...奇迹发生了
我原本持怀疑态度，预计半数扩展会失效、语言服务崩溃或性能低下。
但这些都没发生。
所有依赖的扩展都完美运行，除了Rollup（因其未提供FreeBSD二进制文件）。但这也不成问题——通过WASM构建和npm覆盖轻松解决：
{
"overrides": {
"rollup": "npm:@rollup/wasm-node@^4.30.1"
}
}
最终感悟
结果如何？通过Linuxulator无缝运行Linux二进制文件，我在FreeBSD上获得了快速、流畅且功能完整的远程开发体验。
这感觉如同魔法。
更重要的是，这证明了Linux ABI的稳定性以及FreeBSD的Linuxulator的优秀实现。该方案彻底改变了我使用FreeBSD的方式，消除了工作流程中的最大障碍。
这种看似脆弱实则稳健的方案令我惊叹，也让我对未来可能性充满期待。
（注：原文中关于ARM64设备对比、OpenWRT具体体验等非核心内容已精简，重点保留了Linuxulator实现的关键技术细节和实际效果）
评论总结
评论1（评分：无，作者：wolvoleo）主要观点： 1. 反对使用Linux兼容层 - "我不喜欢使用linuxulator或Linux兼容层...我选择FreeBSD就是因为它不同于Linux" - "如果我们妥协，最终会引入越来越多的Linux特性，最后所有东西都会依赖这些"
- 认为FreeBSD原生方案已足够
- "FreeBSD版的codium工作得很好，只需调整一些设置就能安装专有扩展"
- "有些工具没有FreeBSD移植版，我就选择其他替代方案"
- 坚持纯FreeBSD环境
- "现在我完全没有使用任何Linux兼容层，这很棒"
- "开发者说'用兼容层就好'，但我宁愿选择其他方案"
总结：该用户强烈反对在FreeBSD中使用Linux兼容方案，认为这会损害系统特性，主张坚持纯FreeBSD环境并使用原生替代方案。