News for hackers. Stuff that matters.
Re:Containers vs. Zones vs. Jails vs. VMs (2017) by wmf on Monday April 06, 2020 @05:23PM (#22798035)
People love to bring this up, but if Linux did have first-class containers, how would the developer's experience be different?
Re:Containers vs. Zones vs. Jails vs. VMs (2017) by cyphar on Monday April 06, 2020 @11:37PM (#22800149)
All system programs could operate and manage the containers running on the system, meaning you can use your existing knowledge to manage a bunch of containers.

For instance, you could run your package manager across all containers to see if they have packages with known CVEs. Or manage the filesystems of all containers on the system (the usefulness of this is only clear with filesystems like ZFS and btrfs). This is effectively what you can do with Solaris Zones.

These kinds of improvements to usability aren't as sexy now that everyone is really excited about Kubernetes (where you blow away containers at whim) but it is useful for the more traditional container usecases that Zones and Jails. LXC (and LXD) is probably the one Linux container runtime that is closest to that original container model.

There's also a very big security argument -- it is (speaking as a maintainer of runc) very hard to construct a secure container on Linux. There are dozens of different facilities you need to individually configure in the right order, with hundreds of individual knobs that some users might want to disable or quirks you need to work around. It's basically impossible to implement a sane and secure container runtime without having read and understood the kernel code which implements the interfaces you're using. If containers were an in-kernel primitive then all of the security design would rest in one single codebase, and all of the policies would be defined by one entity (the kernel).

Re:Containers vs. Zones vs. Jails vs. VMs (2017) by danieldk on Tuesday April 07, 2020 @05:17AM (#22801622)
For instance, you could run your package manager across all containers to see if they have packages with known CVEs. Or manage the filesystems of all containers on the system (the usefulness of this is only clear with filesystems like ZFS and btrfs). This is effectively what you can do with Solaris Zones.

You can also do this on Linux with NixOS, where you can define the system and all containers it runs declaratively. Updating the system will update everything, including the containers (of course, you can also pin the containers or packages in the containers to specific versions).

Re:Containers vs. Zones vs. Jails vs. VMs (2017) by cyphar on Tuesday April 07, 2020 @08:20AM (#22802493)
Sure that's because the package manager is container-aware (and NixOS is very cool -- don't get me wrong), but the distinction is that on Solaris all system tools are Zone-aware (including things like DTrace which would require specifically an in-kernel container concept because you need to be able to aggregate by container and there isn't any in-kernel data to aggregate on in Linux -- and no, cgroup IDs aren't sufficient).
Re:Containers vs. Zones vs. Jails vs. VMs (2017) by zurn on Tuesday April 07, 2020 @07:16AM (#22802182)
Docker would probably diverge less from LXC, because it was first built on LXC and only later got its own low level implementation using namespaces and the other low-level things. Hard to say if the alternative world would have been better or worse, a lot of LXC/LXD implementation details seem more technically competent than Docker.
Re:Containers vs. Zones vs. Jails vs. VMs (2017) by lmm on Monday April 06, 2020 @07:50PM (#22799076)
There would maybe be more consistency. E.g. currently if I say an application is running in a container, do you expect there is virtual networking in place, or not?
Re:Containers vs. Zones vs. Jails vs. VMs (2017) by wmf on Monday April 06, 2020 @08:51PM (#22799391)
Jails and Zones probably also have bridged, routed, and NATed modes so I'm not sure that example is that useful. It's true that networking is different in Docker vs. k8s but there are valid reasons for it.