Hacker News Board Hacker News, browsed like a classic message board
Live data from Hacker News

Gone Full Unikernel

deferpanic.com

Post reply on HN
Print view View original

91–98 of 98 posts

Re: Gone Full Unikernel

#91

Post by ryao »

eru wrote: post #74
ryao wrote: post #69

Earlier quoted context omitted.

> No double caching: most of our applications have an in-memory working set, and no disk state. Some do (eg, Cassandra databases). I see no disadvantage for unikernel on hypervisor setups versus applications on a container host setups in applications where there is no disk state. However, I see no advantage either. The techniques used to talk to hardware directly work in userland too. netmap is a fantastic example of…

> However, the world is adopting containers in traditional kernels and unless a unikernel on a hypervisor can be better, I do not see much value in devoting resources to unikernels too. Unikernels allow more experimentation. The interface that the hypervizor provides is generally lower level (especially with hardware passthrough) than the traditional operating system's interface. Unikernel 'programs' would normally u…

That is nice, but it is very different than the statements of unikernels being more secure from being smaller and being more performant that I have heard lately. The more I learn about unikernels, the more I think these are false promises.

By the way, I am a fan of rumpkernels, which also offer the ability to do experimentation. Rumprun is apparently a unikernel design, while rump kernels are building blocks. Rump kernels need not be used in unikernels. They can be used in whatever you want them to be, with unikernels being one place that they can go.

Re: Gone Full Unikernel

#92

Post by bcg1 »

pjmlp wrote: post #83
bcg1 wrote: post #64

Earlier quoted context omitted.

There's more to unikernels than just being another virtualization technology. Most of the conversation on HN (as well as the content of this article) seems centered around unikernels vs. containers vs. a traditional OS in a VM, etc. But that conversation sort of misses the point. Rather than just being a competing virtualization solution, "Unikernels" are really about eschewing the existing OS paradigm altogether. Fo…

The Mirage folks didn't discover anything new in that regard. It is how the safe OS from Burroughs, DEC, Xerox Parc, ETHZ and many others used to work. Those OSes were written in strong typed systems programming languages, the whole stack. Part of their security was based on the language type system.

Fair enough! I definitely wasn't trying to suggest that is a completely new feature, nor that it is the only feature of Mirage OS ... really was just trying to make the point that there is more to the unikernel story than just figuring out whether it is better or worse for running my buggy crud application than some other virtualization technique. Thank you for the info though, I will have to read up on those things you mentioned.

Re: Gone Full Unikernel

#93

Post by pjmlp »

bcg1 wrote: post #92
pjmlp wrote: post #83

Earlier quoted context omitted.

The Mirage folks didn't discover anything new in that regard. It is how the safe OS from Burroughs, DEC, Xerox Parc, ETHZ and many others used to work. Those OSes were written in strong typed systems programming languages, the whole stack. Part of their security was based on the language type system.

Fair enough! I definitely wasn't trying to suggest that is a completely new feature, nor that it is the only feature of Mirage OS ... really was just trying to make the point that there is more to the unikernel story than just figuring out whether it is better or worse for running my buggy crud application than some other virtualization technique. Thank you for the info though, I will have to read up on those things…

You can find some links to those systems here

https://news.ycombinator.com/item?id=11856479

Re: Gone Full Unikernel

#94

Post by moby_click »

haberman wrote: post #11

Tell me if I'm missing something, but the premise of Unikernels seems to be that a ring-0 x86 hardware environment is the perfect fit for a universal container/host interface. Or to put it more charitably, since cloud compute services are based around booting VM images based on this model, we'll just go with it instead of trying to use an abstraction that is actually designed for this. Correct me if I'm wrong, but it…

Xen offers a couple of ways to load and start a kernel and you'd want to start a kernel in long or protected mode. Ideally, you also use the hypervisors virtual device interfaces instead of scanning for emulated devices. I don't know if the sane startup protocol is final but here are some pieces of documentation: http://xenbits.xen.org/docs/4.7-testing/misc/hvmlite.html http://xenbits.xen.org/docs/4.7-testing/misc/pvh.html

The nice thing about ring-0 is that on modern hardware with SR-IOV, a VM can be associated with devices and the multiplexing that had to be done within a kernel or hypervisor can now be done in hardware.

Re: Gone Full Unikernel

#95

Post by wangchow »

zenlikethat wrote: post #82
wangchow wrote: post #81

This whole movement seems strange to me. It's like these are statically linking the entire OS to run a single app. Why not ditch the OS completely? I'd say this is taking the whole container concept a bit far, but who knows what will come next!

If I'm not mistaken, the whole idea _is_ to ditch the OS completely. To avoid a fully functioning kernel with lots of juicy device drivers to exploit, code intended to work on systems your app will never need to worry about running on, and layers upon layers of abstraction ready and waiting to be exploited (e.g. shells). One reason MirageOS uses OCaml, for instance, is for its memory safety properties. A truly stagge…

Interesting. I'll have to do a bit more research on this.

Re: Gone Full Unikernel

#96

Post by Ericson2314 »

Traditional VMs suck. Containers a la Joyent and Unikernels are really two points on the same spectrum of distribution of complexity between host and client. Eventually they will converge, because neither POSIX nor (virtual) hardware are interfaces designed this purpose.

The one-language library-centric ideology of e.g. MirageOS especially is really orthogonal to questions of provisioning data centers. It is truly a huge step in the right direction, and before the unikernel-container convergence, could be applied to the host OS of a container rig.

Re: Gone Full Unikernel

#97

Post by coroutines »

superuser2 wrote: post #57
coroutines wrote: post #21

Earlier quoted context omitted.

I'm with you - Docker has done an excellent job of showing application developers the minimum they need for a runtime. Side-thought: Can Android be dockerized?

> Can Android be dockerized? Why? Aren't Android apps already sufficiently sandboxed?

Well you'd think it's not really necessary to run Android in a VM. The Android x86 project should make it easy to run atop an existing Linux in a container.

Just as an aside: Docker doesn't seem very security-focused, I would not [yet] count on its containers being properly sandboxed. :>

Re: Gone Full Unikernel

#98

Post by rixed »

ryao wrote: post #6

> Try 5, 10, 20 megabyte small. OpenWRT/LEDE will happily work on a system with 4MB of storage: https://www.lede-project.org QNX had a graphical environment, a web browser, a web server, a text editor, image viewer, various games, a package manager, etcetera on a 1.44MB floppy: http://m.youtube.com/watch?v=K_VlI6IBEJ0 Less is definitely more, but you do not need a Unikernel to achieve such sizes and you lose observab…

No, when your service that's running on 10k machines do not behave as expected, you do not attach a debugger to it nor dump a core.

UNIX is a great OS to share a machine amongst many users and many programs. It's not that great when your app is made of thousands of asynchronous programs. Last decade tools are to be reinvented regardless of microkernels.

Post reply on HN