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

101–104 of 104 posts

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

#101

Post by syn0byte »

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…

"Unikernel" is a overly generic term. Technically the Linux kernel is already a "Unikernel". It's just most of the time its discussed as a negative not a positive and the term used is "monolith".

The project you want is "Yocoto", a complete toolchain to build customized embedded OS images.

https://www.yoctoproject.org/

You would have to build your own analyzer. Grepping the dependencies from the makefile/build data or just parsing the output of dpkg and translating that into yocto build specs is not unreasonable.

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

#102

Post by jart »

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…

Linux as a library is unlikely since GPL enforces a boundary between Linux and its users. Otherwise it'd've become just another statically-linkable asset copied into a bunch of corporate codebases long ago. glibc uses the same strategy too w/ LGPL. Folks wanting to overcome the latencies and bloat these barriers create, should consider the problem might be more about politics than engineering.

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

#104

Post by throwaway_391 »

eyberg wrote: post #69
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.

This is brought up quite a lot and isn't answered correctly enough in my opinion. The problem with this approach is that you can make it as small as you want but it's still Linux. At a certain point are you going to start patching things out like support for users? Support for management of multiple processes? There's a non-trivial set of syscalls and data structures designed solely for these constructs. You can't ju…

Size, Content. Pick one.

I'm not suggesting it's a good idea, but it's there. I'm sure there's more minimal, and less minimal options available.

I don't think there's any security impacts with using alpine Linux specifically, aside from default credentials in a bunch of containers a few months back.

Post reply on HN