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
