4 ms·
There are folks who know much more about rump than I. They read HN and I stand to be corrected. But the description of bootrino seems like it is has a mislead
by aplorbust 9y ago
There are folks who know much more about rump than I. They read HN and I stand to be corrected. But the description of bootrino seems like it is has a misleading definition of rump unikernels. It suggests because a Linux distribution and a rump kernel can both be made small enough to fit in RAM and perhap focus on a single application, they are therefore similar. That does not sound right.
On rump:
"Two different operating modes are explored: 1) a transparent mode, in which the file system is mounted in the typical fashion by using the kernel code as a userspace server, and 2) a standalone mode, in which applications can use a kernel file system as a library. The first mode provides isolation from the trusted computing base and a secure way for mounting untrusted file systems on a monolithic kernel. The second mode is useful for file system utilities and applications, such as populating an image or viewing the contents without requiring host operating system kernel support. Additional uses for both modes include debugging, development and testing."
source: https://www.usenix.org/legacy/event/usenix09/tech/full_papers/kantee/kantee_html/ https://www.usenix.org/legacy/event/usenix09/tech/full_paper...
As far as I can see (which is not far), this is quite different from, e.g., a "trimmed down" Linux kernel plus busybox. For example, I can utilise rump to mount corrupted filesystems that would otherwise crash the kernel. Maybe I am missing something here about the comparison.
I applaud the bootrino authors work and struggle against the incompatibilities between "cloud" hosting providers. Time well spent.
However I have a few alternative thoughts:
If I have an image, in a portable format such as ffs, with a bootloader and a custom kernel with embedded filesystem that I created myself that is small enough to fit in RAM, why do I need to bother with "cloud" hosting?
Why do I need to have a hosting provider run Linux (or another OS of the providers choosing) in order to boot the image when the image has everything it needs to boot on a wide variety of hardware? Is the reason one that benefits me in all use cases?
Assuming for whatever reason I am amenable to have my kernels running on the same computer as other customers software, along with the providers software running as well, then do I at least get to choose the host OS (e.g., in Xen, the dom0)? Why not? Even if my kernels run better under an alternative host OS?
If I have a bootloader that is compatible, e.g., with Xen, and does not require, e.g., Python or Grub to be used, why do I have to accept the hosting providers choice of host OS and bootloader?
There is a severe absence of choice and flexibility compared to what I get outside of the "cloud" hosting market.
What with Spectre and Meltdown, are there good reasons for me to not share a computer with other customers software and the providers software? What if there are alternatives to "cloud" hosting that do not involve running other peoples software on the computer I am using? What if the real advantages of "cloud" hosting are to the hosting provider?
Cloud hosting may not be for everybody. Personally, I have created enough of these small images to run from RAM that I have lost count, using small sized USB sticks, SD cards and CF cards to store a. kernels with embedded ramdisks and b. other stuff I might need before network access. The amount of configuration I can do is limited only by my imagination, but none of it ever requires a cloud hosting provider or some web-based "administration console".
I prefer having physical access to dedicated hardware, or paying someone to access it for me. I am willing to pay more for this peace of mind, but as others on HN have highlighted repeatedly over the years, many times dedicated hardware is actually more economical. As always, it depends on what the customer is doing.
Using "cloud" hosting providers is overkill for own custom kernels, and way too much hassle. For example, I use ffs for the images and it "just works" on every computer. The fact that every hosting provider has to have their own "proprietary" image format is enough to keep me away. That is not user-friendly.
But, to each her own. This is only one users opinion.
- andrewstuart 9y ago>> It suggests because a Linux distribution and a rump kernel can both be made small enough to fit in RAM, they are therefore similar. That does not sound right. It's a good question. Given a unikernel and an extremely trim Linux kernel plus application code only, what's the practical difference? Does it matter at any real level if there's 4.5 megabytes of Linux kernel in there?
- BraveNewCurency 9y agoHuge difference. It's not the kernel size, it's the interface (ABI). In a unikernel, the kernel is part of the application (like a library). Instead of a complex/slow transition from user space to kernel space, you just call a function. A unikernel will also know exactly what your application needs (i.e. if you only use UDP, it doesn't bother including TCP.) It's possible to strip down the Linux kernel, but it requires a LOT of work (basically, remove something, then test that your application still works.)