3 ms·

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

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

by cturner 10y ago

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