Plan 9 from Bell Labs (1995)(plan9.bell-labs.com)
plan9.bell-labs.com
Plan 9 from Bell Labs (1995)
http://plan9.bell-labs.com/sys/doc/9.html
10 comments
Ok, first question, why aren't we all using Plan 9 instead of a linux-based OS? Maybe more importantly, what could the next upstart kernel/OS do different than Plan 9 if it wants to be more successful?
Rob Pike and the other folks who developed Plan 9 worked at AT&T's Bell Laboratories. Nothing developed in a Bell Lab has ever been 'free' directly. Rather folks who have seen the research and been inspired by it have made changes to their free stuff which you use every day. There are influences from Plan 9 in Linux (the /proc file system for example which was influenced by the SunOS /proc filesystem which was influenced by Plan 9) but that is as far as it goes.
not true, plan9 as of the 4th edition has a OSI/FSF approved license.
Ah there you go, I sit corrected. It was free as of June 2002, so presumably for the last 10 years we could have been using it instead of Linux.
However, I would guess that had it been freely available when it was released in the early 90's then it actually would have more of a presence vis-a-vis Linux today.
However, I would guess that had it been freely available when it was released in the early 90's then it actually would have more of a presence vis-a-vis Linux today.
There have been some great answers from others in this thread already. Here's my take on things:
1. As others pointed out, Plan 9 was not initially free. If you go back and look at the very oldest messages from the 9fans mailing list (http://9fans.net/archive/, starts in 1993) you'll see lots of messages from people just trying to figure out how to get a license. At the same time, you could get Linux for free or very cheap.
2. Plan 9 is unfamiliar for new users. Face it: most people define "intuitive", "powerful", and "useful" as "that thing I'm already used to". Programming in Plan 9 is pretty similar to programming Unix, and the shell feels much the same, but you still need to learn new concepts and people don't like that.
3. Plan 9 is not Unix. People have, from the beginning, wanted to reshape Plan 9 in the image of the Unix/Linux environments they are familiar with, even when it doesn't make sense. They want Emacs or Vim, without having even tried Acme or sam. They want bash, ssh, X11, Firefox, and GNOME. Some of this software, like ssh, X11, and even Vim, have been ported or re-implemented because they're useful for interoperability with Unix or simply because somebody wanted it bad enough to do the port (Vim).
Those aren't the only reasons, but they're pretty substantial.
As for what the next kernel/OS should do, I'd say it's not enough to just exist and be good. You have to be used widely and have enough developers become familiar with it. If, for instance, some engineer at Facebook comes up with a nifty kernel and convinces them to start using it on all their servers, that kernel will probably be successful outside because there's suddenly a massive deployment of it.
Alternately, if you can get into a market that's less entrenched than the desktop, you may have a chance. We saw this to some extent with netbooks (some of the earliest ones shipped with Linux by default), we've definitely seen it with smartphones, and I have a feeling that we may see it in tablets. The problem with the desktop frequently comes down to: "Why can't it run Firefox and open my Word documents?"
1. As others pointed out, Plan 9 was not initially free. If you go back and look at the very oldest messages from the 9fans mailing list (http://9fans.net/archive/, starts in 1993) you'll see lots of messages from people just trying to figure out how to get a license. At the same time, you could get Linux for free or very cheap.
2. Plan 9 is unfamiliar for new users. Face it: most people define "intuitive", "powerful", and "useful" as "that thing I'm already used to". Programming in Plan 9 is pretty similar to programming Unix, and the shell feels much the same, but you still need to learn new concepts and people don't like that.
3. Plan 9 is not Unix. People have, from the beginning, wanted to reshape Plan 9 in the image of the Unix/Linux environments they are familiar with, even when it doesn't make sense. They want Emacs or Vim, without having even tried Acme or sam. They want bash, ssh, X11, Firefox, and GNOME. Some of this software, like ssh, X11, and even Vim, have been ported or re-implemented because they're useful for interoperability with Unix or simply because somebody wanted it bad enough to do the port (Vim).
Those aren't the only reasons, but they're pretty substantial.
As for what the next kernel/OS should do, I'd say it's not enough to just exist and be good. You have to be used widely and have enough developers become familiar with it. If, for instance, some engineer at Facebook comes up with a nifty kernel and convinces them to start using it on all their servers, that kernel will probably be successful outside because there's suddenly a massive deployment of it.
Alternately, if you can get into a market that's less entrenched than the desktop, you may have a chance. We saw this to some extent with netbooks (some of the earliest ones shipped with Linux by default), we've definitely seen it with smartphones, and I have a feeling that we may see it in tablets. The problem with the desktop frequently comes down to: "Why can't it run Firefox and open my Word documents?"
I don't use Plan 9 much because it lacks a modern web browser, though I miss it dearly. I get some comfort on Linux and Mac OS X by using Russ Cox's excellent port of the Plan 9 tools to Unix[1]. To me, the most important Plan 9 tool is of course, the editor, Rob Pike's acme[2].
[1] http://swtch.com/plan9port/
[2] http://acme.cat-v.org/
[1] http://swtch.com/plan9port/
[2] http://acme.cat-v.org/
Could you talk about the editor? Without knowing the editor specifically, it'd would seem at a severe disadvantage to either editors with much large communities (vi, emacs) or editors that are much more modern (textmate, sublime?).
As an Acme user, I most appreciate the window management. I have no trouble keeping all 20+ source files of a project open at once, each with its own spacial position I can quickly return to. It's easy to expand a buffer just a little bit so I can look at function prototypes in a .h file while coding in another window. If I want to open another file, I just right-click it in the directory listing.
The command language is powerful enough to do what I want day-to-day. It's easy to apply an editor command across every open buffer, if you need to refactor for instance. Like emacs, you can write applications which run in Acme; we have a mail client, news reader, CD player, and IRC client (among others).
When it comes time to compile, I can execute a "mk" command from within Acme by simply typing "mk" anywhere and executing it with the middle mouse button--this isn't just for mk, you can do that with any command. It'll put the output in a new buffer, and if there are compilation errors, you just right-click on the filename:line-number (foo.c:42) and Acme instantly jumps you to that line of the file.
There are more cool things about Acme, but I can't sit here and type all day! It's basically what you get when you take the Unix concept "It's all just text" and make an editor out of it: text is content, text acts as commands, text is for searching.
The command language is powerful enough to do what I want day-to-day. It's easy to apply an editor command across every open buffer, if you need to refactor for instance. Like emacs, you can write applications which run in Acme; we have a mail client, news reader, CD player, and IRC client (among others).
When it comes time to compile, I can execute a "mk" command from within Acme by simply typing "mk" anywhere and executing it with the middle mouse button--this isn't just for mk, you can do that with any command. It'll put the output in a new buffer, and if there are compilation errors, you just right-click on the filename:line-number (foo.c:42) and Acme instantly jumps you to that line of the file.
There are more cool things about Acme, but I can't sit here and type all day! It's basically what you get when you take the Unix concept "It's all just text" and make an editor out of it: text is content, text acts as commands, text is for searching.
> It's easy to apply an editor command across every open buffer, if you need to refactor for instance.
As as example:
Edit X/.* / ,s,loginAdmin,loginIdiAmin,g
I edit this text (in a guide file for the current directory) to suit my current need; highlight it by dragging while the left mouse button is down; and then middle-click anywhere on the highlight to run it. After I run it, every open buffer that was changed gets a dirty-bit marker, and I can either middle-click the word Putall (usually in the top row) to save all the files' changes, or Undo (in any buffer's tag) to undo all of the changes across all buffers.
Edit is a separate executable which Acme runs. It talks behind the scenes to all the control files Acme publishes for the files it edits, just like any program you could write yourself. So the editing features are not built into the Acme executable, and are independently changeable. This outsourcing of even core (to other editors) functionality inverts the emacs approach, which brings everything into a big global elisp space.
X/.* / says to address every open buffer, since .* matches any pattern. There should not usually be a space after the asterisk, but HN's formatdoc makes the following text italic and removes the asterisk if I don't put a space there. (In Inferno Acme this particular case appears to work anyway, probably because of the space after the filename in buffer tags.)
,-before-s says to edit the entire content of the buffer, not just a highlighted section.
s,loginAdmin,loginIdiAmin, is a tasteless replacement command in Edit's dialect of sam (and in ed, sed, vi, and vim). These commas could be replaced by any character, as long as that character is not in the set of characters to be replaced, or in the replacement set.
g-after-, says to replace every instance of loginAdmin, not just the first.
As as example:
Edit X/.* / ,s,loginAdmin,loginIdiAmin,g
I edit this text (in a guide file for the current directory) to suit my current need; highlight it by dragging while the left mouse button is down; and then middle-click anywhere on the highlight to run it. After I run it, every open buffer that was changed gets a dirty-bit marker, and I can either middle-click the word Putall (usually in the top row) to save all the files' changes, or Undo (in any buffer's tag) to undo all of the changes across all buffers.
Edit is a separate executable which Acme runs. It talks behind the scenes to all the control files Acme publishes for the files it edits, just like any program you could write yourself. So the editing features are not built into the Acme executable, and are independently changeable. This outsourcing of even core (to other editors) functionality inverts the emacs approach, which brings everything into a big global elisp space.
X/.* / says to address every open buffer, since .* matches any pattern. There should not usually be a space after the asterisk, but HN's formatdoc makes the following text italic and removes the asterisk if I don't put a space there. (In Inferno Acme this particular case appears to work anyway, probably because of the space after the filename in buffer tags.)
,-before-s says to edit the entire content of the buffer, not just a highlighted section.
s,loginAdmin,loginIdiAmin, is a tasteless replacement command in Edit's dialect of sam (and in ed, sed, vi, and vim). These commas could be replaced by any character, as long as that character is not in the set of characters to be replaced, or in the replacement set.
g-after-, says to replace every instance of loginAdmin, not just the first.
* It's not enough to be better to displace something ubiquitous (as unix like systems are today). You likely have to be orders of magnitude "better".
* Do not be hostile to your potential users. (The community that formed around Plan 9 as it went open source were quite hostile, there's no need for public beatings just because someone suggests to port X11 to Plan 9 even if it's a bad idea).
* Do not be hostile to your potential users. (The community that formed around Plan 9 as it went open source were quite hostile, there's no need for public beatings just because someone suggests to port X11 to Plan 9 even if it's a bad idea).
> The community that formed around Plan 9 as it went open source were quite hostile
I remember at FOSDEM a few years back, there was this Spanish dude and some of his friends, who were frothing-at-the-mouth fans of Plan 9, and, as they became progressively more inebriated in the place where a bunch of us were staying, he kept ranting louder and louder (and more by himself) about the perceived injustices and deficiencies of a world where Linux was more popular than something so beautiful, so elegant, as Plan 9.
It was ... a bit disturbing to watch. That kind of passion should be reserved for relationships with other people.
I think part of the problem with its diffusion was that it only became free software a decade after Linux, with no clear niche to attack (see: Crossing the Chasm) and make its own.
I remember at FOSDEM a few years back, there was this Spanish dude and some of his friends, who were frothing-at-the-mouth fans of Plan 9, and, as they became progressively more inebriated in the place where a bunch of us were staying, he kept ranting louder and louder (and more by himself) about the perceived injustices and deficiencies of a world where Linux was more popular than something so beautiful, so elegant, as Plan 9.
It was ... a bit disturbing to watch. That kind of passion should be reserved for relationships with other people.
I think part of the problem with its diffusion was that it only became free software a decade after Linux, with no clear niche to attack (see: Crossing the Chasm) and make its own.
I think I know who you're talking about; we have people who get way too excited about Plan 9. Oddly enough, the people who get the most frothy about it often don't run it themselves (the guy you saw, for instance, if I'm guessing correctly).
I like how you use "perceived" to modify Linux's deficiencies but "frothing-at-the-mouth" to describe individuals whose perspectives differ from yours. It's just so nicely objective.
Reading comprehension: "perceived" refers to the "injustices of a world ..." in my comment. Also, I've met plenty of people who disagree with me who don't froth at the mouth. For instance, BSD vs Linux used to be a Topic of Debate on the internet, and often the BSD guys would be fairly rational about what they preferred (of course some of them frothed too, just like some of the Linux fans).
You're right. We were assholes. We still are.
Plan9 doesn't replace Linux-the-kernel; it contains its own kernel, but there exists a port of the Plan9 utilities to the Linux kernel, replacing the GNU utilities (I'm not sure if this is complete).
For what it's worth, I use wmii on Linux, which uses the Plan9 model for configuration. It makes it super-scriptable and really easy to use.
For what it's worth, I use wmii on Linux, which uses the Plan9 model for configuration. It makes it super-scriptable and really easy to use.
> why aren't we all using Plan 9
Plan 9 wasn't always free.
Also, its GUI sucks. That's sort of important for end users.
Plan 9 wasn't always free.
Also, its GUI sucks. That's sort of important for end users.
On that note what are some common misconceptions, myths and FUD surrounding Plan 9? I just get the impression that's it's a pretty amazing operating system that never took off... And considering you are a Plan 9 user I suspect you don't think poorly of it either.
For instance, many people think Plan 9 development hasn't progressed since 2002, because that's the date of the 4th edition release on Wikipedia. The truth is that following the 4th edition, development switched to a rolling model in which patches are integrated and a new ISO is built daily.
Another is that there are no "decent" editors. For many people, the definition of "decent" means the executable must be named "vim". As I've said elsewhere, Plan 9 actually has a port of Vim, but if you skip our excellent native editors to use Vim, it's like visiting a foreign country and eating only McDonalds because the local cuisine is unfamiliar.
Another is that there are no "decent" editors. For many people, the definition of "decent" means the executable must be named "vim". As I've said elsewhere, Plan 9 actually has a port of Vim, but if you skip our excellent native editors to use Vim, it's like visiting a foreign country and eating only McDonalds because the local cuisine is unfamiliar.
Reading through the archives of the Plan 9 mailing list at http://9fans.net/archive you can follow along with the progress of Linux and the web as they completely displaced and then decimated operating systems research, culminating in famous Pike's utah2000 paper. You see each casual user show up on the mailing list demanding "modern" features, arguing about the license, screeching about security "holes" they don't understand, before, ultimately, declaring that they are retreating to Linux (or, later, Mac OSX), where at least they can play Flash games and login to turbotax.com and watch Youtube videos.
I wish it had stuck.
In a related vein, I idly wonder if there's a project around intended to bring useful security to a practical Unix derivative. Nobody uses a big timesharing box any longer (for all reasonable definitions of nobody); and the protections mooted to keep "users" away from "wheel" are basically pointless and counterproductive in a world where attacks come from outside. Apple's code-signing is one reaction to this new reality; what's the current status of capability based systems?
In a related vein, I idly wonder if there's a project around intended to bring useful security to a practical Unix derivative. Nobody uses a big timesharing box any longer (for all reasonable definitions of nobody); and the protections mooted to keep "users" away from "wheel" are basically pointless and counterproductive in a world where attacks come from outside. Apple's code-signing is one reaction to this new reality; what's the current status of capability based systems?
> the protections mooted to keep "users" away from "wheel" are basically pointless and counterproductive in a world where attacks come from outside.
Attacks may come from the outside, but they usually exploit code running on the target. IIRC, Apparmor is an implementation of what you seek - an easy way to limit what any given executable can do, in addition to what its process credentials can do.
Attacks may come from the outside, but they usually exploit code running on the target. IIRC, Apparmor is an implementation of what you seek - an easy way to limit what any given executable can do, in addition to what its process credentials can do.
You can do quite a bit in Linux with CGroups and SELinux. Projects making good use of those are Fedora, Systemd and Chromium browser.
I'll check it out. Next up, doing away with POSIX.
POSIX defines a pretty good framework, which is why Plan 9 is POSIX-ish. They changed things that they thought needed improvement. I just wanted to point out that doing away with POSIX merely to do away with POSIX isn't necessarily wise; if you don't have a better idea to use instead, you'll just end up reimplementing much of POSIX under another name.
I sent an email to Bell Labs a couple of weeks ago suggesting that Plan 9 be released as "public domain" code. I even suggested that this could be a great way to honour the late Dennis Ritchie (who worked there, of course), getting the code "out there" for all and sundry to use, no strings attached. Unfortunately, I didn't get a reply, so I guess the email was deleted without being read. ( Probably thought "Arrrrgh! Another one of those P.D. zealots!" ) ( And they'd be right.... ;) )
I just think it is TRAGIC and a HUGE waste that such an elegant and beautifully-designed OS as Plan 9 continues to basically sit in a backwater, ignored and unused by almost everyone. And it is sitting there when I am convinced that a P.D. release would see its use rocket into the stratosphere.
What would be the harm in releasing it to the public domain? It is already open-source so it's not as if any revenue would be lost. It would be a good P.R. opportunity for Bell Labs too (and as I say, a nice way of honouring D.R.
Let's face it - if Unix itself had been released as P.D. in the first place, then there would have been no need to reinvent it (as with the BSDs and Linux). It could simply have been continually improved upon. That's where I'm "coming from", as it were.
SQLite shows what is possible with P.D. code. It is apparently used in darned-near every smartphone out there, so it's not as if companies won't use P.D. code if it is good enough. If it meets their needs, they will go for it.
I just think it is TRAGIC and a HUGE waste that such an elegant and beautifully-designed OS as Plan 9 continues to basically sit in a backwater, ignored and unused by almost everyone. And it is sitting there when I am convinced that a P.D. release would see its use rocket into the stratosphere.
What would be the harm in releasing it to the public domain? It is already open-source so it's not as if any revenue would be lost. It would be a good P.R. opportunity for Bell Labs too (and as I say, a nice way of honouring D.R.
Let's face it - if Unix itself had been released as P.D. in the first place, then there would have been no need to reinvent it (as with the BSDs and Linux). It could simply have been continually improved upon. That's where I'm "coming from", as it were.
SQLite shows what is possible with P.D. code. It is apparently used in darned-near every smartphone out there, so it's not as if companies won't use P.D. code if it is good enough. If it meets their needs, they will go for it.
The LPL which Plan 9 now uses is basically equivalent to the BSD licence. It's non-viral.
The linked text is from the 90s. Not exactly news. But Plan 9 was a big improvement over Unix. Unfortunately, good things are often ignored.
A lot of the ideas in Plan 9 were ported to Linux. UTF-8, the /proc filesystem, and the idea of union filesystems. Also Plan 9 is arguably better because of what's not in it http://c2.com/cgi/wiki?WhatIsNotInPlanNine
/proc in Linux is nothing like /proc in Plan 9 though. Not only that the exported files are completely different conceptually and in their internal format, but on Linux I can't bind /proc from another box and do remote debugging with tools that know nothing about where the process runs.
Also Linux union mounts are clunky and not as useful as they are in Plan 9 because you can't have private namespaces if you are not root.
Also Linux union mounts are clunky and not as useful as they are in Plan 9 because you can't have private namespaces if you are not root.
> Unfortunately, good things are often ignored
...which is why we're still using Unix.
...which is why we're still using Unix.
Phew, Nostalgia indeed. I looked a Plan 9 back in late 90's when we were doing research for alternative OS's and ways of sharing stuff securely across a network without the cruft of DFS...
It had a lot of promise. What did become of it I wonder?
It had a lot of promise. What did become of it I wonder?
Coraid ships ATA over ethernet storage based on Plan 9.
Bell Labs still uses plan 9 internally and develops it.
9front is a community fork of Plan 9 with a bunch of interesting changes.
There's a small but interested community of die-hard plan 9'ers that care about it, and the principles it set forth. A lot of it came from some very good, very sane development with people who often spend more time thinking than coding (a virtue we could all benefit from I think)
Bell Labs still uses plan 9 internally and develops it.
9front is a community fork of Plan 9 with a bunch of interesting changes.
There's a small but interested community of die-hard plan 9'ers that care about it, and the principles it set forth. A lot of it came from some very good, very sane development with people who often spend more time thinking than coding (a virtue we could all benefit from I think)
it's a shame the first paragraph is exactly what we're once again moving away from. all hail cloud computing
And the relationship to Inferno is...?
Inferno is kind of like Plan 9 running on a VM, with its own peculiarites like a really nice shell language. Having a VM, versus integrating with the host os like plan9port or cygwin, lets you use new features of the os like directory binding and the /env directory of shell variables. There's an os command to run programs on the underlying host, be it windows, windows with cygwin, or linux.
Let me know when they release a decent editor for it...
As gchpaco points out, both sam and acme are pretty usable. Acme makes a good enough programming editor that I use it for all my coding at work, while I keep a tarball of the original sam port on a server for those times when I have to use a system with a crappy version of vi and no admin privileges to install something better.
Oh, and you can run Vim on Plan 9 now. But it's kind of like visiting a foreign country and eating only McDonalds.
Oh, and you can run Vim on Plan 9 now. But it's kind of like visiting a foreign country and eating only McDonalds.
I used emacs for 11 years (93-04) and then acme-like editors (wily, plan9port acme, Acme SAC, Inferno acme) for 8 years (04-). Acme (especially guide files) made a distinct and pervasive change to my working style that emacs never did: sped me up, prevented me from forgetting, gave me help just when I need it, and reduced errors. Inferno's VM gave me a minimal unix environment whose executable and my scripts I can take via usb to clients' machines.
Is there any articles about workflow/philosophy of sam ? I recall stumbling upon few videos, too introductory to be interesting compared to the emacs/vim-fu we're used too nowadays.
http://doc.cat-v.org/plan_9/4th_edition/papers/sam/ reproduces the original paper by Rob Pike, which goes into some detail, and at length. http://sam.cat-v.org/ collects links to sam implementations, papers, and paraphernalia (such as ssam, which I originally wrote with Russ Cox). To better learn sam in a workaday role, figure out why the sam idioms at http://sam.cat-v.org/cheatsheet/ work (I have Acme versions of many of these at https://raw.github.com/catenate/acme-fonts/master/test/1/acm...).
Sam and acme are both very good; they're weird, certainly, and very different from editors before and since but they are quite nice to work in. At least the equal of vi.
I tried very seriously to use Sam instead of vi. My main criticism of it is that you have to be a pixel-perfect mouse acrobat to use it efficiently. I'm not pixel-perfect. I couldn't use the graphical parts of Sam, and that kind of negated all the rest of it. It did have some very interesting (to me, as a programmer) ways of doing things, including structural regular expressions.
It is surprisingly demanding of mice; you need to have a three button mouse and ideally with a separate button, as chording on the mouse wheel can be error prone. I try to switch now and again but I never really stay; particularly with acme I find I like the way wily (a nominal clone) did the current working directory better; easier to create utility files.
But it is a really good editor, just not to my taste.
But it is a really good editor, just not to my taste.
"My main criticism of it is that you have to be a pixel-perfect mouse acrobat to use it efficiently."
That was my major complaint about Plan 9 in general. As far as I could tell, it really wanted me to run with a one-handed keyboard and mouse.
...that plus the fact that Bell Labs invented "Not Invented Here" Syndrome.
That was my major complaint about Plan 9 in general. As far as I could tell, it really wanted me to run with a one-handed keyboard and mouse.
...that plus the fact that Bell Labs invented "Not Invented Here" Syndrome.
Sam and acme do away with almost all the cursor movement commands and keystrokes of other editors, and replaces them with the mouse (to move the cursor around, just point and click, simpler and faster) and structured regular expressions (to select text segments in a document, then run commands across just those). They even use mouse chords for common operations such as cut, paste, and run a command, which are so muscle-memory to me now they don't interrupt my stream of thought.
I've done quite a bit of poking around in Plan 9, but of course I don't know all of it. I've hacked in the kernel and worked on the 64-bit version as well, I've fooled with the compilers, and I've hacked on the window manager.
If anyone wants to ask questions about some aspect of Plan 9, I'll do my best to answer--and if I can't, I bet others can jump in and take over. It would be great to clear up some of the misconceptions, myths, and FUD!