Hacker News Board Hacker News, browsed like a classic message board
Live data from Hacker News

Why Plan 9? (2001)

marc.info

Post reply on HN
Print view View original

41–50 of 55 posts

Re: Why Plan 9? (2001)

#41

Post by renox »

technofiend wrote: post #30
asveikau wrote: post #18

Earlier quoted context omitted.

> 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 netwo…

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. P…

Does plan9 works well over a WAN? (Genuine question)

Re: Why Plan 9? (2001)

#42

Post by koenigdavidmj »

Esau wrote: post #37
Koshkin wrote: post #21

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.

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?

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.

Re: Why Plan 9? (2001)

#43

Post by technofiend »

digi_owl wrote: post #33
technofiend wrote: post #30

Earlier quoted context omitted.

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. P…

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.

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

Re: Why Plan 9? (2001)

#44

Post by pjmlp »

Esau wrote: post #39
cm3 wrote: post #4

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

When I ran Plan 9 inside of VMWare Fusion, the one thing I missed was Readline/Libedit. I honestly don't know how people did without them.

If you make use of a real UNIX, you will be surprised how many GNU and BSD goodies improve the usability.

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

Re: Why Plan 9? (2001)

#45

Post by joushou »

pedrocr wrote: post #38

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

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.

Re: Why Plan 9? (2001)

#46

Post by joushou »

renox wrote: post #41
technofiend wrote: post #30

Earlier quoted context omitted.

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. P…

Does plan9 works well over a WAN? (Genuine question)

Yes. For remote control, drawterm (a client to "cpu" into a plan9 box from a non-plan9 box) can even make the GUI feel local over poor connections (except if you try to play doom or something).

Re: Why Plan 9? (2001)

#47

Post by joushou »

cm3 wrote: post #4

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

What you lose is VT escape sequences, a hack to try to make TUI's when there was no alternative. In Plan9, your terminal windows naturally transition to be fully fledged GUI's when needed.

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.

Re: Why Plan 9? (2001)

#48

Post by joushou »

cm3 wrote: post #7
dmm wrote: post #6

Earlier quoted context omitted.

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.

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

devdraw, which is more of an X equivalent than curses, but oh well.

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

Re: Why Plan 9? (2001)

#49

Post by joushou »

joushou wrote: post #47
cm3 wrote: post #4

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

What you lose is VT escape sequences, a hack to try to make TUI's when there was no alternative. In Plan9, your terminal windows naturally transition to be fully fledged GUI's when needed. 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.

A thing I forgot to mention: this means that if you "cpu" into another host, you can run text based commands, but you can also start the browser, mothra, or even doom in the same window. There is no difference between telnet and x forwarding on plan9.

Re: Why Plan 9? (2001)

#50

Post by cturner »

joushou wrote: post #46
renox wrote: post #41

Earlier quoted context omitted.

Does plan9 works well over a WAN? (Genuine question)

Yes. For remote control, drawterm (a client to "cpu" into a plan9 box from a non-plan9 box) can even make the GUI feel local over poor connections (except if you try to play doom or something).

That's over a LAN. But what about over the distances earlier in the thread - the earlier example was a line across a significant bit of continental US. [More interesting still would be Sydney to London.]
Post reply on HN