4 ms·

> Summoning a unikernel on-demand to service a single request has demonstrated to be plausible. Instead of leaving a long-running process running you have a hig

by temac 11y ago

> Summoning a unikernel on-demand to service a single request has demonstrated to be plausible. Instead of leaving a long-running process running you have a highly-restricted machine summon your application process in an isolated unikernel for a few milliseconds before it's gone. From a "far enough" pov (but not too far...), how is that system different from a kernel running processes on-demand? Why any replacement for the libc would contain less vulnerability? Same question for replacing a kernel with an "hypervisor". I feel I still don't know enough on these subject to think this whole game in the end consist in renaming various components, rewriting parts of them in the process for no real reason. But maybe this is actually it.

agentultra 11y ago
Why don't you read http://www.skjegstad.com/blog/2015/08/17/jitsu-v02/ http://www.skjegstad.com/blog/2015/08/17/jitsu-v02/ and decide for yourself? The gist of it is that for a typical DNS server you can boot a unikernel per-request to service the query instead of leaving a long-running process going on a typical server. You can boot these things fast enough to even map them to URLs and create a unikernel to serve each page of your site. It's hard to approach it from the perspective of what you already know to be true and reliable. It's still experimental and we've only begun to explore the possibilities.
- temac 11y ago
  Honestly to my untrained eyes, it stills looks like a weird operating system except more complicated, all of that to implement features you could have implemented more simply with a less crazy architecture that does not involve launching a program as if it was the complete system of a standalone computer. Now I'm not saying that it is bad to experiment, but if you don't come up beforehand with actual things to test that were not possible on current modern systems or at least substantially more difficult to do instead of quite the opposite, it's not a very useful experiment but just a curious contraption.
lmm 11y ago
> Why any replacement for the libc would contain less vulnerability? Because it would be written in better languages. > Same question for replacing a kernel with an "hypervisor". Because the hypervisor implements a much smaller, better specified API than a kernel does.

by temac 11y ago

agentultra 11y ago

Why don't you read http://www.skjegstad.com/blog/2015/08/17/jitsu-v02/ http://www.skjegstad.com/blog/2015/08/17/jitsu-v02/ and decide for yourself? The gist of it is that for a typical DNS server you can boot a unikernel per-request to service the query instead of leaving a long-running process going on a typical server. You can boot these things fast enough to even map them to URLs and create a unikernel to serve each page of your site. It's hard to approach it from the perspective of what you already know to be true and reliable. It's still experimental and we've only begun to explore the possibilities.

temac 11y ago
Honestly to my untrained eyes, it stills looks like a weird operating system except more complicated, all of that to implement features you could have implemented more simply with a less crazy architecture that does not involve launching a program as if it was the complete system of a standalone computer. Now I'm not saying that it is bad to experiment, but if you don't come up beforehand with actual things to test that were not possible on current modern systems or at least substantially more difficult to do instead of quite the opposite, it's not a very useful experiment but just a curious contraption.

lmm 11y ago

> Why any replacement for the libc would contain less vulnerability? Because it would be written in better languages. > Same question for replacing a kernel with an "hypervisor". Because the hypervisor implements a much smaller, better specified API than a kernel does.