9 ms·

Plan 9: The way the future was

197 points by niyazpk 15y ago

6ren 15y ago
Ugly now beats beautiful later. An elegant solution requires a deep understanding of a problem, and that understanding takes a lot of data (awareness of cases), and then a lot of time and effort to create a simple theory of it and to create a simple solution embodying that theory.
- bct 15y ago
  The trick is to build ugly systems that are able to grow into beautiful ones.
  - jff 15y ago
    That is quite a trick. The problem is that pretty soon, everyone depends on the behavior of the ugly warts in your original system, so now you're stuck with them lest you break the holy Compatibility.
    - deleted 15y ago
      [deleted]
wladimir 15y ago
It seems that (almost?) everything that was planned out for plan9 is finding its way into operating systems. The ideas were good, but somehow they had to take the long way around. It was way ahead of its time.
- _delirium 15y ago
  I remember an interview with one of the ex-Plan9 people now at Google (Rob Pike maybe?) talking about how he's switched to Linux, since that's what Google runs on, and finds it a strange experience, as if a bunch of bugs you thought you'd fixed 20 years ago have resurfaced in the main branch. But Linux does seem to be picking up a steady number of the features.
  - shimon_e 15y ago
    It was Rob Pike from the slashdot interview. http://interviews.slashdot.org/story/04/10/18/1153211/rob-pike-responds http://interviews.slashdot.org/story/04/10/18/1153211/rob-pi...
    - johncoltrane 15y ago
      Thanks for the link. (irrelevant: I like how he used wOOd to represent OO programming)
pavpanchekha 15y ago
First, one should note that this is a chapter (or section) of "The Art of Unix Programming", by esr; it is a fantastic book (I'm going through it now, on chapter 9 of 20, and the wisdom has been near-palpable). As for the specifics of the article. Plan 9 did indeed do many things right; in fact, many things are done in a very Unixy way. For example, the networking stack is build precisely where it ought to be: as a detail below a powerful network protocol (9P) which can be made as transparent or concrete as necessary (one can easily write individual TCP or UDP packets using the file system; just as easily, you can network-export any file system). Similarly, Plan 9's handling of security, in particular the elimination of the superuser, was fantastic. And while I in particular disagree with the approach Plan 9 takes to the GUI, it is certainly a consistent, powerful, and inspired model. And a variety of its other ideas, such as UTF-8 and the /proc and /sys file systems, have worked their way into modern Unixes such as Linux. Now, Plan 9's failure has been aptly explained elsewhere, in particular in the article linked. But, being somewhat old (2004, I believe; though when that particular section was written I do not know), it makes the prediction that Unixes will eventually come to absorb all of the Plan 9 features. Instead, it looks like the Linux kernel, at least, has mostly given up on ever implementing union mounts (one of the most inspired of Plan 9's innovations, at least in my view). And while the /net file system is incredibly useful, its power is much diminished when you can't assume that the world speaks 9P, which will seemingly never be the case. And a variety of Plan 9's choices are impossible without ignoring POSIX compatibility, which causes problems of its own. Unix rode the growth of servers in the seventies and eighties, and is by now rather entrenched (see the History chapter in Art of Unix Programming); much like the WIMP GUI metaphor rode the personal computing wave. I think both of these areas are by now too old and entrenched for us to simply replace the current monopolies there. And I've come to terms with the fact that Plan 9 will never, ever become the standard OS --- it is simply not designed for any battlegrounds except those it has already lost in. But I strongly urge anyone designing an OS (or, really, any sort of all-encompassing computer system) to look over the innovations and ideas of Plan 9. Luckily, I don't think anything like Windows or Unix will win in a totally new environment, because Windows and Unix aren't made for any environments but their own. So while Plan 9 never won, I think its ideas have a good chance of living on. And I await an exciting time of innovation in Operating Systems in the coming century.
jbarham 15y ago
Unsurprisingly given the common pedigree, a number of ideas from Plan 9 have made their way into Go. E.g., compare http://golang.org/pkg/net/#Dial http://golang.org/pkg/net/#Dial and http://plan9.bell-labs.com/magic/man2html/2/dial http://plan9.bell-labs.com/magic/man2html/2/dial. Go's approach to concurrency is familiar in the Plan 9 world from Alef (http://en.wikipedia.org/wiki/Alef_(programming_language) http://en.wikipedia.org/wiki/Alef_(programming_language), http://swtch.com/~rsc/thread/alef.pdf http://swtch.com/~rsc/thread/alef.pdf) and Limbo (http://www.vitanuova.com/inferno/papers/limbo.html http://www.vitanuova.com/inferno/papers/limbo.html), the language used to implement Inferno, a Plan 9 spinoff.
- dhconnelly 15y ago
  Cool. I wasn't sure if it was common knowledge that Ken Thompson and Rob Pike created Go. The Go compiler toolchain is from Plan 9, too: http://golang.org/cmd/ http://golang.org/cmd/.
thristian 15y ago
The impression I got was that the guys behind Unix were annoyed when their operating-systems research was stalled in the name of "API compatibility", so they started Plan 9 and actively resisted commercialisation for as long as possible (for example, they gave it the least marketable name they could think of). There's so many interesting ideas in Plan 9, I'm occasionally tempted to install it and try it out... but then I read things like the list of keyboard shortcuts in the standard editor acme¹, and I get cold feet. ¹: http://acme.cat-v.org/keyboard http://acme.cat-v.org/keyboard - in particular, note that there are no keyboard shortcuts for 'move the cursor to the next/previous line'. Think about that.
- 4ad 15y ago
  The problem wasn't that the Plan 9 guys opposed commercialization, quite the contrary, the problem was that AT&T never let the system become open source. For some time it wasn't even available outside universities. That killed it. Yes, acme doesn't have keyboard shortcuts, I use it every day.
  - hollerith 15y ago
    >the problem was that AT&T never let the system become open source. The whole thing except the fonts was put under a very liberal open-source licence 10 or 12 or so years ago. (By then it was owned by Bellcore or Lucent, not AT&T.) Before then there were severe restrictions; is your opinion that by time the severe restrictions were lifted, it was too late because Linux had already become entrenched?
    - 4ad 15y ago
      Yes, it was made open source in 2000, 8 years after the first release of 1992, far too late.
- jff 15y ago
  Regarding acme, everyone comes in and goes "Yuck, you mean I can't type 'C-c M-x undoify'?" However, once you get used to it, it's actually rather nice. I have something like 30-40 files open in acme right now, and I find it far, far easier to manage open buffers than in Emacs. Arranging and re-arranging buffers (to use the emacs term, since it's familiar) is very convenient and helps me keep things organized. It also has "mouse shortcuts" (chords) that tend to reward using the mouse more--meaning you don't need to switch from mouse to keyboard as often, because you can do cut, copy, paste, search, command execution, etc. all with a click of the mouse (and no hunting through menus, either). It's hard to explain... you really have to use Acme, or even better, watch someone use it. http://www.youtube.com/watch?v=dopu3ZtdCsg http://www.youtube.com/watch?v=dopu3ZtdCsg seems to be a decent intro, although I haven't had time to watch the whole thing yet.
gioele 15y ago
Plan 9 was and is too good to be ignored. Indeed many of its features are now a must in Linux systems (for example good support for private namespaces) and the p9fs, designed to be virtualizable and distributed, is getting serious traction in the virtualization world (see 9p virtio). And Plan 9 also has the best mascot around!
- mdwrigh2 15y ago
  It helps that Eric Van Hensbergen, the guy behind 9p virtio, was a Plan 9 developer.
  - 4ad 15y ago
    s/was/is/ He was one of the guys that ported Plan 9 to the Blue Gene supercomputer. He has many active projects in the Plan 9 community.
rbanffy 15y ago
This need updating. "The Room", a film that came after the article was written, is obviously worse than either "Manos" or "Plan 9", as anyone who saw even its first minutes will readily attest. edit: I'm sorry. I often forget my colleagues are humourless at this time in the morning.
- astrange 15y ago
  I think "Birdemic" would be more appropriate, since the first half is about someone pitching a tech startup (and the second half is about being vomited on by animated GIFs of birds).
  - rbanffy 15y ago
    I can't disagree with facts. According to IMDB, http://www.imdb.com/title/tt1316037/ http://www.imdb.com/title/tt1316037/ is worse than http://www.imdb.com/title/tt0368226/ http://www.imdb.com/title/tt0368226/
haberman 15y ago
Am I the only one who doesn't get excited about the idea of absolutely everything being a file? People seem to like the idea of being able to say things like "cat file.wav > /dev/dsp". But a sound card is a complex thing that can be configured in umpteen different ways; what if the file has a different sample rate than the card is currently running at? Even if you gerry-rigged a kernel driver that could handle this case (by, for example, noticing when the file had been open()'d and expecting the next bytes to be a WAV header, which it uses to reconfigure the card), you're left with something that doesn't have even the most basic functionality that you'd expect from a sound player; for example, "pause." So what has representing /dev/dsp as a file really bought you? It doesn't help you know what devices are available, because there's tons of crap in /dev that doesn't necessarily have a kernel driver loaded for it. It's not that useful as an end-user interface for selecting a sound card, because users don't want to choose between /dev/dsp and /dev/dsp2, they want to see nice names like "Internal Speaker" or "Apogee Duet." Files give you a simple API for lots of common operations, which is nice, but the fact that all files are not created equal means that operations sometimes don't work like you expect. For example, how would you guess that "tail -f" is implemented? If you're like me, you would have expected that it works by calling poll/select/etc. and waiting for the file to become read-ready. But this approach doesn't actually work for monitoring growing files; the select() will just return immediately with read-ready even if you're at EOF. So what "tail -f" actually does is a loop that alternates between sleep() and fstat(). I'm serious! http://git.savannah.gnu.org/gitweb/?p=coreutils.git;a=blob;f=src/tail.c;h=29ddabd62c650c4b0c9ed9b52bb3270e25f1bb90;hb=02551d8a62d84b8788a8793de121c2f1e5212d63#l1071 http://git.savannah.gnu.org/gitweb/?p=coreutils.git;a=blob;f...
- strictfp 15y ago
  You could configure it by doing something like echo "22050" > /dev/dsp/config/sample_rate_hz echo "lanczos" > /dev/dsp/config/resample_algorithm You could then search for configs by using find, back them up by using tar, be able to easily replicate settings between computers using rsync etc. The idea is not to have one unconfigurable binary reciever, but rather to expose the interface as a hierarchy of rw files instead of a number of C functions, because the C functions have no easy shell representation, and most command-line tools fail using them. It's very reminiscent of REST.
gosub 15y ago
> 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. Isn't this concept applicable to every system once it incorporates programmability?
mhw 15y ago
I've often thought that Plan 9's everything-is-a-file system with a consistent API for access is the missing link between Unix's everything-is-a-file and REST's consistent interface constraint. I think it's certainly arguable that Plan 9 shares many features with RESTful architectures.
shimon_e 15y ago
The real shame is that inferno never became android. It was around early enough. Had the right feature set. I guess it was not in Google's backyard (America) and had lost it's backbone a little to early. I guess when Google was shopping for mobile OS they were also looking for a talent grab. With Inferno by 2005 most had already left.
- sambeau 15y ago
  True, but, they already had all the talent from Plan 9
- luriel 15y ago
  By 2005 most of the team that created Plan 9 and Inferno at Bell Labs were already working at Google. But they were working on other stuff, like Go.
mhd 15y ago
I always find it pretty sad that while everybody speaks about the integrated environments of Smalltalk and Plan 9, Niklaus Wirth's Oberon is almost left forgotten…
- hollerith 15y ago
  For over a decade, dozens of actual people used Plan 9 as their main environment. (Many but not all of these people worked at Bell Labs.) I tend to believe that Smalltalk has also seen serious numbers of actual users. In contrast, who has ever used Oberon as their main software environment except perhaps students required to do so to pass some class?
  - mhd 15y ago
    If we're talking about popularity contests here, all the "contestants" aren't doing very well…
    - bitwize 15y ago
      Smalltalk is a stealth weapon in the banking industry. I know Wells Fargo has a codebase based on it. I know this because roundabout 2008 I was pestered by recruiters looking for Smalltalk devs willing to move to cold, cold Minnesota. (Boston winters are more than enough for me so I bade them a courteous no-thank-you.) Also, most of the currently trending methodology buzzwords (Extreme Programming, TDD, refactoring, etc.) emerged out of a community of Smalltalk programmers on real professional software projects. What Smalltalk lacks is marketing hype.
- adbge 15y ago
  One of the Plan 9 papers actually refers to Oberon as an example of a similarly integrated system. I believe it's the one titled 'The Use of Name Spaces in Plan 9,' but I'm not certain. Unfortunately, the server is down right now so I'm unable to check but, if you're curious, the various papers can be found here: http://plan9.bell-labs.com/sys/doc/ http://plan9.bell-labs.com/sys/doc/
Craiggybear 15y ago
"Those who don't understand UNIX are condemned to reinvent it. Poorly." – Henry Spencer
- atuladhar 15y ago
  Except that Plan 9 was designed by the people who built UNIX. Are you implying that the people who built UNIX don't understand it?
  - Craiggybear 15y ago
    No, no! Quite the reverse.
runjake 15y ago
Plan 9 wasn't a failure and it wasn't the future, directly. It was a research OS that was never even close to being positioned to market, be it consumers, servers, etc -- although technology coming out of Plan 9 did make it into some commercial applications. Indirectly, Plan 9 technologies (or inspired successors) made their way into real products. Linux's procfs is one notable example.
morphles 15y ago
I recently tried plan 9 for a bit. Though i understand all the cool things it does and agree with a lot of it. One thing really disappointed and struck me as totally brain dead: there is no such thing as terminal emulator or it seems something like text only mode. In general it seems to me that achieving keyboard only control (that is comfortable to use) is not really possible at least for now.
angli 15y ago
A good introduction to the Plan 9 UI I found, for any who are interested: http://vimeo.com/7748726 http://vimeo.com/7748726

197 points by niyazpk 15y ago

6ren 15y ago

Ugly now beats beautiful later. An elegant solution requires a deep understanding of a problem, and that understanding takes a lot of data (awareness of cases), and then a lot of time and effort to create a simple theory of it and to create a simple solution embodying that theory.

bct 15y ago
The trick is to build ugly systems that are able to grow into beautiful ones.
- jff 15y ago
  That is quite a trick. The problem is that pretty soon, everyone depends on the behavior of the ugly warts in your original system, so now you're stuck with them lest you break the holy Compatibility.
  - deleted 15y ago
    [deleted]

wladimir 15y ago

It seems that (almost?) everything that was planned out for plan9 is finding its way into operating systems. The ideas were good, but somehow they had to take the long way around. It was way ahead of its time.

_delirium 15y ago
I remember an interview with one of the ex-Plan9 people now at Google (Rob Pike maybe?) talking about how he's switched to Linux, since that's what Google runs on, and finds it a strange experience, as if a bunch of bugs you thought you'd fixed 20 years ago have resurfaced in the main branch. But Linux does seem to be picking up a steady number of the features.
- shimon_e 15y ago
  It was Rob Pike from the slashdot interview. http://interviews.slashdot.org/story/04/10/18/1153211/rob-pike-responds http://interviews.slashdot.org/story/04/10/18/1153211/rob-pi...
  - johncoltrane 15y ago
    Thanks for the link. (irrelevant: I like how he used wOOd to represent OO programming)

pavpanchekha 15y ago

First, one should note that this is a chapter (or section) of "The Art of Unix Programming", by esr; it is a fantastic book (I'm going through it now, on chapter 9 of 20, and the wisdom has been near-palpable). As for the specifics of the article. Plan 9 did indeed do many things right; in fact, many things are done in a very Unixy way. For example, the networking stack is build precisely where it ought to be: as a detail below a powerful network protocol (9P) which can be made as transparent or concrete as necessary (one can easily write individual TCP or UDP packets using the file system; just as easily, you can network-export any file system). Similarly, Plan 9's handling of security, in particular the elimination of the superuser, was fantastic. And while I in particular disagree with the approach Plan 9 takes to the GUI, it is certainly a consistent, powerful, and inspired model. And a variety of its other ideas, such as UTF-8 and the /proc and /sys file systems, have worked their way into modern Unixes such as Linux. Now, Plan 9's failure has been aptly explained elsewhere, in particular in the article linked. But, being somewhat old (2004, I believe; though when that particular section was written I do not know), it makes the prediction that Unixes will eventually come to absorb all of the Plan 9 features. Instead, it looks like the Linux kernel, at least, has mostly given up on ever implementing union mounts (one of the most inspired of Plan 9's innovations, at least in my view). And while the /net file system is incredibly useful, its power is much diminished when you can't assume that the world speaks 9P, which will seemingly never be the case. And a variety of Plan 9's choices are impossible without ignoring POSIX compatibility, which causes problems of its own. Unix rode the growth of servers in the seventies and eighties, and is by now rather entrenched (see the History chapter in Art of Unix Programming); much like the WIMP GUI metaphor rode the personal computing wave. I think both of these areas are by now too old and entrenched for us to simply replace the current monopolies there. And I've come to terms with the fact that Plan 9 will never, ever become the standard OS --- it is simply not designed for any battlegrounds except those it has already lost in. But I strongly urge anyone designing an OS (or, really, any sort of all-encompassing computer system) to look over the innovations and ideas of Plan 9. Luckily, I don't think anything like Windows or Unix will win in a totally new environment, because Windows and Unix aren't made for any environments but their own. So while Plan 9 never won, I think its ideas have a good chance of living on. And I await an exciting time of innovation in Operating Systems in the coming century.

jbarham 15y ago

Unsurprisingly given the common pedigree, a number of ideas from Plan 9 have made their way into Go. E.g., compare http://golang.org/pkg/net/#Dial http://golang.org/pkg/net/#Dial and http://plan9.bell-labs.com/magic/man2html/2/dial http://plan9.bell-labs.com/magic/man2html/2/dial. Go's approach to concurrency is familiar in the Plan 9 world from Alef (http://en.wikipedia.org/wiki/Alef_(programming_language) http://en.wikipedia.org/wiki/Alef_(programming_language), http://swtch.com/~rsc/thread/alef.pdf http://swtch.com/~rsc/thread/alef.pdf) and Limbo (http://www.vitanuova.com/inferno/papers/limbo.html http://www.vitanuova.com/inferno/papers/limbo.html), the language used to implement Inferno, a Plan 9 spinoff.

dhconnelly 15y ago
Cool. I wasn't sure if it was common knowledge that Ken Thompson and Rob Pike created Go. The Go compiler toolchain is from Plan 9, too: http://golang.org/cmd/ http://golang.org/cmd/.

thristian 15y ago

The impression I got was that the guys behind Unix were annoyed when their operating-systems research was stalled in the name of "API compatibility", so they started Plan 9 and actively resisted commercialisation for as long as possible (for example, they gave it the least marketable name they could think of). There's so many interesting ideas in Plan 9, I'm occasionally tempted to install it and try it out... but then I read things like the list of keyboard shortcuts in the standard editor acme¹, and I get cold feet. ¹: http://acme.cat-v.org/keyboard http://acme.cat-v.org/keyboard - in particular, note that there are no keyboard shortcuts for 'move the cursor to the next/previous line'. Think about that.

4ad 15y ago
The problem wasn't that the Plan 9 guys opposed commercialization, quite the contrary, the problem was that AT&T never let the system become open source. For some time it wasn't even available outside universities. That killed it. Yes, acme doesn't have keyboard shortcuts, I use it every day.
- hollerith 15y ago
  >the problem was that AT&T never let the system become open source. The whole thing except the fonts was put under a very liberal open-source licence 10 or 12 or so years ago. (By then it was owned by Bellcore or Lucent, not AT&T.) Before then there were severe restrictions; is your opinion that by time the severe restrictions were lifted, it was too late because Linux had already become entrenched?
  - 4ad 15y ago
    Yes, it was made open source in 2000, 8 years after the first release of 1992, far too late.
jff 15y ago
Regarding acme, everyone comes in and goes "Yuck, you mean I can't type 'C-c M-x undoify'?" However, once you get used to it, it's actually rather nice. I have something like 30-40 files open in acme right now, and I find it far, far easier to manage open buffers than in Emacs. Arranging and re-arranging buffers (to use the emacs term, since it's familiar) is very convenient and helps me keep things organized. It also has "mouse shortcuts" (chords) that tend to reward using the mouse more--meaning you don't need to switch from mouse to keyboard as often, because you can do cut, copy, paste, search, command execution, etc. all with a click of the mouse (and no hunting through menus, either). It's hard to explain... you really have to use Acme, or even better, watch someone use it. http://www.youtube.com/watch?v=dopu3ZtdCsg http://www.youtube.com/watch?v=dopu3ZtdCsg seems to be a decent intro, although I haven't had time to watch the whole thing yet.

gioele 15y ago

Plan 9 was and is too good to be ignored. Indeed many of its features are now a must in Linux systems (for example good support for private namespaces) and the p9fs, designed to be virtualizable and distributed, is getting serious traction in the virtualization world (see 9p virtio). And Plan 9 also has the best mascot around!

mdwrigh2 15y ago
It helps that Eric Van Hensbergen, the guy behind 9p virtio, was a Plan 9 developer.
- 4ad 15y ago
  s/was/is/ He was one of the guys that ported Plan 9 to the Blue Gene supercomputer. He has many active projects in the Plan 9 community.

rbanffy 15y ago

This need updating. "The Room", a film that came after the article was written, is obviously worse than either "Manos" or "Plan 9", as anyone who saw even its first minutes will readily attest. edit: I'm sorry. I often forget my colleagues are humourless at this time in the morning.

astrange 15y ago
I think "Birdemic" would be more appropriate, since the first half is about someone pitching a tech startup (and the second half is about being vomited on by animated GIFs of birds).
- rbanffy 15y ago
  I can't disagree with facts. According to IMDB, http://www.imdb.com/title/tt1316037/ http://www.imdb.com/title/tt1316037/ is worse than http://www.imdb.com/title/tt0368226/ http://www.imdb.com/title/tt0368226/

haberman 15y ago

Am I the only one who doesn't get excited about the idea of absolutely everything being a file? People seem to like the idea of being able to say things like "cat file.wav > /dev/dsp". But a sound card is a complex thing that can be configured in umpteen different ways; what if the file has a different sample rate than the card is currently running at? Even if you gerry-rigged a kernel driver that could handle this case (by, for example, noticing when the file had been open()'d and expecting the next bytes to be a WAV header, which it uses to reconfigure the card), you're left with something that doesn't have even the most basic functionality that you'd expect from a sound player; for example, "pause." So what has representing /dev/dsp as a file really bought you? It doesn't help you know what devices are available, because there's tons of crap in /dev that doesn't necessarily have a kernel driver loaded for it. It's not that useful as an end-user interface for selecting a sound card, because users don't want to choose between /dev/dsp and /dev/dsp2, they want to see nice names like "Internal Speaker" or "Apogee Duet." Files give you a simple API for lots of common operations, which is nice, but the fact that all files are not created equal means that operations sometimes don't work like you expect. For example, how would you guess that "tail -f" is implemented? If you're like me, you would have expected that it works by calling poll/select/etc. and waiting for the file to become read-ready. But this approach doesn't actually work for monitoring growing files; the select() will just return immediately with read-ready even if you're at EOF. So what "tail -f" actually does is a loop that alternates between sleep() and fstat(). I'm serious! http://git.savannah.gnu.org/gitweb/?p=coreutils.git;a=blob;f=src/tail.c;h=29ddabd62c650c4b0c9ed9b52bb3270e25f1bb90;hb=02551d8a62d84b8788a8793de121c2f1e5212d63#l1071 http://git.savannah.gnu.org/gitweb/?p=coreutils.git;a=blob;f...

strictfp 15y ago
You could configure it by doing something like echo "22050" > /dev/dsp/config/sample_rate_hz echo "lanczos" > /dev/dsp/config/resample_algorithm You could then search for configs by using find, back them up by using tar, be able to easily replicate settings between computers using rsync etc. The idea is not to have one unconfigurable binary reciever, but rather to expose the interface as a hierarchy of rw files instead of a number of C functions, because the C functions have no easy shell representation, and most command-line tools fail using them. It's very reminiscent of REST.

gosub 15y ago

> 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. Isn't this concept applicable to every system once it incorporates programmability?

mhw 15y ago

I've often thought that Plan 9's everything-is-a-file system with a consistent API for access is the missing link between Unix's everything-is-a-file and REST's consistent interface constraint. I think it's certainly arguable that Plan 9 shares many features with RESTful architectures.

shimon_e 15y ago

The real shame is that inferno never became android. It was around early enough. Had the right feature set. I guess it was not in Google's backyard (America) and had lost it's backbone a little to early. I guess when Google was shopping for mobile OS they were also looking for a talent grab. With Inferno by 2005 most had already left.

sambeau 15y ago
True, but, they already had all the talent from Plan 9
luriel 15y ago
By 2005 most of the team that created Plan 9 and Inferno at Bell Labs were already working at Google. But they were working on other stuff, like Go.

mhd 15y ago

I always find it pretty sad that while everybody speaks about the integrated environments of Smalltalk and Plan 9, Niklaus Wirth's Oberon is almost left forgotten…

hollerith 15y ago
For over a decade, dozens of actual people used Plan 9 as their main environment. (Many but not all of these people worked at Bell Labs.) I tend to believe that Smalltalk has also seen serious numbers of actual users. In contrast, who has ever used Oberon as their main software environment except perhaps students required to do so to pass some class?
- mhd 15y ago
  If we're talking about popularity contests here, all the "contestants" aren't doing very well…
  - bitwize 15y ago
    Smalltalk is a stealth weapon in the banking industry. I know Wells Fargo has a codebase based on it. I know this because roundabout 2008 I was pestered by recruiters looking for Smalltalk devs willing to move to cold, cold Minnesota. (Boston winters are more than enough for me so I bade them a courteous no-thank-you.) Also, most of the currently trending methodology buzzwords (Extreme Programming, TDD, refactoring, etc.) emerged out of a community of Smalltalk programmers on real professional software projects. What Smalltalk lacks is marketing hype.
adbge 15y ago
One of the Plan 9 papers actually refers to Oberon as an example of a similarly integrated system. I believe it's the one titled 'The Use of Name Spaces in Plan 9,' but I'm not certain. Unfortunately, the server is down right now so I'm unable to check but, if you're curious, the various papers can be found here: http://plan9.bell-labs.com/sys/doc/ http://plan9.bell-labs.com/sys/doc/

Craiggybear 15y ago

"Those who don't understand UNIX are condemned to reinvent it. Poorly." – Henry Spencer

atuladhar 15y ago
Except that Plan 9 was designed by the people who built UNIX. Are you implying that the people who built UNIX don't understand it?
- Craiggybear 15y ago
  No, no! Quite the reverse.

runjake 15y ago

Plan 9 wasn't a failure and it wasn't the future, directly. It was a research OS that was never even close to being positioned to market, be it consumers, servers, etc -- although technology coming out of Plan 9 did make it into some commercial applications. Indirectly, Plan 9 technologies (or inspired successors) made their way into real products. Linux's procfs is one notable example.

morphles 15y ago

I recently tried plan 9 for a bit. Though i understand all the cool things it does and agree with a lot of it. One thing really disappointed and struck me as totally brain dead: there is no such thing as terminal emulator or it seems something like text only mode. In general it seems to me that achieving keyboard only control (that is comfortable to use) is not really possible at least for now.

angli 15y ago

A good introduction to the Plan 9 UI I found, for any who are interested: http://vimeo.com/7748726 http://vimeo.com/7748726