8 ms·

Why Plan 9? (2001)

102 points by _acme 10y ago

cm3 10y ago
http://harvey-os.org/news/#clang-intel-c-compiler-apex-and-zfs http://harvey-os.org/news/#clang-intel-c-compiler-apex-and-z...
rcarmo 10y ago
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)
- _acme 10y ago
  It's available at http://plan9.bell-labs.com/sources/contrib/miller/ http://plan9.bell-labs.com/sources/contrib/miller/.
  - rcarmo 10y ago
    Thanks!
- cturner 10y ago
  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 10y ago
    > 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).
    - cturner 10y ago
      Thanks for the corrections. There are many reasons to dislike X, but sounds like speed isn't one.
    - technofiend 10y ago
      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 10y ago
        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.
cm3 10y ago
It's great terminal emulation doesn't exist in Plan9, but with that you lose 99% of terminal application functionality, especially curses.
- wtbob 10y ago
  There's an emulator, IIRC.
  - cm3 10y ago
    Do you mean Plan9's terminal? If so, the whole point of it is that it's not constrained to emulating TTY.
    - wtbob 10y ago
      vt(1) [1] is a terminal emulator installed on Plan 9 which can emulate a vt100 for any program which needs it. So you have something which can give you curses if you want it. [1] http://plan9.bell-labs.com/magic/man2html/1/vt http://plan9.bell-labs.com/magic/man2html/1/vt
      - cm3 10y ago
        Cool, hadn't seen that before. Unfortunately, doesn't seem to be in plan9port.
        hollerith 10y ago
        That's because the OSes on which plan9port runs already have plenty of apps that can emulate a vt100. 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.
softinio 10y ago
Is there a usable version of plan9 we can install?
- ori_b 10y ago
  9front.org
- cturner 10y ago
  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 10y ago
    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!
  - 1ris 10y ago
    http://plan9.bell-labs.com/sources/contrib/miller/9pi.img.gz http://plan9.bell-labs.com/sources/contrib/miller/9pi.img.gz 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.
- jpm9 10y ago
  9front runs on virtual machine and on hardware just fine.
Koshkin 10y ago
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 10y ago
  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 10y ago
    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.
krmboya 10y ago
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
pedrocr 10y ago
> 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?
- dleslie 10y ago
  I've not used Plan9; but one ought to consider that any IO may not be successful, and this is regardless of the device. It may generally be less likely to encounter disk read errors than it is to encounter network timeouts, but both will eventually occur.
- joushou 10y ago
  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 10y ago
    > 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.

Why Plan 9? (2001)

102 points by _acme 10y ago

cm3 10y ago

http://harvey-os.org/news/#clang-intel-c-compiler-apex-and-zfs http://harvey-os.org/news/#clang-intel-c-compiler-apex-and-z...

rcarmo 10y ago

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)

_acme 10y ago
It's available at http://plan9.bell-labs.com/sources/contrib/miller/ http://plan9.bell-labs.com/sources/contrib/miller/.
- rcarmo 10y ago
  Thanks!
cturner 10y ago
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 10y ago
  > 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).
  - cturner 10y ago
    Thanks for the corrections. There are many reasons to dislike X, but sounds like speed isn't one.
  - technofiend 10y ago
    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 10y ago
      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.

cm3 10y ago

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

wtbob 10y ago
There's an emulator, IIRC.
- cm3 10y ago
  Do you mean Plan9's terminal? If so, the whole point of it is that it's not constrained to emulating TTY.
  - wtbob 10y ago
    vt(1) [1] is a terminal emulator installed on Plan 9 which can emulate a vt100 for any program which needs it. So you have something which can give you curses if you want it. [1] http://plan9.bell-labs.com/magic/man2html/1/vt http://plan9.bell-labs.com/magic/man2html/1/vt
    - cm3 10y ago
      Cool, hadn't seen that before. Unfortunately, doesn't seem to be in plan9port.
      - hollerith 10y ago
        That's because the OSes on which plan9port runs already have plenty of apps that can emulate a vt100. 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.

softinio 10y ago

Is there a usable version of plan9 we can install?

ori_b 10y ago
9front.org
cturner 10y ago
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 10y ago
  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!
- 1ris 10y ago
  http://plan9.bell-labs.com/sources/contrib/miller/9pi.img.gz http://plan9.bell-labs.com/sources/contrib/miller/9pi.img.gz 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.
jpm9 10y ago
9front runs on virtual machine and on hardware just fine.

Koshkin 10y ago

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 10y ago
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 10y ago
  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.

krmboya 10y ago

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

pedrocr 10y ago

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

dleslie 10y ago
I've not used Plan9; but one ought to consider that any IO may not be successful, and this is regardless of the device. It may generally be less likely to encounter disk read errors than it is to encounter network timeouts, but both will eventually occur.
joushou 10y ago
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 10y ago
  > 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.