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

71–80 of 104 posts

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

#71

Post by convolvatron »

weberc2 wrote: post #55
imbriaco wrote: post #46

Earlier quoted context omitted.

> 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".

in general right now, running on a full-featured monolithic kernel, the debugging experience is really pretty bad. especially in the target environment of horizontal clustered services or lots of little micro services.

so I actually believe there is an opportunity here to focus on the important pieces (network messages, control flow tracing, memory footprints, etc) after ejecting a huge amount of irrelevant stuff

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

#72

Post by sp332 »

oblio wrote: post #58
ggm wrote: post #52

Earlier quoted context omitted.

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

I'm not sure it's relevant. All real machines have limitations that we accept when we write programs and feed them data. Anyway just because you can't prove that all possible programs will or won't run correctly doesn't mean you can't prove this for a useful subset of programs.

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

#74

Post by o-__-o »

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…

This sounds a lot like an Ethereum dApp...

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

#75

Post by mlinksva »

roddux wrote: post #57
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 r…

The authors of the NCC paper are evaluating MirageOS as well. IIRC from listening to their talk on the paper and ongoing research https://www.youtube.com/watch?v=b68VFuB_y5M it's got more of the problems other unikernels do than I'd have assumed. I'm pretty ignorant, but the paper gave me the impression that there's a long (rather than fair) way to go yet, especially relative to seemingly widespread assumption that unikernels are inherently more secure.

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

#77

Post by spamizbad »

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…

Genuinely curious: Wouldn't the teeny-tiny "attack surface" at least mitigate attacks, and should one be successful on say a memcache server running inside a unikernel... what exactly can you do on a "rooted" machine that has no userspace tooling or libraries? Assuming it's running in isolation, it wouldn't be much different than breaking into a container through an unprivileged process, right?

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

#78

Post by imbriaco »

weberc2 wrote: post #55
imbriaco wrote: post #46

Earlier quoted context omitted.

> 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".

No, I'm not moving any goal posts. I was reacting to the statement "Tooling/Perf/etc is not needed when running". I'm not sure where you'd get the idea that I'm anti-unikernel, I just wanted to not disregard that challenge since it does matter.

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

#79

Post by imbriaco »

convolvatron wrote: post #71
weberc2 wrote: post #55

Earlier quoted context omitted.

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".

in general right now, running on a full-featured monolithic kernel, the debugging experience is really pretty bad. especially in the target environment of horizontal clustered services or lots of little micro services. so I actually believe there is an opportunity here to focus on the important pieces (network messages, control flow tracing, memory footprints, etc) after ejecting a huge amount of irrelevant stuff

Totally agree, there's definitely an opportunity there if the surface area of what the system is doing gets smaller. The big difference today is that it's a lot easier to compose a debugging suite using additional tools on top of a traditional host-based runtime for now.

Definitely excited to see how the technology evolves over the next few years. It hasn't moved as fast as I'd have expected over the last 2-3 years but I'd love to see that accelerate.

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

#80

Post by robto »

oblio wrote: post #58
ggm wrote: post #52

Earlier quoted context omitted.

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

The halting problem states that it's impossible to know if computation will terminate in the general case, but there are lots of specific cases where we can prove that it will terminate. The Idris language compiler (think haskell with dependent types) will actually warn/error if you've written a function that it can't prove will terminate. It's actually really cool! If you're interested in learning more, I'd check out any talks by Edwin Brady or pick up his book[0]

[0]Type-Driven Development with Idris

Post reply on HN