> Docker for Windows/Mac is the easiest way to use containers

This is depressing.

Even more depressing is that macOS still doesn't seem to have native containers. (Correct me if I'm wrong - perhaps the sandboxing system can be used as a container system including virtual network interfaces attached to process groups?)

Docker images depend on Linux which means "Docker" on macOS runs in a Linux VM. Presumably docker for Windows could use WSL.

> Docker images depend on Linux which means "Docker" on macOS runs in a Linux VM. Presumably docker for Windows could use WSL.

WSL2 is also a VM. Docker is in truth Linux-only software, and "Docker" on any other platform is a polished interface for spinning up a Linux VM and running the real version of Docker there.

I don't think this is such a bad thing. What non-Linux Docker really provides is a nice UI.

On my Mac, I switched from doing a lot of development in VMWare Fusion to using docker-machine (set up to still use VMWare under the hood). With docker-machine especially, it's quite obvious that I'm still just using a VM, but it all feels a lot more seamless than when I was running a bunch of commands to start up VMWare, SSH in, and sync my local files.

----------

† I can't use Docker Desktop because I insist on running an old version of OS X.

Docker for Windows is capable of running Linux containers (on top of WSL2 or a Docker-specific Hyper-V VM), and it can also run Windows containers. You can only pick one of those, but if you want to containerize Windows software, Docker can do this. (If you’re on Windows 10 Home, only the WSL2 backend is available.)

You can actually run both Windows and Linux containers at the same time. You don't need to pick "one of these". I think the flag to switch between them on the fly is "--platform".

Containers aren't really a thing. That's the more troubling bit.

Docker containers are an amalgamation of features, tweaks, and functions which combine together into one experience. There is no kernel concept of a container. There are cgroups, namespaces, capabilities, chroots, CoW Overlay VFS, bind mounts, firewalls, virtual networking... And a whole lot of custom crap Docker provides. You have to have a lot of custom glue to make it all work. You need "a Docker".

Every attempt to make a replacement for Docker falls short because of how many things it has to touch to make things easy to use. To replace it all (since it's not an OS primitive) requires product development, which is expensive and complicated, and probably not vendor-compatible with Docker anyway. So you might as well just have people run Docker.

Containers fundamentally change the concepts used to maintain and operate applications in OSes. I think eventually they will become core features, but it's going to take a while. Someone's going to need to start sending in some pretty big patch sets one piece at a time, such as kernel drivers for all the various features. OCI also needs a lot more help before we can run a container everywhere, and it will undoubtedly involve some virtualization layers we don't yet use as part of containers, which will add more complexity.

> Even more depressing is that macOS still doesn't seem to have native containers.

Docker containers are reliant on Linux cgroups, so even if macOS had its own native containers, it would need to add a Linux cgroups compatibility layer on top of it for Docker to work natively.

Doesn't docker support pluggable backends for actually running containers? It can't possibly be hard-tied to cgroups, since docker can run native Windows containers.

It does use WSL2 if present.

And it works pretty well, other than some network bugs every now and then, which seem to be a WSL2 thing. I moved from OSX to Windows around the release of build 2004 and the development experience has been great.

> Even more depressing is that macOS still doesn't seem to have native containers. (Correct me if I'm wrong - perhaps the sandboxing system can be used as a container system including virtual network interfaces attached to process groups?)

I always found that to be weird as well, since AFAIK Darwin does have jails, but it's only used on iOS for some reason (unless I've misunderstood what "jailbreaking" means).

You've misunderstood what the concept of jailbreaking means.

Jailbreaking in the sense it is used for breaking out of the Apple defined jail/walled garden.

Darwin does not have jails as FreeBSD does. And the software they have for limiting what an application can do is not in any way similar to what a jail is.

Thanks for correcting me. That's surprising on its own merits, but at least it does explain no jails on desktop darwin...

Author here. Thanks for your comment! I struggled with this as well. I agree that I might be conflating things a bit, but I did try to contextualize the slow but gradual move away from all things docker with the fate of the company, starting with the platform wars and resulting in the runtime deprecation. I think a lot of what happened came about because Docker took on Kubernetes with Swarm and lost.

But take a look at this from a different angle. Yes, from the business perspective Docker, inc. seems to be failing badly. But from the engineering perspective they did a tremendous job splitting the monolith to separate components. Containerd was once part of Docker daemon and then abstracted away to an independent entity. And we all hugely benefit from this split.

Now, the next big thing is happening - buildkit. It is already possible to build containers using buildkit without docker. There is even a plugin for kubectl for convenience.

Docker is tearing itself apart but I see only good things happening around it.

P.S. It has been possible to use containerd directly as CRI for Kubernetes since v1.10 https://kubernetes.io/blog/2018/05/24/kubernetes-containerd-...