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

IncludeOS – A minimal, resource efficient unikernel for cloud services

includeos.org

Post reply on HN
Print view View original

61–70 of 85 posts

Re: IncludeOS – A minimal, resource efficient unikernel for cloud services

#61

Post by AnIdiotOnTheNet »

tannhaeuser wrote: post #35
ckocagil wrote: post #12

Earlier quoted context omitted.

I don't understand all the hatred towards containers. It's simply an OS abstraction to facilitate isolation. What's wrong with that? In fact I'd love to see more containers, especially on the Linux desktop: for example a container aware compositor that could render windows from container processes and color code their borders, like Qubes does. I have nothing against VMs either. But even when they're tiny (as in the c…

Docker-style containers only shield you from mixed-library situations eg. where one "service" needs version A and another needs version B. It's painful because this situation is entirely accidental and could be trivially solved by linking everything statically. Then once you have two or more containers up and running, these libraries still need security updates and other fixes which is the entire point of shared libs…

> It's painful because this situation is entirely accidental and could be trivially solved by linking everything statically.

It could and historically has been solved even without linking everything statically, it's just that Linux people have some shared delusion that a stable and consistent base system is bad, there should be no distinction between system and application, and having two copies of a library is an unforgivable sin. Consequently we get the nightmare complexity and inflexibility of the package management scheme to do things we did in DOS on a 286 with no special software at all.

Re: IncludeOS – A minimal, resource efficient unikernel for cloud services

#63

Post by zbentley »

hestefisk wrote: post #49
Thaxll wrote: post #13

Earlier quoted context omitted.

Jails and Zones are inferior to Docker overall, the advantage of Docker is not the isolation technology but the whole workflow of using those containers.

You can get a similar workflow with Jails. Docker became popular because of the CLI but there are many similar options now on FreeBSD.

> Docker became popular because of the CLI

Docker became popular because of a ubiquitous CLI. Having good UX is only part of the battle: the massive network effect (and associated tooling boost/community support) is significant and should not be discounted.

I'm sure there are similar things to Docker's all-in-one UX that have emerged on the BSDs. I'm also sure there are programs to configure Dropbox using an SCM and FTP links in a fast, seamless way on par with the Dropbox setup flow, but they aren't going to take off, because the predecessor is not only convenient, but is also pre-existing with massive popularity.

The same is true for Docker:containers. Some competitor may replace them in time, but whoever they are, "as good as" is not going to be their value prop.

Re: IncludeOS – A minimal, resource efficient unikernel for cloud services

#64

Post by zaarn »

ckocagil wrote: post #12
kunthar wrote: post #3

finally the end of lx* containers on the way. not the actual end of course, who knows docker guys could buy this one as they did to some other unikernel companies.

I don't understand all the hatred towards containers. It's simply an OS abstraction to facilitate isolation. What's wrong with that? In fact I'd love to see more containers, especially on the Linux desktop: for example a container aware compositor that could render windows from container processes and color code their borders, like Qubes does. I have nothing against VMs either. But even when they're tiny (as in the c…

Docker ruined containers. I've been using LXC exclusively on my server and it's much better than Docker, especially since I don't have to retool and it behaves like any other server while still being a container. If all else fails, I can easily bootstrap it into a virtual machine (basically, install the same distro on a virtual machine, tar up the container and dump the contents at the root, adjust networking configuration, done)

Re: IncludeOS – A minimal, resource efficient unikernel for cloud services

#65

Post by johannes1234321 »

bizzleDawg wrote: post #41
fwsgonzo wrote: post #32

Earlier quoted context omitted.

I am a kernel developer working on IncludeOS. Take everything I say with a grain of salt as this is just my thoughts at 9 in the morning in written form. 1. I can build a bootable binary without the full TCP and UDP, shaving off 60% of the whole IP stack. LTO removes a large amount of code as well. It makes all the difference. 2. Performance comes from building a fixed binary (all memory addresses are constant), as w…

I was reading this thinking that security would be mentioned at some point in your response! Presumably a big benefit of smaller codebases is a more realistic possibility of auditing the security?

While the code base of a non-unikernel can be larger a mainstream project like Linux also attracts more reviewers, who spend more time reviewing the code (especially in the critical areas, some hardly used device driver might see less attention)

Re: IncludeOS – A minimal, resource efficient unikernel for cloud services

#66

Post by tinktank »

fwsgonzo wrote: post #32
tinktank wrote: post #27

I have never really got unikernels, maybe someone could educate me? - There is the argument of reduced attack surface/typechecked safety. I get that, but I don't see how this is different from compiling custom Linux/NetBSD kernels per VM? - There is the argument for increased performance. I don't get that at all -- I've done experiments on unikernel system for MirageOS vs IncludeOS vs Kernel on a web and memcache ser…

I am a kernel developer working on IncludeOS. Take everything I say with a grain of salt as this is just my thoughts at 9 in the morning in written form. 1. I can build a bootable binary without the full TCP and UDP, shaving off 60% of the whole IP stack. LTO removes a large amount of code as well. It makes all the difference. 2. Performance comes from building a fixed binary (all memory addresses are constant), as w…

Thank you very much for your response. Some follow-up questions, in the same order as your responses:

1. So, in production, we do this all the time with the kernel. We have specific .config's that we use on a per-app basis so I'm not sure why this point is made against the kernel? Is it because in general people run what they're provided by the distro? I don't really understand the LTO argument as well, is it that the kernel is smaller? When I compared IncludeOS against the production kernels we run for memcache they were 1.5x bigger. In general, how much of an issue is kernel code size? a 50M kernel, while big pales in comparison to the amount of memory required for runtime operation. Have you done any measurements on runtime costs?

2. Do you have any benchmarks/evidence you could point me to? My benchmarks showed the exact opposite at a huge development cost (debugging unikernels is very painful - at least for me)

3. What do you mean by "same old same old"? The primitives for isolation are provided by the hardware with VT-x and VT-d and your point about "removing the ability to even talk to the hypervisor after configuration stage" is referring to VT-x from what I gather. All modern hypervisors use these primitives and in combination with VT-x and PCIe VFs provide the illusion of complete access to hardware so I think I'm missing your point.

4. I'm sorry but I find the argument that "threads automatically mean worse" hard to understand. The cost of a context switch is the cost of a context switch. The cost of a context switch between threads/processes on the same CPU is still much cheaper than the cost of a context switch between VMs on the same CPU. If a program requires threading then, with the Unikernel either I need an abstraction for threading (e.g. co-operative scheduling) that bypasses the cost of the switch _or_ I need to write the program differently. In your answer, you make the point you don't support threads which means that either I move to an event-driven model (which I can do in Linux too) until I run out of CPU or I switch between VM contexts, which in my understanding is much more costly. Do you mind elaborating further?

5. Do you have an official line on this? I would assume the people you're selling against will be deploying containers so it would be good to get a feel for unikernels on containers.

Thanks again for your response. I found it most helpful.

Re: IncludeOS – A minimal, resource efficient unikernel for cloud services

#67

Post by tinktank »

perbu wrote: post #37

FWIW the most interesting tidbit I've learned after working with IncludeOS for couple of years is this; The operating system cannot reconfigure itself. All Unix and Windows-derived systems are meant to have the ability to reconfigure themselves. For a lot of systems there isn't really a good reason why the system itself should have this capability. My Wifi access point is a good example. The fact that it runs Linux m…

Your response confuses me so I must be misunderstanding it. Code is code, all I need is an indirect jump to a pointer somewhere in memory to run the arbitrary code I've installed to compromise the system, so why are unikernels not susceptible to this attack?

Re: IncludeOS – A minimal, resource efficient unikernel for cloud services

#68

Post by dankohn1 »

tannhaeuser wrote: post #35
ckocagil wrote: post #12

Earlier quoted context omitted.

I don't understand all the hatred towards containers. It's simply an OS abstraction to facilitate isolation. What's wrong with that? In fact I'd love to see more containers, especially on the Linux desktop: for example a container aware compositor that could render windows from container processes and color code their borders, like Qubes does. I have nothing against VMs either. But even when they're tiny (as in the c…

Docker-style containers only shield you from mixed-library situations eg. where one "service" needs version A and another needs version B. It's painful because this situation is entirely accidental and could be trivially solved by linking everything statically. Then once you have two or more containers up and running, these libraries still need security updates and other fixes which is the entire point of shared libs…

I think this is a very helpful hypothetical journey to explain why containers are so useful:

"You Could Have Invented Container Runtimes: An Explanatory Fantasy" https://medium.com/@gtrevorjay/you-could-have-invented-conta...

Re: IncludeOS – A minimal, resource efficient unikernel for cloud services

#69

Post by javajosh »

ArtWomb wrote: post #5

Worth watching is Justin Cormack's recent presentation on unikernels, LinuxKit, eBPF and databases such as SeaStar: The Modern Operating System In 2018 https://www.youtube.com/watch?v=dR2FH8z7L04

Yeah, that's a really good overview. I think it's interesting how progress in the DevOps field is characterized by removing things more than adding them, and I think it's great. In a way I think that's the highest and hardest aim of computing technology, not deciding what to build, but deciding what to leave out.

Re: IncludeOS – A minimal, resource efficient unikernel for cloud services

#70

Post by buzzier »

juancampa wrote: post #21
chewzerita wrote: post #2

Cool! Can this be used with languages other than C++?

But, in theory, you can embed V8 and run Javascript on top

runtime.js - javascript library operating system for the cloud

It's built on V8 JavaScript engine and uses event-driven and non-blocking I/O model inspired by Node.js. At the moment KVM is the only supported hypervisor.

http://runtimejs.org/

Post reply on HN