一个叫Farid Zakaria的开发者最近把自己过去几年的Nix工作总结成了一个网站:trynix.dev。它用qemu-wasm在浏览器里跑出一整台x86_64 Linux虚拟机,理论上可以加载过去13年里任何一个Nix包。你打开https://trynix.dev/?pkg=python3%403.6.2,点一下Load,几秒后就能在一个2017年的Python 3.6.2环境里敲命令——没有服务器,没有安装,全在Wasm里跑完。他管这个叫自己的"magnum opus"。
这套东西没有停在demo层面。他紧接着做了个GitHub Action叫trynix-preview:在PR下面自动评论一个链接,点开就能在浏览器里直接启动这个PR构建出来的产物,官方说法是"no servers, just browsers"。这句话听起来像是又一个PR预览工具,但它背后的技术路线和市面上所有同类产品都不一样。
全虚拟机和沙盒,根本不是一回事
PR预览这件事早就不新鲜了。Netlify、Vercel做的是静态站点托管;Gitpod、GitHub Codespaces给你一个远程容器或虚拟机;StackBlitz的WebContainers更轻,直接在浏览器沙盒里跑Node.js。这几派方案有个共同点:要么依赖远程算力,要么只能跑浏览器/Node能理解的东西,原生二进制、Docker、数据库基本碰不了。
trynix走的是完全不同的路。它不是在浏览器里模拟一个JS运行时,而是通过qemu-wasm把一整台x86_64系统跑起来,再挂载Nix生态里现成的构建产物。这意味着理论上凡是Nix能打包的东西——编译型语言、系统级依赖、非JS工具链——都可能在这台"浏览器虚拟机"里跑。这不是又一个预览工具换了皮肤,而是"boot a PR"这件事第一次有可能不再局限于前端项目。
网上流传的一些"PR预览安全框架",讲的其实是WebContainers那套沙盒隔离逻辑,拿来套trynix并不合适——两者根本不是同一种信任模型,直接借用会误导判断。
"无服务器"这句话,经不起细问
trynix最响亮的宣传是"no servers, just browsers"。但"过去13年任意Nix包"这句话本身就带着一个巨大的隐藏成本:要让任何历史版本的包都能被URL直接寻址启动,背后必须有海量的Nix store构建产物被托管和索引。这层存储/CDN到底是谁在扛、成本怎么摊,原文和公开资料里都没有交代。
- 风险.浏览器里启动的是一台由不可信PR代码构建出来的完整虚拟机,而不是沙盒化的运行时,攻击面理论上更大,目前看不到公开的安全隔离说明。
Nix本身的可重现构建特性,是trynix能做到"任意历史包一键复现"的技术前提——这一点没有Nix生态过去多年在内容可寻址存储上的积累,trynix做不出来。但"客户端全靠WebAssembly"和"服务端零成本"是两件事,前者成立不代表后者也成立。
能跑通demo和能扛住真实评审流程,中间还差一整套信任机制
谁会真的用它,接下来看什么
对Nix社区和喜欢折腾历史环境的人来说,trynix.dev本身已经是个有用的工具——调试老版本依赖、复现多年前的构建结果,不用再自己搭一套Nix环境。但trynix-preview要真正进入开源项目的日常代码评审,还要过几关:qemu-wasm在浏览器里跑完整系统的启动时间和内存占用能不能接受、私有仓库怎么做认证、以及最关键的——用陌生PR代码启动一整台虚拟机,安全边界到底谁来兜底。
这几个问题目前都没有公开答案。Gitpod、Codespaces这类托管方案暂时不必紧张,它们的容器/远程算力模式在企业场景里已经跑了多年;真正该盯着看的,是trynix-preview有没有更多真实仓库愿意接入,以及第一次安全事故什么时候出现。