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

51–55 of 55 posts

Re: Why Plan 9? (2001)

#51

Post by joushou »

cturner wrote: post #50
joushou wrote: post #46

Earlier quoted context omitted.

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

No, I was talking about WAN, not LAN. (Note that 9front's fork of drawterm is a lot faster than the normal version - a regular drawterm can be a bit slow)

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

Re: Why Plan 9? (2001)

#52

Post by jacquesm »

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…

This abstraction works fantastically well in QnX, a system used in production the world over so I see absolutely no reason why it wouldn't work in plan9.

Re: Why Plan 9? (2001)

#53

Post by derefr »

joushou wrote: post #45
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 li…

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

Re: Why Plan 9? (2001)

#54

Post by joushou »

derefr wrote: post #53
joushou wrote: post #45

Earlier quoted context omitted.

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

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

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.

Re: Why Plan 9? (2001)

#55

Post by joushou »

madmax96 wrote: post #23
hollerith wrote: post #19

Earlier quoted context omitted.

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

And Plan 9 will never have more than 1000 users because it can't get a web browser to deliver a satisfactory experience. It's a horrible chicken-and-egg thing.

Which is a great thing, as we can then focus on what matters/we care about. Normal people are annoying, and tend to be demanding. :)
Post reply on HN