Hacker News new | past | comments | ask | show | jobs | submit login
Designing Plan 9 (1990) (cat-v.org)
94 points by jeffreyrogers on Nov 22, 2014 | hide | past | web | favorite | 22 comments



Plan 9 did give us one thing that is used almost everywhere: UTF-8.

https://www.cl.cam.ac.uk/~mgk25/ucs/utf-8-history.txt


And Go by means of Limbo.


What I haven't understood about Plan 9 is if it does process migration. If you run a multi-threaded, computation-intensive process will Plan 9 automatically distribute the computation to all CPU servers and gather up the results?

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."


Unfortunately for plan-9 the world has moved on. Plan 9 will (and already has) influence many follow-ons but it is now behind the times in some aspects and still ahead in others.

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.


> Community is the single most important factor in whether or not a technology will succeed in the longer term or not.

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 community around Java is mindbogglingly large. That community was bought-and-paid for rather than grown organically but there are more ways than one to skin a cat.

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).


I don't know; I think that there's still space in the world for Plan 9 to compete. The fundamental ideas are sound, and the OS itself could be quite high-performance and secure (I won't write that it is, because AFAIK there's never been a comprehensive audit).

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.


If by "cpu server allocator" you mean cluster/distributed scheduler, no there's no such thing. late in the life of plan9 an attempt was made to craft something like that on top of it but by then both BL and the public had passed on the system. You have to remember that "cluster" as a term postdates this talk. A network in the view of Plan 9's creators in 1990 was composed of heterogeneous hardware and you made the choice beforehand whether you wanted to run on the big multicore system, the one with the faster I/O, or the one that displayed graphics. a homogenous entity of cheap COTS systems where everything looked the same and you made the choice where to run based on availability took another decade to materialize.

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.


Probably should mention Inferno https://en.wikipedia.org/wiki/Inferno_(operating_system) too, though afaik it doesn't have any kind of automatic distributed execution either.


The deluxe, and generally just unusual, hardware probably did a lot to kill Plan 9 adoption, or would have if the license hadn't got there first. Unix seems to have been successful partly because it ran on the hardware that people already owned, or hardware they would have been likely to buy anyway.


It wasn't even that deluxe at the time (especially not the display hardware). The hardware didn't help, the license didn't help, keeping it behind closed doors is what killed it.

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.


I think even then the weird mix of pro-windowing and anti-graphics app orientations were doomed to sink it. The fact that it was difficult to see how even a modern web browser would work (there were attempts, but half-hearted at best) really made breaking out of its limited niche very hard.


But if it had become sufficiently popular then someone would probably have just bodged X onto it (as unpleasant as that is to contemplate).


there was an x11 port to plan9. it's still there:

    $ 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.


Yes. So ironic that "worse is better", which was said about Unix vs Lisp Machines, worked this time again (Plan9 vs Linux).


what's this `cl` program ?


Apparently that port is used for the "plan 9 file service", so it's probably some kind of ftp-like client for 9p.


probably cl[ient] then




At a guess an alias for 'lc' (list contents).


I think `ls` is list as in unix and `lc` is list columns, just like `ls|mc` `list` | `multicolumn`.

There is no manual page for `cl`, so thats probably a typo.




Guidelines | FAQ | Support | API | Security | Lists | Bookmarklet | Legal | Apply to YC | Contact

Search: