HackerNews中文版

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

查看原文

In recent days, I attempted to contribute a discussion to the 9fans mailing list regarding the architectural direction of 9front. The post was carefully written and presented in good faith. It raised questions about the project's focus on single-user workflows and the apparent decline in emphasis on distributed computing, a hallmark of the original Plan 9 design.The post was rejected by moderators. My account was banned under the claim that the message was AI-generated. It was not. While I occasionally use writing assistants to refine grammar and clarity, the ideas and arguments were entirely my own. The banning effectively closed the door on any opportunity for clarification, correction, or productive debate.This reaction highlights a deeper issue. In certain communities, critique of direction—particularly from outside core maintainers is met with defensiveness rather than discussion. Questions about design decisions, even when rooted in a sincere appreciation for the system's philosophy, may be dismissed not on their merits, but on assumptions about the messenger.To be clear, I do not oppose 9front. I respect its technical accomplishments and the immense effort behind it. My concern lies with architectural choices that, from my perspective, shift the system away from Plan 9's founding ideas, ideas worth preserving, extending, and, where necessary, challenging.One such example is the replacement of cpu(1) with rcpu(1). This move, while practical in some respects, avoids rather than addresses the deeper problem of latency in the 9P protocol. A more ambitious path might have explored optimising 9P itself. Similarly, changes in tooling and community discussion reflect a growing emphasis on local workflows and standalone use cases, diverging from the distributed ethos outlined in the Plan 9 papers.That divergence is not inherently wrong. Systems evolve, and community priorities shift. But it should be acknowledged clearly. If a project is no longer following the original architecture or design philosophy, calling it “Plan 9” without qualification becomes misleading, especially to newcomers expecting a distributed system by default.A project being “Plan 9-like” is not a criticism. It is a description. And it need not diminish the work being done. But clarity matters, and open discourse matters more.I continue to believe in the value of Plan 9’s namespace model, per-process resources, and network-transparent design. If creating a new distribution or derivative is the only way to preserve and extend those principles, then so be it. Let that work proceed openly, without presuming consensus where none exists.And if a community like 9fans cannot host such dialogue, others will.- Thales

架构、社区与 Plan 9 的精神