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

31–40 of 55 posts

Re: Why Plan 9? (2001)

#31

Post by TurboHaskal »

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.

mothra(1) delivers

Re: Why Plan 9? (2001)

#32

Post by cturner »

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.

There is a potential path. Someone builds a killer app that uses a 9p mechanism to deliver content, or else a better experience for an existing app. With this done, a browser decides to implement drawterm as a browser mode. Once you had that, it could start challenging html/css/javascript.

Re: Why Plan 9? (2001)

#33

Post by digi_owl »

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…

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.

Re: Why Plan 9? (2001)

#34

Post by paulryanrogers »

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…

Nomachine worked reasonably well for me cities apart. I believe it was adding some compression to X at the time; circa 2011.

Re: Why Plan 9? (2001)

#35

Post by gkya »

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.

Curses has nothing to do with the unix philosophy, and "terminal application" should not be confused with what is actually characteristic of unix: its IPC and IO model, and its possibilities for composing programmes through those. The fact that you most often utilise these features through a terminal emulator that runs a shell does not mean that curses and the ilk are essential to unix because they happen to draw interfaces in those terminal emulators. Curses it not more or less unixy than any other windowing/UI-widget library.

Re: Why Plan 9? (2001)

#36

Post by cm3 »

gkya wrote: post #35
cm3 wrote: post #7

Earlier quoted context omitted.

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

Curses has nothing to do with the unix philosophy, and "terminal application" should not be confused with what is actually characteristic of unix: its IPC and IO model, and its possibilities for composing programmes through those. The fact that you most often utilise these features through a terminal emulator that runs a shell does not mean that curses and the ilk are essential to unix because they happen to draw int…

I don't understand what you're replying to. I didn't say curses==unix. Most terminal based applications use curses, therefore the lack of it limits the pool of applications.

Re: Why Plan 9? (2001)

#37

Post by Esau »

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?

Re: Why Plan 9? (2001)

#38

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

Re: Why Plan 9? (2001)

#39

Post by Esau »

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.

Re: Why Plan 9? (2001)

#40

Post by dleslie »

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…

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.

Post reply on HN