4 ms·

Forgive my ignorance - can anyone elaborate on what sorts of innovations came from Plan 9, and why it didn't overtake Unix? I'm intrigued, but I don't know anyt

Forgive my ignorance - can anyone elaborate on what sorts of innovations came from Plan 9, and why it didn't overtake Unix? I'm intrigued, but I don't know anything about it.

i80and 17y ago
I'm personally not all that familiar with it either, but I have read that it's a much cleaner and more modern equivalent to Unix, applying the "everything is a file" paradigm to far more. In Unix, a lot of behavior got tied into ioctl and binary sockets as the need for additional features grew. Plan 9 is far more file-oriented and textual in its interfaces, and relies more on file servers (i.e. eschewing an ftp command for an ftpfs filesystem). ESR believes that it may have died just because Unix was "good enough", which sounds reasonably plausible to me. If someone else knows more, I would also be very interested.
suraj 17y ago
Wikipedia (http://en.wikipedia.org/wiki/Plan_9_from_Bell_Labs http://en.wikipedia.org/wiki/Plan_9_from_Bell_Labs) article is a good start. Most notably the /proc filesystem which represents the state of kernel was lifted straight from Plan 9 into Linux. As for the success of Plan 9, this quote on wikipedia sums it up - Plan 9 failed simply because it fell short of being a compelling enough improvement on Unix to displace its ancestor. Compared to Plan 9, Unix creaks and clanks and has obvious rust spots, but it gets the job done well enough to hold its position. There is a lesson here for ambitious system architects: the most dangerous enemy of a better solution is an existing codebase that is just good enough.
- elblanco 17y ago
  >the most dangerous enemy of a better solution is an existing codebase that is just good enough. These are words of wisdom for anybody that doesn't understand how Windows came to be the dominant desktop OS.
gchpaco 17y ago
That's a very large question, but I'll take a stab at a quick summary. - All resources in Plan 9 are accessed through the file system. Want to get a screenshot? Read from /dev/window. Want to get access a file on a machine halfway around the world? Mount it on your file system. Want to interrogate the kernel, or change things? /proc. (this last bit has been ported to Linux and other Unixes; only greybeards tend to remember the days when ps had to be setuid root) - (almost) all resources are textual. None of this business of sending obscure bits to ioctl; if you want your connection to be a certain baud, you open the appropriate "file" and tell it so. - Related: none of this connect, bind, nonsense. You want network sockets? Open stuff in /net. - There is no one single "file system", unlike in Unix. When you are running in a 9term, /dev/cons is the console. When you are typing in a different 9term, it's still reading from /dev/cons but it's a different /dev/cons. It's possible for every program on the system to have a completely different view of the filesystem (although I doubt it's really sensible). Accordingly there's no superuser; there's only "permission to access X". - Union mount points. There's no /bin, /usr/bin, $HOME/bin, etc; everything is always in /bin. The system automatically makes /bin contain the executables that are most appropriate fro your processor; rc is always /bin/rc but on one machine it's MIPS code and on another it's x86 code. - A resulting truly distributed system. Typical use had you logging in from a network terminal (like an X terminal) and running jobs on a CPU server mostly transparently, there's disk servers you can mount, etc. I'm not 100% sure how this part works, because I've never been able to run it in the wild. - Plan 9 was designed with the intent of GUI stuff from the get go. There's no curses stuff, no console libraries; if you want to do that stuff, you use a GUI. But these GUIs were designed by folks who were very comfortable with using a command line, and so one ends up with huge amounts of text on screen that you interact with (the history mechanism for rc actually looks at the window buffer for the terminal it is running in, looking for prompts). There's an input language for mice, that's most obvious in acme (where cut and paste are done by mouse button chords). - As a result of this most of userland has been worked over, probably because somebody was forced to think seriously of reimplementing the Bourne shell. rc is remarkably minimal for a login shell in this day of zsh, and seems useless in an xterm; but because in a 9term you can edit previous output and previous command lines and tell the terminal not to send input at the end of a line but instead wait for you to decide you're finished it ends up being surprisingly powerful and usable. It's hard to get this in Unix because a lot of the tricks they did with it involve accessing the textual representation of the contents of the 9term and e.g. grepping over it or the like. Plan 9 from User Space does manage it and it's a very strange experience. - Unicode throughout, which doesn't seem like such a big deal now but was pretty significant back in 1992. - A bunch of fascinating programs written as a general solution to specific frustrations. Modern terminal replacements sometimes highlight URLs or the like; the Plan 9 plumber would do this with anything, and was consistently implemented across the system (Button 3 in recent acmes, for example, runs the plumber and only does local search if that fails to match). Plan 9 can be very disturbing to work with at first; everything seems incredibly primitive, and it has a very minimalist feel to it, but when you get used to the idioms it can be incredibly powerful. It's a pity they never wrote a real web browser for it, I would love to see what it would look like. The whole experience is very strange, and yet there's a certain elegance to it.

Forgive my ignorance - can anyone elaborate on what sorts of innovations came from Plan 9, and why it didn't overtake Unix? I'm intrigued, but I don't know anything about it.

i80and 17y ago

I'm personally not all that familiar with it either, but I have read that it's a much cleaner and more modern equivalent to Unix, applying the "everything is a file" paradigm to far more. In Unix, a lot of behavior got tied into ioctl and binary sockets as the need for additional features grew. Plan 9 is far more file-oriented and textual in its interfaces, and relies more on file servers (i.e. eschewing an ftp command for an ftpfs filesystem). ESR believes that it may have died just because Unix was "good enough", which sounds reasonably plausible to me. If someone else knows more, I would also be very interested.

suraj 17y ago

Wikipedia (http://en.wikipedia.org/wiki/Plan_9_from_Bell_Labs http://en.wikipedia.org/wiki/Plan_9_from_Bell_Labs) article is a good start. Most notably the /proc filesystem which represents the state of kernel was lifted straight from Plan 9 into Linux. As for the success of Plan 9, this quote on wikipedia sums it up - Plan 9 failed simply because it fell short of being a compelling enough improvement on Unix to displace its ancestor. Compared to Plan 9, Unix creaks and clanks and has obvious rust spots, but it gets the job done well enough to hold its position. There is a lesson here for ambitious system architects: the most dangerous enemy of a better solution is an existing codebase that is just good enough.

elblanco 17y ago
>the most dangerous enemy of a better solution is an existing codebase that is just good enough. These are words of wisdom for anybody that doesn't understand how Windows came to be the dominant desktop OS.

gchpaco 17y ago

That's a very large question, but I'll take a stab at a quick summary. - All resources in Plan 9 are accessed through the file system. Want to get a screenshot? Read from /dev/window. Want to get access a file on a machine halfway around the world? Mount it on your file system. Want to interrogate the kernel, or change things? /proc. (this last bit has been ported to Linux and other Unixes; only greybeards tend to remember the days when ps had to be setuid root) - (almost) all resources are textual. None of this business of sending obscure bits to ioctl; if you want your connection to be a certain baud, you open the appropriate "file" and tell it so. - Related: none of this connect, bind, nonsense. You want network sockets? Open stuff in /net. - There is no one single "file system", unlike in Unix. When you are running in a 9term, /dev/cons is the console. When you are typing in a different 9term, it's still reading from /dev/cons but it's a different /dev/cons. It's possible for every program on the system to have a completely different view of the filesystem (although I doubt it's really sensible). Accordingly there's no superuser; there's only "permission to access X". - Union mount points. There's no /bin, /usr/bin, $HOME/bin, etc; everything is always in /bin. The system automatically makes /bin contain the executables that are most appropriate fro your processor; rc is always /bin/rc but on one machine it's MIPS code and on another it's x86 code. - A resulting truly distributed system. Typical use had you logging in from a network terminal (like an X terminal) and running jobs on a CPU server mostly transparently, there's disk servers you can mount, etc. I'm not 100% sure how this part works, because I've never been able to run it in the wild. - Plan 9 was designed with the intent of GUI stuff from the get go. There's no curses stuff, no console libraries; if you want to do that stuff, you use a GUI. But these GUIs were designed by folks who were very comfortable with using a command line, and so one ends up with huge amounts of text on screen that you interact with (the history mechanism for rc actually looks at the window buffer for the terminal it is running in, looking for prompts). There's an input language for mice, that's most obvious in acme (where cut and paste are done by mouse button chords). - As a result of this most of userland has been worked over, probably because somebody was forced to think seriously of reimplementing the Bourne shell. rc is remarkably minimal for a login shell in this day of zsh, and seems useless in an xterm; but because in a 9term you can edit previous output and previous command lines and tell the terminal not to send input at the end of a line but instead wait for you to decide you're finished it ends up being surprisingly powerful and usable. It's hard to get this in Unix because a lot of the tricks they did with it involve accessing the textual representation of the contents of the 9term and e.g. grepping over it or the like. Plan 9 from User Space does manage it and it's a very strange experience. - Unicode throughout, which doesn't seem like such a big deal now but was pretty significant back in 1992. - A bunch of fascinating programs written as a general solution to specific frustrations. Modern terminal replacements sometimes highlight URLs or the like; the Plan 9 plumber would do this with anything, and was consistently implemented across the system (Button 3 in recent acmes, for example, runs the plumber and only does local search if that fails to match). Plan 9 can be very disturbing to work with at first; everything seems incredibly primitive, and it has a very minimalist feel to it, but when you get used to the idioms it can be incredibly powerful. It's a pity they never wrote a real web browser for it, I would love to see what it would look like. The whole experience is very strange, and yet there's a certain elegance to it.