
Why Plan 9? (2001) - _acme
http://marc.info/?l=9fans&m=111558822710356&w=2
======
rcarmo
Incidentally, the Raspberry Pi image was recently updated and has better
multi-core support. Pretty nice for a near-instant boot terminal, although the
non-UNIXness of it becomes a little bit grating when trying to remember how to
SSH in a hurry.

(On mobile, so I'll add the link later, but
[http://taoofmac.com/space/os/Plan9](http://taoofmac.com/space/os/Plan9) has
my notes)

~~~
cturner
More on Raspberry Pi port in case others are interested. Raspberry Pi port is
interesting, because it allows us to run plan9 on native hardware (access
keyboard, mouse, video and probably audio - haven't checked). It doesn't
matter that there isn't much power in it, because plan9 is designed to be
distributed. Once you have a terminal, you can set up a cpu server and file
server to run under a linux hypervisor in the same network.

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.

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

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

~~~
technofiend
Oh, God. Are you serious? Listen try sitting in Texas some time and opening a
X application even over a compressed SSH link from Delaware. It literally
takes minutes for a splash screen to paint. And using applications are nearly
impossible due to interaction lag. You're better off using a VMware console,
RDP heck even Citrix which at one time was itself supposedly X based.

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.

~~~
digi_owl
The problem there is not so much X, as software devs not using X but instead
just painting everything into "image" that is then dumped into X. This means
you are effectively looking at what amounts of a VNC session, without the
benefit of compression.

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.

~~~
technofiend
I did mention compression of the X session itself by way of compressing the
SSH tunnel. The problems run deeper than "software devs just painting
everthing into image". X itself has a mix of synchronous and asynchronous
calls that are very sensitive to latency. XCB instead Xlib and use of LBX can
help but do not eliminate the performance issues with X Window.

See
[http://keithp.com/~keithp/talks/usenix2003/html/net.html](http://keithp.com/~keithp/talks/usenix2003/html/net.html)
and
[http://vis.lbl.gov/Events/SC08/RemoteX/index.html](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.

------
pedrocr
_> Finally, Plan 9 fits well with a networked environment. Since files or
directory trees can be imported from other machines, and all resources are
files or directory trees, it's easy to share resources. Want to use a
different machine's sound card? Import its /dev/audio. Want to debug processes
that run on another machine? Import its /proc. Want to use a network interface
on another machine? Import its /net. And so on._

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?

~~~
joushou
The 9P protocol is designed to deal with arbitrary blocking, as synthetic
filesystems commonly block reads until some data is present. There are also
automatic reconnection proxies (aan), and when a mountpoint is entirely
unresponsive (lost connectivity), you can just unmount it. The pending calls
will all fail gracefully.

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.

~~~
derefr
> how do you unmount without being able to read the binary

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.

~~~
joushou
What's your definition of embedded? It's not embedded if you're running a full
blown OS on a regular ARM chip.

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.

------
Koshkin
I found that the web browser that comes with Inferno, which is a very
interesting variant (not a distribution) of Plan9, is quite a bit better than
the one found in the "original" Plan9. Inferno is amazing in its own right and
is worth having a look at.

~~~
Esau
I've never really understood Inferno. Sometimes it is described as something
you run from a browse and others as a standalone OS. Which is it?

~~~
koenigdavidmj
The userspace is compiled to something kind of like Java byte code, that runs
in a VM. A hardware kernel exists that provides this VM, but it also has
implementations that run in userspace on the big three OSes.

------
cm3
[http://harvey-os.org/news/#clang-intel-c-compiler-apex-
and-z...](http://harvey-os.org/news/#clang-intel-c-compiler-apex-and-zfs)

------
krmboya
Some may find the plain text version easier to read:

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

------
cm3
It's great terminal emulation doesn't exist in Plan9, but with that you lose
99% of terminal application functionality, especially curses.

~~~
dmm
People tend to conflate the concept of text based interfaces with terminals
and curses but it's possible to have text interfaces without curses. Most plan
9 applications have text interfaces but do not use terminals.

~~~
cm3
What's the curses equivalent?

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

~~~
dmm
Windows in plan 9 are images that are drawn to. There are libraries for
drawing fonts and various shapes.

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](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/window) [http://plan9.bell-
labs.com/magic/man2html/2/graphics](http://plan9.bell-
labs.com/magic/man2html/2/graphics) [http://plan9.bell-
labs.com/magic/man2html/2/draw](http://plan9.bell-
labs.com/magic/man2html/2/draw)

~~~
cm3
Thanks for the long reply, though I must admit I'm aware of all that. I was
hoping for some surprise information.

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.

------
softinio
Is there a usable version of plan9 we can install?

~~~
cturner
Couple of options: Raspberry Pi, or virtualisation.

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

~~~
swiley
Qemu is a thousand times better if your OS has KVM support. Especially for
running terminals since the only files you'll need are plan9.ini (a short text
file) and 9pcf (the terminal kernel). You don't even have to set up a disk
image, it just mounts root from your file server and you have everything ready
to go!

