8 ms·

What People Like About the Plan 9 OS

119 points by rbc 13y ago

carterschonwald 13y ago
Woah: I didn't realize there was still active work on plan 9. They've participated in Gsoc the past four years even!
rdtsc 13y ago
I was fascinated with Plan 9. It just has really cool ideas in its design. It has been said before and I agree. The problem with Plan 9 adoption isn't Plan 9. Plan 9 is beautiful. The problem is that Linux is quite alright as well. Also, Linux has drivers for more hardware when Plan 9 was ready to be played with. Plan 9 doesn't. It is a chicken and egg problem. I remember trying Plan 9 and it just didn't have drivers for some of my hardware. It was like Linux in back in the days.
- pjmlp 13y ago
  Plan9 is fine if you only care about daemons and command line interfaces.
  - klrr 13y ago
    Unix is more command line oriented, honestly. Plan 9's is really GUI centric, although not a ordinary GUI.
    - pjmlp 13y ago
      I have used Plan9 and don't agree, specially looking at the examples of Amiga OS, Atari OS, Mac OS (X), Windows, OS/2, IRIX, NeXTStep, Native Oberon, SmallTalk...
      - weland 13y ago
        Have you also used Acme (non-trivially)? The UI makes heavy use of text (the whole thing being a text processing environment after all) but the graphical aspect is highly significant, and most of the (fairly complex) interaction is via mouse. The Plan 9 userspace excels at tying text-using utils, but the traditional Unix CLI is not the means by which you tie them. Even the terminal is quite far removed from a typical command line.
        pjmlp 13y ago
        Acme is based on how the whole Native Oberon OS works, which provides a much better UI experience using the same principles, specially the last version (System 3).
      - deleted 13y ago
        [deleted]
        pjmlp 13y ago
        That is nothing new, it is how Native Oberon works (1987), which is based on Smaltalk (1972) works. In Native Oberon, every module can export functions as commands that are mouse callable in the UI and take input from mouse selections, which can even be UI objects (gadgets). Most of the mouse/keyboard interactions in Rio were already available in Native Oberon.
  - nmcfarl 13y ago
    Which is fantastic endorsement. GUIs and the Web may be nice for mucking about - but when I work - I work on the command line (or in emacs). All I truly care about is daemons and command line interfaces. Of course - my daemons and command line interfaces have to produce pretty output, for people who care about other things. But those people are not me. So I installed Plan 9 from User Space[1] last night - largely on this recommendation :) [1] http://swtch.com/plan9port/ http://swtch.com/plan9port/
    - pjmlp 13y ago
      > All I truly care about is daemons and command line interfaces. Welcome to the world of computing in 70's. Some of us prefer the future. :) I enjoy GUIs since my Amiga 500 days.
      - qu4z-2 13y ago
        I feel like GUIs these days cater too much to novice users. Obviously the old-school terminal/no-graphics style is pretty dated, but I have yet to see a nicely integrated solution with the advantages of GUIs and the power of the cli.
        pjmlp 13y ago
        Maybe, but I don't feel that way. I do enjoy the power of the CLI for automation and pipelining of commands and build scripts. However I am a visual guy and also enjoy the power of IDEs when coding. So I rather use the GUI and make use of the CLI when required, than the other way around. This was exactly how one would use Amiga OS. Spend most of the time in Workbench and use Amiga DOS when required to do so. Or even the old Mac OS, where a terminal was a third party application. There was no command line, only GUI.
        nmcfarl 13y ago
        So after your first comment I was wondering what GUI gives you as far as tools in an IDE that you couldn't have with curses style terminal-based interface. Emacs (and vi) do a wide assortment of refactorings, auto-completions, multipaned outputs, large scale cut and pastes etc. I couldn't think of anything that actually needed graphics. Given that i couldn't think of any reason why an IDE needed to be a GUI. That is to say I can see people preferring the look, or the use of a pointing device, but I couldn't figure out any coding features that where actually GUI-only. You have any I couldn't think of?
- sillysaurus2 13y ago
  Well, the problem with Plan 9 is that it requires everything support the Plan 9 protocol. The entire stack has to speak Plan 9, otherwise nothing works. So anything that interacts with it would have to support the full protocol, whereas Unix is just "pipe this output stream into that input stream," which is quite a lot easier to adopt.
  - p9idf 13y ago
    It's not unusual for an operating system to require its programs to use its system calls. A Unix program that doesn't speak Unix protocols is just as useless as a Plan 9 program that doesn't speak Plan 9 protocols. It's a moot point though, since you'd have a difficult time unwittingly making a compiler generate a program that doesn't work on its own operating system. Pipes on Plan 9 use the same pipe, read, write, and close system calls as Unix does; they are an equivalent amount of work to use (or adopt, as you say).
  - throwaway2048 13y ago
    its important to note that "speaking the plan9 protocol" amounts to normal file operations like read(), write(), stat() etc. This also works fine with pipes.
- derefr 13y ago
  I'm amazed that "drivers" are still a consideration in OS design anywhere other than embedded systems. Why aren't we writing our operating systems to target hardware-abstracting hypervisors yet? Isn't that an obvious separation of concerns?
  - gizmo686 13y ago
    Isn't the BIOS supposed to be the hardware abstracting layer we run our programs directly on? That doesn't work any more (because BIOS is a legacy mess), so now we have kernels that act as the hardware abstraction, and write operating systems on top of those. Of course, now you need to target you operating system to a kernel.
    - derefr 13y ago
      Yes, the BIOS is exactly what's supposed to be doing the hardware abstraction, such that jobs like "read a block from a block device" are done via hardware interrupts, not system calls. I think hypercalls are a good compromise, these days; what is a hypervisor but a BIOS running on the CPU? There are already specialty OSes that take this tack--things like Openmirage (http://www.openmirage.org/ http://www.openmirage.org/) and Erlang on Xen (http://erlangonxen.org/ http://erlangonxen.org/). It could be done with a general-purpose OS just as easily.
      - derleth 13y ago
        > what is a hypervisor but a BIOS running on the CPU? Generally, a hypervisor implies a VM which multiplexes the hardware and allows multiple OSes to run at once, which is more than any BIOS has ever done. Also, a hypervisor generally doesn't provide any hardware abstraction, to be compatible with existing OSes which expect to be alone on the hardware.
        rjsw 13y ago
        If the hypervisor is a paravirtualized one then it will provide hardware abstractions. The Openmirage project described above is essentially an OCaml Machine, it only needs drivers to talk to the generic Xen devices for disk, network, console etc...
- rektide 13y ago
  The problem is that Linux is quite alright as well. The advantage of plan9 was "at scale," being able to commingle multiple system's resources in interesting novel ways. This has never been and still is in no ways Linux's strength. Linux is inward focused: a monolithic kernel designed to serve as a pleasant base for anything running under it. There are probably near a thousand different Node.js projects each implementing some kind of coordination layer between Node.js processes (ex: https://github.com/amino/amino https://github.com/amino/amino) and similar efforts abound on for all other applications to be coded against (Hazelcast, Hadoop, &c). Why? It's all done as application framework level because the Linux operating system's design space is sitting on a box and running. The fanciest interconnect you're going to get is when you first modprobe in USB-IP (allows network control of a usb peripheral). It's downhill, and back to writing applications if you want to push on. Linux is definitely quite alright. We're fine with Hadoop, running on the JVM, running on Linux. We were delighted to have a desktop Unix, to have X running- the never ending parade of "year of the linux desktop" stories, year after year. Linux arose when we wanted better ways to run things on a box, and most problems fit on a box. Linux was what we wanted, took care of the pressing matter of running a single box, and it was good at that, whereas when it and Plan9 were in their early days, it was a harsh and hostile landscape and we weren't good at working within the confines of the box. Plan9 has always been for those cases where you abutted the constraints of the box, and wanted to think more openly more broadly about the problems about us- and plan9 was for those who wanted to reap solutions that could scale and reach out in a common interoperable serviceable way. It was ahead of it's time, and we couldn't picture the use of a fabric that would let the boxes work together, in part because boxes were still rapidly individually advancing from the very crude, hard to use machines of the mainframe days into things we could begin to use. Thanks Linux for getting us so far, but I tend towards suspecting that thinking of a running environment that thinks chiefly of itself, that remains firmly about it's own box, is too old world to be of much real service these days.
  - rdtsc 13y ago
    > There are probably near a thousand different Node.js projects each implementing some kind of coordination layer between Node.js processes (ex: https://github.com/amino/amino https://github.com/amino/amino) and similar efforts abound on for all other applications to be coded against (Hazelcast, Hadoop, &c). Why? There is only one Erlang though and it has been around for 20+ years. It has built in distribution and automatic failover. Yes it is built on top of Linux/Mac/Windows OS. But wait, that's not all. There is this project that basically attempts to thin out the OS and replace it with Erlang -- http://erlangonxen.org/ http://erlangonxen.org/ -- Erlang VM implemented on top of Xen hypervisor. To make it even more interesting and bring it back home -- the underlying clustering support is based on 9P (the plan 9 distribution protocol). I think that is pretty cool.
- rbc 13y ago
  You can run Plan 9 under Xen, Amazon AWS being one of those places. I've been running it under VirtualBox as well. If you are already using virtualization, the Plan 9 device drivers may be less of an issue.
  - RamiK 13y ago
    Qemu(KVM) works as well.
D9u 13y ago
http://www.plan9.bell-labs.com/wiki/plan9/what_do_people_like_about_plan_9/index.html http://www.plan9.bell-labs.com/wiki/plan9/what_do_people_lik... http://plan9.bell-labs.com/wiki/plan9/faq http://plan9.bell-labs.com/wiki/plan9/faq http://plan9.bell-labs.com/wiki/plan9/ http://plan9.bell-labs.com/wiki/plan9/ Connection refused: plan9.bell-labs.com:80 I can't access any of the above... :(
- nanofortnight 13y ago
  Google Cache: http://webcache.googleusercontent.com/search?q=cache:www.plan9.bell-labs.com/wiki/plan9/what_do_people_like_about_plan_9/index.html http://webcache.googleusercontent.com/search?q=cache:www.pla...
- rbc 13y ago
  I guess news.ycombinator.com sent them more traffic than they are accustomed to. Oops... Sorry guys.
  - tomphoolery 13y ago
    Solution: stop webserver? :P
    - rbc 13y ago
      What do you bet their web server fell over? It smells like some kind of a process failure.
      - D9u 13y ago
        It's still inaccessible for me. I tried different browsers, proxies, Tor, and tried accessing from a remote shell running lynx. No go... It's too bad, as I am a distro-hopper, and would like to be able to access Plan9 related online compendia if I'm going to be using Plan9. Edit: Thanks for the link @ nanofortnight
        13y ago
rbc 13y ago
There are Amazon AMI's for plan 9, called plan9-fossil. You don't use ssh to get in though. You need to use the plan 9 "cpu" command, using the "ec2" user and a random password printed on the instance console/system log. I have a plan 9 host running under VirtualBox that I used to access my Amazon Plan 9 host. It worked just great. Another little item is you have to allow TCP access to ports 17010 and 17013 on the instance.
- sanderjd 13y ago
  Are there any ports of the `cpu` command for other operating systems?
  - rbc 13y ago
    Use drawterm. It is a X11 application that allows you to connect to a remote Plan 9 server.
    - rbc 13y ago
      Here's the command line I used: drawterm -c 54.245.176.166 -u ec2 & Note that I put it in the background. You will want to adjust your server address as appropriate. I should add that drawterm just opens a blank Plan 9 desktop after you authenticate. You have to open a new command session on your own. A right click brings up a menu, you want to choose "new". This will turn the pointer to a "+" shape. You then right click and hold, stretching out the command window until it's the right size. When you release the right click, you will have a rc shell to type commands into.
      - sanderjd 13y ago
        Neat! Thanks for the instructions - that's definitely the easiest way to play around with Plan9 that I've come across (but I guess I haven't been looking too hard...)
- nmcfarl 13y ago
  Some details on that ami: Specs: http://thecloudmarket.com/image/ami-cfa332ff--plan9-fossil#/definition http://thecloudmarket.com/image/ami-cfa332ff--plan9-fossil#/... Link to launch via AWS Console: https://console.aws.amazon.com/ec2/home?region=us-west-2#launchAmi=ami-cfa332ff https://console.aws.amazon.com/ec2/home?region=us-west-2#lau...
frozenport 13y ago
Plan 9 was also slow and didn't support a normal version of GCC. Developers! Developers! Developers!
- rbc 13y ago
  If you want more of a unix like build environment on Plan 9, you'll probably want the Plan 9 ANSI/POSIX Environment (APE).
- weland 13y ago
  That's partly due to historical reasons I think. Some of the platforms they intended to run Plan 9 on had very buggy GCC ports. It's also worth noting that that the "native" Plan 9 compilers had some quirks of their own (see http://doc.cat-v.org/plan_9/4th_edition/papers/compiler http://doc.cat-v.org/plan_9/4th_edition/papers/compiler ). It was never really intended to be a very familiar Unix environment, and they tried to straighten up a couple of things even in the way software is written. There is a POSIX environment available (the APE) but I don't know much about it, I never really tried it. To be fair, between the "good enough" phenomenon and the licensing problems, it never really took off, which is rather sad.
dasil003 13y ago
I think to really understand what makes Plan 9 great requires a deep understanding of Unix, but once you have a deep understanding of Unix...
- iv_08 13y ago
  Plan 9 was basically the successor of Unix by the same research group, more modern, taking the ideas of Unix further, a distributed operating system with full network transparency, better shell (actually, rc already replaced the Bourne shell in version 10 Unix) and lots of other goodies such as the plumber. And it served as the "reference implementation" for UTF-8.
  - pjmlp 13y ago
    And yet, like many cool ideas, the world was not ready for it. Nowadays it does not matter any longer.
  - dasil003 13y ago
    I understand all that. My point was that if you know enough to appreciate Plan 9 then you know enough to take advantage of the *nix ecosystem as it exists today, which is far too mature for Plan 9 to catch up to. We can always dream though...
    - D9u 13y ago
      lull them into thinking that Plan 9 is Just Another Unix. From what I read, Plan9 has its own concepts which are not Unix analogues, thereby discounting Unix knowledge due to divergence.
  - deleted 13y ago
    [deleted]
rcarmo 13y ago
Interesting. Serendipitously, I just came across some GSOC posts regarding getting Java on it: https://groups.google.com/forum/m/#!forum/plan9-gsoc https://groups.google.com/forum/m/#!forum/plan9-gsoc If that turns out OK and someone manages to port a browser over, it might be a good environment to do run Clojure.
WasimBhai 13y ago
Considering plan9 is so great for distributed computing, those with Big Data experience, do you think it is only a matter of time before plan9 replaces other operating systems being used in map-reduce, clustered environments?
tete 13y ago
A bit sad that the page is down. However, people interested into (vanilla) Plan 9 might also be interested in this: http://code.google.com/p/plan9front/ http://code.google.com/p/plan9front/
lectrick 13y ago
It's a revolutionary OS hampered by licensing. Open source the goddamn thing to save its ideas at this point before they are lost to nerd-history and let's see what happens.
- RamiK 13y ago
  Plan9 been free and open source for over a decade (2003). At first it was released with some very unusual constraints(Lucent Public License v1.0). But those were quickly lifted(Lucent Public License v1.02). GNU's stance on the revised license seems mostly favorable with some mild reservations: http://gplv3.fsf.org/wiki/index.php/Lucent_Public_License_version_1.02 http://gplv3.fsf.org/wiki/index.php/Lucent_Public_License_ve...
a0 13y ago
One of my favorite features of Plan 9 is the extremely powerful filesystem abstraction through the 9p file protocol. It is incredible how clean becomes the design of the applications and the communication between the modules with a simple file interface. Currently I'm working on potential extension of this idea - an ontology-based virtual filesystem, where the files are replaced by objects and the organization is defined by relations, instead of the hierarchical structures.
- matiasb 13y ago
  9p is really cool. I've seen a lot of papers about it, and some experiments done at university. https://code.google.com/p/diod/wiki/protocol#Sample_Session https://code.google.com/p/diod/wiki/protocol#Sample_Session http://graverobbers.blogspot.com/2007/08/v9fs-performance-versus-nfs.html http://graverobbers.blogspot.com/2007/08/v9fs-performance-ve... http://9p.cat-v.org/implementations http://9p.cat-v.org/implementations

119 points by rbc 13y ago

Woah: I didn't realize there was still active work on plan 9. They've participated in Gsoc the past four years even!

rdtsc 13y ago

I was fascinated with Plan 9. It just has really cool ideas in its design. It has been said before and I agree. The problem with Plan 9 adoption isn't Plan 9. Plan 9 is beautiful. The problem is that Linux is quite alright as well. Also, Linux has drivers for more hardware when Plan 9 was ready to be played with. Plan 9 doesn't. It is a chicken and egg problem. I remember trying Plan 9 and it just didn't have drivers for some of my hardware. It was like Linux in back in the days.

pjmlp 13y ago
Plan9 is fine if you only care about daemons and command line interfaces.
- klrr 13y ago
  Unix is more command line oriented, honestly. Plan 9's is really GUI centric, although not a ordinary GUI.
  - pjmlp 13y ago
    I have used Plan9 and don't agree, specially looking at the examples of Amiga OS, Atari OS, Mac OS (X), Windows, OS/2, IRIX, NeXTStep, Native Oberon, SmallTalk...
    - weland 13y ago
      Have you also used Acme (non-trivially)? The UI makes heavy use of text (the whole thing being a text processing environment after all) but the graphical aspect is highly significant, and most of the (fairly complex) interaction is via mouse. The Plan 9 userspace excels at tying text-using utils, but the traditional Unix CLI is not the means by which you tie them. Even the terminal is quite far removed from a typical command line.
      - pjmlp 13y ago
        Acme is based on how the whole Native Oberon OS works, which provides a much better UI experience using the same principles, specially the last version (System 3).
    - deleted 13y ago
      [deleted]
      - pjmlp 13y ago
        That is nothing new, it is how Native Oberon works (1987), which is based on Smaltalk (1972) works. In Native Oberon, every module can export functions as commands that are mouse callable in the UI and take input from mouse selections, which can even be UI objects (gadgets). Most of the mouse/keyboard interactions in Rio were already available in Native Oberon.
- nmcfarl 13y ago
  Which is fantastic endorsement. GUIs and the Web may be nice for mucking about - but when I work - I work on the command line (or in emacs). All I truly care about is daemons and command line interfaces. Of course - my daemons and command line interfaces have to produce pretty output, for people who care about other things. But those people are not me. So I installed Plan 9 from User Space[1] last night - largely on this recommendation :) [1] http://swtch.com/plan9port/ http://swtch.com/plan9port/
  - pjmlp 13y ago
    > All I truly care about is daemons and command line interfaces. Welcome to the world of computing in 70's. Some of us prefer the future. :) I enjoy GUIs since my Amiga 500 days.
    - qu4z-2 13y ago
      I feel like GUIs these days cater too much to novice users. Obviously the old-school terminal/no-graphics style is pretty dated, but I have yet to see a nicely integrated solution with the advantages of GUIs and the power of the cli.
      - pjmlp 13y ago
        Maybe, but I don't feel that way. I do enjoy the power of the CLI for automation and pipelining of commands and build scripts. However I am a visual guy and also enjoy the power of IDEs when coding. So I rather use the GUI and make use of the CLI when required, than the other way around. This was exactly how one would use Amiga OS. Spend most of the time in Workbench and use Amiga DOS when required to do so. Or even the old Mac OS, where a terminal was a third party application. There was no command line, only GUI.
        nmcfarl 13y ago
        So after your first comment I was wondering what GUI gives you as far as tools in an IDE that you couldn't have with curses style terminal-based interface. Emacs (and vi) do a wide assortment of refactorings, auto-completions, multipaned outputs, large scale cut and pastes etc. I couldn't think of anything that actually needed graphics. Given that i couldn't think of any reason why an IDE needed to be a GUI. That is to say I can see people preferring the look, or the use of a pointing device, but I couldn't figure out any coding features that where actually GUI-only. You have any I couldn't think of?
sillysaurus2 13y ago
Well, the problem with Plan 9 is that it requires everything support the Plan 9 protocol. The entire stack has to speak Plan 9, otherwise nothing works. So anything that interacts with it would have to support the full protocol, whereas Unix is just "pipe this output stream into that input stream," which is quite a lot easier to adopt.
- p9idf 13y ago
  It's not unusual for an operating system to require its programs to use its system calls. A Unix program that doesn't speak Unix protocols is just as useless as a Plan 9 program that doesn't speak Plan 9 protocols. It's a moot point though, since you'd have a difficult time unwittingly making a compiler generate a program that doesn't work on its own operating system. Pipes on Plan 9 use the same pipe, read, write, and close system calls as Unix does; they are an equivalent amount of work to use (or adopt, as you say).
- throwaway2048 13y ago
  its important to note that "speaking the plan9 protocol" amounts to normal file operations like read(), write(), stat() etc. This also works fine with pipes.
derefr 13y ago
I'm amazed that "drivers" are still a consideration in OS design anywhere other than embedded systems. Why aren't we writing our operating systems to target hardware-abstracting hypervisors yet? Isn't that an obvious separation of concerns?
- gizmo686 13y ago
  Isn't the BIOS supposed to be the hardware abstracting layer we run our programs directly on? That doesn't work any more (because BIOS is a legacy mess), so now we have kernels that act as the hardware abstraction, and write operating systems on top of those. Of course, now you need to target you operating system to a kernel.
  - derefr 13y ago
    Yes, the BIOS is exactly what's supposed to be doing the hardware abstraction, such that jobs like "read a block from a block device" are done via hardware interrupts, not system calls. I think hypercalls are a good compromise, these days; what is a hypervisor but a BIOS running on the CPU? There are already specialty OSes that take this tack--things like Openmirage (http://www.openmirage.org/ http://www.openmirage.org/) and Erlang on Xen (http://erlangonxen.org/ http://erlangonxen.org/). It could be done with a general-purpose OS just as easily.
    - derleth 13y ago
      > what is a hypervisor but a BIOS running on the CPU? Generally, a hypervisor implies a VM which multiplexes the hardware and allows multiple OSes to run at once, which is more than any BIOS has ever done. Also, a hypervisor generally doesn't provide any hardware abstraction, to be compatible with existing OSes which expect to be alone on the hardware.
      - rjsw 13y ago
        If the hypervisor is a paravirtualized one then it will provide hardware abstractions. The Openmirage project described above is essentially an OCaml Machine, it only needs drivers to talk to the generic Xen devices for disk, network, console etc...
rektide 13y ago
The problem is that Linux is quite alright as well. The advantage of plan9 was "at scale," being able to commingle multiple system's resources in interesting novel ways. This has never been and still is in no ways Linux's strength. Linux is inward focused: a monolithic kernel designed to serve as a pleasant base for anything running under it. There are probably near a thousand different Node.js projects each implementing some kind of coordination layer between Node.js processes (ex: https://github.com/amino/amino https://github.com/amino/amino) and similar efforts abound on for all other applications to be coded against (Hazelcast, Hadoop, &c). Why? It's all done as application framework level because the Linux operating system's design space is sitting on a box and running. The fanciest interconnect you're going to get is when you first modprobe in USB-IP (allows network control of a usb peripheral). It's downhill, and back to writing applications if you want to push on. Linux is definitely quite alright. We're fine with Hadoop, running on the JVM, running on Linux. We were delighted to have a desktop Unix, to have X running- the never ending parade of "year of the linux desktop" stories, year after year. Linux arose when we wanted better ways to run things on a box, and most problems fit on a box. Linux was what we wanted, took care of the pressing matter of running a single box, and it was good at that, whereas when it and Plan9 were in their early days, it was a harsh and hostile landscape and we weren't good at working within the confines of the box. Plan9 has always been for those cases where you abutted the constraints of the box, and wanted to think more openly more broadly about the problems about us- and plan9 was for those who wanted to reap solutions that could scale and reach out in a common interoperable serviceable way. It was ahead of it's time, and we couldn't picture the use of a fabric that would let the boxes work together, in part because boxes were still rapidly individually advancing from the very crude, hard to use machines of the mainframe days into things we could begin to use. Thanks Linux for getting us so far, but I tend towards suspecting that thinking of a running environment that thinks chiefly of itself, that remains firmly about it's own box, is too old world to be of much real service these days.
- rdtsc 13y ago
  > There are probably near a thousand different Node.js projects each implementing some kind of coordination layer between Node.js processes (ex: https://github.com/amino/amino https://github.com/amino/amino) and similar efforts abound on for all other applications to be coded against (Hazelcast, Hadoop, &c). Why? There is only one Erlang though and it has been around for 20+ years. It has built in distribution and automatic failover. Yes it is built on top of Linux/Mac/Windows OS. But wait, that's not all. There is this project that basically attempts to thin out the OS and replace it with Erlang -- http://erlangonxen.org/ http://erlangonxen.org/ -- Erlang VM implemented on top of Xen hypervisor. To make it even more interesting and bring it back home -- the underlying clustering support is based on 9P (the plan 9 distribution protocol). I think that is pretty cool.
rbc 13y ago
You can run Plan 9 under Xen, Amazon AWS being one of those places. I've been running it under VirtualBox as well. If you are already using virtualization, the Plan 9 device drivers may be less of an issue.
- RamiK 13y ago
  Qemu(KVM) works as well.

D9u 13y ago

http://www.plan9.bell-labs.com/wiki/plan9/what_do_people_like_about_plan_9/index.html http://www.plan9.bell-labs.com/wiki/plan9/what_do_people_lik... http://plan9.bell-labs.com/wiki/plan9/faq http://plan9.bell-labs.com/wiki/plan9/faq http://plan9.bell-labs.com/wiki/plan9/ http://plan9.bell-labs.com/wiki/plan9/ Connection refused: plan9.bell-labs.com:80 I can't access any of the above... :(

nanofortnight 13y ago
Google Cache: http://webcache.googleusercontent.com/search?q=cache:www.plan9.bell-labs.com/wiki/plan9/what_do_people_like_about_plan_9/index.html http://webcache.googleusercontent.com/search?q=cache:www.pla...
rbc 13y ago
I guess news.ycombinator.com sent them more traffic than they are accustomed to. Oops... Sorry guys.
- tomphoolery 13y ago
  Solution: stop webserver? :P
  - rbc 13y ago
    What do you bet their web server fell over? It smells like some kind of a process failure.
    - D9u 13y ago
      It's still inaccessible for me. I tried different browsers, proxies, Tor, and tried accessing from a remote shell running lynx. No go... It's too bad, as I am a distro-hopper, and would like to be able to access Plan9 related online compendia if I'm going to be using Plan9. Edit: Thanks for the link @ nanofortnight
      - 13y ago

rbc 13y ago

There are Amazon AMI's for plan 9, called plan9-fossil. You don't use ssh to get in though. You need to use the plan 9 "cpu" command, using the "ec2" user and a random password printed on the instance console/system log. I have a plan 9 host running under VirtualBox that I used to access my Amazon Plan 9 host. It worked just great. Another little item is you have to allow TCP access to ports 17010 and 17013 on the instance.

sanderjd 13y ago
Are there any ports of the `cpu` command for other operating systems?
- rbc 13y ago
  Use drawterm. It is a X11 application that allows you to connect to a remote Plan 9 server.
  - rbc 13y ago
    Here's the command line I used: drawterm -c 54.245.176.166 -u ec2 & Note that I put it in the background. You will want to adjust your server address as appropriate. I should add that drawterm just opens a blank Plan 9 desktop after you authenticate. You have to open a new command session on your own. A right click brings up a menu, you want to choose "new". This will turn the pointer to a "+" shape. You then right click and hold, stretching out the command window until it's the right size. When you release the right click, you will have a rc shell to type commands into.
    - sanderjd 13y ago
      Neat! Thanks for the instructions - that's definitely the easiest way to play around with Plan9 that I've come across (but I guess I haven't been looking too hard...)
nmcfarl 13y ago
Some details on that ami: Specs: http://thecloudmarket.com/image/ami-cfa332ff--plan9-fossil#/definition http://thecloudmarket.com/image/ami-cfa332ff--plan9-fossil#/... Link to launch via AWS Console: https://console.aws.amazon.com/ec2/home?region=us-west-2#launchAmi=ami-cfa332ff https://console.aws.amazon.com/ec2/home?region=us-west-2#lau...

frozenport 13y ago

Plan 9 was also slow and didn't support a normal version of GCC. Developers! Developers! Developers!

rbc 13y ago
If you want more of a unix like build environment on Plan 9, you'll probably want the Plan 9 ANSI/POSIX Environment (APE).
weland 13y ago
That's partly due to historical reasons I think. Some of the platforms they intended to run Plan 9 on had very buggy GCC ports. It's also worth noting that that the "native" Plan 9 compilers had some quirks of their own (see http://doc.cat-v.org/plan_9/4th_edition/papers/compiler http://doc.cat-v.org/plan_9/4th_edition/papers/compiler ). It was never really intended to be a very familiar Unix environment, and they tried to straighten up a couple of things even in the way software is written. There is a POSIX environment available (the APE) but I don't know much about it, I never really tried it. To be fair, between the "good enough" phenomenon and the licensing problems, it never really took off, which is rather sad.

dasil003 13y ago

I think to really understand what makes Plan 9 great requires a deep understanding of Unix, but once you have a deep understanding of Unix...

iv_08 13y ago
Plan 9 was basically the successor of Unix by the same research group, more modern, taking the ideas of Unix further, a distributed operating system with full network transparency, better shell (actually, rc already replaced the Bourne shell in version 10 Unix) and lots of other goodies such as the plumber. And it served as the "reference implementation" for UTF-8.
- pjmlp 13y ago
  And yet, like many cool ideas, the world was not ready for it. Nowadays it does not matter any longer.
- dasil003 13y ago
  I understand all that. My point was that if you know enough to appreciate Plan 9 then you know enough to take advantage of the *nix ecosystem as it exists today, which is far too mature for Plan 9 to catch up to. We can always dream though...
  - D9u 13y ago
    lull them into thinking that Plan 9 is Just Another Unix. From what I read, Plan9 has its own concepts which are not Unix analogues, thereby discounting Unix knowledge due to divergence.
- deleted 13y ago
  [deleted]

rcarmo 13y ago

Interesting. Serendipitously, I just came across some GSOC posts regarding getting Java on it: https://groups.google.com/forum/m/#!forum/plan9-gsoc https://groups.google.com/forum/m/#!forum/plan9-gsoc If that turns out OK and someone manages to port a browser over, it might be a good environment to do run Clojure.

WasimBhai 13y ago

Considering plan9 is so great for distributed computing, those with Big Data experience, do you think it is only a matter of time before plan9 replaces other operating systems being used in map-reduce, clustered environments?

tete 13y ago

A bit sad that the page is down. However, people interested into (vanilla) Plan 9 might also be interested in this: http://code.google.com/p/plan9front/ http://code.google.com/p/plan9front/

lectrick 13y ago

It's a revolutionary OS hampered by licensing. Open source the goddamn thing to save its ideas at this point before they are lost to nerd-history and let's see what happens.

RamiK 13y ago
Plan9 been free and open source for over a decade (2003). At first it was released with some very unusual constraints(Lucent Public License v1.0). But those were quickly lifted(Lucent Public License v1.02). GNU's stance on the revised license seems mostly favorable with some mild reservations: http://gplv3.fsf.org/wiki/index.php/Lucent_Public_License_version_1.02 http://gplv3.fsf.org/wiki/index.php/Lucent_Public_License_ve...

a0 13y ago

One of my favorite features of Plan 9 is the extremely powerful filesystem abstraction through the 9p file protocol. It is incredible how clean becomes the design of the applications and the communication between the modules with a simple file interface. Currently I'm working on potential extension of this idea - an ontology-based virtual filesystem, where the files are replaced by objects and the organization is defined by relations, instead of the hierarchical structures.

matiasb 13y ago
9p is really cool. I've seen a lot of papers about it, and some experiments done at university. https://code.google.com/p/diod/wiki/protocol#Sample_Session https://code.google.com/p/diod/wiki/protocol#Sample_Session http://graverobbers.blogspot.com/2007/08/v9fs-performance-versus-nfs.html http://graverobbers.blogspot.com/2007/08/v9fs-performance-ve... http://9p.cat-v.org/implementations http://9p.cat-v.org/implementations