What is Plan 9?

Plan 9’s Influence on Other Systems

• 9P / v9fs is praised as a clean, “network-native” filesystem interface; some prefer it to FUSE on Linux.
• Commenters note 9P is used in Windows Subsystem for Linux to expose the Windows filesystem to Linux.
• Some see Plan 9 / 9front as a more coherent distributed-OS model than Docker+namespaces+k8s; others say k8s is effectively a distributed OS built on Linux.

Language Choices: C, Rust, Go, Limbo

• Desire is expressed for “more Rust on Plan 9,” but there’s no native Rust compiler; Plan 9 uses its own C dialect and toolchain.
• A Rust reimplementation of the Plan 9 kernel (r9) is mentioned, with unknown maturity.
• Several argue Rust’s toolchain (and LLVM) is too large and complex relative to 9front’s small codebase.
• Others value Plan 9’s simplicity and reject “modern = complex”; Plan 9 C is described as “therapeutic” compared to C++/Swift.
• Extended debate over Limbo, Alef, Go, Cyclone, and Rust: influences around type systems, concurrency, GC vs reference counting, and how much Rust really resembles Limbo/Alef.

Current Status and Practical Use of Plan 9 / 9front

• 9front is described as very much alive, with frequent commits and an active conference (IWP9).
• Users enjoy hacking on 9front, especially its “everything is a file” design, but struggle to adopt it as a daily driver due to lack of modern browser and GPU acceleration.
• Some note Plan 9’s UI feels mouse-heavy. Others consider server/router or specialized roles instead of desktop use.
• A Retina-capable drawterm fork for macOS is highlighted as a practical improvement (resizing, dynamic scaling).

“Everything is a File” and Distributed OS Debate

• One camp doubts OS research “close to the metal” is still impactful and questions whether “everything is a file” helps in a world dominated by web APIs and SQL.
• Others argue:
  • Low-level OS design, especially network-native and distributed models, is still under-explored.
  • A uniform file(‑server) abstraction simplifies composition, scripting, and distribution (mounting remote /net, VPN/NAT as namespace tricks, etc.).
• Skeptics counter that:
  • Mapping rich protocols (SQL/web APIs) onto files often looks like awkward indirection.
  • Filesystems impose tree structures on inherently graph-shaped data.
  • Performance and complexity issues arise from “ctl files” and user-space file servers.

APIs, Sockets, and Filesystem Interfaces

• Some lament that BSD sockets live outside the filesystem, being “almost” but not quite a file interface.
• Plan 9’s /net hierarchy (TCP/UDP as files, NAT/VPN/firewalls via union mounts) is admired as conceptually clean.
• Others note trade-offs:
  • File-centric control via text “ctl” files can be clumsy and slower than ioctl-style binary interfaces.
  • Plan 9’s model can mean more context switches and protocol parsing; Linux is moving toward io_uring-style batching instead.
• FUSE is seen as a partial analogue (“everything as a filesystem” in user space), but Plan 9 proponents argue its model is deeper and more uniform than what Linux can offer while preserving POSIX compatibility.

Architecture Ports and Low-level Research

• There is interest in a Plan 9 port for RISC-V RV32I; a 9legacy port and an in-progress 9front port are mentioned.
• Some want a simple multitasking, network-capable OS for soft RISC-V cores, closer to Unix/CP‑M than an RTOS.

Broader OS Evolution and Stability

• One commenter argues mainstream OSes should “feature-freeze” and focus innovation above the OS, citing past disruptive desktop-environment churn on Linux.
• Others respond that OSes remain the layer where drivers, isolation, namespaces, and security live, so research OSes like Plan 9 still matter.

Miscellaneous

• A “modern Plan9 web version” project (apptron) is linked; others question what concretely makes it Plan 9–like.
• The name “Plan 9 from Bell Labs” is confirmed as a reference to the film “Plan 9 from Outer Space.”