* Re: [9fans] The Big Questioning: Plan 9 everywhere?
[not found] <CAJCpOFxsQrW5v_jrEPX7tuy+uin2h32ADFchti7Vk1RL=OxxnQ@mail.gmail.com>
@ 2025-06-05 15:35 ` Jacob Moody
[not found] ` <CAJCpOFy=_HNk+hnusKu=TWK2B=kTuhJtCXBw1kB8hJSURh10Qw@mail.gmail.com>
2025-06-06 4:08 ` Adrian
1 sibling, 1 reply; 10+ messages in thread
From: Jacob Moody @ 2025-06-05 15:35 UTC (permalink / raw)
To: 9fans
Responses in-line.
On 6/5/25 07:42, Daniel Maslowski via 9fans wrote:
>
> Operating systems have made their journeys as well. Be it macOS, Windows or Ubuntu as they are today having iterated over many concepts in terms of widgets and interaction design, and BeOS famously having experimented a lot in the realm of multimedia. The respin Haiku is close to a stable version 1.0. Let me cite from haiku-os.org <http://haiku-os.org>:
> "Haiku is an open-source operating system that specifically targets personal computing. Inspired by the BeOS, Haiku is fast, simple to use, easy to learn and yet very powerful."
>
> And here goes the idea of "simplicity": It isn't simple nor easy to *develop* those things, but the primitives are simple. On the other hand, it is the developers' burden to deliver simplicity to the end user. Let's keep that in mind: Missing out on a decent user experience creates tons of complexity on the side of the user. Like, say, having tons of abbreviations and little use of colors and such in 2025, in which we have 8k screens, terabytes of storage, gigabytes of RAM, touch input, and tons
> of gadgets in everyone's hands - that can change.
I personally like that while Plan 9 presents a very cohesive environment,
it never really papers over technical issues. Plan 9 often chooses simpler
implementations and exposing the reality to the user instead of attempting to
hide the real world complexities of the problem.
Plan 9 is a system that invites you to understand your computer.
In doing so, a lot of code can be straight forward.
Plan 9 is "simple" in the sense that most implementations are simple.
If people want a hand-holding user experience I suggest sticking to a mac.
>
> Part2: Where do I want to go with Plan 9?
>
> The question now is what I am doing here. It's simple (pun intended).
> I read that Plan 9 ought to be simple, and I want to see that work out. So I look at it from a bunch of angles and see that it is quite different from my expectation of simplicity. Though there is potential to get somewhere. I think that would fit the spirit of the Bell Labs folks who started it all.
>
> A lightweight system that can run on those many gadgets we now have? Awesome, let's do that! I see a ton of potential in being able to, say, drawterm / cpu into the tablet I hung up in my kitchen. The stock Android is long defunct. Or the wristband I am wearing. Tiny SBCs that I can plug into my laptop via USB. The small https://racklet.io/ <https://racklet.io/> cluster that I am helping to build. Whatever wicked still may come!
9front is less of a "let's do X or Y" and a "this bothers me so I'll put in the work".
If people want change they send the patches. I dislike this "this work should be done"
talk instead of a "How do I start doing this work? Here I have a sketch of this idea but
I'm having issues".
The biggest issue with supporting whatever tablet or whatever you have hanging in your
kitchen is the lack of documentation and the crazy interfaces that are required to make
it work sensibly. Nice to have? Sure why not. Easy to do? Likely no.
>
> So I have been working on hardware platform initialization firmware, this project called oreboot (yes, without C), and boot loaders, that is, LinuxBoot, and next, I want to bring up Plan 9. I mainly work on RISC-V based platforms, now also a bit of Arm, and little x86.
>
> With the experience in doing this, I paired up with Shawn to hack on Moody's WIP port of 9front for RISC-V in QEMU. And I checked with Ron and Ori if we can LinuxBoot into Plan 9 / 9front on x86 (might work again with Ron's fix; I gotta retry!).
What do you mean get "LinuxBoot into plan 9 / 9front",
if you mean getting a linux kernel in as a bootloader that won't happen.
If you mean to add support for booting 9front kernel using linuxboot,
our amd64 kernel already supports multiboot.
I did this dance of getting a 9front kernel booting with kexec (ala linuxboot),
for the power64 talos and the interface sucked. I'd rather not propagate this to other
systems. If I recall correctly I had to make up some bullshit addresses in the ELF
header because the linux kernel had a validity check for a value it never used.
LinuxBoot is designed to do just that, boot linux.
>
> Over the last few days, I created a tool to convert Plan 9 a.out files to ELF (amd64 so far, RISC-V WIP), and I added Plan 9 a.out support for RISC-V to radare2. Those tools should help with the endeavor.
Converting Plan 9 a.outs to ELFs is going to be bound with issues if you're doing
it after the fact. Plan 9 code is not position independent and we do not provide
the structure required for relocation.
Now for the real reason I sent this email, you didn't add RISC-V plan 9 a.out support to radare2.
You took someone else's patch that I had generously shared with you while you were poking at the RISC-V kernel
and upstreamed it behind our backs claiming it as your own.
Your PR(https://github.com/radareorg/radare2/pull/24261) mentions nowhere that this was someone else's code.
To be entirely honest I find this behavior shocking and troubling, and now I feel responsible for being the
one to send it over to you. I'm sorry but I will not be interested in continuing to share the ongoing work
of the RISC-V port if this is the respect we have for each others work.
------------------------------------------
9fans: 9fans
Permalink: https://9fans.topicbox.com/groups/9fans/Tf84d656c78bbda91-M150bbbe09802d0172c82dcdd
Delivery options: https://9fans.topicbox.com/groups/9fans/subscription
^ permalink raw reply [flat|nested] 10+ messages in thread
* Re: [9fans] The Big Questioning: Plan 9 everywhere?
[not found] ` <CAJCpOFy=_HNk+hnusKu=TWK2B=kTuhJtCXBw1kB8hJSURh10Qw@mail.gmail.com>
@ 2025-06-05 18:39 ` Jacob Moody
[not found] ` <CAJCpOFwnfDeoCQ1mWQLy_Ntn+2boNxxFSqwf8thY5mDFKXER3g@mail.gmail.com>
0 siblings, 1 reply; 10+ messages in thread
From: Jacob Moody @ 2025-06-05 18:39 UTC (permalink / raw)
To: 9fans
Responses in-line.
On 6/5/25 12:10, Daniel Maslowski via 9fans wrote:
> Moody, first of all, I apologize. To be clear, I would not wamt to claim anyone else's work as mine, especially not right in front of them. Quite the opposite; I credit others on a regular basis. All I'm trying here is to help bring things further.
> I do recall that you had mentioned a patch for something on IRC, but I had forgotten about it and not taken a closer look, focusing on the fiddling we did that evening; sorry if it was exactly this for r2. I have no logs, otherwise I'd check.
Thank you for the apology.
For full transparency, this is the irc log snippet that has the conversation regarding this:
250525:2056 CyReVolt ⇒ Is there a way to get something like an objdump so that we can look at the whole kernel?
250525:2058 CyReVolt ⇒ We cannot even stepi or hit a breakpoint anymore with a static ...
250525:2059 moodman ⇒ radare2 has support for plan 9 binaries
250525:2059 moodman ⇒ and can connect to a remote gdb
250525:2059 moodman ⇒ I have a patch for working riscv support
250525:2059 moodman ⇒ if that helps
250525:2100 CyReVolt ⇒ working riscv support in r2?
250525:2101 moodman ⇒ for specifically plan9 binaries
250525:2103 CyReVolt ⇒ ah so r2 riscv support
250525:2103 CyReVolt ⇒ Where's that patch? =)
250525:2105 moodman ⇒ http://okturing.com/src/25279/body
250525:2113 CyReVolt ⇒ okay we managed to print a static char[] using uartputs for once
250525:2114 CyReVolt ⇒ i.e. static char foo[] = "12345"; uartputs(foo, 5); WORKS
250525:2114 CyReVolt ⇒ BUT uartputs("Plan 9", 6); does NOT work
250525:2115 CyReVolt ⇒ sounds like dinner time
(that okturing link is still live, if anyone wants to see what the original patch was)
> The changes I made were my own, in the context of yesterday's exchange with pancake, https://mastodon.social/@CyReVolt/114625651395826989 <https://mastodon.social/@CyReVolt/114625651395826989> - being trivial enough that you probably did very much the same, though I am not sure whether what I did there was correct or complete. I just took a kernel that Shawn had built and it seemed to work fine. If I had had your changes, I would not have done this.
I told you what the patch was and you explicitly asked for it.
You're right that the code is trivial, I do find it plausible that two people just
wound up with very similar looking code, and there are slight modifications.
I don't want to make a mountain out of a mole hill, so I'm comfortable assuming
good faith on your part. I still wanted to provide the log of the conversation
I recall the two of us having because I had made a serious allegation and wanted
to explain why I had reached my initial thoughts on the matter.
Thank you for your explanation, and I hope you can see why my thoughts were what they were.
> And I wouldn't have spent a whole week creating another tool, which is obviously 100x the effort. I didn't even know what ELF really looks like until now.
> While it's not ideal either, it makes it possible to see the symbols in gdb now, at least.
> I started with x86 because I had a kernel from Ron in both a.out and ELF that I took as a fixture, and just added 64-bit RISC-V ELF support today, which should get some cleanups because it got pretty ugly.
>
> Regarding LinuxBoot, stories like yours on the Talos system are what I see as input for improvement. Yes, I agree, the current state is not great, and a lot of work is necessary to make it smooth.
Work that has to happen outside of our ecosystem. There's not much for us to do to make
the linuxboot situation less bad.
------------------------------------------
9fans: 9fans
Permalink: https://9fans.topicbox.com/groups/9fans/Tf84d656c78bbda91-Mb1ec41504f2ab5ebd84b8b2f
Delivery options: https://9fans.topicbox.com/groups/9fans/subscription
^ permalink raw reply [flat|nested] 10+ messages in thread
* Re: [9fans] The Big Questioning: Plan 9 everywhere?
[not found] <CAJCpOFxsQrW5v_jrEPX7tuy+uin2h32ADFchti7Vk1RL=OxxnQ@mail.gmail.com>
2025-06-05 15:35 ` [9fans] The Big Questioning: Plan 9 everywhere? Jacob Moody
@ 2025-06-06 4:08 ` Adrian
1 sibling, 0 replies; 10+ messages in thread
From: Adrian @ 2025-06-06 4:08 UTC (permalink / raw)
To: 9fans
[-- Attachment #1: Type: text/plain, Size: 6275 bytes --]
Me, I don't want Plan9 to work like everything else, because what's the point in that, to have the same stuff on a different OS? What does that get you?
Nothing.
Everybody thought 9p was kooky 25 years ago, but now 9p file systems are everywhere.
Adrian
On June 5, 2025 8:42:12 AM EDT, Daniel Maslowski via 9fans <9fans@9fans.net> wrote:
> Hey fans,
>
> Here's the voice from the abyss.
>
> Prelude:
>
> Let me begin with something I have experienced in this community, and I
> would like to shine some light on the effects of the mentality behind. I'll
> be subtle.
> Please read to the end, and I'm sure it will make you happy.
>
> This first part mainly goes out to people assuming that I or anyone else
> might be just too much "used to Linux": Nope, you're wrong, plain wrong.
>
> Part 1: Where I am coming from
>
> Let me explain. I am using machines to assist me with what I do, and if one
> doesn't fit, I will change it. If the system doesn't offer what I need, I
> will pick a different one. I have worked with all the major ones, be it
> Windows, macOS, Linux or FreeBSD, and they all have their ups and downs. I
> want mostly the ups, and I anticipate everyone does.
>
> What I want is a decent desktop experience with no shenanigans, easy
> software installation, no animations, no annoying OEM tray icons etc.. That
> is what ruled out Windows and macOS for me. So I had FreeBSD and Linux
> left. Except FreeBSD isn't FreeBSD and Linux isn't Linux, so we're
> comparing pineapples and pomegranates here.
>
> Now there are multiple graphics systems and desktop stacks to choose from,
> the usual X vs Wayland and KDE vs GNOME vs Xfce vs maybe just i3/Sway
> choice. I pick i3/Sway because it fits my needs, and that is where that
> discussion ends. Coincidentally, they have strong roots in Plan 9, and they
> did this one thing: improve a lot.
>
> We even see ideas making their way back into Plan 9, e.g., with Lola. Tabs?
> That is how I use i3/Sway! All windows in full size and tabbed, so that I
> can set up a workspace ("desktop") with all I need there. I rarely tile,
> and if I do, it will be something like editor + browser or editor + PDF
> viewer so I see what my code changes.
> So that's the way I roll, and everyone has their own way. And that's okay.
>
> Now you may know that I've got a decade of experience in web development, a
> field that exploded over the years, and I also acknowledge that many of you
> simply hate it. Why though? Does user experience design discomfort you? I
> do understand that a lot of the development is not perfect, and I also see
> how a lot of the web has turned into ad platforms. We can easily agree that
> those aspects need improving. So back to the OS.
>
> Operating systems have made their journeys as well. Be it macOS, Windows or
> Ubuntu as they are today having iterated over many concepts in terms of
> widgets and interaction design, and BeOS famously having experimented a lot
> in the realm of multimedia. The respin Haiku is close to a stable version
> 1.0. Let me cite from haiku-os.org:
> "Haiku is an open-source operating system that specifically targets
> personal computing. Inspired by the BeOS, Haiku is fast, simple to use,
> easy to learn and yet very powerful."
>
> And here goes the idea of "simplicity": It isn't simple nor easy to
> *develop* those things, but the primitives are simple. On the other hand,
> it is the developers' burden to deliver simplicity to the end user. Let's
> keep that in mind: Missing out on a decent user experience creates tons of
> complexity on the side of the user. Like, say, having tons of abbreviations
> and little use of colors and such in 2025, in which we have 8k screens,
> terabytes of storage, gigabytes of RAM, touch input, and tons of gadgets in
> everyone's hands - that can change.
>
> Part2: Where do I want to go with Plan 9?
>
> The question now is what I am doing here. It's simple (pun intended).
> I read that Plan 9 ought to be simple, and I want to see that work out. So
> I look at it from a bunch of angles and see that it is quite different from
> my expectation of simplicity. Though there is potential to get somewhere. I
> think that would fit the spirit of the Bell Labs folks who started it all.
>
> A lightweight system that can run on those many gadgets we now have?
> Awesome, let's do that! I see a ton of potential in being able to, say,
> drawterm / cpu into the tablet I hung up in my kitchen. The stock Android
> is long defunct. Or the wristband I am wearing. Tiny SBCs that I can plug
> into my laptop via USB. The small https://racklet.io/ cluster that I am
> helping to build. Whatever wicked still may come!
>
> So I have been working on hardware platform initialization firmware, this
> project called oreboot (yes, without C), and boot loaders, that is,
> LinuxBoot, and next, I want to bring up Plan 9. I mainly work on RISC-V
> based platforms, now also a bit of Arm, and little x86.
>
> With the experience in doing this, I paired up with Shawn to hack on
> Moody's WIP port of 9front for RISC-V in QEMU. And I checked with Ron and
> Ori if we can LinuxBoot into Plan 9 / 9front on x86 (might work again with
> Ron's fix; I gotta retry!).
>
> Over the last few days, I created a tool to convert Plan 9 a.out files to
> ELF (amd64 so far, RISC-V WIP), and I added Plan 9 a.out support for RISC-V
> to radare2. Those tools should help with the endeavor.
>
> I would be very happy to see some more support. I can read quite a lot of
> code, and I will have questions. Some I can answer myself with more or less
> effort, and some which I can only work through with a lot of patience and
> help.
>
> Postlude:
>
> Anyway, sorry for the very lengthy email. I am not much of an email person
> anyway, so please bear with me should you reply and wait for my response.
> Thank you! 🧡
>
> With all that, have a good day!
------------------------------------------
9fans: 9fans
Permalink: https://9fans.topicbox.com/groups/9fans/Tf84d656c78bbda91-M8740a0295220c8c83d434c90
Delivery options: https://9fans.topicbox.com/groups/9fans/subscription
[-- Attachment #2: Type: text/html, Size: 8224 bytes --]
^ permalink raw reply [flat|nested] 10+ messages in thread
* Re: [9fans] The Big Questioning: Plan 9 everywhere?
[not found] ` <0647a4e1-4354-4447-ab79-9b5e3084d57b@app.fastmail.com>
@ 2025-06-06 6:16 ` adventures in9
2025-06-06 7:20 ` Daniel Maslowski via 9fans
2025-06-07 10:07 ` sirjofri via 9fans
2 siblings, 0 replies; 10+ messages in thread
From: adventures in9 @ 2025-06-06 6:16 UTC (permalink / raw)
To: 9fans
On Thu, Jun 5, 2025 at 3:44 PM <vester.thacker@fastmail.fm> wrote:
> 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.
If there is a "user interface" for Plan 9, it is the namespace.
Anything after that is just decoration.
All rio does is provide a blue-green border and an rc shell to a namespace.
Lets me move it around the screen with other namespaces.
And everything speaking 9P means nothing is tied to being centric to anything.
I routinely have windows open in rio that incorporate stuff from
devices connected to raspberry pis, or wifi routers, or remote file
systems.
I also have a soft spot for the BeOS/Haiku interface.
A small tab on the windows and a button with a clock in the corner is
about all I would really want.
But I certainly don't want something that limits me to a single user
and the resources of a single computer.
------------------------------------------
9fans: 9fans
Permalink: https://9fans.topicbox.com/groups/9fans/Tf84d656c78bbda91-M1e31ccbbe0199bf82693f26d
Delivery options: https://9fans.topicbox.com/groups/9fans/subscription
^ permalink raw reply [flat|nested] 10+ messages in thread
* Re: [9fans] The Big Questioning: Plan 9 everywhere?
[not found] ` <0647a4e1-4354-4447-ab79-9b5e3084d57b@app.fastmail.com>
2025-06-06 6:16 ` adventures in9
@ 2025-06-06 7:20 ` Daniel Maslowski via 9fans
2025-06-07 10:07 ` sirjofri via 9fans
2 siblings, 0 replies; 10+ messages in thread
From: Daniel Maslowski via 9fans @ 2025-06-06 7:20 UTC (permalink / raw)
To: 9fans
[-- Attachment #1: Type: text/plain, Size: 7474 bytes --]
Just to be clear here: I do not mean to move toward GTK or similar, nor to
a complex UI in general. All I'm trying to get toward is adapting to modern
input and output devices. While I'm still working on the setup to make that
happen, I am trying to explain my thoughts and what I'm struggling with. It
is a chicken-and-egg issue. 🙂
Thank you for your elaborate explanation. It confirms a lot of my
understanding. Especially the distributed nature of the OS is what peaked
my interest.
At IWP9 2024, I tried to convey my thoughts around the development of
machines that resulted in each of us having more than one machine, and I
still think the Plan 9 model would fit well into this world and would allow
us to connect them all. Moody is right that putting that into practice
would mean tons of work especially in terms of drivers.
As I wrote, I do that sort of hackery a lot, and so I know that running a
very basic system that only works with a serial suffices to get going.
Adding a single additional channel for communication enables driving
anything remotely then, such as USB via its gadget feature, as Gorda also
suggested at IWP9 2025. And I would like to e.g. drive another machine's
screen remotely. It isn't too hard, I have a PoC for that already.
On Fri, 6 Jun 2025, 00:44 , <vester.thacker@fastmail.fm> wrote:
> 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-M3979a2a878f875364c18871a
Delivery options: https://9fans.topicbox.com/groups/9fans/subscription
[-- Attachment #2: Type: text/html, Size: 9396 bytes --]
^ permalink raw reply [flat|nested] 10+ messages in thread
* Re: [9fans] The Big Questioning: Plan 9 everywhere?
[not found] ` <0647a4e1-4354-4447-ab79-9b5e3084d57b@app.fastmail.com>
2025-06-06 6:16 ` adventures in9
2025-06-06 7:20 ` Daniel Maslowski via 9fans
@ 2025-06-07 10:07 ` sirjofri via 9fans
2025-06-09 6:26 ` Lucio De Re
2 siblings, 1 reply; 10+ messages in thread
From: sirjofri via 9fans @ 2025-06-07 10:07 UTC (permalink / raw)
To: 9fans
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
^ permalink raw reply [flat|nested] 10+ messages in thread
* Re: [9fans] The Big Questioning: Plan 9 everywhere?
2025-06-07 10:07 ` sirjofri via 9fans
@ 2025-06-09 6:26 ` Lucio De Re
2025-06-09 16:46 ` adventures in9
2025-06-09 18:52 ` sirjofri via 9fans
0 siblings, 2 replies; 10+ messages in thread
From: Lucio De Re @ 2025-06-09 6:26 UTC (permalink / raw)
To: 9fans
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 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-M80379190c8004ca867bc6726
Delivery options: https://9fans.topicbox.com/groups/9fans/subscription
^ permalink raw reply [flat|nested] 10+ messages in thread
* Re: [9fans] The Big Questioning: Plan 9 everywhere?
2025-06-09 6:26 ` Lucio De Re
@ 2025-06-09 16:46 ` adventures in9
2025-06-09 18:09 ` Re[2]: " Alexandr Babic
2025-06-09 18:52 ` sirjofri via 9fans
1 sibling, 1 reply; 10+ messages in thread
From: adventures in9 @ 2025-06-09 16:46 UTC (permalink / raw)
To: 9fans
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 <lucio.dere@gmail.com> 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 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-M392ad342775e5f35b22f0633
Delivery options: https://9fans.topicbox.com/groups/9fans/subscription
^ permalink raw reply [flat|nested] 10+ messages in thread
* Re[2]: [9fans] The Big Questioning: Plan 9 everywhere?
2025-06-09 16:46 ` adventures in9
@ 2025-06-09 18:09 ` Alexandr Babic
0 siblings, 0 replies; 10+ messages in thread
From: Alexandr Babic @ 2025-06-09 18:09 UTC (permalink / raw)
To: 9fans
hello.
that's nice and i like it, the idea you can do gui action which has simple mapping to filesystem action.
i was thinking about connecting rio windows with arrows that it works like pipe and the functionality is simple filesystem action like connecting standard output of a program in one window to standard input of program running in another window.
i don't like complex gui actions, i prefer simple rio, acme functionality.
br, alex (alex@plan9.cz)
----- Původní zpráva -----
Odesilatel: adventures in9 (adventuresin9@gmail.com)
Datum: 06/09/25 19:31
Příjemce: 9fans (9fans@9fans.net)
Předmět: Re: [9fans] The Big Questioning: Plan 9 everywhere?
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 <lucio.dere@gmail.com> 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 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-Mb8d1c8c3062baaed0463b8f3
Delivery options: https://9fans.topicbox.com/groups/9fans/subscription
^ permalink raw reply [flat|nested] 10+ messages in thread
* Re: [9fans] The Big Questioning: Plan 9 everywhere?
2025-06-09 6:26 ` Lucio De Re
2025-06-09 16:46 ` adventures in9
@ 2025-06-09 18:52 ` sirjofri via 9fans
1 sibling, 0 replies; 10+ messages in thread
From: sirjofri via 9fans @ 2025-06-09 18:52 UTC (permalink / raw)
To: 9fans
09.06.2025 14:39:50 Lucio De Re <lucio.dere@gmail.com>:
> 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.
Independent of the general Plan 9 design (the "which"), I believe the interfaces on Plan 9 systems (the "how") are mostly the filesystems.
Like, the filesystems and their specific structures are the API implementation. The specification of those interfaces is often enough only vaguely described in the man pages, and most specifically in the source code. If I look at other API documentations, I believe there is still room for improvement.
Regarding everything else you wrote, the idea of Plan 9 is quite simple, I think: every resource can be abstracted as a filesystem, and thus be presented in a namespace. The challenge is to actually do the work of designing that abstraction.
sirjofri
------------------------------------------
9fans: 9fans
Permalink: https://9fans.topicbox.com/groups/9fans/Tf84d656c78bbda91-M7f9b9ad40965bfcb679a435e
Delivery options: https://9fans.topicbox.com/groups/9fans/subscription
^ permalink raw reply [flat|nested] 10+ messages in thread
end of thread, other threads:[~2025-06-09 19:40 UTC | newest]
Thread overview: 10+ messages (download: mbox.gz / follow: Atom feed)
-- links below jump to the message on this page --
[not found] <CAJCpOFxsQrW5v_jrEPX7tuy+uin2h32ADFchti7Vk1RL=OxxnQ@mail.gmail.com>
2025-06-05 15:35 ` [9fans] The Big Questioning: Plan 9 everywhere? Jacob Moody
[not found] ` <CAJCpOFy=_HNk+hnusKu=TWK2B=kTuhJtCXBw1kB8hJSURh10Qw@mail.gmail.com>
2025-06-05 18:39 ` Jacob Moody
[not found] ` <CAJCpOFwnfDeoCQ1mWQLy_Ntn+2boNxxFSqwf8thY5mDFKXER3g@mail.gmail.com>
[not found] ` <0647a4e1-4354-4447-ab79-9b5e3084d57b@app.fastmail.com>
2025-06-06 6:16 ` adventures in9
2025-06-06 7:20 ` Daniel Maslowski via 9fans
2025-06-07 10:07 ` sirjofri via 9fans
2025-06-09 6:26 ` Lucio De Re
2025-06-09 16:46 ` adventures in9
2025-06-09 18:09 ` Re[2]: " Alexandr Babic
2025-06-09 18:52 ` sirjofri via 9fans
2025-06-06 4:08 ` Adrian
This is a public inbox, see mirroring instructions
for how to clone and mirror all data and code used for this inbox;
as well as URLs for NNTP newsgroup(s).