

What People Like About the Plan 9 OS - rbc
http://www.plan9.bell-labs.com/wiki/plan9/what_do_people_like_about_plan_9/index.html

======
rdtsc
I was fascinated with Plan 9. It just has really cool ideas in its design.

It has been said before and I agree. The problem with Plan 9 adoption isn't
Plan 9. Plan 9 is beautiful. The problem is that Linux is quite alright as
well.

Also, Linux has drivers for more hardware when Plan 9 was ready to be played
with. Plan 9 doesn't. It is a chicken and egg problem. I remember trying Plan
9 and it just didn't have drivers for some of my hardware. It was like Linux
in back in the days.

~~~
derefr
I'm amazed that "drivers" are still a consideration in OS design anywhere
other than embedded systems. Why aren't we writing our operating systems to
target hardware-abstracting hypervisors yet? Isn't that an obvious separation
of concerns?

~~~
gizmo686
Isn't the BIOS supposed to be the hardware abstracting layer we run our
programs directly on? That doesn't work any more (because BIOS is a legacy
mess), so now we have kernels that act as the hardware abstraction, and write
operating systems on top of those. Of course, now you need to target you
operating system to a kernel.

~~~
derefr
Yes, the BIOS is exactly what's supposed to be doing the hardware abstraction,
such that jobs like "read a block from a block device" are done via _hardware
interrupts_ , not system calls. I think hypercalls are a good compromise,
these days; what is a hypervisor but a BIOS running on the CPU?

There are already specialty OSes that take this tack--things like Openmirage
([http://www.openmirage.org/](http://www.openmirage.org/)) and Erlang on Xen
([http://erlangonxen.org/](http://erlangonxen.org/)). It could be done with a
general-purpose OS just as easily.

~~~
shin_lao
The BIOS provides the programmer with basic I/O routines, but let's say
performance wise it's far from being very efficient... And access from
protected mode is quite tricky (but possible if you don't care about
performance, security and reliability, but FreeBSD does it routinely to guess
supported video modes from the graphic card).

When I read you, you seem to believe that writing to a disk (for example), is
just a matter of having a "driver". That might be possible in a world where
caching doesn't exist and where you don't have to support shitload of devices
that claim to be a disk but really aren't or other drivers trying to pretend
that they are a disk or other drivers trying to catch your writes to the disk,
but really, you don't need an os I guess, just something minimal with
hypercalls?

Tell me then, just as a thought experiment, if you get a kernel panic, what do
you tell to the disk controller? Not today?

A snarky comment, I know, but I happen to be a kernel programmer and reading
your comment was really annoying.

~~~
derefr
I'm assuming a full hypervisor, like Xen, which is basically a full-blown
kernel that does its own resource pooling and abstraction. A "disk" for Xen is
just like a "disk" for Linux--something that presents a disk-like interface in
its driver and nothing more.

Let me rephrase my previous idea. You have _two_ kernels. One is an
exokernel/library kernel, responsible only for managing the hardware[1]. It
only does things when it's called into. The other is a "userspace" kernel,
that does the virtual memory, process/thread management, etc. It's the one
that registers interrupt vectors.

You could do this to Linux, today. Rip all the stuff that starts the machine
and initializes the devices and abstracts them out, away from all the stuff
that touches userspace, and put an known ABI between them. Then, take
advantage of modern processors' specific support for hypervisors to make this
ABI more performant.

The important idea is not that "somebody else" deals with the "drivers and
stuff", leaving you free to write "just" an OS. Both the driver part and the
process part can be considered part of one OS, and you can't have just one or
the other, and likely the same vendor will be worrying about both. No, the
important part is that each is a _layer_ , which should be able to treat the
other layer as a black box with a known interface. In exactly the same way
that TCP doesn't care whether it's being carried by IP or NetBEUI, while IP
doesn't care whether it's carrying TCP or UDP, moving the driver part of a
kernel out into a hypervisor means that the process-management part doesn't
have to care what hardware-management part it's talking to, and vice versa. An
"OS stack", to match your "network stack."

Really, we already _have_ "OS stacks" in a sense -- that's when we run a full-
blown Linux kernel, running an (optionally paravirtualized) IA32/64 emulator,
running another full-blown Linux kernel, running your software. This just
eliminates everything redundant about that configuration, while keeping all
the advantages.

\---

[1] Notably, this also means that the outer kernel is responsible for
_permissions_ to the hardware. This means that each "inner kernel" running on
this hardware only gets a single effective permission-set; if the one process
on the inner kernel has access to a resource (a disk, say), then _every_
process on the inner kernel has access to that resource, because the inner
kernel doesn't deal with the hypercall--it goes directly to the hypervisor.

This would have been a terribly big deal 10 years ago. Now? Who runs things as
more than one mutually-untrustworthy user within the same virtual machine any
more? Today, if you want separate security contexts, you use containerization.
Which is to say, you get the hypervisor, not the OS, to enforce resource
permissions.

~~~
shin_lao
Windows has got a Hardware Abstraction Layer:
[http://en.wikipedia.org/wiki/Hardware_abstraction#Microsoft_...](http://en.wikipedia.org/wiki/Hardware_abstraction#Microsoft_Windows)

Until Windows 4, even the graphic part wasn't in the kernel, eventually they
had to compromise for performance reasons.

I don't know Linux well enough to answer your question about Linux, but I'm
pretty sure that concerns are well separated, however they are so fundamental
to what the OS does that you can't just rely on some "external library".

An Hypervisor doesn't touch any hardware stuff. Basically if you consider
kernel mode to run in ring 0 and user mode to run in ring 3, the Hypervisor
runs in ring -1 and just deals with privileges to sum up. At to no instance
does the hypervisor deal with the hardware such as disks or network cards.
That code lies in the ring 0 kernel. All the Hypervisor says is ... "yeah ok,
ring -1 kernel, you can play in that sandbox".

For example when you run a VM, the VM emulates hardware but the OS running in
the VM stills need drivers...

Now it's not that easy to separate the OS from the drivers, because each OS
has got some ideas about how the cache should work and how disks should be
managed and what is actually a NIC.

When you write an OS you make your best so that writing a driver can be done
to someone else and the code can be reused (e.g. for writing to multiple OS)
but you CAN'T expect to use a common framework because well, at some point you
will want to do DMA and you don't want to tell your user that their Intel SSD
will run at 10 MiB/s.

~~~
yuhong
Windows 4 != NT4

------
rbc
There are Amazon AMI's for plan 9, called plan9-fossil. You don't use ssh to
get in though. You need to use the plan 9 "cpu" command, using the "ec2" user
and a random password printed on the instance console/system log. I have a
plan 9 host running under VirtualBox that I used to access my Amazon Plan 9
host. It worked just great. Another little item is you have to allow TCP
access to ports 17010 and 17013 on the instance.

~~~
sanderjd
Are there any ports of the `cpu` command for other operating systems?

~~~
rbc
Use drawterm. It is a X11 application that allows you to connect to a remote
Plan 9 server.

~~~
rbc
Here's the command line I used:

drawterm -c 54.245.176.166 -u ec2 &

Note that I put it in the background. You will want to adjust your server
address as appropriate.

I should add that drawterm just opens a blank Plan 9 desktop after you
authenticate. You have to open a new command session on your own. A right
click brings up a menu, you want to choose "new". This will turn the pointer
to a "+" shape. You then right click and hold, stretching out the command
window until it's the right size. When you release the right click, you will
have a rc shell to type commands into.

~~~
sanderjd
Neat! Thanks for the instructions - that's definitely the easiest way to play
around with Plan9 that I've come across (but I guess I haven't been looking
too hard...)

------
D9u
[http://www.plan9.bell-
labs.com/wiki/plan9/what_do_people_lik...](http://www.plan9.bell-
labs.com/wiki/plan9/what_do_people_like_about_plan_9/index.html)

[http://plan9.bell-labs.com/wiki/plan9/faq](http://plan9.bell-
labs.com/wiki/plan9/faq)

[http://plan9.bell-labs.com/wiki/plan9/](http://plan9.bell-
labs.com/wiki/plan9/)

    
    
        Connection refused: plan9.bell-labs.com:80
    

I can't access any of the above... :(

~~~
rbc
I guess news.ycombinator.com sent them more traffic than they are accustomed
to. Oops... Sorry guys.

~~~
tomphoolery
Solution: stop webserver? :P

~~~
rbc
What do you bet their web server fell over? It smells like some kind of a
process failure.

~~~
D9u
It's still inaccessible for me.

I tried different browsers, proxies, Tor, and tried accessing from a remote
shell running lynx. No go...

It's too bad, as I am a distro-hopper, and would like to be able to access
Plan9 related online compendia if I'm going to be using Plan9.

    
    
        Edit:
    

Thanks for the link @ nanofortnight

~~~
seryoiupfurds
I think that server is pretty skunkworks, and when it goes down on a weekend
it doesn't get restarted until somebody comes in on Monday.

------
carterschonwald
Woah: I didn't realize there was still active work on plan 9. They've
participated in Gsoc the past four years even!

------
a0
One of my favorite features of Plan 9 is the extremely powerful filesystem
abstraction through the 9p file protocol. It is incredible how clean becomes
the design of the applications and the communication between the modules with
a simple file interface. Currently I'm working on potential extension of this
idea - an ontology-based virtual filesystem, where the files are replaced by
objects and the organization is defined by relations, instead of the
hierarchical structures.

~~~
matiasb
9p is really cool. I've seen a lot of papers about it, and some experiments
done at university.

[https://code.google.com/p/diod/wiki/protocol#Sample_Session](https://code.google.com/p/diod/wiki/protocol#Sample_Session)

[http://graverobbers.blogspot.com/2007/08/v9fs-performance-
ve...](http://graverobbers.blogspot.com/2007/08/v9fs-performance-versus-
nfs.html)

[http://9p.cat-v.org/implementations](http://9p.cat-v.org/implementations)

------
rcarmo
Interesting. Serendipitously, I just came across some GSOC posts regarding
getting Java on it:

[https://groups.google.com/forum/m/#!forum/plan9-gsoc](https://groups.google.com/forum/m/#!forum/plan9-gsoc)

If that turns out OK and someone manages to port a browser over, it might be a
good environment to do run Clojure.

------
dasil003
I think to really understand what makes Plan 9 great requires a deep
understanding of Unix, but once you have a deep understanding of Unix...

~~~
iv_08
Plan 9 was basically the successor of Unix by the same research group, more
modern, taking the ideas of Unix further, a distributed operating system with
full network transparency, better shell (actually, rc already replaced the
Bourne shell in version 10 Unix) and lots of other goodies such as the
plumber. And it served as the "reference implementation" for UTF-8.

~~~
dasil003
I understand all that. My point was that if you know enough to appreciate Plan
9 then you know enough to take advantage of the *nix ecosystem as it exists
today, which is far too mature for Plan 9 to catch up to. We can always dream
though...

~~~
D9u

        lull them into thinking that Plan 9 is Just Another Unix.
    

From what I read, Plan9 has its own concepts which are not Unix analogues,
thereby discounting Unix knowledge due to divergence.

------
WasimBhai
Considering plan9 is so great for distributed computing, those with Big Data
experience, do you think it is only a matter of time before plan9 replaces
other operating systems being used in map-reduce, clustered environments?

------
tete
A bit sad that the page is down.

However, people interested into (vanilla) Plan 9 might also be interested in
this:

[http://code.google.com/p/plan9front/](http://code.google.com/p/plan9front/)

------
frozenport
Plan 9 was also slow and didn't support a normal version of GCC.

Developers! Developers! Developers!

~~~
weland
That's partly due to historical reasons I think. Some of the platforms they
intended to run Plan 9 on had very buggy GCC ports. It's also worth noting
that that the "native" Plan 9 compilers had some quirks of their own (see
[http://doc.cat-v.org/plan_9/4th_edition/papers/compiler](http://doc.cat-v.org/plan_9/4th_edition/papers/compiler)
). It was never really intended to be a very familiar Unix environment, and
they tried to straighten up a couple of things even in the way software is
written. There is a POSIX environment available (the APE) but I don't know
much about it, I never really tried it.

To be fair, between the "good enough" phenomenon and the licensing problems,
it never really took off, which is rather sad.

------
lectrick
It's a revolutionary OS hampered by licensing.

Open source the goddamn thing to save its ideas at this point before they are
lost to nerd-history and let's see what happens.

~~~
RamiK
Plan9 been free and open source for over a decade (2003). At first it was
released with some very unusual constraints(Lucent Public License v1.0). But
those were quickly lifted(Lucent Public License v1.02).

GNU's stance on the revised license seems mostly favorable with some mild
reservations:
[http://gplv3.fsf.org/wiki/index.php/Lucent_Public_License_ve...](http://gplv3.fsf.org/wiki/index.php/Lucent_Public_License_version_1.02)

