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

Unikernels: The Next Stage of Linux's Dominance [pdf]

cs.bu.edu

Post reply on HN
Print view View original

41–50 of 104 posts

Re: Unikernels: The Next Stage of Linux's Dominance [pdf]

#41

Post by mirceal »

c0l0 wrote: post #9
rapsey wrote: post #3

> Unikernels have demonstrated enormous advantages over Linux in many important domains, causing some to propose that the days of Linux's dominance may be coming to an end. Where are unikernels widely used?

I don't think that this statement describes the reality we live in. To me, unikernels feel quite a bit like statically linked server binaries running under an unprivileged UID - but you're choosing not to trust Linux' (or any other kernel's) user separation facilities, but your hypervisor's domU separation facilities instead. In exchange, you lose virtually all of your existing OS's amazing debugging and performance…

i think this kindof misses the mark. A unikernel is both the kernel (just the things you need) + app together. It’s build for one thing: whatever the app is doing.

Tooling/Perf/etc is not needed when running (do you really want to debug in production) but tooling can be used in the process of development.

Why consider unikernels? 1) they’re stupid fast. You have only the things you need (booting in nanoseconds? yepp) 2) small attack surface (because you only have your app that’s the only attack surface. you don’t have cruft that build up in you os/kernel over years) 3) light resource usage (you could run thousands of these on the same physical machine) 4) true isolation via the hypervisor

definitely worth keeping an eye on the developments in this space

Re: Unikernels: The Next Stage of Linux's Dominance [pdf]

#42

Post by panpanna »

mtgx wrote: post #27

I'd rather see unikernels written in Rust or any other memory-safe language. If we're going to start from scratch with this, let's do it right this time. 70%-90% of bugs seem to be memory-related. Let's end that with a little bit of effort upfront for much fewer headaches in the long-term. https://twitter.com/LazyFishBarrel/status/115341007092920320... https://www.zdnet.com/article/microsoft-70-percent-of-all-se... h…

We need Rust to mature a bit before we can do that.

Everything looks great on surface but as soon as you start doing low level coding a lot of issues pop up and you need the nightly compiler and xargo and some undocumented library for the boot sequence and whatnot.

TL;DR: great idea. Let's just wait 2 years

Re: Unikernels: The Next Stage of Linux's Dominance [pdf]

#43

Post by madmax96 »

panpanna wrote: post #42
mtgx wrote: post #27

I'd rather see unikernels written in Rust or any other memory-safe language. If we're going to start from scratch with this, let's do it right this time. 70%-90% of bugs seem to be memory-related. Let's end that with a little bit of effort upfront for much fewer headaches in the long-term. https://twitter.com/LazyFishBarrel/status/115341007092920320... https://www.zdnet.com/article/microsoft-70-percent-of-all-se... h…

We need Rust to mature a bit before we can do that. Everything looks great on surface but as soon as you start doing low level coding a lot of issues pop up and you need the nightly compiler and xargo and some undocumented library for the boot sequence and whatnot. TL;DR: great idea. Let's just wait 2 years

Would you happen to have a link to some sources describing some of these issues?

Re: Unikernels: The Next Stage of Linux's Dominance [pdf]

#44

Post by panpanna »

madmax96 wrote: post #43
panpanna wrote: post #42

Earlier quoted context omitted.

We need Rust to mature a bit before we can do that. Everything looks great on surface but as soon as you start doing low level coding a lot of issues pop up and you need the nightly compiler and xargo and some undocumented library for the boot sequence and whatnot. TL;DR: great idea. Let's just wait 2 years

Would you happen to have a link to some sources describing some of these issues?

Choose any "let's write an OS in Rust" project that has recently been featured on HN. Then try to follow it using the stable compiler (sudo apt install rustc) and see what happens.

Maybe "work in progress" better describes the situation. We need to wait for the language to stabilize, then the tooling and finally the libraries before starting a huge project like writing an OS.

Re: Unikernels: The Next Stage of Linux's Dominance [pdf]

#45

Post by rwmj »

panpanna wrote: post #39
antsoul wrote: post #30

Earlier quoted context omitted.

How do they relate to microkernels ? Since last HN post about GNU Hurd, I'm wondering why not try to join this Free microkernel project instead of looking in another kernel's direction ?

Architecturally, microkernels and unikernels are direct opposites. Unikernels strive to minimize communication complexity (and size and footprint but that is not relevant to this discussion) by putting everything in the same address space. This gives them many advantages among which performance is often mentioned but ease of development is IMHO equally important. However, the two are not mutually exclusive. Unikernel…

Right answer.

While a unikernel might be structured to some extent internally into modules, it's basically all linked into a single blob and running in a single address space. Some programming languages may support some kind of PL-level separation, but there is no hardware enforcement. In the case of what Ali is doing because all the code is written in C (it's all Linux, glibc and memcached) there is neither software nor hardware separation internally.

Re: Unikernels: The Next Stage of Linux's Dominance [pdf]

#46

Post by imbriaco »

mirceal wrote: post #41
c0l0 wrote: post #9

Earlier quoted context omitted.

I don't think that this statement describes the reality we live in. To me, unikernels feel quite a bit like statically linked server binaries running under an unprivileged UID - but you're choosing not to trust Linux' (or any other kernel's) user separation facilities, but your hypervisor's domU separation facilities instead. In exchange, you lose virtually all of your existing OS's amazing debugging and performance…

i think this kindof misses the mark. A unikernel is both the kernel (just the things you need) + app together. It’s build for one thing: whatever the app is doing. Tooling/Perf/etc is not needed when running (do you really want to debug in production) but tooling can be used in the process of development. Why consider unikernels? 1) they’re stupid fast. You have only the things you need (booting in nanoseconds? yepp)…

> Tooling/Perf/etc is not needed when running (do you really want to debug in production) but tooling can be used in the process of development.

Whether or not you want to debug in production, reality often means that you will see things in a live environment that you will not see in other environments.

Unikernels are very interesting and have a number of compelling attributes, but let's not pretend that the current state of available tooling for troubleshooting, instrumentation, and general debugging isn't a challenge.

Re: Unikernels: The Next Stage of Linux's Dominance [pdf]

#47

Post by majewsky »

pjmlp wrote: post #38
majewsky wrote: post #31

Earlier quoted context omitted.

Great, now I have to learn a new set of debugging capabilities for every language in my heterogenous stack.

Or you, just get to used to heterogeneous monitoring tools like DataDog and Prometheus.

Prometheus is great, but it won't tell me why that container gets "no route to host" when taking to that service. That's when I need a shell for running traceroute, tcpdump etc.

Re: Unikernels: The Next Stage of Linux's Dominance [pdf]

#48

Post by pjmlp »

majewsky wrote: post #47
pjmlp wrote: post #38

Earlier quoted context omitted.

Or you, just get to used to heterogeneous monitoring tools like DataDog and Prometheus.

Prometheus is great, but it won't tell me why that container gets "no route to host" when taking to that service. That's when I need a shell for running traceroute, tcpdump etc.

That was just a possible example.

If you want a shell, that is what stuff like JMX, or server side REPLs are for.

"Lisp at NASA: using a REPL to debug Deep Space 1 while it was 100 million miles away"

http://www.flownet.com/gat/jpl-lisp.html

Re: Unikernels: The Next Stage of Linux's Dominance [pdf]

#49

Post by ggm »

Long ago, an OS I worked inside had a tool which took shared library indirect calls, and wired them out so you did not have a nested indirect function call cost, but went direct from the call to the backend without the pass-through the null function mapping into the specific .so library. It made things faster by one layer of the onion skin.

Strip, as a UNIX tool removes the textual crap in a debuggable binary, to leave behind only the bits you needed.

It feels to me like if you can do runtime code call checks, and confirm which actual calls you make, then stripping the bits of libc and associated libraries out, being left with only the strictly required calls, and then by extension the syscalls, and then by extension the kernel elements, is actually possible a lot of the time.

So, library -> reduced library -> reduced calls -> reduced syscalls -> reduced kernel state is a sequence or set or something, of applied minimisations which can be done, if you can predict all the call paths in your code and their dependencies.

But then its not a generic OS any more: its an application specific binding to a general purpose CPU.

Why not go all the way, and work into the ALU and remove the bits you don't need? And then go into the micro code, and the associated FPGA, and everything else..

Re: Unikernels: The Next Stage of Linux's Dominance [pdf]

#50

Post by mirceal »

imbriaco wrote: post #46
mirceal wrote: post #41

Earlier quoted context omitted.

i think this kindof misses the mark. A unikernel is both the kernel (just the things you need) + app together. It’s build for one thing: whatever the app is doing. Tooling/Perf/etc is not needed when running (do you really want to debug in production) but tooling can be used in the process of development. Why consider unikernels? 1) they’re stupid fast. You have only the things you need (booting in nanoseconds? yepp)…

> Tooling/Perf/etc is not needed when running (do you really want to debug in production) but tooling can be used in the process of development. Whether or not you want to debug in production, reality often means that you will see things in a live environment that you will not see in other environments. Unikernels are very interesting and have a number of compelling attributes, but let's not pretend that the current…

hah. they're a new technology/approach. of course there are going to be challenges.
Post reply on HN