Hacker News Board Hacker News, browsed like a classic message board
Live data from Hacker News

My First Unikernel

roscidus.com

Post reply on HN
Print view View original

21–30 of 53 posts

Re: My First Unikernel

#21

Post by paulasmuth »

andolanra wrote: post #17
paulasmuth wrote: post #12

Earlier quoted context omitted.

No, this is fundamentally different from docker. Docker/cgroups/namespaces allow you to isolate multiple applications running in userspace on the same kernel to a very high degree. This gets rid of isolation and multiprocessing altogether and runs a single application without any kernel at all (i.e. with just a very limited amount of support code linked in). Put simply; the technology behind docker improves isolation…

I don't see how this, "...does the exact opposite," of what Docker does—both are very different approaches to the similar goals of having individual processes run in isolated ways. Docker does it by isolating individual running Linux processes under a single kernel, whereas unikernel-based systems do it by building those processes as lightweight programs that get compiled to their own kernel images and then running t…

Yes, you are right, this is not a binary classification and it really depends on the perspective. What I was trying to say is that - on some levels - the two approaches are almost antithetical.

Re: My First Unikernel

#22

Post by n0body »

interesting, although the old mantra of "hardware is cheap, developers are expensive" is still true. you could hire 10 perl/c/c++/javascript/php/etc dev with ease for your project, but struggle to find one ocaml dev. And even then your ocaml dev will need to know the mirage library, xen and have a good knowledge of way more stuff than your project scope

that said, it's still really cool, but it's not something i'd use, and especially not in production

Re: My First Unikernel

#23

Post by hderms »

paulasmuth wrote: post #10
krat0sprakhar wrote: post #9

Earlier quoted context omitted.

> If Ocaml can only handle one core and does not do SMP, how does it do in the cloud? +1 to this question? Any one experienced enough in OCaml to answer this?

One could argue that threading is not strictly necessary to utilize a multicore machine. A lot of applications (think web apps) can be implemented just fine as a single thread and then scaled up by increasing the number of processes (or the number of virtual machines in this case) rather than the number of threads. A lot of popular web frameworks follow this paradigm and I would guess that most application code runni…

You'd probably have to move more to a CSP type concurrency versus threads if you were to leverage multicore machines. Erlang doesn't allow individual processes to share memory with each other, but Erlang is undoubtedly a great platform to build apps in that make use of concurrency (depending on use case). Something tells me that the use cases for which one would use Mirage for would be those more likely to use Erlang-type concurrency semantics versus highly multithreaded code using shared memory.

Re: My First Unikernel

#24

Post by hderms »

andolanra wrote: post #15
paulasmuth wrote: post #6

This sounds like an awesome and fun project to hack on! However, optimizing around context switches and task preemptions is something you would usually do if your application is actually bound by IO/context switching, is extremely latency sensitive or when you are trying to squeeze the last bits of performance out of a machine. Why did you choose to build such a microoptimized system in a garbage collected language?…

Don't think of it as optimizing around context switches—think of it as just omitting what you don't need, and losing context-switches as a side benefit. A multi-user OS has a lot of stuff which might not be necessary for a single virtualized service (various security mechanisms, lots of file system niceties, running other services, &c), so writing a unikernel like this allows you to select exactly as much as you need…

Additionally, Linux wasn't as secure as it is now out of starting gates. It's a very effective and well-written piece of software, but there have been high profile bugs and exploits. C code isn't impossible to make safe, but there is an argument to be made that it needs more attention towards safety (and therefore developer time) than a language that makes certain types of bugs impossible. The space shuttle software was written in assembly language, but it damn sure had a ton of people working on it who valued safety (not necessarily security as we know it now) as one of the highest priorities.

Re: My First Unikernel

#25

Post by 616c »

krat0sprakhar wrote: post #9
616c wrote: post #7

So I have been following this stuff with a lot of interest, but I am not very familiar with Ocaml and have tried looking at Mirage docs with some limited downtime. If Ocaml can only handle one core and does not do SMP, how does it do in the cloud? Does this mean Mirage unikernels handle only one processor/core in Amazon and elsewhere?

> If Ocaml can only handle one core and does not do SMP, how does it do in the cloud? +1 to this question? Any one experienced enough in OCaml to answer this?

Yeah I am familiar with the theory of alternative methods in a general way (CSP, message passing between full or light procs, green threads, etc.) but what is the story with OCaml and Mirage. I am curious because if it is the same as OCaml I am curious how much performance can be eeked out of it without SMP.

Re: My First Unikernel

#26

Post by rjsw »

n0body wrote: post #22

interesting, although the old mantra of "hardware is cheap, developers are expensive" is still true. you could hire 10 perl/c/c++/javascript/php/etc dev with ease for your project, but struggle to find one ocaml dev. And even then your ocaml dev will need to know the mirage library, xen and have a good knowledge of way more stuff than your project scope that said, it's still really cool, but it's not something i'd us…

There is nothing stopping people from implementing something similar in other languages.

The developer using this doesn't need to know anything about Xen, they just see a single address space system that runs their code.

Re: My First Unikernel

#27

Post by Guvante »

paulasmuth wrote: post #18
andolanra wrote: post #15

Earlier quoted context omitted.

Don't think of it as optimizing around context switches—think of it as just omitting what you don't need, and losing context-switches as a side benefit. A multi-user OS has a lot of stuff which might not be necessary for a single virtualized service (various security mechanisms, lots of file system niceties, running other services, &c), so writing a unikernel like this allows you to select exactly as much as you need…

> so writing a unikernel like this allows you to select exactly as much as you need for your particular service. I agree this is a big upside of the authors approach. Less dependencies lead to fewer problems caused by external/upstream changes. > OCaml isn't all that much slower than C++. To use the Programming Language Shootout as a rough esimation[^1], it can even come close to matching C++ in certain programs, and…

> That's the beauty of having a kernel though. If one of those userland processes is broken it won't affect the whole system.

With a Unikernel there is nothing else to affect. You are running a virtual machine anyway so even if you kill the kernel you only took down yourself.

> This assumes that the OCaml compiler/interpreter and the hardware are free of bugs...

They are not free of bugs. For most purposes you can consider everything to have bugs in it. However there is a big difference between a compiler/interpreter bug (which usually just makes your system run differently) and a service bug (which can lead to all kinds of problems).

Re: My First Unikernel

#28

Post by n0body »

rjsw wrote: post #26
n0body wrote: post #22

interesting, although the old mantra of "hardware is cheap, developers are expensive" is still true. you could hire 10 perl/c/c++/javascript/php/etc dev with ease for your project, but struggle to find one ocaml dev. And even then your ocaml dev will need to know the mirage library, xen and have a good knowledge of way more stuff than your project scope that said, it's still really cool, but it's not something i'd us…

There is nothing stopping people from implementing something similar in other languages. The developer using this doesn't need to know anything about Xen, they just see a single address space system that runs their code.

i didn't say there was, but it's still complicating the task.

i'm not saying it isn't cool, but it's a very round about way of doing something, and as such it becomes more expensive in development time and skill required

Re: My First Unikernel

#29

Post by toolslive »

rjsw wrote: post #26
n0body wrote: post #22

interesting, although the old mantra of "hardware is cheap, developers are expensive" is still true. you could hire 10 perl/c/c++/javascript/php/etc dev with ease for your project, but struggle to find one ocaml dev. And even then your ocaml dev will need to know the mirage library, xen and have a good knowledge of way more stuff than your project scope that said, it's still really cool, but it's not something i'd us…

There is nothing stopping people from implementing something similar in other languages. The developer using this doesn't need to know anything about Xen, they just see a single address space system that runs their code.

for Haskell, there's HaLVM: https://github.com/GaloisInc/HaLVM

for Erlang, there's ErlangOnXen: http://try.erlangonxen.org/zerg

There are others, if you care to search for them.

Re: My First Unikernel

#30

Post by bincat »

616c wrote: post #7

So I have been following this stuff with a lot of interest, but I am not very familiar with Ocaml and have tried looking at Mirage docs with some limited downtime. If Ocaml can only handle one core and does not do SMP, how does it do in the cloud? Does this mean Mirage unikernels handle only one processor/core in Amazon and elsewhere?

I doubt. Here is another approach: http://erlangonxen.org/
Post reply on HN