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

31–40 of 104 posts

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

#31

Post by majewsky »

pjmlp wrote: post #16
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…

Except that those amazing debugging capabilities are also possible, as anyone that used Erlang, Java or .NET debugging capabilities in production is aware of.

Great, now I have to learn a new set of debugging capabilities for every language in my heterogenous stack.

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

#32

Post by vidarh »

rwmj wrote: post #25
vidarh wrote: post #24

Earlier quoted context omitted.

> The linking stage automatically removes all parts of Linux (eg. drivers) that are not needed. So does the normal kernel build process once you've specified which drivers you need compiled in. That's in no way unique to a unikernel approach. There'll be extremely little code that can be stripped from a unikernel that can not be stripped from a kernel built for the purpose of running a specific application. It's just…

That's not how most distro kernels are built, but sure you can build a custom kernel with everything statically linked in. What you can't do is link your application in as well and do whole-program optimizations on the whole binary, which is what Ali is trying to do here. We're also hoping that the eventual solution will be distro friendly enough that we can pack the "kernel library" into a future Fedora which you ca…

Of course it's not, but the comment I replied to was about whether using it to build binaries for extremely small embedded systems made sense. In that scenario a distro kernel from one of the desktop distros is a total non-starter.

If a few MB of space matters, then you'll want a suitably configured kernel that disables a ton of stuff that is totally irrelevant for such a system, and you'll need to take that configuration into account whether or not you're building a normal kernel or a unikernel, as it involves not just excluding drivers and the like, but disabling functionality that if left enabled will not get removed by the linker because there will be calls into it from code paths that are reachable.

Do that, and you'll find it is pretty straightforward to get a Linux kernel down under 1MB.

Now, it's possible your tooling makes that easier, but my point is that it is equally possible to disable those parts of the kernel for a non-unikernel system as well, and you're not going to make significant additional savings. And if you want to, then ditching glibc for one of the smaller libcs would be a better starting point.

This is not a criticism of this project - size is simply not what most people look to unikernels to address, especially not one built on a general purpose kernel.

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

#33

Post by geggam »

throwaway_391 wrote: post #26
squarefoot wrote: post #7

The article is Tl;Wbmloc;Dr (too long, way beyond my level of comprehension, didn't read), so forgive any stupid questions. Could the unikernel technology be used to build extremely small Linux distros that contain just the bare minimum to satisfy all dependencies for running say a single software or a small group of them. I'm not interested in virtual machines for network related services but rather in small embedde…

Alpine Linux is a reasonably small (20mb) Linux distribution, I've seen it run on bare metal but it's more common to see it in Docker environments. Building minimal bootable to be very small is possible, but is difficult in comparison to an apt install - I imagine for the most part porting docker container configs to a bootable OS might be the best approach for small-medium projects.

I miss Trinux ( ramdrive boot from floppy fits in 12MB ram OS )

http://trinux.sourceforge.net/legacy/

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

#34

Post by yjftsjthsd-h »

geggam wrote: post #33
throwaway_391 wrote: post #26

Earlier quoted context omitted.

Alpine Linux is a reasonably small (20mb) Linux distribution, I've seen it run on bare metal but it's more common to see it in Docker environments. Building minimal bootable to be very small is possible, but is difficult in comparison to an apt install - I imagine for the most part porting docker container configs to a bootable OS might be the best approach for small-medium projects.

I miss Trinux ( ramdrive boot from floppy fits in 12MB ram OS ) http://trinux.sourceforge.net/legacy/

I suppose Tiny Core Linux is the modern equivalent.

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

#35

Post by wwarner »

c0l0 wrote: post #9
rapsey wrote: post #3

> Unikernels have demonstrated enormous advantages over Linux in many important domains, causing some to propose that the days of Linux's dominance may be coming to an end. Where are unikernels widely used?

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.

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

#36

Post by pizzazzaro »

rapsey wrote: post #3

> Unikernels have demonstrated enormous advantages over Linux in many important domains, causing some to propose that the days of Linux's dominance may be coming to an end. Where are unikernels widely used?

Why would you do such a thing? Creating masses of crippled, non-general operating systems out of linux?! For the actually unheardof performance.

Basically, you've taken the whole /sbin/init link out of the OS init chain, and replaced it with... A single binary you may remember.

To do this took a little extra work. Your glibc and any other dependency ended up in kernel space.

Single-use virtual machines obviously have the biggest boost, but other uses exist. Your kerberos-daemon isolated into its own vm on the network. Someone's gotta serve network filesystems. Apache servers for various websites you may host - the possibilities are endless.

The processor itself has a Massive timesink for isolating kernel-space from user-space (even root is just another user at this level, I'm afraid). Even Server-side admins have simply gotten used to it - every application, server, program Ever runs on that user-space.

So you have a bunch of single use VMs... and that much "context-switching" between virtual-drivers and memory allocation on one side, and the actual server the vm is for on the other. Now these VMs are running on an OS's hypervisor with the same context-switching performance problem!

So, we package each vm as a unikernel - shove each virtualized server into the kernel. We avoid that context switching.

Build that kernel lean enough, and sometimes the unikernel VM can perform almost at baremetal speeds.

What if we did the same for the Host OS - built a hypervisor Unikernel to delegate hardware and nothing else? zomg folks are squeeing with excitement about a new way to frame building a lean system...

But it gets us compiling in-house again instead of using COTS (commercial, off-the-shelf software). Got an old Gentoo-user hanging around that can debug kernel code, harden the kernel against attack, and compile it all lean?

That guy is who we're gonna need to figure out what goes wrong with any of this. Because Murphy's law is unreliably unreliable, yet ultimately absolute.

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

#37

Post by kingraoul3 »

majewsky wrote: post #31
pjmlp wrote: post #16

Earlier quoted context omitted.

Except that those amazing debugging capabilities are also possible, as anyone that used Erlang, Java or .NET debugging capabilities in production is aware of.

Great, now I have to learn a new set of debugging capabilities for every language in my heterogenous stack.

Haven't you heard? Devs aren't going to need us any more. They've been telling us that since the 70's, at least!

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

#38

Post by pjmlp »

majewsky wrote: post #31
pjmlp wrote: post #16

Earlier quoted context omitted.

Except that those amazing debugging capabilities are also possible, as anyone that used Erlang, Java or .NET debugging capabilities in production is aware of.

Great, now I have to learn a new set of debugging capabilities for every language in my heterogenous stack.

Or you, just get to used to heterogeneous monitoring tools like DataDog and Prometheus.

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

#39

Post by panpanna »

antsoul wrote: post #30
rwmj wrote: post #21

Oh, it's a paper I am (rather peripherally) involved with. If you have questions then ask away, although it's possible I might not have all the answers ... Edit: In case you can't read the paper there's a copy here: https://www.cs.bu.edu/~jappavoo/Resources/Papers/unikernel-h... (Thanks anonymousDan in the comments below for linking to it)

How do they relate to microkernels ? Since last HN post about GNU Hurd, I'm wondering why not try to join this Free microkernel project instead of looking in another kernel's direction ?

Architecturally, microkernels and unikernels are direct opposites.

Unikernels strive to minimize communication complexity (and size and footprint but that is not relevant to this discussion) by putting everything in the same address space. This gives them many advantages among which performance is often mentioned but ease of development is IMHO equally important.

However, the two are not mutually exclusive. Unikernels often run on top of microkernels or hypervisors.

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

#40

Post by panpanna »

rwmj wrote: post #23
rapsey wrote: post #3

> Unikernels have demonstrated enormous advantages over Linux in many important domains, causing some to propose that the days of Linux's dominance may be coming to an end. Where are unikernels widely used?

To be fair that's not exactly what the paper says. It says that unikernels have demonstrated "enormous" advantages (a bit of an exaggeration), but they are not widely used right now and no one is claiming that.

I think it's fair to say that in certain scenarios they are very useful.

The original unikernel paper used a streaming media device as an example and the numbers they provided were really good.

Post reply on HN