surely you can imagine a situation in which a developer prefers to develop on a mac but wants to deploy to a linux server though? that's the use case here.

This is the exact workflow that VSCode w/ remote is supposed to enable: you just connect to the VM and everything works. VM could be somewhere else. Or it could be on the local machine. Doesn't matter.

I don't want to maintain my own special-snowflake VM just to run docker containers on it. I want a dumb cattle VM running Container OS or an equivalent, whose only job is to run containers, ephemerally, connected to my host. The less it can do other than that, the better. In fact, best if it gets blown away on every restart.

Any statefulness is to be avoided, because a stateful Docker host might mislead me that my images will work in prod, when they're really dependent on something in my dev VM. Caches, databases, message queues? In development, they're ephemeral. Blow those containers away, please. I don't want any persistent volumes, host mounts, any of that. This is development, not deployment. Any data is just there to verify that the code is doing the right thing. Why would any such data need to live longer than the containers producing+consuming it?

(In the rare case that I do want a persistent database, I run it on the host. It's already a special snowflake; may as well treat it like one. As a bonus, this forces me to ensure my applications can target external resources using connection-string env-vars — which is almost-always relevant in production, where the DBMS is going to be some cluster external to the compute environment.)

> VM could be somewhere else. Or it could be on the local machine. Doesn't matter.

I don't know about docker itself, but I'm using Docker on Mac for Kubernetes "application" development. Targeting my commands to my local Docker-on-Mac k8s cluster vs a remote one is just a `kubectl config set-context` away. (Or you can do the same from the Docker on Mac tray menu.)

Yet, it works, and well, your shock notwithstanding.

If your goal is a SINGLE portable, virtualized platform for your developers, which does not require a persistent internet/SSH connection, and which is "fast enough" for developers to be effective, Docker on Mac is a pretty swell solution.

You can dismiss this but if your dev shop is doing dev work that lands in a k8s cluster, it sure is nice to just have devs install docker desktop for Mac and they have a fully functioning k8s cluster that just works.

My whole company uses macs except me. I had to spend a bunch of time figuring out how to get a dev environment working on Linux. And it wasn’t easy as none of the out of the box k8s solutions support how we developed our build system. If I wasn’t a k8s admin from early versions of k8s I would have just given up.

No platform is perfect.

It sounds like your company built its dev tooling specifically around Docker for Mac. It's not surprising that it was a pain to replicate on Linux your company's work as a sole programmer.

But that doesn't mean that Linux doesn't support Kubernetes well. Linux is the primary target for k8s! It runs more efficiently and has better support than Kubernetes on Mac. Minikube has worked as a dev cluster on Linux long before Docker for Mac shipped a k8s dev cluster.

(I, too, have been involved with Kubernetes projects since the early days, and have built k8s tooling at fairly large companies.)

Go install docker desktop for Mac. Click a preference and you have kubernetes.

That is not the case in Linux. Can you install kind? Sure. Can you install minikube? Sure.

And define support? To give you a simple example, in minikube on Linux how do you make local images built by docker available in minikube?

https://hasura.io/blog/sharing-a-local-registry-for-minikube...

It involves using dockerhub (rate limited) or running another local registry that you retag and push.

How about docker for Mac? No changes required at all, if the image is in the docker registry, it works in kubernetes

This is the exact type of retagging non sense that I hate in a dev workflow and is completely hacky.

So I solved it myself using k3s but I don’t think I have seen anyone else tackle it on Linux. Especially not minikube or kind

This is nonsense. We invested multiple man month this year to create a local k8s dev environment for our company. Our devs use MacOS and Linux. Me and my colleague evaluated various solutions for running k8s locally, all of which worked fine on Linux out of the box, while the process of setting them up for MacOS was riddled with issues (mostly around performance).