(On mobile, so I'll add the link later, but http://taoofmac.com/space/os/Plan9 has my notes)
(On mobile, so I'll add the link later, but http://taoofmac.com/space/os/Plan9 has my notes)
You can think of a cpu server as being similar to this scenario: you ssh to a fast box, and run an app on that remote machine. However, due to the elegance of the plan9 architecture, instead of having the app run in the terminal window or over a laborious x-windows protocol, it writes quickly over the network to the window that you invoked the command from.
Unlike the unix experience, cross-compiling is trivial in this environment. Hence, it's fine to run varying architectures in the same system. Setting up a Raspberry Pi terminal is easy and cheap.
Some might ask - why? My motive: I see it as a different approach to software development. Instead of bolting monolithic systems together, I'll be able to implement platforms as devices that are exposed over 9p. Consider how much easier it is to do init for multi-host applications. Convential unix approach is and ugly spaghetti of scripts+ssh. In this design, just mount the apps and script them from one host. The network becomes transparent: you just script against devices.
I don't understand the distinction you are trying to make with the phrsase "quickly over the network". SSH and networked X aren't exactly slow. The latter can be a slug with a bad network, but I recently had to do something kind of fringe and ended up running firefox over wifi with ssh -Y, and it was usable.
You can argue that protocols, implementation, API, etc. are better with plan9 (consistent with claims I heard before) but I don't totally understand how that would necessarily translate into performance (if anything I would expect things used by more people over more time would be better tuned).
X is simply awful over the WAN, trust me. Please note: I'm not talking about an essentially text-only experience like xterm, which works fine. I mean actually using X as a graphical client.
There are at least one X extension out there that offer compression for long distance connections. But for some reason they never really took off.
See http://keithp.com/~keithp/talks/usenix2003/html/net.html and http://vis.lbl.gov/Events/SC08/RemoteX/index.html for more details.
As it relates to the original topic I'd be interested to see real-world performance comparisons between Plan 9 and X because as the papers state X stinks on ice over the WAN.
I am not located in the US, but hopping borders in europe does not seem to be a problem. It's less of a problem than with X-forwarding or VNC.
As for regular fs mounts (note that a remote control session on plan9 is actually also just a regular fs mount), I mount things from the US every once in a while, and I am located in Sweden. It's obviously not fast due to very high latency and limited bandwidth, but it works just fine within those constraints.
But of course, if the RTT >1 second, then it will take >1 second for a keystroke to show up on screen in a remote control session. You cannot be resistant to this (mosh tries to guess how things would look if the keystrokes had gone through, which is a major hack, and not really an issue).