

Designing Plan 9 (1990) - jeffreyrogers
http://doc.cat-v.org/plan_9/1st_edition/designing_plan_9

======
Joeri
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](https://www.cl.cam.ac.uk/~mgk25/ucs/utf-8-history.txt)

~~~
pjmlp
And Go by means of Limbo.

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

~~~
jacquesm
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.

~~~
yellow_and_gray
> 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?

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

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

~~~
jacquesm
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.

~~~
stormbrew
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.

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

~~~
f2f
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.

~~~
agumonkey
what's this `cl` program ?

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

~~~
agumonkey
probably cl[ient] then

