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

71–80 of 187 posts

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

#71

Post by pinopinopino »

rwmj wrote: post #37
pinopinopino wrote: post #36

Earlier quoted context omitted.

Really cool work! Is there really a support layer for Emacs in the kernel? Now the real question. You are statically linking against a modified glibc, so they make calls to your kernel library instead to the system call and you can do some nice optimizations along the way. Which I think make sense. I can see this is cool for things that directly interface to glibc, but do you think this is viable for applications usi…

At the moment you must go through glibc. For example issuing SYSENTER or INT 80h will not work. We have only run C applications so far, so I'm unsure how it will all work for servers written in other programming languages. I think applications which rely on complex multi-process middleware (like Java JBoss, etc) will be hard or even impossible to port.

Understandable, thanks for your answer!

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

#72

Post by bitcharmer »

ncmncm wrote: post #26

When I make a system where a unikernel could do the job, I usually want a full OS for program setup and initialization, and then an isolated core for the main loop, sharing (single-writer) memory pages with other, less performance-critical processes for logging, stats reporting, and any needed file system activities. The makers of top-performing NICs have been quite good at providing direct user-space access to their…

I don't think the tuning you refer to is sufficient to bring the platform noise to levels required for some workloads. You will still see a lot of system call interrupts, TLB shootdowns, timer events, etc. Funnily enough yesterday I published an article tangential to this problem field.

http://bitcharmer.blogspot.com/2020/05/t_84.html

I'm not an expert on unikernels but my assumption is that you will see none of that OS jitter.

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

#73

Post by rwmj »

wltprgm wrote: post #70
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-...

I'm not sure I can say anything intelligent about WASM in the regular kernel, but from a UKL point of view we're talking with Enarx and they're going to join us on one of our regular meetings in a few weeks. For more info on Enarx and web assembly see: https://www.youtube.com/watch?v=5wrQSe-IdMI

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

#75

Post by nabla9 »

perbu wrote: post #12

Unikernels are typically statically linked. Using copyleft code means the whole resulting binary is subject to copyleft. Free software is great, but not everyone is in the position where they can release all of their code all the time. For a unikernel to be viable it can't have copyleft code in it.

This is not categorically true.

Linux is licensed under GPL-2.0 WITH Linux-syscall-note.

>NOTE! This copyright does not cover user programs that use kernel services by normal system calls - this is merely considered normal use of the kernel, and does not fall under the heading of "derived work".

More generally can link LGPL code statically without making resulting binary subject to copyleft or releasing the source code. Increasing number of programmers don't know what object file is anymore (they didn't learn to program in C/C++) and this causes endless confusion.

https://www.gnu.org/licenses/gpl-faq.html#LGPLStaticVsDynami...

> For the purpose of complying with the LGPL (any extant version: v2, v2.1 or v3):

> (1) If you statically link against an LGPLed library, you must also provide your application in an object (not necessarily source) format, so that a user has the opportunity to modify the library and relink the application.

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

#76

Post by nabla9 »

dathinab wrote: post #38
lmm wrote: post #16

Earlier quoted context omitted.

Depends what you're using it for. If you're just running it as a server then (non-A) GPL code is fine since you're not distributing the program.

But what about the cloud and auto scaling wouldn't that count as distribution (through for internal use only)?

Internal use is not distributing.

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

#77

Post by k__ »

tasubotadas wrote: post #3
rwmj wrote: post #2

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

What is a unikernel and why it's good?

Think of it as "Your app runs like an operating system".

Instead of installing an OS and installing your app on that OS, the OS is a library you use to talk to the hardware.

It's good for two reasons.

First security, if you only use the HDD and network, you don't have to include code for display or mouse etc. which could be a security risk.

Second, it's faster, because you don't have to do syscalls, since your app IS the OS, syscalls don't need to get out of userspace.

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

#78

Post by nabla9 »

masklinn wrote: post #48
vbezhenar wrote: post #45

Earlier quoted context omitted.

You can write proprietary kernel drivers. Why can't you link user code with kernel? User code usually depends on POSIX interface and Linux is just one of the implementations.

> You can write proprietary kernel drivers. IIRC you can write proprietary kernel modules , which are loaded at runtime. > Why can't you link user code with kernel? User code usually depends on POSIX interface and Linux is just one of the implementations. Because the kernel is licensed under GPLv2. If you statically link to the kernel, then all interpretations of the GPL are that your work is a derivation and must be…

Linux is licensed under GPL-2.0 WITH Linux-syscall-note.

>NOTE! This copyright does not cover user programs that use kernel services by normal system calls - this is merely considered normal use of the kernel, and does not fall under the heading of "derived work".

(even without actual syscall, you can consider unikernels as normal use of kernel)

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

#79

Post by MrBuddyCasino »

microcolonel wrote: post #67
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 c…

So, a niche technology for a handful of HFT firms, betting platforms and hyper-scale cloud vendors. Those already use non-mainstream tech (eg LMAX disruptor) to achieve max performance.

This is all nice and good, but the Unikernel guys claim since 20 years its the next big revolutionary thing. In the real world, the evolutionary approach using containers has turned out to solve the problems most people care about.

Don’t get me wrong, this is fascinating stuff. But there is a difference between „changes mainstream computing“ and „cool tech to shave off another millisecond of latency“.

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

#80

Post by brmgb »

masklinn wrote: post #52
reubensutton wrote: post #8

My gut instinct is always that using traditional kernels in a unikernel way is a bit suboptimal because it doesn’t become a “library operating system” in the same way that Mirage does.

While that's true, the flip side is that "traditional" kernels have much better hardware (and general) support because they benefit from the long history of the "main project". Stripping down traditional kernels to work as unikernels is not a new thing: https://github.com/rumpkernel/rumprun

Does it really matter ? Are people actually planning of running unikernel on bare metal a situation where you would need significant tooling to manage them ?

MirageOS was initially clearly designed to run on top of an hypervisor. The idea was going from host os, guest os and application to just host os and unikernel.

As I see it, it was a different way of solving the same problem containers are now used for : do you really need both a host os and guest os when all you want is isolation ? Using container is pushing isolation in the kernel while losing the actual virtualization (in a way merging host os and guest os) while unikernel is pushing the useful part of the guest os into the application (merging guest os and application) keeping the benefits of full virtualization. I think it's why Docker bought the company making MirageOS.

I don't really see where rump kernels sit there. Clearly there is interest as people are working on them but I fail to see where they would be useful.

Post reply on HN