Re: [9fans] The Big Questioning: Plan 9 everywhere?

["sirjofri via 9fans" <9fans@9fans.net>]

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.

06.06.2025 00:44:39 vester.thacker@fastmail.fm:
> 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-Mecad69b25850ee8f1d79295b
Delivery options: https://9fans.topicbox.com/groups/9fans/subscription