Plan 9 isn't restricted to a distributed OS, but it is the standout feature, and since it is an essential feature, it is going to affect the user interface.
Like, drag-n-drop is a pretty standard feature in most GUIs, but how do you manage that in Plan9 when there isn't a monolithic file tree shared between the windows? If I open a program, like a browser or a drawing program, but forget to bind in a network or a drawing tablet, will the user program be able to do binds, or do I have to exit out, run bind, and rerun the program? Would there be visual cues to let a user know what the namespace of a particular window is? Most of this can be shaken out from using Plan9 in these situations. But few people are. The closest I've seen is the demonstration video of Plan B; https://youtu.be/aOdaERBkBXw On Mon, Jun 9, 2025 at 5:39 AM Lucio De Re <[email protected]> wrote: > > > On 2025/06/07 12:07, sirjofri via 9fans wrote: > > Hi, > > > > Vic, your mail raised many arguments which I didn't agree with. Discussion > > inline. > > > > As the original mail was already quite long, this response is even longer. > > If you still want to read it, prepare yourself with a cup of tea or > > something. > > May I summarise my own grasp of this discussion? The modern GUI ought to > be what the browser would have become if allowed to incorporate its own > local terminal OS. Neither Netscape nor Microsoft wanted that to happen > and so it didn't. > > I think Vester is mistaken to believe that Plan 9 as a product is > restricted to a distributed OS; its essence is, but its instances could > be as different as KenFS was from a CPU server (or an AUTH server, which > may be a more interesting example). It's a maintenance problem that gave > rise to Fossil (one product, not many), and it's the same maintenance > problem that's preventing Plan 9 to give birth to a better Netscape that > can operate without, say, storage management. > > I am all in favour of generalisations, but I also believe that sharply > clear boundaries make for simplifications, so a text terminal, a CPU or > AUTH server, a file server or a web page renderer are all examples where > Plan 9 could be the philosophy and individual "features" matching the > philosophy are built upon it. > > I'm tempted to close off with something like: "The concept of API is a > generalisation, each individual API defines its own boundary" even > though it is too concise to convey what I would need to develop much > further. Feel free to challenge my presentation, I will be happy to > adjust my understanding where it needs it. > > Lucio. > > > 06.06.2025 00:44:39 [email protected]: > >> 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. > > I think the first question here would be, what even is an operating system? > > Is it just the basis of hardware abstraction, a philosophical idea, a > > strict implementation? Does it involve user interfaces of any kind or is it > > or technical? I don't think we all agree with every detail about this > > question, but in this context, it is important to think about that. > > > >> Perhaps that is indeed the intended direction. > >> It gives one pause and invites reflection. > > Pause and reflection is important. I like that our community is small > > enough and comes without any strings attached: There's no huge pile of > > software that the world depends on. > > > >> 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. > > User interface design and human computer interaction are about learning > > from the human, and applying human capabilities to that interface is the > > important step. It starts from physical limitations (humans have two eyes > > and two hands) and goes into depths of how the human thinks. > > > > But even then, most interaction with the computer is just learned behavior. > > Even using the mouse to move a pointer on the screen is something you need > > to learn. > > > > I believe that our current "modern" UI designs are modernizations of the > > same principles we used for many years. That is, windows, icons, buttons, > > text, and so on. It doesn't have to be like that, but that's what people > > are used to. If we make a new UI design, we can only choose between (1) > > following that same principles, and (2) expecting people to learn our new > > principles, or any mix between those two. > > > > About your statement: what are the requirements of modern graphical desktop > > environments? And whatever you name: is it really a requirement? > > > > I believe anything there it's a solution to a problem. Many of those > > problems aren't even problems at all, but evolved from an idea of some > > developer/designer who thought it would be nice. Other problems aren't > > problems on a plan 9 system. Both those categories don't need a solution. > > > > The third category are the valid problems we should focus about. But > > instead of copying the solutions of other systems, we have the option to > > think about them thoroughly and try to find an elegant solution that fits > > existing plan 9 principles and the existing architecture. I bet that in > > most cases we can find solutions that are as simple and elegant as the > > other plan 9 components. > > > > "But then, the user has to learn them" you might argue. Sure, but is it a > > bad thing? Plan 9 is a lot about transparency, so a user is expected to > > learn many things anyway. I'd prefer to give the user a matching and > > consistent UI solution to learn, than a copy of everything that already > > exists, but is a foreign thing that doesn't belong here. > > > > And people are able to learn. My mother knows next to nothing about > > computer, she only uses the programs she needs to fulfill her tasks, both > > at work and at home. She still had to learn some basic on a c64 back when > > she became a typewriter teacher. Is argue that anyone who touches a > > computer has to learn a bit about how to use it. There's no such thing as > > intuitive design, because every intuition is applied learned behavior. You > > don't go to a foreign country and just start speaking their language, you > > have to learn it. > > > >> 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. > > Sure, let's go into it. > > > >> Plan 9 is not a desktop-centric system > > Before going into this topic let me clarify one thing first. I believe that > > every system that is desktop centric is a failure from the beginning. User > > interfaces are about the user, not machines. That's why we're talking about > > UI, not API. > > > > A system that focuses about the desktop/UI instead of the user cannot build > > good solutions for the user. > > > >> 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. > > Sure, that's the underlying components. Plan 9 being about transparency, > > the user will always be able to see that in their namespace. > > > > But nobody talked about a single-machine use. And yet, there are > > limitations a user just naturally has. I don't know about you, but I have > > two hands with 5 fingers each. I am able to coordinate my finger to an > > extent that I can type with 10 fingers, essentially, but I'll never be able > > to use two keyboards simultaneously. I might be able to use two mice at the > > same time, but three mice? > > > > Humans are limited, and while we find elegant solutions to extend our > > capabilities (also with the help of computers), we will always hit walls at > > some point. > > > > But even then, who said that we can't build a desktop environment that goes > > about multiple machines, even a full network of machines? I'd argue that we > > already have that to some extent. Different namespaces and their view are > > basically a small form of that. I can have multiple rio windows with their > > own view on the resources of my network. I can build software that uses > > these resources, and yes, that also involves so-called "desktop > > environments", whatever that means. They just don't have to follow current > > expectations. > > > >> User sessions span file, compute, and authentication servers. > >> The 9P protocol manages communication among those parts. > >> All user interaction flows through remote interfaces. > > I sometimes wish plan 9 would be more like that, but that's a different > > topic. > > > >> 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. > > These are all solutions to problems we don't necessarily have. Why would we > > need a window compositor? For doing fancy graphics with transparency and > > effects? Is that important for a desktop environment? > > > > UI toolkits is a point that I can almost agree with. Libcontrol was never > > finished, and draw is just drawing. There are a few others, but there's no > > single solution that works for everything. Though here's the question: do > > we need that? Plan 9 can easily work with multiple different toolkit > > solutions, as it does today. It just needs solid ones that are easy to use > > and to work with. Funnily enough, we are working on this[1]. > > > >> 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. > > What is a desktop? > > > > Coming from the name, it's a metaphor of the surface of a desk. The common > > meaning of a desktop also evolved over time. Win3x had a desktop with all > > the hidden windows only, but no system tray. I also wouldn't count it's > > graphical shell (the program manager) as "global" in the sense of an > > omni-present start menu. All that evolved over time as a solution to that > > problem. > > > > The components you mention are either not relevant in a plan 9 system as we > > don't have these problems, or just aren't invented yet. For those that > > don't exist yet, they could still be written in a way that fits the plan 9 > > philosophy and architecture. As a simple example, many months ago I wrote a > > notification system for plan 9, which uses the plumber[2]. > > > > Regarding rio, I don't think that rio is what makes the plan 9 UI the plan > > 9 UI, but the other way around: I believe rio is the way it is _because_ of > > plan 9. > > > > This is important, because if we take away rio, it doesn't take away a core > > component of plan 9. We can replace it with a different window system that > > fits equally into plan 9. Rio is just a consequence of plan 9. > > > >> 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. > > That's what they do, yes, but that's not what makes them modern. If we want > > to build a modern system for plan 9, that doesn't mean that we should copy > > that to _become_ modern. > > > >> 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. > > Some we do have. We have menus with sweeping actions, swallowing window > > contents for graphical applications. > > > > Others are questionable if they make sense. > > > > Most people here agree that the system shouldn't be in the way. The first > > thing I do on a Windows system is, enable the "do not disturb" mode, as I > > hate those notifications popping up. They are annoying and are in the way. > > > > Why should plan 9 follow bad conventions or conventions that didn't make > > sense? > > > > Just because the others do that? Maybe because that's what defined a > > "modern desktop environment". If that's the definition, is rather not have > > it. > > > > I think we can do better. > > > >> To expect such behaviors from Plan 9 creates mismatch. > >> Its assumptions are not built around UI design goals. > > Yeah, and that's good. > > > >> Its definition of simplicity is structural, not visual. > > The visual simplicity follows the structural simplicity. You have a complex > > structure? Then everything that visualizes is needs to be complex, too, as > > well as the implementation, specifically _because_ of that complexity. > > > > You have a simple structure? Then it's much easier to implement a solution > > that's simple. A plan 9 desktop will this be much simpler than what we know > > from other OSes. > > > >> 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. > > If we see the computer as an extension of the user, there is a global > > environment: the user. > > > > The user is always the global environment of their own "computing/thinking > > space". On most systems, the computer itself provides another part of that > > same global environment in the firm of a single view on the abstractions. > > > > A plan 9 system is different, as each window provides a different local > > view and is this not part of that global environment. > > > > However, you can argue that the rio background is part of that global > > environment. And that same environment is often used for the plumber, > > webfs, factotum, and so on. > > > >> Fonts, window systems, and authentication are per-user. > >> They are often delivered by different machines. > >> This model supports separation, not convenience. > > It still is convenient. In fact, it's so convenient that modern systems use > > that, too. Password managers are often storing the secrets in the cloud, > > personal files are often mirrored, user accounts exist on some server, and > > so on. Because it is convenient. > > > >> 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. > > Why? > > > > My pixel watch is coupled with my phone, so it would naturally get its user > > settings via that. > > > > Android tablets support multiple users for many years already. > > > > And even then: why restrict a feature when you can just decide not to use > > it? > > > > Most OSes support multiple users, but most machines are only used by one > > person. > > > > I don't see why this situation would lead to "incomplete graphical support". > > > >> No touch input, accessibility, or decoration exists. > >> These would need to be implemented as external layers. > > Sure, these are missing components (besides decoration, which is optional). > > How they're implemented (external components it not) is a completely > > different topic. Localization is btw also mostly missing. > > > >> To add those layers means departing from Plan 9’s model. > >> The system is not designed to embed them natively. > > None of the modern systems supported them massively. The unit systems > > weren't even designed to support any graphics massively. And windows, > > originally being an extension to DOS, didn't even have preemptive > > multitasking! > > > > I'd argue that plan 9 has more native support for graphics in general than > > all those systems had back then. > > > > I'd also argue that you wouldn't have to depart from the plan 9 model when > > implementing solutions for the mentioned problems. In fact, I believe you > > can find more elegant solutions on a plan 9 system. > > > >> 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. > > Why? Because we want to transform plan 9 into a Linux? > > > > If I wanted a Linux, I'd still use it. > > > > People wanting tabbing support doesn't equal them wanting the exact same > > thing i3 provides. > > > >> 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. > > /dev/mouse, (/dev/theme), /dev/..., libevent, just to mention a few. And > > they just work, unlike any word abstractions they have on other systems, > > that only work under specific circumstances. > > > > And the fact that those systems provide all those features doesn't mean > > that we want them or have to copy them. I never missed drag and drop, for > > example, but I miss plumbing and mouse chording on other systems. > > > >> Plan 9 is not incompatible with graphics frameworks. > >> However, these do not exist in its environment today. > >> Adding them requires constructing new interface layers. > > Or, following the plan 9 architecture, new /dev devices or other > > filesystems. > > > > Like anything on plan 9 does. > > > >> 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. > > Yeah, because nobody has done the work yet. > > > >> 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. > > No. Plan 9 is designed for this. > > > > Otherwise I could argue that every port would diverge from the original > > plan 9 assumptions, because they introduce new drivers. Even though the > > filesystem abstraction is the same and this compatible to that in other > > ports. > > > > Sure, we need to introduce new filesystems with new abstractions that > > didn't exist yet. But plan 9 is designed for this. I could even say, that > > is exactly what plan 9 is for! > > > >> 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. > > That's why we don't have devdraw, devmouse, devcons, .... > > > > The mentioned components are explicitly designed for a "local screen" and > > "local control". > > > > "Local" in the sense of astral projection, if you get that reference. > > > >> A desktop OS assumes a single, local, GUI-heavy use case. > > I don't agree. Any desktop OS provides capabilities to allow for multiple > > use cases. Most use cases nowadays are handled in a browser, which means > > the task is happening on a server (thus not local). > > > > GUI-heaviness is not an argument. Most plan 9 users use rio (or some other > > window manager) and start graphical applications, btw. > > > > Funnily enough, most Linux users that I know start a terminal emulator at > > some point. > > > > Putting more functionality into GUIs is also not necessarily good. > > > >> It provides persistence, session memory, and input focus. > >> It assumes consistent visual interaction patterns. > > All of this exists on a plan 9 system, just in a different way. > > > >> These two models begin with different root structures. > > They do in some core aspects, but UI-wise, they logically aren't so > > different. > > > >> They diverge at the level of system services. > > Sure, as that's the point of having a different OS. > > > >> They do not share the same goals or interface paths. > > I partly disagree. Of course, plan 9 as a research OS has a different > > focus, but that doesn't make it incompatible with a user-friendly desktop > > environment, whatever that is. > > > >> 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. > > I don't agree here. > > > > A desktop OS is about UI, and UI is about the user. Since the user needs to > > learn any interaction with a computer, we shouldn't copy things, but > > research how to integrate the user with the core system. The result of that > > research can be used to design a system that represents plan 9 and is > > simple enough for the user to learn. > > > > A few examples in our community show that it is already possible to use > > plan 9 as a user, as a desktop, to some extent. Following the described > > path can extend the functionality of the existing UI and make it more > > usable for a larger user base. > > > > That can involve rewriting a few components, but not in a sense of just > > copying what exists already. That said, it is fine to copy solutions if > > they also work for plan 9. > > > > Note that I said "desktops are about UI", not "desktops are about GUI". I > > believe that a user doesn't necessarily want to do everything graphically. > > The user wants to use a good user interface. > > > > An example: Everyone I introduced to git, I started with some git gui. And > > everyone just used the command line at some point. And I wouldn't even > > count the git CLI as "good". > > > >> 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. > > Desktop doesn't mean GUI-first, in my opinion. And also, plan 9 was more > > graphical from the beginning, and they considered graphics at the core. > > > > Standard interface abstractions might be standard, but they are still > > learned. > > > >> Plan 9 does not. > >> That distinction defines what can be built on each base. > > So, let's all just throw away plan 9 as it was clearly never designed to be > > used by an end user? > > > > I don't agree. > > > > In fact, I believe that we have to go to the base of UI research and > > understand what it means. It's not about copying standards, it's about > > building new standards based on research. Standards that work for a user of > > a plan 9 system. > > > > It's a challenge, but that's just what UI design, human interface design, > > and HCI is. > > > > In that aspect, plan 9 should still be a research OS. And that's a good > > thing, because we don't have to follow the expectations. > > > > sirjofri > > > > [1]: people like sigrid, adventuresin9, and myself have worked or are > > actively working on different toolkit solutions. > > > > [2]: https://shithub.us/sirjofri/notif/HEAD/info.html ------------------------------------------ 9fans: 9fans Permalink: https://9fans.topicbox.com/groups/9fans/Tf84d656c78bbda91-M392ad342775e5f35b22f0633 Delivery options: https://9fans.topicbox.com/groups/9fans/subscription
