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

Unikernels: The Next Stage of Linux’s Dominance (2019)

dl.acm.org

Post reply on HN
Print view View original

61–70 of 187 posts

Re: Unikernels: The Next Stage of Linux’s Dominance (2019)

#61

Post by rwmj »

joosters wrote: post #55
rwmj wrote: post #2

I'm one of the authors on this paper, so ask away if you have questions.

What are the plans regarding multithread / multiprocess support? On the face of it, multiprocess support might seem a bit stupid, but it would greatly help the porting of more complex applications. The 'processes' wouldn't need virtual address space or memory protection, just give them a block of memory and pick a CPU to run the code. If you have multithreading, do you need any scheduling code, or can you just pick a…

I don't know where things will go in the future, but now: Multiprocess no. fork() will fail. Pthreads works already.

Re: Unikernels: The Next Stage of Linux’s Dominance (2019)

#62

Post by rwmj »

transpute wrote: post #59
rwmj wrote: post #2

I'm one of the authors on this paper, so ask away if you have questions.

Thanks for taking questions. Are there outstanding work items for QEMU being statically linked with a unikernel?

It's not really something that anyone in the project has thought about. Running the vmlinux on baremetal is actually more interesting to us.

Re: Unikernels: The Next Stage of Linux’s Dominance (2019)

#63

Post by arbarb »

joosters wrote: post #55
rwmj wrote: post #2

I'm one of the authors on this paper, so ask away if you have questions.

What are the plans regarding multithread / multiprocess support? On the face of it, multiprocess support might seem a bit stupid, but it would greatly help the porting of more complex applications. The 'processes' wouldn't need virtual address space or memory protection, just give them a block of memory and pick a CPU to run the code. If you have multithreading, do you need any scheduling code, or can you just pick a…

UKL is multi threaded, not multi process because there is no fork. Plus it's a Unikernel i.e., just one process. You don't need any scheduling code, Linux does it like it does normally for kernel and user threads.

Re: Unikernels: The Next Stage of Linux’s Dominance (2019)

#64

Post by subaru_shoe »

rwmj wrote: post #60
MaxBarraclough wrote: post #57

Earlier quoted context omitted.

What do you make of the highly critical Assessing Unikernel Security paper [0]? Have things changed since its publication? [0] https://www.nccgroup.trust/globalassets/our-research/us/whit... , from https://news.ycombinator.com/item?id=19738905

I can't read that paper. Firefox says the HSTS cert is wrong. Edit: Thanks for the updated link. UKL can be compiled with usual hardening features like ASLR, stack hardening, RELRO. As I said here ( https://news.ycombinator.com/item?id=23202042 ) I'm dubious about the security story around unikernels, but most of the issues in this paper are not relevant to UKL specifically.

you wrote this paper but can’t figure out how to solve this issue? really?

Re: Unikernels: The Next Stage of Linux’s Dominance (2019)

#65

Post by MaxBarraclough »

rwmj wrote: post #60
MaxBarraclough wrote: post #57

Earlier quoted context omitted.

What do you make of the highly critical Assessing Unikernel Security paper [0]? Have things changed since its publication? [0] https://www.nccgroup.trust/globalassets/our-research/us/whit... , from https://news.ycombinator.com/item?id=19738905

I can't read that paper. Firefox says the HSTS cert is wrong. Edit: Thanks for the updated link. UKL can be compiled with usual hardening features like ASLR, stack hardening, RELRO. As I said here ( https://news.ycombinator.com/item?id=23202042 ) I'm dubious about the security story around unikernels, but most of the issues in this paper are not relevant to UKL specifically.

Very strange, it works fine for me regardless of browser.

Mirror: https://web.archive.org/web/20200311095425/https://www.nccgr...

Re: Unikernels: The Next Stage of Linux’s Dominance (2019)

#66

Post by FeepingCreature »

MrBuddyCasino wrote: post #54

> Unikernels have demonstrated enormous advantages over Linux in many important domains By domains, do they mean that as "actually in use in certain sectors in the industry" or "a prototype has shown that"? > causing some to propose that the days of Linux's dominance may be coming to an end Who exactly would make that claim? So, besides performance : what actual, real-life problems does this solve? I think there is s…

> Who exactly would make that claim?

Didn't you hear? Some.

Re: Unikernels: The Next Stage of Linux’s Dominance (2019)

#67

Post by microcolonel »

MrBuddyCasino wrote: post #54

> Unikernels have demonstrated enormous advantages over Linux in many important domains By domains, do they mean that as "actually in use in certain sectors in the industry" or "a prototype has shown that"? > causing some to propose that the days of Linux's dominance may be coming to an end Who exactly would make that claim? So, besides performance : what actual, real-life problems does this solve? I think there is s…

> So, besides performance: what actual, real-life problems does this solve?

Well, don't go jumping to "besides performance". Dennard scaling is dead, and the things that can interrupt your program in a full preemptive kernel system are myriad.

Furthermore, even if your application properly manages and produces backpressure, the OS can introduce buffering where you don't want it, often by necessity (to avoid massive context switch costs). Now, if you just want to manage backpressure over the network, an application-hosted networking stack is probably a fine solution, but if you want to accurately translate disk backpressure to network backpressure it gets more complicated.

There are heaps and heaps of ordinary programs written for preemptive systems that would see noticeable, tangible benefits to users if they were run instead on unikernels; but the main thing halting adoption is the inconvenience of adapting programs. I tried getting Capstan/OSv to work the other day and the documentation dragged me through several apparently-outdated methods of achieving the same thing, all of which failed in incomprehensible ways. Tooling for these things could use a lot of work.

Re: Unikernels: The Next Stage of Linux’s Dominance (2019)

#68

Post by smorrow »

perbu wrote: post #22
tasubotadas wrote: post #3

Earlier quoted context omitted.

What is a unikernel and why it's good?

Basically you replace the system calls into the kernel with library calls. So you end up with a single binary that contains both the application as well as the operating system functionality. This can lead to some rather spectacular performance benefits. One thing is that you remove the syscall overhead, but more importantly you can do a lot more optimizations at the compiler/linking steps. You can remove complex cod…

Bringing a new operating system to market is challenging, bringing a new operating system with a entirely different architecture is even harder.

Being actually different is one of the few things that gives someone a reason to look twice at the new system.

Re: Unikernels: The Next Stage of Linux’s Dominance (2019)

#69

Post by toyg »

FeepingCreature wrote: post #66
MrBuddyCasino wrote: post #54

> Unikernels have demonstrated enormous advantages over Linux in many important domains By domains, do they mean that as "actually in use in certain sectors in the industry" or "a prototype has shown that"? > causing some to propose that the days of Linux's dominance may be coming to an end Who exactly would make that claim? So, besides performance : what actual, real-life problems does this solve? I think there is s…

> Who exactly would make that claim? Didn't you hear? Some.

Top men. Top. Men.

Re: Unikernels: The Next Stage of Linux’s Dominance (2019)

#70

Post by wltprgm »

rwmj wrote: post #2

I'm one of the authors on this paper, so ask away if you have questions.

Correct me if I am wrong, Unikernels are basically allowing binary to run at Ring 0?

What do you think about WASM in the kernel with the same high level concept with Unikernel? link in the below

https://destroyallsoftware.com/talks/the-birth-and-death-of-...

Post reply on HN