What seemed intriguing to me was that for the last 8 years with all the linux/unix around, I never came across any references in - books/blogs/articles.
link: http://en.wikipedia.org/wiki/Plan_9_from_Bell_Labs
- Eric S. Raymond
It's worth noting that Plan 9/Inferno are cited pretty regularly in computer science papers and a number of the ideas of P9 have been absorbed by Linux, such as representing 'everything' with the filesystem. Last I checked, the 2.6.x kernels also support the P9 protocol.
"...for the last 8 years" Yeah, well, Plan 9 hasn't had an official release since 2002.
That said, Plan 9 seems to see continued use in some niches. For example, Plan 9 has been ported to Blue Gene.
(What's kinda cute is that the Plan 9 kernel (including TCP and such) has fewer lines of code than the Ruby parser, 8000 vs 10000, IIRC.)
The first obvious answer (also mentioned in other comments) is because "Systems Software Research is Irrelevant". See Rob Pike's paper by that name: http://herpolhode.com/rob/utah2000.pdf
To the reasons Pike offers there, I'll add:
1. The companies that owned the software had poor strategies for encouraging widespread adoption, if that was even ever their goal.
2. The first dot-com boom ca 2000 greatly expanded the IT / programmer workforce and (I claim) significantly dumbed it down. The advantages of a new operating system lack economic impact until a huge number of programmers are trained to use those advantages. We have huge sunk costs invested in maintaining a huge supply of mostly weakly skilled programmers and admins, a sort unlikely to adapt to and adopt a new OS.
3. In a related way, the sectors that could in principle drive something like Plan 9 adoption are heavily invested, by now, in massive amounts of bloatware that, dysfunctional as it is, is both critical and non-portable.
4. Modern hardware is fast enough that fairly high level programming languages and environments tend to dominate. These often include a "least common denominator" view OS capabilities so that programs port easily among Windows, Linux, Unix, MacOS, etc. This hurts demand for OS features other than the "least common denominator".
-----------------
Why it might get better:
Notice that none of the reasons listed above apply to a market niche like "the OS for Google's clusters" or, say, massive clusters providing an SQL-based RDMS.
On clusters like that:
1) You don't need a mass audience of buyers for a new OS. One or a few big customers will be plenty.
2) You don't care about hordes of cheap, weakly skilled programmers. Paying experts is peanuts compared to your hardware, power, and real estate costs.
3) You're not tied to bloatware. You need only run a few things very, very well.
4) You don't need to do "least common denominator" programming and, in fact, any new OS feature that can save you some $s per server-hour is potentially a huge win.
My betting money is that Pike et al. will produce YANOS (yet another new OS), quite possibly mostly written in the Go programming language, really well suited for huge compute clusters.
Can't wait to see what kernel programming in Go will be like.
Check out the blurb on their main page (http://www.dragonflybsd.org/):
The DragonFly project's ultimate goal is to provide native clustering support in the kernel. This involves the creation of a sophisticated cache management framework for filesystem namespaces, file spaces, and VM spaces, which allows heavily interactive programs to run across multiple machines with cache coherency fully guaranteed in all respects. This also involves being able to chop up resources, including the cpu by way of a controlled VM context, for safe assignment to unsecured third-party clusters over the internet (though the security of such clusters itself might be in doubt, the first and most important thing is for systems donating resources to not be made vulnerable through their donation).
If anyone truly "gets" cloud computing, it's these guys. And they have the advantage of not being quite as big of a jump from existing systems as Plan 9 is.
It's not at all clear that this is desirable. I'd much rather have thin (one or two socket) systems with a reliable network and write for distributed memory. Even four-socket systems have quite unpredictable performance characteristics.
Cache coherency gets increasingly expensive with scale. At some point, the costs exceed the benefits.
The location of point depends on lots of things, but if you're on the other side....
Also, there are many kinds of coherency.
However, there are some things that came from Plan 9 that are very much mainstream, the most notable being UTF-8 which was invented by Ken Thompson and first implemented on Plan 9. Linux's clone(2) system call is obviously inspired by Plan 9's rfork.
And one could argue that the Go language is a spin-off of Plan 9 as it's substantially implemented by Plan 9 refugees to Google (Ken Thompson, Rob Pike, Russ Cox) and is explicitly descended from other languages that came out of Bell Labs (Newsqueak, Alef, Limbo). Of course whether Go will be a success is an open question, but I think its chances are as good as any other equivalent language.
Not substantially powerful or enough libraries for use in web dev (yet, this could change).
Global GC (inappropriate for the niche it's ostensibly targeting).
Overly opinionated about concurrency. (C++ and Java are the gold-standard for library-centric concurrency methodologies)
Go sits in an uncanny valley.
The last time I checked concurrency isn't possible with standard C++. And multi-threaded programming in Java has been called many things, but "gold-standard" isn't one of them.
[1] You can implement asynchronous message passing on top of synchronous message passing, but not the other way around. Presumably the "least opinionated" language would simply give you the concurrency primitive with which you can implement the greatest number of other concurrency primitives, which presumably[2] is locks.
[2] I could be wrong about this.
A lot of the best libraries and concurrency approaches I've implemented in Clojure so far have been imports from Java. (NIO2 being one example)
If you don't know, then I can't tell you. People have been doing threading, re-entrant code, libevent/libev in C and C++ for decades. (cf. DragonflyBSD)
I didn't say it was trivial, just that it's an industry standard for when you need to get things done (TM).
DragonflyBSD, a project that was only started in 2003, has obviously not been around for "decades" so hardly serves to advance your claim.
They're not supposed to. They're systems programming languages. When you're writing a kernel or embedded software, having the language mandate some kind of concurrency model at the standards level is nonsensical.
I wasn't linking decades to DragonflyBSD, I was saying that the techniques and methods have been known and used for decades.
The original point, restated here for clarity is this.
Go was supposed to be a new-age systems programming language. Its current design (mandated concurrency model and global GC) preclude that from ever happening without fundamental changes.
Rust has a better chance of becoming the next systems programming language.
I don't know what your niche or corner of the realm of software is, but I get the feeling you're commenting on a field you have no substantial experience in.
It's evident to anybody with any real experience or wisdom concerning software that having choices like concurrency made for you at the language-level narrow the scope of usefulness for that particular language and pretty much precludes it from being a top-grade choice for embedded/systems development.
Example:
Were it not for the glut of hardware performance and memory capacity improvements in smartphones, Dalvik/java would've been impractical at best on Android. It's still a vastly inferior experience compared to the iPhone, which is obj-c with optional drop-down to C/C++.
And don't mention the NDK for Android, it's a bad joke.
Bootstrapping a runtime for a language that depends on a particular concurrency model irrespective of the problem at hand is stupid beyond my faculty for describing with words.
tl;dr good luck using Go for hard real-time systems.
Why do you think C++ achieved popularity so quickly? It was pliable to the demands of the problem being solved just like C at the expense of complexity.
However, if you define a systems programming language more broadly to include statically typed languages that compile to machine code with good support for a theoretically and practically sound concurrency model based on CSP, Go might very well be something worth investigating.
And I wouldn't say that C++ achieved popularity "quickly" inasmuch as according to Stroupstrup he started working on it in 1979 (http://www2.research.att.com/~bs/bs_faq.html#invention) but it wasn't in widespread use until the early/mid-1990's and wasn't standardized until 1998. By that timetable I'd say that Go has a few years yet before it can fairly be judged a success or a failure.
I don't care, that's not what I'm talking about.
I was talking about the use-case uncanny valley it sits in.
If you have a point unrelated to anything I said, use your blog. I've had enough grief from hackerne.ws over the past week that I have zero patience for someone using me as some kind of pontification aid.
I know what's involved in making a kernel, and what's typical for systems programming and embedded development today. I don't give a good goddamn what the devs of Go have to say about it.
Use case inappropriate. That's the last time I'm repeating myself.
> C++ and Java are the gold-standard for library-centric concurrency methodologies.
It's a standard, but it is not by any means the gold standard. Just about anything would be a better concurrency model. Also see "Threads Cannot be Implemented as a Library": http://www.hpl.hp.com/techreports/2004/HPL-2004-209.html
It's a product of their design decisions and has nothing at all to do with implementation or time.
Look at Rust if you want to see a realistic up-and-coming systems programming language.
>It's a standard, but it is not by any means the gold standard. Just about anything would be a better concurrency model.
Right, well get back to me when you write that multi-threaded web server in Python.
But the progress is quite impressive, and it might hit a niche for lots of people (those Zed Shaw tends to call "longbeards"). Unix systems programming is still dominated by C, as there aren't that many valid alternatives. Java is systems programming for the Java system, C++ is C++. Ocaml is probably one step too far for bit pushers. And then there's the pedigree of the developers.
I think within a year the language should have matured enough. If someone manages to come up with a "killer application" for it (c.f. RoR/Ruby or node.js/server-side Javascript), it might take off.
It might also end up like Modula-3.
I think it's mostly because of some internal and positioning issues. I haven't been following it recently, but I remember some problems with different standard libraries, D 1 vs D 2, and three compilers that each had issues. Maybe that's resolved, but it certainly didn't make things look too good.
Also, it seems to be more a successor to C++, which makes some people a bit distrustful. Yes, it's much cleaner, but also quite a bit more complex than C, and not a total programming environment as Java or C#. So it mainly gets its users from the C++ camp, which isn't the mightiest army nowadays (And whose Windows battalions aren't supported very well by D).
Go is in the news a lot because of its Google and Unix (Pike, Thompson) heritage, because it's a bit simpler (more C crossed with Python than ++C++), and because it has some prominent concurrency support, which is close to the current hype (every emerging language has to prove its mettle there).
By the way, don't read this as a value judgment. It's just a personal assessment why I think that Go is currently a bit more popular and will continue to be so.
From the language faq : http://wiki.github.com/graydon/rust/language-faq
"Have you seen this Google language, Go? How does Rust compare?
Yes.
Rust development was several years underway before Go launched, no direct inspiration.
Though Pike’s previous languages in the Go family (Newsqueak, Alef, Limbo) were
influential, Go adopted semantics (safety and memory model) that are quite unsatisfactory.
Shared mutable state.
Global GC.
Null pointers.
No RAII or destructors.
No type-parametric user code.
There are a number of other fine coroutine / actor languages in development presently.
It’s an area of focus across the PL community."I've also been in correspondence with one group at another company who have written close over 50k lines of Go code for their storage infrastructure. They're very happy with it. (Just rooting for a better garbage collector; it's coming.)
Despite its familiar appearance, Go represents a different approach to programming in general. One that I find personally refreshing, and it seems to be catching on.
That said, at our startup we use Go for all server side work and I wrote Go production code while still working for Google. In my little world it's very popular, the only other language we use is Javascript.
/snark
Also, does it solve any particular problem in such a way that it can't be ignored? Doesn't seem like it to me.
http://www.gnu.org/philosophy/plan-nine.html
Once it became "free" it had too little functionality.
There's too little of the software and it's not so easy to port the existing Unix/Linux software:
http://plan9.bell-labs.com/wiki/plan9/porting_alien_software...
Moreover, very, very little of the hardware is supported.
Incidentally, the 'crossing the chasm' approach would be to find some niche where a new OS could succeed - perhaps something where the network effects were less pernicious.
My own view is that Linux is Good Enough for most people. And that "good enough" beats "better", at least for most values of "better". This is an admission that "path dependence" matters for the operating system market, and that network effects can cause the appearance of market failure.
Plan 9 is still relevant and interesting and useful for some tasks. It may still be ahead of its time. Plan 9 has had data deduplication for about a decade, years before network data dedupe storage appliances became an important product. The Linux kernel is still struggling to figure out a decent way to implement union directories in filesystems, but unions have been working elegantly in Plan 9 since its early days.
- too weird - Plan 9 is very difficult to get used to as a user experience. Novel, fascinating, powerful, yes! But also minimal, impenetrable, and very very different from the UI you're used to as a Unix hacker.
- nonexistent marketing
- too hard to get into initially; I wish they had gone to a public source repository model earlier, although in all fairness the project predates a lot of this.
But, it was still an enormous success:
- UTF8 came from Plan 9
- Linux's clone syscall
- /proc
- numerous other minor things
The main thing I wish I saw more that was in Plan 9 was structured regular expressions. I'd love an awk based around them, or an ssam that didn't basically run sam on the file. The second thing I wish I saw more was Plan 9's per-process filesystem namespaces. Chroot and jail are crude hacks compared.
Not really, Ken Thompson certainly contributed to it, but they didn't invent it.
Key quote: "Looking around at some UTF-8 background, I see the same incorrect story being repeated over and over. The incorrect version is: 1. IBM designed UTF-8. 2. Plan 9 implemented it. That's not true. UTF-8 was designed [by Ken Thompson], in front of my eyes, on a placemat in a New Jersey diner one night in September or so 1992."
2. It's a research OS not necessarily meant for every day use.
The other possible place for a big breakthrough is mobile. For example, if all of your "apps" are in Java and those apps hardly ever touch traditional unix system calls, it is easy to knock a Linux or Windows OS out from the bottom of the stack.
1. lack of device drivers for commonly found hardware at the time.
2. Ugly looking graphics and desktops and difficult (relative to what was widely used at the time) to use as well.
IBM's use of Plan9 with BlueGene uses the server side benefits so they need only a small number of custom device drivers and the GUI is not used at all.
One was basing the machine on PPC processors initially, because it limited their audience. I thought it was a cool idea, but wasn't willing to buy outdated hardware to get the OS. Mac users at the time could have simply acquired the OS and installed it, but the number of mac users willing to do that wouldn't ever be large.
One was not supporting IDE when they ported to x86. When they finally went after a large market, they made sure that hardly anyone in that market COULD use it. I had to do a lot of finagling with my computer in order to install BeOS on it.
AFAIK Apple actually DID try to buy Be before going after NeXT once they realized that Rhapsody simply wasn't going to happen. I've heard a number of stories regarding this, and I don't know which to believe; I was informed that the Be CEO rejected Apple's offer. If someone has better knowledge of that part of history than I and can confirm or correct me, that would be appreciated :)
BTW, where you wrote Rhapsody you meant Copland. NeXTSTEP was renamed to Rhapsody (and then OS X) after Apple bought it.
You're probably also right about the reason for starting out with a PPC based system. I'd heard about a similarly sized offer for Be, as well as JLG's refusal.
There weren't a lot of realtime OS's out there, and still aren't -- BeOS could have been the next OS/2, only without IBM's marketing behind it. (Can anyone say, "Friendly fire?")
It's actually not that surprising since good design on its own is never a sufficient criteria for something to become mainstream.
Oh and I really like its name and the "Plan 9 from User Space" thing, especially after having seen the fabulous movie! But I think of it only as a cool thing to know, never seriously think about using it in place of a GNU/Linux or a *BSD. (same thing for Open Solaris too in fact)
* Licensing - Plan9 wasn't open when open was the in thing.
* No web browser - just as the web became a big thing, no web browser is a deathtrap.
* The gap is too great a leap - until the recent LinuxEMU almost NONE of your fave apps were available - unless you really like cmd line tools (I do :)
* Hard to justify in your organisation - when you're one of only 50 people in the world that know how to use an OS, making it part of your infrastructure is a huge risk.
That said, to suggest it is a failure is erroneous. We have at least one successful company using Plan9 in their hardware - Coraid. They have the commitment, income and a few of those 50 people to make it work for them. IBM also use it on Blue Gene and other super computers, as do Sandia National Labs, LANL and others around the world. It was also used at the Sydney Olympics to control the stadium lighting and Lucent use it in their cell phone masts in Real Time mode.
Come and chat to people in irc://irc.freenode.org/#plan9
Oh - there's also a fantastic port of many of the tools into Linux / BSD. http://swtch.com/plan9port I use them every day - Venti is particularly useful
To expand a bit, I think Plan 9 has potential in the world of scientific computing. There are a few things scientists expect on their supercomputers, and Plan 9 either has them or can have them without unreasonable effort. They include: MPI, Python (already available), Linux compatibility layer (exists), and FORTRAN 77 (this can happen if we reaallllly need it). Check out the HARE project, where Plan 9 was ported to the Blue Gene systems as part of the ongoing Fast-OS project, which aims to find a better OS for supercomputing. (Basically, Linux is too huge, whereas custom kernels are just too stripped down and customized. Plan 9 is small but general)
http://9fans.net/archive/2010/02/344
and