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

Does this kind of abstraction actually work well? Networks are generally quite unreliable so does it really work well to treat everything as files even when the latency can be so different depending on if the resource is local or remote? Do the plan9 APIs make it natural to write code that deals well with random blocking when reading/writing to files?

It may generally be less likely to encounter disk read errors than it is to encounter network timeouts, but both will eventually occur.

The abstraction works well. The main issue is when you lose access to your root device. Just like if you booted a Linux machine from NFS, the root disk connection must be stable (how do you unmount without being able to read the binary). All other mounts can be arbitrarily flakey.

We have enough RAM now that there's no reason (even on embedded devices!) to ever unload the initrd/initramfs. An OS should be able to be configured such that you can unmount your rootfs whenever you like, and just automatically be de-pivot-root'ed and end up back in your initramfs, where you can mount the rootfs again.

Anyway, you could make a ramdisk, put things in it and put it in your path. I doubt that a linux box will survive a dead root without hardcore sysadm skills, but it should work on plan9. Initrd is not meant to stay behind after boot, though.

For what it's worth, anything that does more than just print to stdout breaks in 9term.

Another thing that get conflated with text interfaces is keyboard control. For whatever reason the plan 9 developers were very adverse to this and preferred mouse based interaction.

Anyway plan 9 is interesting because of how it's different. If you're approaching it asking "Where's emacs and vim?" or "Why can't I get my shell history by pressing up?" you're probably not getting the full value out of it. Part of the problem is probably that it's close enough to unix to make people put unix expectations on it.

Here's a video about acme, a programmer's interface for plan 9.

https://news.ycombinator.com/item?id=4533156

Check out these man pages. http://plan9.bell-labs.com/magic/man2html/2/window http://plan9.bell-labs.com/magic/man2html/2/graphics http://plan9.bell-labs.com/magic/man2html/2/draw

Your comment of it seeming like Unix might be the key point to take away. I know that I'm supposed to search in the buffer for history and use the mouse to select and rerun it, but having tried it multiple times, I cannot get comfortable with a mutable terminal buffer. That's also why in Emacs I only use term and not the editable terminals. Maybe one day I'll get comfortable.

Again, the vt terminal emulator is available if you want vim over ssh.

Also note that there is vt (at least on 9front), a terminal emulator for plan9, if you really want to use such applications. There's ssh too, if you need it.

An out of the box installation is hardly better than UNIX System V.

[1] http://plan9.bell-labs.com/magic/man2html/1/vt

Your question suggests to me that you still don't get it: nothing in Plan 9 -- not the shell, not the ability to issue command lines and get stdout and stderr back -- depends on vt(1). vt(1) is used only to communicate with (tty drivers on) other OSes, over the network.

Just as most of time, a user of OS X has no need for an X server, most of the time, a Plan 9 user has no need for vt(1) or for ncurses.

I'm not suggesting you give Plan 9 a try BTW: on its best day ever, it had fewer than 1000 users, and if it was ever going to break 1000 users, it would have done so by now. The whole OS (excluding some fonts) has been available under an OSI- FSF- and DFSG-approved license since 2002.

So for example, Plan 9 will almost certainly never have a web browser capable a delivering a satisfactory experience on more than half of the 1000 most popular web sites -- because porting such a web browser to Plan 9 would cost 10s of millions of dollars in programmer time, and no one is going to spend that money to get fewer than 1000 new users.

It's a horrible chicken-and-egg thing.

9front say to avoid virtualbox, but it works. Here's a tutorial, https://www.youtube.com/watch?v=n5XAhsHyqow

Is the image for the Rasperry Pi. Is said to be working with Pi 0/1/2.

Has be a quite frustrating experience for me. I recommend to run it on qemu or virtual box. 9vx is the coolest way to run plan 9 (it's thin virtualisation layer that allows access to the host) but it does not seem to work 9front.

https://marc.info/?l=9fans&m=111558822710356&q=raw