1 分•作者: Thales_Miletus•10 个月前
最近几天,我尝试在 9fans 邮件列表中就 9front 的架构方向发表讨论。帖子经过精心撰写,并以诚意呈现。它提出了关于该项目侧重于单用户工作流程,以及对分布式计算(Plan 9 最初设计的标志)的重视程度明显下降的问题。
该帖子被版主拒绝。我的帐户被封禁,理由是该消息是 AI 生成的。事实并非如此。虽然我偶尔会使用写作助手来润色语法和清晰度,但其中的想法和论点完全是我自己的。禁令实际上关闭了任何澄清、纠正或进行富有成效的辩论的机会。
这种反应凸显了一个更深层的问题。在某些社区中,对方向的批评——尤其是来自核心维护者之外的人的批评,往往会遭到防御,而不是讨论。即使是对设计决策的质疑,即使是源于对系统哲学的真诚欣赏,也可能不会根据其优点来驳回,而是基于对发帖人的假设。
需要明确的是,我并不反对 9front。我尊重它的技术成就以及背后付出的巨大努力。我的担忧在于架构选择,在我看来,这些选择使系统偏离了 Plan 9 的创始理念,这些理念值得保留、扩展,并在必要时进行挑战。
一个例子是用 rcpu(1) 替换 cpu(1)。这一举措虽然在某些方面是实用的,但它回避了而不是解决了 9P 协议中的延迟问题。一个更具雄心的道路可能探索优化 9P 本身。同样,工具和社区讨论的变化反映出对本地工作流程和独立用例的日益重视,这与 Plan 9 论文中概述的分布式精神背道而驰。
这种分歧本身并没有错。系统会演变,社区的优先事项也会发生变化。但应该明确承认这一点。如果一个项目不再遵循最初的架构或设计理念,那么不加限定地称其为“Plan 9”就会产生误导,特别是对于期望默认使用分布式系统的新人而言。
一个项目“类似 Plan 9”并不是批评。这是一种描述。而且它不必削弱正在进行的工作。但清晰度很重要,公开的讨论更重要。
我仍然相信 Plan 9 的命名空间模型、每个进程的资源和网络透明设计的价值。如果创建新的发行版或衍生版本是保留和扩展这些原则的唯一方法,那就这样吧。让这项工作公开进行,不要在不存在共识的地方推定共识。
如果像 9fans 这样的社区无法进行这种对话,那么其他人会。
——泰勒斯