21–30 of 104 posts
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)
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…
It doesn't really make much difference in terms of size in itself, I suspect. You're still carrying along the whole kernel and the application code, they're just linked together into a single binary. You can certainly then trim things down a lot by stripping the kernel to its bones by removing drivers etc., but you can do that even without linking it together, and you can go a lot further than what the normal kernel…
> 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?
Earlier quoted context omitted.
It doesn't really make much difference in terms of size in itself, I suspect. You're still carrying along the whole kernel and the application code, they're just linked together into a single binary. You can certainly then trim things down a lot by stripping the kernel to its bones by removing drivers etc., but you can do that even without linking it together, and you can go a lot further than what the normal kernel…
The linking stage automatically removes all parts of Linux (eg. drivers) that are not needed. We can also apply various link-time and whole process profile-guided optimizations. Apparently most of the performance improvement comes from getting rid of system call overhead although we still have a student measuring these things more precisely.
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 not where the benefits of a unikernel are. As I said, and you reiterated, it's really cutting latency from syscalls that is the big benefit of a unikernel.
Earlier quoted context omitted.
The linking stage automatically removes all parts of Linux (eg. drivers) that are not needed. We can also apply various link-time and whole process profile-guided optimizations. Apparently most of the performance improvement comes from getting rid of system call overhead although we still have a student measuring these things more precisely.
> 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…
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…
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.
70%-90% of bugs seem to be memory-related. Let's end that with a little bit of effort upfront for much fewer headaches in the long-term.
https://twitter.com/LazyFishBarrel/status/115341007092920320...
https://www.zdnet.com/article/microsoft-70-percent-of-all-se...
https://security.googleblog.com/2019/05/queue-hardening-enha...
I'd rather see unikernels written in Rust or any other memory-safe language. If we're going to start from scratch with this, let's do it right this time. 70%-90% of bugs seem to be memory-related. Let's end that with a little bit of effort upfront for much fewer headaches in the long-term. https://twitter.com/LazyFishBarrel/status/115341007092920320... https://www.zdnet.com/article/microsoft-70-percent-of-all-se... h…
Edit: I don't mean to say you have to use C for the "userspace" part of this. It should be possible -- in future -- to use any language for that. However at the end of the day you'll still be linking that with Linux (written in C) and glibc into a single binary that runs in one address space.
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)
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 ?