让 Tmux 成为操作系统
一位长期使用终端的用户设想了一种围绕类似 tmux 的持久性和键盘中心窗口管理构建的操作系统界面，这引发了关于这一愿景是否只是重新发明平铺式窗口管理器，以及 i3、Niri 或 Emacs 等现有工具的争论。评论者分成两派：一派重视高度可配置、面向高级用户的设置；另一派则认为要实现主流采用，必须有更友好的默认设置和更少的手动配置，也许还能借助本地 LLM。更深层的争论则围绕文件系统与应用专属数据孤岛展开，以及用任务中心或应用中心模型取代传统的基于文件的组织方式是否真的对用户更有利。
Tmux、复用器和持久性
- 多条评论把跨会话和跨机器的持久性视为 tmux 的主要价值。
- 有人建议使用 tmux-resurrect 和 tmux-continuum 等插件，在重启后恢复布局。
- 还提到了 zellij 和其他自定义终端复用器等替代方案；也有人指出 HTML 邮件和富内容是摩擦点。
- 也有人说在迁移到更新的窗口管理器或集成终端方案后，已经完全放弃了 tmux。
平铺式窗口管理器 vs “tmux 作为操作系统”
- 许多人认为这篇文章其实描述的是平铺式窗口管理器，而不是一种操作系统变更。
- i3、sway、hyprland、Niri、EXWM、Ratpoison、各种 twm 以及类似工具都被提到，它们已经解决了大部分布局和导航问题。
- 在 macOS 和 Windows 上，也讨论了 yabai、Aerospace、OmniWM、Nehir、komorebi 等对应方案，但对于打磨程度、稳定性和复杂度的反馈褒贬不一。
- 有人认为作者只需稍微配置一下就能解决自己的问题；也有人强调，配置本身就是非技术用户和大规模采用的门槛。
垂直标签页、树状结构与任务流
- Arc 的垂直标签页引发了争论；有人不满简单的垂直列表突然流行起来，而更早的树状标签扩展其实能提供更丰富的任务分组。
- 也有人对嵌套/树状标签模型很感兴趣，因为它们更贴近“任务树”（例如展开/折叠一个完整的 HN 阅读会话），尽管如今这类支持已经很小众。
文件系统 vs 应用孤岛
- 对“文件系统是脆弱抽象”这一观点，出现了强烈反驳。
- 支持文件系统的评论强调可移植性、中立性，以及在切换应用时不会失去对数据的访问。
- 以应用为中心的存储（如 Apple 的 Photos/Notes/iCloud 风格）则被批评为不透明、难以管理或 diff；也有人回应说，许多应用内部结构（缓存、数据库）本来就不适合直接暴露原始文件，而沙盒和云同步又会推动应用数据库化。
- 还出现了更广泛的“名词 vs 动词”框架：以数据为中心的文件系统模型 vs 以应用为中心的模型，而这里大多数人更偏向前者。
生产力、UX 与“普通用户”
- 有人坚持 UI 是带有品味差异的“艺术”，而 Unix 式的自由组合与配置文件（甚至可以由 LLM 生成）从长远看是赢家。
- 也有人认为，对窗口和任务管理具备基本能力应该是职业要求；混乱的桌面会在协作中浪费每个人的时间。
- 反方则指出，思考、设计和代码质量比高级用户的操作速度更重要；窗口或打字上的小低效通常无关紧要。
LLM 与配置
- 多条评论建议使用本地或捆绑式 LLM 来生成窗口管理器配置，或让用户用自然语言描述理想桌面。
- 怀疑者则指出当前 LLM 可靠性不足，并警告不要把它们变成桌面体验的基础。