Plan 9把4台机器压进1台电脑，40岁程序员玩嗨了

192.168.1.188、192.168.1.189、192.168.1.193——三个IP地址，四台虚拟机器，全部跑在一台OpenBSD主机上。这不是什么云计算架构图，而是一个诞生于1992年的操作系统，正在被2020年代的开发者用古董级方式复活。

Plan 9的设计初衷就是网络原生：认证服务器、文件服务器、CPU服务器、终端，四者分离各司其职。文件服务器只存数据，CPU服务器只跑程序（本地零存储，所有代码和用户文件都从网络读取），终端则是用户面前那台"傻终端"。这种架构在30年前堪称激进，放到今天反而成了理解分布式系统的完美教具。

但新手困境很真实：没人愿意为了"试试"而先搭四台机器。于是多数人选择单机运行所有服务，关系却糊成一团——认证和文件服务缠在一起，CPU和终端分不清边界。更麻烦的是，Plan 9的文件编辑、权限管理、命名空间几乎处处与Unix相悖，新手连改个配置文件都要先学一套新语法。

Unix工具链的"作弊"方案

这篇指南的解法堪称巧妙：用OpenBSD（或任意Unix）作为宿主，把Plan 9的网络架构"翻译"成熟悉的生态。

认证服务由authsrv9提供——这是Plan 9认证服务的Unix移植版。文件服务靠u9fs，Plan 9官方自带的9P2000协议服务器。两者都走inetd启动，老牌Unix管理员看到这会心一笑。CPU服务器最复古：用QEMU启动，只挂一张软盘镜像，真正意义上的无盘启动。终端则用drawterm，Plan 9生态里经典的图形终端模拟器。

整个网络的IP规划清晰得像个教学案例：192.168.1.188给文件服务（ufs1.local），189给认证（auth1.local），193给CPU（cpu1.local）。每个服务独占地址，未来替换成物理机只需改DNS，架构不用动。

核心收益被作者轻描淡写地带过：你可以用Vim或Emacs直接编辑Plan 9的文件，用grep和awk处理日志，用熟悉的shell脚本做自动化。Plan 9的命名空间和权限模型依然需要学，但至少编辑配置文件这件事，不必先跨过ed或acme的门槛。

9P协议：被低估的分布式基石

文件服务跑的是9P2000协议，Plan 9的灵魂所在。它把"文件"抽象做到极致——网络中的任何资源都是文件，通过open、read、write、stat、close这组原语操作。不是REST，不是gRPC，不是GraphQL，就是最简单的文件语义。

这种设计的后劲很足。Linux的/proc和/sys文件系统直接借鉴了Plan 9的思想。Docker早期版本用过9P做容器文件系统。甚至今天的VS Code远程开发，底层也在用类似的"把所有东西变成文件句柄"的思路。

但Plan 9的完整网络架构很少被完整体验过。单机版抹平了服务边界，让人误以为它只是个"更干净的Unix"。这篇指南的价值在于还原了原始设计：四台机器的对话，三个IP地址的握手，软盘启动时那几秒的等待——这些" inefficiency"恰恰是理解系统的关键。

谁还在玩这个？

作者Mechiel的邮箱后缀是ueber.net，一个典型的个人技术站点。9fans邮件列表、Freenode的#plan9频道、Plan 9 Wiki——这些资源的存在本身说明社区虽小但活跃。IRC频道在2021年后随Freenode的动荡迁移过，但核心讨论延续至今。

目标读者画像清晰：读过Bell Labs那篇经典论文《Plan 9 from Bell Labs》，对"一切都是文件"有过理论认知，现在想动手验证。不是考古学家，是工程师——想用最低成本理解一个影响深远但从未大规模商用的系统。

QEMU软盘启动的细节值得玩味。作者特意强调"without local storage"，这不是怀旧，是在强制还原Plan 9的设计约束：CPU服务器必须无状态，所有持久化交给网络文件服务。现代Kubernetes的"无状态容器"理念，在这里能找到30年前的原型。

drawterm作为终端同样关键。它不只是SSH替代品，而是完整实现了Plan 9的图形协议——鼠标、键盘、窗口管理全部走网络。在Unix宿主的X11或Wayland桌面上，你操作的是一个完全异构的图形环境，窗口管理器、文本编辑器、调试器都来自另一个宇宙。

这种"混合生态"的体验很难复制。云厂商不会卖给你，发行版不会打包，只有手动搭建才能触及。

IP地址的选择也有讲究。192.168.1.0/24是最常见的家用网段，指南默认读者有完全控制权。如果要在公司网络或云VPC复现，需要调整网段——但架构本身不变，这正是模块化设计的好处。

inetd的使用暴露了年代感。现代Linux默认用systemd socket activation，BSD系还在坚守inetd的传统。authsrv9和u9fs作为inetd服务启动，意味着它们按需派生、用完即走，没有常驻进程的开销。对于实验性部署，这种"懒启动"反而更合适。

作者没有提及但隐含的事实：这套方案的性能足以支撑真实开发。Plan 9的原始硬件环境是MIPS工作站和9600波特率的串口，千兆以太网上的QEMU实例堪称豪华。瓶颈不在虚拟化，而在9P协议的往返延迟——但这正是学习材料，不是生产系统。

遗留系统的现代课堂

Plan 9从未获得商业成功，但它的技术遗产散落各处。Go语言的并发模型、Linux的命名空间、Docker的远程文件系统、甚至现代浏览器的进程架构，都能找到Plan 9的影子。

这篇指南的巧妙之处在于"借壳"。不强迫读者先成为Plan 9专家，而是用Unix作为舒适区，逐步引入异构概念。编辑文件用Vim，查日志用tail，只有当你准备好时，才进入drawterm的陌生世界。

对于25-40岁的技术从业者，这种渐进式暴露比"从零开始装Plan 9"更可持续。时间有限，要学的东西太多，能用周末下午搭起来的实验环境才有生命力。

三个IP地址，四台虚拟机器，一张软盘镜像。这套配置的维护成本趋近于零——OpenBSD的稳定声誉、inetd的简洁、QEMU的成熟，都是经过 decades 验证的组件。你可以把它放在树莓派上，放在VPS上，放在任何能跑OpenBSD的角落。

作者最后列出的求助渠道值得注意：邮件列表、Wiki、IRC、手册页。没有Discord，没有Slack，没有官方论坛。这种沟通方式的坚持本身，就是Plan 9文化的一部分。

如果你按这篇指南搭好了网络，第一个想测试的是什么——是用rc脚本写个自动化，还是把Go程序跑在这个30年前的调度器上？