Live data from Hacker News

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

infoq.com

191–196 of 196 posts

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

#191
post #186
post #180

Earlier quoted context omitted.

There is already a solutions such as Guix and Nix, but then people aren't willing to learn a new language that allows expressing dependencies. Docker solves dependencies in same way a disk image does, you save the image and it should look the same way each time you look at it. The Dockerfile is not a reproducible though, you just list steps iteratively to generate an image, but it doesn't guarantee to produce the sam…

Agreed. Nix and Guix actually solve the dependency problem, Docker allows you to work around it. But a work around is better than nothing.

Well, but my point there isn't nothing, there are alternatives, which can (or at least nix can) generate docker or OCI containers.

Docker is trying to sell itself as something more than it is, in reality it is just an overglorified zip file.

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

#192
post #153

Earlier quoted context omitted.

> this is what naming things refers to in Phil Karlton's quote "There are only two hard things in Computer Science: cache invalidation and naming things," not to the literal naming of variables in computer programs That is mighty interesting. Do you happen to have a source for this? It's the first time I've heard it being put in this particular way.

The version I've heard is "There are only two hard things in Computer Science: cache invalidation, naming things, and off by one errors".

There are only two hard things in Computer Science:

0. cache invalidation

1. naming things

47. asynchronous callbacks

2. off by one errors

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

#193

Earlier quoted context omitted.

I think you could build a secure application environment with just bare metal. The only hip tool I would use is Ansible after paying my respects to cfengine. No virtualisation No containers No overlay networks A few VLANs perhaps. If I may. It can be done. Just a few dedicated people. The kind of people colonel Kurtz talked about...

I'm working on something like this with the DebOps[1] project. It's a set of Ansible playbooks and roles that lets you manage Debian environments. I aim for it to be agnostic - roles can be used effectively both in LXC containers, virtual machines or bare metal. You can start with a few machines with Debian netinst + SSH installed, and build them up with the services you want. Applications are installed either from D…

Thank you for sharing this!

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

#194

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…

In my experience even the best of package managers are fundamentally ill suited for deployments because of assumptions about use cases.

Can you elaborate?

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

#195

I’ve been thinking about these problems for a while. Previously, I thought that the “put a VM on it” approach was the right one. In 2015, I wrote novm [1], which I think served as inspiration for some developments that followed. My thinking has changed over the years and I actually work on gVisor today (disclaimer!). I’d like to share some thoughts here. Hypervisors never left. They are a fundamental building block f…

Hi, completely agree with all of this. In fact, we've been focusing on the problem you mention about needing FS holes for VMs to regain container semantics (https://www.usenix.org/system/files/hotstorage19-paper-kolle...). Just in case, these are some of the container semantics we care about: FS crash consistency, file sharing (write+write), and efficient use of memory due to having a single page cache. The key question is: what's the smallest hole we can poke (smaller than allowing every single FS operation in the host)?

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

#196
post #108

Earlier quoted context omitted.

Because current model of processes frankly sucks. If I give you random binary would you run it? You can talk about sandboxing, lecture about permissions and principles of least privilege. But that still doesn't answer the question: can it run hostile code without having side effects on the rest of the system? Other than the newer web tech initiatives like WebAssembly/JS sandboxing, there do not exist any other techno…

> From far away, Windows and Fuchsia are very similar, but Windows have to contend with decades of code compatibility needs even if they want to start shoving everything into a locked down app) DOS and such were designed around everything on the device being shared, with conflicts resolved at the application layer. Windows was built to maintain some (even ideological) compatibility with that world, while adding some…

This comment made me remember my first Mac where when you launched an app it was given complete control over the hardware, with ASM calls to the Mac Toolbox.

Remembering these times it makes me wonder why should there be only one direction, and that maybe there is an alternative to putting all our most sensitive data in every internet connected devices? In old times when you had a computer to do some hobby like games, photo editing, music, etc... the data was only related to that activity, and in the worst case of nuking the hard drive you lost only that work.

Post reply on HN