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

51–60 of 104 posts

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

#51

Post by sp332 »

ggm wrote: post #49

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 lea…

You have to make sure your test cases exercise every possible code path. German demogroup .theprodukkt made a demo one time, .kkreiger, a first-person shooter game in 96kb. They used a technique like this to strip every line of source code that was not hit during a playtest. But the playtester didn't press the up-arrow in the main menu, so that doesn't work. More importantly they didn't get hit by any bullets, so in the final release the player is invulnerable because the code that handles damage was never compiled.

Edit: more informative link https://fgiesen.wordpress.com/2012/04/08/metaprogramming-for...

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

#52

Post by ggm »

sp332 wrote: post #51
ggm wrote: post #49

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 lea…

You have to make sure your test cases exercise every possible code path. German demogroup .theprodukkt made a demo one time, .kkreiger, a first-person shooter game in 96kb. They used a technique like this to strip every line of source code that was not hit during a playtest. But the playtester didn't press the up-arrow in the main menu, so that doesn't work. More importantly they didn't get hit by any bullets, so in…

Yes. And its almost impossible to do this without a huge investment in time and effort, except: If you use languages with FP, and are rigorous, then I believe (possibly wrongly) its actually somewhat simpler to understand because the style of coding in FP exposes much of this "better" than in classic imperative coding

So yes, I think you're right: great dream, hugely hard to do, if not actually impossible in most cases near as damnit, but there are places where program proofs take you to this, Military/Space/Medical needs to know the code calls don't have unexpected outcomes. And language choices which express as "how" you express code, can also help. Probably not enough.

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

#53

Post by vectorEQ »

all unikernels so far suck ALOT regarding security. wouldn't recommend any of them to run in any production environment unless you want to lose all of your data.

NCC group did a good article on unikernels and how crap they are if you want to know.

A better idea, like already suggested would be to create an OS which builds itself according to a target application and system, to host that application on said system specifically. that would reduce about as much code, but keep potential security mechanisms like aslr, stack protection , user / kernel separation etc. in tact. (now kernels / oses build to target system ,but not application! -> application would only use subset of kernel, and thus kernel can be built to target application, reducing kernel to whats needed).

don't try to be cheap for performance and skip security, we're not in the damned 80s anymore.

/endrant

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

#54

Post by ori_b »

wwarner wrote: post #35
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…

True, it's a different picture. It's about how to create a really efficient computing mesh. If unikernels are faster (they start faster, then they run faster), and simpler, and you offload security and topology to kubernetes (or some other orchestration system), then you have a superior system, both in terms of performance and in terms of control.

If you run under a vm, your competition is a process, not an OS. Your unikernel is effectively a process with a funny syscall ABI.

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

#55

Post by weberc2 »

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…

You're moving the goal posts and invoking a straw man. No one is advocating for "pretending", and the anti-unikernel argument is that the inherent cost of unikernels in general is the loss of kernel debugging tools; not simply that "right now the unikernel debugging experience is subpar".

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

#56

Post by arbarb »

vectorEQ wrote: post #53

all unikernels so far suck ALOT regarding security. wouldn't recommend any of them to run in any production environment unless you want to lose all of your data. NCC group did a good article on unikernels and how crap they are if you want to know. A better idea, like already suggested would be to create an OS which builds itself according to a target application and system, to host that application on said system spe…

If you read that article, they tested two unikernels and the key point was that unikernels don't implement security mechanisms present in a normal OS. This Linux Unikernel, otoh, does not delete any of that security functionality. The boot up code is the same, it just calls a specific code instead of bringing up the general userspace. Unikernels and security don't have to be mutually exclusive.

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

#57

Post by roddux »

vectorEQ wrote: post #53

all unikernels so far suck ALOT regarding security. wouldn't recommend any of them to run in any production environment unless you want to lose all of your data. NCC group did a good article on unikernels and how crap they are if you want to know. A better idea, like already suggested would be to create an OS which builds itself according to a target application and system, to host that application on said system spe…

I'd argue the Mirage Unikernel (built almost wholly in OCaml) is one of the most robust platforms out there. The NCC paper you talk about looks at two rather old fashioned unikernels in isolation. I don't think the idea of unikernels should be discarded because the current implementations are slightly lacklustre -- it just shows that there's a fair way to go yet.

>[..] A better would be to host that application and reduce the kernel to whats needed

This is a unikernel.

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

#58

Post by oblio »

ggm wrote: post #52
sp332 wrote: post #51

Earlier quoted context omitted.

You have to make sure your test cases exercise every possible code path. German demogroup .theprodukkt made a demo one time, .kkreiger, a first-person shooter game in 96kb. They used a technique like this to strip every line of source code that was not hit during a playtest. But the playtester didn't press the up-arrow in the main menu, so that doesn't work. More importantly they didn't get hit by any bullets, so in…

Yes. And its almost impossible to do this without a huge investment in time and effort, except: If you use languages with FP, and are rigorous, then I believe (possibly wrongly) its actually somewhat simpler to understand because the style of coding in FP exposes much of this "better" than in classic imperative coding So yes, I think you're right: great dream, hugely hard to do, if not actually impossible in most cas…

I think it's impossible, or close to it. Isn't it just another form of the halting problem? https://en.wikipedia.org/wiki/Halting_problem

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

#59

Post by NelsonMinar »

ggm wrote: post #49

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 lea…

That sounds a little like the ideas in the Synthesis kernel, the idea of the kernel JIT-compiling itself to optimize your code path.
Post reply on HN