
Harvey OS – A Fresh Take on Plan 9 - antonkozlov
http://harvey-os.org/
======
SwellJoe
So, a funny thing happened on the way to Linux dominance of the server: We
started container-izing things and focusing on building one-service per
container (or VM). Suddenly the OS matters a lot less; each container only
needs the libs and kernel services that it needs to do its job. It doesn't
need the whole OS and doesn't benefit from the whole OS being present.

I suspect there's an opportunity for a lot of alternative systems to make
inroads in that space. But, then again, if the OS doesn't matter...it may be
that we all just end up using the path of least resistance, which is almost
always a small Linux distro with all the stuff we're used to. But, for someone
that loves Plan 9 or Solaris or OpenBSD and wants to deliver service
containers, they can probably get away with deploying containers using those
systems without people balking at the idea.

~~~
api
Containers and the direction they're evolving is the revenge of Tenenbaum:

[https://en.wikipedia.org/wiki/Tanenbaum–Torvalds_debate](https://en.wikipedia.org/wiki/Tanenbaum–Torvalds_debate)

My take on that debate: They were both right, but they were optimizing for
different things.

Tenenbaum was right in a theoretical sense and an eventual sense. Microkernels
are better. Separation of concerns is better.

Torvalds was right in the early-mid 1990s and right in a pragmatic sense. More
monolithic (or vertically integrated) kernels are easier to build and ship and
are faster on smaller machines. A microkernel made little pragmatic sense on a
early-mid 90s box. But keep in mind that these machines were _far_ less
powerful than a Raspberry Pi. My first Linux machine was a 66mhz 80586 clone
with 32MB of RAM.

Once you have machines with dozens or even _hundreds_ of cores, NUMA, and that
host massively diverse multi-tenant work loads, microkernels start making a
whole lot of sense. Once you have to containerize apps for security, they make
sense too. They also make sense if we want to eliminate reboots, etc. They
make much more pragmatic sense now than they did in the 90s.

Ultimately microkernels or microkernel-like systems will win.

~~~
mwcampbell
What do containers have to do with microkernels?

If we're talking about BSD jails, Solaris/Illumos zones, and Linux cgroups +
namespaces, there are basically two scenarios: Either multi-tenancy is handled
through hardware virtualization (mainstream cloud providers), or all of the
containers are run on a shared monolithic kernel (Joyent's Triton, running
Linux binaries in containers via LX-branded zones on Illumos). I suppose the
former scenario could be seen as a vindication of microkernels, if you
consider the Xen hypervisor a microkernel. But that has nothing to do with
containers.

~~~
MustardTiger
>What do containers have to do with microkernels?

Xen is becoming a major OS, and it is a microkernel OS.

~~~
vertex-four
Containers are not VMs.

~~~
SwellJoe
But, they can be (and are) used in similar ways. I think it's reasonable to
talk about VMs and containers in the same conversation.

~~~
vertex-four
Sure, but the conversation brought up microkernels in relation to containers
specifically - which is nonsensical.

------
rminich
Hello. I'm the guy that funded the amd64 port of the Ken C compilers (later
used by the Go team) and amd64 port for Plan 9, did the Xen 2 and lguest ports
of Plan 9, wrote the first 9p file system implementation for Linux, and ran
the project that ported Plan 9 to 3 generations of the Blue Gene supercomputer
(to name a few Plan 9 things). I wanted to make a few comments about Harvey
since it came up here.

C compiler: yes, years ago, Ken C was faster than alternatives like gcc. To my
surprise, that's no longer true. A full build of all the plan 9 libraries,
tools, and kernels takes about 2-3 minutes with ken c, gcc, and clang. It's
why on every push to github we can do a full build with both gcc and clang
using travis. There's no longer a good reason to stick with the Plan 9 C
compiler and, once the Go team dropped it too, there were lots of good reasons
to move away from it. So we did. As the original paper from Ken pointed out,
it only ever produced medium quality code. It also had several bugs with
64-bit scalars that people had to work around in their C code. It was fast but
in the end not a very good compiler.

Unix wrinkles: there are so many, but just consider the sockets interface.
Sockets completely break the Unix model of named entities that you can open
and close and read and write. Sockets don't have names and are not visible in
the file system. It's a long list of what they got wrong and that's why, in
1978, other mechanisms were proposed (if you're willing to dig you can find
the RFC and you'll see ideas like /dev/tcp/hostname and so on). But to our
dismay (I was there at the time) the current BSD socket interface won. Many of
us were disappointed by that decision but it was the fastest way to get
network support into Unix.

On the acceptance of Harvey: Presotto and Hume showed up for our BOF at the
2015 Usenix in Santa Clara and were very supportive of what we are doing with
Harvey. Other former members of the Bell Labs community have been similarly
supportive.

On the logo: I'm glad people like it.

On the way forward: we welcome new contributors, there's lots of work to do.

~~~
h3ro
:(

------
rcarmo
I like the fact that this is happening, with a live Git repo and all.

9front is alive, sure, but bootstrapping things atop a modern compiler and a
(at least partially) Linux compatible ABI makes a lot of sense.

~~~
mapcars
I didn't get it, what could gcc/clang potentially bring to Plan9?

~~~
kruhft
Plan9 uses a different dialect of C written by Ritchie (his last compiler)
than most of today's software. Also, the standard library and programming
model are quite substantially different than the ANSI C model. There is
something on Plan9 called APE (ANSI Posix Environment), which is kind of like
WINE (an emulation layer, not an emulator or compatible ABI), for porting ANSI
C apps, but it's built with a rather old version of GCC and is far from
complete.

Meaning, most software won't run on Plan9 without major modifications, so
bringing a modern GCC/CLANG would give access to better compilation, but
really there needs to be more work on APE to get more software over (lots of
low hanging fruit there from what I've seen).

~~~
mveety
APE isn't anything like wine. It's just some libraries that give you a posix-
ish api. It also doesnt use GCC at all, it uses kencc (the native plan 9
compiler) and cpp.

------
stepvhen
For, and if anybody was wondering, the name is a reference to the Jimmy
Stewart movie "Harvey"[1] , in which Jimmy Stewart is a grown man who has an
imaginary best friend, a 6 foot tall bunny rabbit.

[1]:
[http://www.imdb.com/title/tt0042546/](http://www.imdb.com/title/tt0042546/)

~~~
toomanythings2
The Harvey character and shadow are one of the most creative things I have
seen in a long time. Bravo!

------
colindean
I can't think of Harvey without thinking "Crichton!"

[http://vignette3.wikia.nocookie.net/farscape/images/b/bd/Har...](http://vignette3.wikia.nocookie.net/farscape/images/b/bd/Harvey_2.jpg/revision/latest/scale-
to-width-down/150?cb=20070108032454&format=webp)

------
transfire
Hope this project makes real inroads!

------
rminich
w.r.t. the speed comment. The Plan 9 C compiler (which I've used for 20 years)
no longer has any speed advantage over, e.g., clang. And the code it produces
is not very good. Time to move on.

------
TheMagicHorsey
Aren't we all supposed to dream about unikernels moving forward anyway?

If I'm just using a library operating system that is linked directly into a
single unikernel that merges the application code and system code, then I
don't really care if I'm running on a hypervisor, on bare metal, or a host
operating system. I'm only using a few system capabilities, and I'm not really
taking advantage of other services running on the OS.

So I don't really care if the host OS is Linux, or Plan 9, or BSD. It just has
to be UNIX-y enough to host a VM for my unikernel.

~~~
ori_b
A unikernel isn't really much more than a weird system call ABI, though. There
are some APIs that are better performing than standard (eg, virtio vs sockets)
but that's a design issue, and operating systems can provide similarly
performing apis. For example, netlink.

------
gtirloni
_operating system that does away with Unix 's wrinkles_

What would those be?

~~~
ori_b
Ever taken a look at the sockets API?

------
hinkley
What's a pooka?

