建筑、社区与Plan 9的精神

1作者: Thales_Miletus5 天前原帖
最近,我试图在9fans邮件列表中就9front的架构方向进行讨论。我的帖子经过仔细撰写,出于善意提出。它提出了关于该项目专注于单用户工作流以及对分布式计算的重视似乎下降的问题,而分布式计算正是原始Plan 9设计的一个标志。 该帖子被版主拒绝。我账户被禁用,理由是该消息是由人工智能生成的。但事实并非如此。虽然我偶尔使用写作助手来改善语法和清晰度,但其中的观点和论点完全是我自己的。禁令实际上关闭了任何澄清、纠正或富有成效的辩论的机会。 这种反应突显了一个更深层次的问题。在某些社区中,来自核心维护者以外的方向批评往往会遭到防御,而不是讨论。即使是出于对系统哲学的真诚欣赏而提出的设计决策问题,也可能不会基于其本身的价值被认真对待,而是基于对发言者的假设而被忽视。 明确来说,我并不反对9front。我尊重它的技术成就和背后的巨大努力。我的担忧在于一些架构选择,从我的角度来看,这些选择使系统偏离了Plan 9的创始理念,而这些理念是值得保留、扩展并在必要时进行挑战的。 一个这样的例子是用rcpu(1)替代cpu(1)。这个举措在某些方面虽然实用,但却回避了9P协议中延迟这一更深层次的问题。一个更具雄心的方向可能会探索优化9P本身。同样,工具和社区讨论的变化反映出对本地工作流和独立用例的日益重视,这与Plan 9论文中所阐述的分布式精神背道而驰。 这种偏离并非固有错误。系统在演变,社区的优先事项也在变化。但这一点应该被明确承认。如果一个项目不再遵循原始的架构或设计哲学,那么在没有任何限定的情况下称其为“Plan 9”就变得具有误导性,尤其是对那些期望默认获得分布式系统的新手而言。 一个项目被称为“类似Plan 9”并不是批评,而是一种描述。这并不必然贬低正在进行的工作。但清晰性很重要,而开放的讨论更为重要。 我依然相信Plan 9的命名空间模型、每个进程的资源和网络透明设计的价值。如果创建一个新的发行版或衍生品是保留和扩展这些原则的唯一方法,那就这样吧。让这项工作公开进行,而不假设不存在的共识。 如果像9fans这样的社区无法进行这样的对话,其他社区会进行。 - Thales
查看原文
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&#x27;s focus on single-user workflows and the apparent decline in emphasis on distributed computing, a hallmark of the original Plan 9 design.<p>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.<p>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&#x27;s philosophy, may be dismissed not on their merits, but on assumptions about the messenger.<p>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&#x27;s founding ideas, ideas worth preserving, extending, and, where necessary, challenging.<p>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.<p>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.<p>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.<p>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.<p>And if a community like 9fans cannot host such dialogue, others will.<p>- Thales