Much of the discussion gives the impression that many here are seeking something quite different from what Plan 9 was originally designed to provide.
What is being described sounds less like an extension and more like the foundation of a new operating system. Perhaps that is indeed the intended direction. It gives one pause and invites reflection. On Departing from the Plan 9 Model Let us examine the structural assumptions embedded in Plan 9 and considers the implications of applying it to desktop-focused or single-user environments. While Plan 9 offers compositional elegance and architectural clarity, its model is not aligned with the requirements of modern graphical desktop systems. This is not a critique of intent or capability, but a reflection on architectural fit. Understanding the boundaries of Plan 9's design helps clarify where adaptation is feasible and where reconstruction becomes necessary. Plan 9 is not a desktop-centric system Plan 9 was not created for single-machine desktop use. Its architecture focuses on distributed coordination. Its goal is to unify machines into one namespace. User sessions span file, compute, and authentication servers. The 9P protocol manages communication among those parts. All user interaction flows through remote interfaces. Each user session connects to remote services explicitly. These include file service, CPU execution, and authentication. This reflects a distributed and multi-terminal model. Plan 9 does not prioritise graphical interface use. There is no window compositor or event manager. There are no UI toolkits or persistent notifications. The Rio window system presents windows but not a desktop. It offers no system tray or global graphical shell. There is no UI state storage between sessions. Plan 9 simplicity is not user interface simplicity Plan 9 is simple in composition and design scope. Its core idea is orthogonality of interfaces. Every system object is addressed as a file. Namespaces are assembled per session by the user. Services and devices are bound by mounting actions. This yields flexibility and minimalism in usage. Modern desktops hide these actions behind UI layers. They abstract system state into persistent sessions. They expose GUI settings and graphical tools. Systems such as GNOME or i3 use visual conventions. These include gestures, layouts, and notification events. These conventions do not exist in Plan 9 by default. To expect such behaviors from Plan 9 creates mismatch. Its assumptions are not built around UI design goals. Its definition of simplicity is structural, not visual. Plan 9 assumes trust-separated, multi-user operation Each user runs in an isolated namespace context. Resources are mounted into the session explicitly. No global environment exists for all users. Fonts, window systems, and authentication are per-user. They are often delivered by different machines. This model supports separation, not convenience. A tablet or wrist device uses one user by nature. Plan 9 must be reconfigured to avoid multi-user defaults. Otherwise, graphical support will remain incomplete. No touch input, accessibility, or decoration exists. These would need to be implemented as external layers. To add those layers means departing from Plan 9’s model. The system is not designed to embed them natively. Desktop conversion leads to architectural misalignment The goals described include tabbed windows and input support. Also included are gestures, integration, and persistence. These needs align with GTK, Qt, or similar stacks. Such systems offer abstracted input models and event loops. They support theming, drag-drop, and high-DPI layouts. These are not present in Plan 9’s design constraints. Plan 9 is not incompatible with graphics frameworks. However, these do not exist in its environment today. Adding them requires constructing new interface layers. These layers must track state and handle input contexts. They must coordinate redraw events and window geometry. No such tools are included in the existing distribution. Bringing these features into Plan 9 changes its scope. It introduces code unrelated to its original structure. The result will diverge from its operating assumptions. Architecture defines outcome more than tools This is not a question of capability or desire. This is a question of alignment with core abstractions. An OS is shaped by its target model and constraints. Plan 9 targets distributed, coordinated systems. It does not assume a local screen and local control. It assumes named users with private namespaces. A desktop OS assumes a single, local, GUI-heavy use case. It provides persistence, session memory, and input focus. It assumes consistent visual interaction patterns. These two models begin with different root structures. They diverge at the level of system services. They do not share the same goals or interface paths. To extend Plan 9 into a desktop OS is to rewrite it. Most layers would need to be added or redesigned. This is not a continuation but a redirection. Other systems already provide GUI-first design. Some of them include Plan 9-inspired structure. Haiku and i3 on Linux are notable examples. These systems begin with graphical interaction in mind. They support single-user tasks and desktop workflows. They reuse or wrap standard interface abstractions. Plan 9 does not. That distinction defines what can be built on each base. - vic ------------------------------------------ 9fans: 9fans Permalink: https://9fans.topicbox.com/groups/9fans/Tf84d656c78bbda91-Mcb191fdbed77e3d5e26a1fad Delivery options: https://9fans.topicbox.com/groups/9fans/subscription
