3 ms·

So that would be 'rio'?[0] I can find screenshots but haven't found much that explains how or why it's different -- what I've read explains it's not how it look

So that would be 'rio'?[0] I can find screenshots but haven't found much that explains how or why it's different -- what I've read explains it's not how it looks so much as how it functions, eg, each process genuinely own a console or mouse rather than getting events from the OS as you might in, say, Windows. I can't tell if I am understanding this correctly, of course. I do know that in Plan9, 'everything is a file' is literally correct. So owning a mouse would mean reading from /path/to/mouse. But what I've also read is that every process can do so believing they own it - it's theirs exclusively? For anyone reading this comment in future please do not trust it, I don't know what I'm talking about, except that standard references I've found don't fully explain. [0] https://en.wikipedia.org/wiki/Plan_9_from_Bell_Labs#Graphical_programs https://en.wikipedia.org/wiki/Plan_9_from_Bell_Labs#Graphica...

bitwize 2mo ago
What I think you're referring to is, every process has its own view of the file system. So you can control what a process has access to simply by controlling what the file tree visible to it looks like. The upshot of this is that each process talking to rio can open a file called '/dev/draw' if it wants to draw to its window, but each process sees its own '/dev/draw' and can thereby only draw to its own window! This can't be done very well in a POSIX OS, for which the file system namespace is global; extensions like Linux containers are a (shitty) workaround for this flaw.
- vintagedave 2mo ago
  That is a very nice explanation. Thankyou!
MisterTea 2mo ago
> I do know that in Plan9, 'everything is a file' is literally correct. Almost correct. There are also shared memory segments via segment(3). You segattach(2) to a segment from a user space process then read/write that memory as a file from a user space process [1]. Drivers can expose memory mapped IO (e.g. PCI cards) using a physical segment and segattach to that from a user space process. The vga(8) program does this to do low level register tweaking. Sometimes, a file server is either too tedious, or not the right abstraction. It also enables memory sharing between processes and user space programs. You can share it over the network with rexport(1) but it gets weird (networked PCI/RAM out of the box...) > So owning a mouse would mean reading from /path/to/mouse. But what I've also read is that every process can do so believing they own it - it's theirs exclusively? Rio and other window managers like Lola, multiplex it [2]. This is how each window only sees the mouse when the cursor is within its border window. If I open two windows and run 'cat /dev/mouse' in each window then move the mouse around, cat only outputs data when the mouse is over the window it's running in. 1. https://man.9front.org/3/segment https://man.9front.org/3/segment 2. https://man.9front.org/3/mouse https://man.9front.org/3/mouse (2nd to last paragraph)
lproven 2mo ago
> haven't found much that explains how or why it's different Windows are directories in the filesystem. Their properties are files inside it. Modify the file, the window changes. This means that to open a window on another machine is trivial. Machine A mounts the relevant part of the filesystem on Machine B over the kernel's integrated 9p networking stack, then creates and populates a folder, and now the window is on the other machine. No "servers" or "clients", no special network protocols, works locally or across the planet, according to appropriate permissions of course. Definitely no need for Windows-like crude hacks such as VNC or RDP.

bitwize 2mo ago

What I think you're referring to is, every process has its own view of the file system. So you can control what a process has access to simply by controlling what the file tree visible to it looks like. The upshot of this is that each process talking to rio can open a file called '/dev/draw' if it wants to draw to its window, but each process sees its own '/dev/draw' and can thereby only draw to its own window! This can't be done very well in a POSIX OS, for which the file system namespace is global; extensions like Linux containers are a (shitty) workaround for this flaw.

vintagedave 2mo ago
That is a very nice explanation. Thankyou!

MisterTea 2mo ago

> I do know that in Plan9, 'everything is a file' is literally correct. Almost correct. There are also shared memory segments via segment(3). You segattach(2) to a segment from a user space process then read/write that memory as a file from a user space process [1]. Drivers can expose memory mapped IO (e.g. PCI cards) using a physical segment and segattach to that from a user space process. The vga(8) program does this to do low level register tweaking. Sometimes, a file server is either too tedious, or not the right abstraction. It also enables memory sharing between processes and user space programs. You can share it over the network with rexport(1) but it gets weird (networked PCI/RAM out of the box...) > So owning a mouse would mean reading from /path/to/mouse. But what I've also read is that every process can do so believing they own it - it's theirs exclusively? Rio and other window managers like Lola, multiplex it [2]. This is how each window only sees the mouse when the cursor is within its border window. If I open two windows and run 'cat /dev/mouse' in each window then move the mouse around, cat only outputs data when the mouse is over the window it's running in. 1. https://man.9front.org/3/segment https://man.9front.org/3/segment 2. https://man.9front.org/3/mouse https://man.9front.org/3/mouse (2nd to last paragraph)

lproven 2mo ago

> haven't found much that explains how or why it's different Windows are directories in the filesystem. Their properties are files inside it. Modify the file, the window changes. This means that to open a window on another machine is trivial. Machine A mounts the relevant part of the filesystem on Machine B over the kernel's integrated 9p networking stack, then creates and populates a folder, and now the window is on the other machine. No "servers" or "clients", no special network protocols, works locally or across the planet, according to appropriate permissions of course. Definitely no need for Windows-like crude hacks such as VNC or RDP.