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

Containers in 2019: They're Calling It a Hypervisor Comeback

infoq.com

Post reply on HN
Print view View original

141–150 of 196 posts

Re: Containers in 2019: They're Calling It a Hypervisor Comeback

#141

Post by bogomipz »

spinlok wrote: post #123
bogomipz wrote: post #84

Earlier quoted context omitted.

>"Using a microkernel as not much more than an overgrown MMU and task switching abstraction layer for someone's monolithic kernel is a cheap hack driven by the needs of academic research, not how they are supposed to be." I found this interesting. Can you or anyone else say what the context was where academic researchers have needed to do this? What problem was it solving for them in a cheap way?

There is a linked article on his blog https://utcc.utoronto.ca/~cks/space/blog/tech/AcademicMicrok... that expands on this. Specifically: >the whole 'normal kernel on microkernel' idea of porting an existing OS kernel to live on top of your microkernel gives you at least the hope of creating a usable environment on your microkernel with a minimum amount of work (ie, without implementing all of a POSIX+ layer and TCP/…

This is a great read. Thank you.

Re: Containers in 2019: They're Calling It a Hypervisor Comeback

#142

Post by snazz »

Havoc wrote: post #110
meddlepal wrote: post #40

Earlier quoted context omitted.

Serverless has been around now for several years and it hasn't taken off yet... definitely not to the same degree containers have. I'm skeptical it will. To adopt serverless you need to be willing to rearchitect your product and retool your developers... that's expensive.

>(Serverless) I'm skeptical it will. They'd get more uptake if it was easier I think. Not re-architect your product...but small things here and there. I wanted to play with azure python functions but despite vs enterprise & lots of credits I can't. Without admin rights on local machine it's basically impossible. (Need VSCode & AZ toolkit) (Unrelated - that kinda blew my mind - no you can't do that in the 2,000 USD VS…

> (Unrelated - that kinda blew my mind - no you can't do that in the 2,000 USD VS enterprise...you need to use the free one)

I’m guessing this is because Microsoft wants it to be more accessible—they probably realize that there isn’t much money to be made in $2,000 developer tools. Visual Studio was never a Python IDE; VS Code is much more language-agnostic.

Re: Containers in 2019: They're Calling It a Hypervisor Comeback

#143

Post by gtirloni »

pjmlp wrote: post #69
gtirloni wrote: post #37

Earlier quoted context omitted.

If the POSIX committee couldn't deliver a solution that was modern and backwards compatible, what hope do we have that developers will selforganize and ever do that?

POSIX committee doesn't deliver anything. POSIX is just a common API across UNIX clones. And besides the AT&T original design, UNIXes have disagreed in almost everything else, hence UNIX wars.

Q1. What is the Portable Application Standards Committee (PASC)?

The IEEE Computer Society's Portable Application Standards Committee (PASC) is the group that has and continues to develop the POSIX family of standards. Historically, the major work has been undertaken within Project 1003 (POSIX) with the best known standard being IEEE Std 1003.1 (also known as POSIX 1003.1, colloquially termed "dot 1"). The goal of the PASC standards has been to promote application portability at the source code level.

http://www.opengroup.org/austin/papers/posix_faq.html

Re: Containers in 2019: They're Calling It a Hypervisor Comeback

#144

Post by braindeath »

sayhello wrote: post #72
regularfry wrote: post #67

Earlier quoted context omitted.

From memory, I seem to recall that Genode takes this to its logical conclusion: every process is isolated with virtualization primitives. As to why: isolating processes the old way needs jails to work properly, BSD lost the popularity contest, and Linux jails didn't get secure enough before VMs and containers took off.

Did the BSD jails provide enough isolation? Would memory from a process truly be isolated from another? How about FD’s? Could there be side channel attacks? At what level? Perhaps the whole kernel design needs to be revisited, which I assume is what’s being taken on by Fuchsia.

I’ve seen no evidence that Fuchsia is bringing much more than 90s era embedded OS design. Just because it’s not Linux doesn’t mean it’s new.

Not that this is a bad thing, but someone please correct me if there is something fundamentally recent in Zircon.

Re: Containers in 2019: They're Calling It a Hypervisor Comeback

#145

Post by gnufx »

naasking wrote: post #29
hinkley wrote: post #3

And let me state again for the record that all of these promises being made by container systems sound an awful lot like the promises I was offered by 'real' operating systems in the early nineties. I think the only real difference is that there has been a sea change in public opinion on this kind of aggressive isolation by default being worthwhile. But a hypervisor publishing a bunch of services that talk to the wor…

> Things are beginning to look a bit more like microkernels as time goes on. Hypervisors typically are microkernels. The very first "hypervisor" was L4 in fact, with L4Linux. Also, you're right that virtualization and containers are fulfilling the promises of operating systems. The problem of earlier OSes is that they didn't take security seriously enough. Modern hypervisors aren't much better at isolation than real…

Isn't the important thing about KeyKOS and EROS capabilities, and L4 variants aren't all capability-based, are they?

Re: Containers in 2019: They're Calling It a Hypervisor Comeback

#146

Post by gnufx »

gtirloni wrote: post #35
naasking wrote: post #30

Earlier quoted context omitted.

The typical problem with microkernels is poor backwards compatibility, mainly due to POSIX. If you add POSIX compatibility, you don't gain any isolation, performance or security benefits of microkernels, and changing your thinking and your programs to gain those benefits requires significant work when they're written against the POSIX API. Building them that way from scratch is pretty much just as easy as writing pro…

If you don't mind this tangent question... Is there a microkernel API that has more acceptance nowadays? In other words, where should anyone wanting to work on real world / enterprise systems based on microkernel look?

I don't know if that's the idea, but Genode works over a few microkernels.

Re: Containers in 2019: They're Calling It a Hypervisor Comeback

#147

Post by pjmlp »

gtirloni wrote: post #143
pjmlp wrote: post #69

Earlier quoted context omitted.

POSIX committee doesn't deliver anything. POSIX is just a common API across UNIX clones. And besides the AT&T original design, UNIXes have disagreed in almost everything else, hence UNIX wars.

Q1. What is the Portable Application Standards Committee (PASC)? The IEEE Computer Society's Portable Application Standards Committee (PASC) is the group that has and continues to develop the POSIX family of standards. Historically, the major work has been undertaken within Project 1003 (POSIX) with the best known standard being IEEE Std 1003.1 (also known as POSIX 1003.1, colloquially termed "dot 1"). The goal of th…

Examples of APIs actually proposed by POSIX, that weren't already in widespread use before adoption by standard updates?

Re: Containers in 2019: They're Calling It a Hypervisor Comeback

#148

Post by burpsnard »

icebraining wrote: post #139
sedachv wrote: post #128

Earlier quoted context omitted.

> No matter how many people sing the praises of isolation and security to Docker, I will continue to suspect that almost all of its adopters use it because packaging software with dependencies is hard, poorly understood, terribly tooled (looking at you, Python), and even more poorly executed in the vast majority of projects and companies. Here is a quote from Eberhard Wolff's _A Practical Guide to Continuous Delivery…

To be fair to Wolff, it's not uncommon for deb and rpm packages of complex daemons (e.g. postgres) to include shell scripts - postinst, preinst, etc - that makes changes to the system, and which do have to be coded in such a way to handle re-execution after partial failure. Taking my /var/cache/apt/ directory as a (poor) sample, about 1/3 of packages had such scripts.

that libc update spawned a wealth of dependency solutions. And 'dll hell' of course

Re: Containers in 2019: They're Calling It a Hypervisor Comeback

#149

Post by burpsnard »

zbentley wrote: post #127
RcouF1uZ4gsC wrote: post #125

Earlier quoted context omitted.

> I will continue to suspect that almost all of its adopters use it because packaging software with dependencies is hard, poorly understood, terribly tooled (looking at you, Python), and even more poorly executed in the vast majority of projects and companies. Static linking solves a lot of these deployment issues. But I guess people are worried about duplicating libraries and security vulnerabilities. So we end up w…

Can't easily statically link a big complex application written in a dynamic language.

That's a reason to avoid dynalangs. Otoh, java and .net have ears and assemblies

Re: Containers in 2019: They're Calling It a Hypervisor Comeback

#150

Post by circute »

dopylitty wrote: post #52

I've had this sneaking but hard to articulate suspicion that datacenters, bare metal servers, VMs, operating systems, containers, OS processes, language VMs, and threads are all really attempts to abstract the same thing. You want to run business code in a way that's protected from other business code but also able to interact with other business code and data in a well defined way. I also have this sneaking suspicio…

Did I write this comment? I've had the same feeling. I work on securing VMs in a hypervisor and part of me wants to look at ring 0 to 3 instead of ring -1 to 0 and see if I can fix that instead of bloating cpu specs with more rings.
Post reply on HN