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

11–20 of 98 posts

Re: Gone Full Unikernel

#11

Post by haberman »

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 seems to me that the first thing any unikernel is going to do when it boots is switch the (virtualized) CPU out of x86 Real Mode (which all x86 machines boot into for legacy reasons, but virtually no one has needed since circa 1995) into protected mode.

Is it just me or does this seem a little bit crazy?

Re: Gone Full Unikernel

#12

Post by wmf »

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…

Yeah, but if you use containers you have to suffer the indignity of the creat() system call. These seem like the smallest possible objections.

Re: Gone Full Unikernel

#13

Post by pjmlp »

4ad wrote: post #2

I never understood why these people didn't bother at all upstreaming their Go port. I even offered myself to be the person responsible for the review. I would gladly do that. I'm very happy about more Go ports, I've done the arm64 and the Solaris ports, and now I am finishing the sparc64 port, but ports need to live upstream.

I look forward for a bare metal runtime to become available, so that people see how close Go features are to Oberon and the system programming is actually possible, even if not all goodies from structure package or functions entry points can be controlled in the current //go:..... flags.

Re: Gone Full Unikernel

#14

Post by bogomipz »

Can someone explain why these rump kernels can not be run on AWS if deferpanic has Xen as a target? AWS is Xen-based. I understand that there currently isn't a target for Docker so that takes Google Cloud out of the equation. The following two statement seem to be contradictory:

Can I use Google Cloud or AWS? You could - although you won’t write much more than a toy app - not until things are changed.

DeferPanic offers managed services for both public and private cloud environments and it's platform targets KVM, Xen, bare metal, and ESX.

Perhaps that falls under the "unfit"statement about these Cloud provider but that seem pretty nebulous for a such a technical discussion.

Re: Gone Full Unikernel

#15

Post by amirmc »

jrv wrote: post #10

It seems this article gleefully admits many of the downsides of unikernels mentioned in https://www.joyent.com/blog/unikernels-are-unfit-for-product... , while being very brief and naive about the upsides (mainly the very contested security argument). I admittedly haven't studied the whole unikernel space yet, but intuitively they do seem unfit for production unless we spend a decade rebuilding tooling (debuggers, pr…

See the discussion about that post over at https://news.ycombinator.com/item?id=10953766

Re: Gone Full Unikernel

#16

Post by haberman »

wmf wrote: post #12
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…

Yeah, but if you use containers you have to suffer the indignity of the creat() system call. These seem like the smallest possible objections.

You are assuming that our only options are "x86 hardware ring-0" or "Linux system call interface." Both are crufty in their own ways, but more importantly, neither of these was designed to be this. The right answer might be an interface that is designed with containerization in mind.

Re: Gone Full Unikernel

#17

Post by lmm »

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…

Yeah. The right thing is hosting providers offering Java application servers or equivalent. Unfortunately there are political and commercial reasons that's not happening.

Still, there are worse container/host interfaces. It could be the full suite of POSIX system calls.

Re: Gone Full Unikernel

#18

Post by [deleted] »

jrv wrote: post #10

It seems this article gleefully admits many of the downsides of unikernels mentioned in https://www.joyent.com/blog/unikernels-are-unfit-for-product... , while being very brief and naive about the upsides (mainly the very contested security argument). I admittedly haven't studied the whole unikernel space yet, but intuitively they do seem unfit for production unless we spend a decade rebuilding tooling (debuggers, pr…

[deleted]

Re: Gone Full Unikernel

#19

Post by agentultra »

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…

An oft-overlooked advantage is the ability to specify a holistic system with a fine-grain of accuracy.

With a monolithic kernel in the way you have to make some black-box concessions.

Re: Gone Full Unikernel

#20

Post by kev009 »

I can't help but think this is just a severe reaction to the tire fire that most Linux distros are, especially RedHat/CentOS and Ubuntu. BSD or Alpine Linux get in the way a lot less, are much more customization and compact, and have a smaller attack surface while still catering to production operations where you can run shells, profiling, logging, etc inside the execution environment.
Post reply on HN