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.

That is a very nice explanation. Thankyou!

> 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 2. https://man.9front.org/3/mouse (2nd to last paragraph)

> 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.