EDIT: It turns out the article does talk about process migration, but still doesn't answer the distributed computation question.
"Process migration is also deliberately absent from Plan 9. Although Plan 9 makes it easy to instantiate processes where they can most effectively run, it does nothing explicit to make this happen. The compiler, for instance, does not arrange that it run on the CPU server. We prefer to do coarse-grained allocation of computing resources simply by running each new command interpreter on a lightly-loaded CPU server. Reasonable management of computing resources renders process migration unnecessary."
EDIT2: Ah, there's no automatic thread distribution. But you can fake it but forking multiple processes on multiple CPU servers and sharing their address spaces. Does this mean you have to write your own CPU server allocator?
"Plan 9 does not implement lightweight processes explicitly. We are uneasy about deciding where on the continuum from fine-grained hardware-supported parallelism to the usual timesharing notion of a process we should provide support for user multiprocessing. Existing definitions of threads and lightweight processes seem arbitrary and raise more questions than they resolve. We prefer to have a single kind of process and to permit multiple processes to share their address space. With the ability to share local memory and with efficient process creation and switching, both of which are in Plan 9, we can match the functionality of threads without taking a stand on how users should multiprocess."
Vmware and other virtualization vendors as well as the various cluster computing solutions are capable of live process migration, checkpointing and a ton of other nice features that Plan-9 simply doesn't have because at the time it was to be an improvement on Unix and 'Beowulf' was still just the name of a character in a story, Amazon was a figment of Jeff Bezos' imagination and the Google guys were still playing with their Lego.
To really revive Plan-9 would imply diverting resource from a lot of projects that have progressed far beyond where Plan-9 has been stuck for well over a decade. So as much as I love the whole idea behind Plan-9 and the way they've made a better unix I fear that they will never be able to get the kind of push they need to gain parity. Pity, really.
Plan-9 could have been where Linux is now if they had caught the wind at the right time. Community is the single most important factor in whether or not a technology will succeed in the longer term or not. Linus Torvalds beat all of the incumbents by doing one simple thing: opening up the source right from day #1 when the barrier to entry was sufficiently low that he got buy-in from a lot of capable people.
I'm not so sure. I wouldn't make that statement about Java for example. Technologies that succeed in the longer term have some merit to them. If it was just about community, Lisp would have ceased to exist, and yet you typed your comment in a web app written in a Lisp.
Plan 9 is the Lisp of operating systems. Why does my gut say Plan9-as-a-service is an undervalued startup idea?
The lisp eco-system is more like a collection of communities of very small (individuals?) sub-communities.
What technology underpins the web-app here has very little to do with the success of the community interacting here, though for sure there are many more lisp capable programmers here than on most other programmer hang-outs (lambda the ultimate excepted).
With virtualisation, its hardware requirements are no longer a dealbreaker.
With the rise of Go, I've been wondering if perhaps deep within Google there's a quiet use of Plan 9.
Plan 9 did implement lightweight processes by the time it was open sourced in 2000 using coroutines (http://man.cat-v.org/plan_9/2/thread) which were a C port of the primitives used in the Alef programming language, which never made it to open source land. Alef appeared in 1992.
The first 'ok to use commercially' release was in 2000, by the Linux had eaten up any market that Plan-9 could have conceivably had.
$ cl -addr sources.cs.bell-labs.com:564
9p> ls -l extra/X11.iso.bz2
-rw-rw-r-- rsc sys 24878378 X11.iso.bz2
9p>
that didn't sink plan9. what sank plan9 was that linux was there and was "good enough", and that it took a full decade to realize that the concepts of plan9 can't be backported to unix/linux piecemeal. that they fit much better together in a coherent system that didn't carry the baggage of unix (the root user, for example). this is what the original plan9 papers were trying to say: it's a rethinking, you have to cut the cord to eliminate the baggage. the baggage has proven sufficiently heavy that more than 20 years later you're not seeing private namespaces in linux. instead you see fully virtualized instances of the operating system -- with all the baggage that they carry -- and most efforts are focused on making them work efficiently, rather than on inventing something truly original.that said, if plan9 was open sourced in 1995 and had taken over, we wouldn't be talking now about a linux behemoth bolting systemd onto itself, but a plan9 one. successful software grows itself into morbidity. plan9 would've been no different.