> the alternatives suffer from the same filesystem performance issues that this release claims to improve

Hehe, not if you run Docker in a Linux VM, edit your code using the SSH VSCode plugin, and port forward any services from the VM to your Mac.

After doing this for over a year, I don't know why anyone still uses Docker for Mac, other than corporate how-to guides that still start with "1. Download Docker for Mac", or feeling unfamiliar with Linux.

Docker was originally created as a chroot'ed process container with abstracted networking, nothing more -- and certainly not a full VM. Why not run it as it was intended to be run?

Edit: Am I incorrect? Or is something else wrong?

What you described (running a Linux VM and forwarding ports) is exactly what Docker Desktop already does for you without having to maintain packages, configure ssh keys, deal with networking, etc.

The thing I don't like about your method is having all my code checked out on the VM. As soon as I want to start using anything other than VSCode to manage it, I'm now hopping through layers. I'm also restricted to the VM's filesystem/size limits, and individual changes to files are not backed up by Time Machine, only the entire VM disk image.

And only because you mentioned corporate how-to guides, Docker Desktop requires a paid license for commercial use. I think your method is a perfectly valid way to work around needing a license, but the license comes with commercial support and some other features some companies may find useful.

Sorry, what do you think Docker for Mac does? It’s exactly what you’ve described, with more ease of use and features like volume mounts from your Mac into the VM (which this post talks about optimizing). Your approach requires lots more fiddling with little to no benefit.

Prior to these improvements there was a huge benefit: much better filesystem performance. This blog post says they increased performance by up to 98%, which tells you just how slow it was before (slow enough that I personally chose to forgo Docker altogether).

The filesystem performance within the VM is the same; the issue only arises/arose when mounting from macOS into the VM. To each their own, of course; but there’s no real perf difference between rolling your own and using Docker for Mac.

If you're running 10+ docker containers like my company does, running all of them inside a single VM will use significantly less memory than spinning up multiple VMs like Docker Desktop does.

> the issue only arises/arose when mounting from macOS into the VM

Isn't that the usual case: you have your code on your local filesystem and then run it using an interpreter in the Docker VM?

Nope. You can certainly do that; but “the right way” is to add your sources and compile them (as necessary) during the image build; and then treat the container as an “application”, not as an “environment”. This is how any sane production setup works, and you get a lot of benefits using it during development (such as reproducible builds and only one pre-req for a dev setup: Docker). If you’re just volume-mounting your code into the container, all Docker is providing is a disposable runtime environment. Which is handy for some things, but the general idea is to end up with a fully containerized program that you can tag, push to a registry; and pull to your production environment.

> This is how any sane production setup works

Well sure, but almost nobody is running production workloads on macOS. Regarding development workflows. Won't rebuilding the image every time you make changes be slow? I can get ~1 second reload times for node.js services outside of Docker. And I believe inside Docker too on linux.

It's not necessarily because people are serving their production workloads from macOS systems.

However, they develop on them - and it makes sense to make those environments (and the processes) similar to your actual production setup. So if your applications code gets compiled, and deployed as part of the Docker image - then ideally when you spin up a dev environment, it should follow the same process.

That isn’t how Docker Desktop works, there’s one VM.

So in that model, you have to ship your codebase into the VM and then work on it from there. If you're git-managed now you're having to either ship your git credentials into that VM to push stuff up, or you're like having to figure out how to ship the codebase back to the host when you need to.

The whole "magic" is that you work on the files on your host machine! I think VSCode is doing god's work (along with other tools) to make remote editing a nicer experience, but well... I use Docker on Linux and just edit files locally. It's nice!

Git credentials are not a huge deal if you use ssh keys. You can forward your local ssh identity to the VM / remote host by adding these options to the Host entry in you ssh config:

  IdentitiesOnly yes
  AddKeysToAgent yes
  ForwardAgent yes

At this point you can just use Vagrant again and skip using Docker.

Vagrant also has filesystem performance issues. VirtualBox host directory sharing is awfully — unusably — slow, even more so than the old Docker Desktop mount.

Vagrant takes a lot more disk space and RAM. VirtualBox isn't as efficient as the macOS hypervisor. And every Vagrant project is a separate VM, instead sharing the same VM for multiple projects.

Ease of use. Some people like the conveniences in Desktop and the stuff you described has to be set up and maintained. Lots of people out there just need to start writing application code and get it running in the dev environment they've been given. And employers will happily pay for licenses.

This is exactly how we configure our development environments after trying all sorts of different combinations.

We find it significantly faster to do macOS + Linux VM + Docker than macOS + Docker for Mac. We're using the Remote Containers plugin in VSCode.

I just tried Docker for Mac 4.6.0 and it is still slower than the above setup - though I think this might be down to bind vs. volume mounts.

Well, I use SublimeText, SublimeMerge, Finder, and Preview. All of which you can pry from my cold, dead paws. :)

Before anyone mentions sshfs, macFUSE+sshf is literally the only thing I’ve seen that can fuck up the entire disk subsystem’s ability to mount and unmount anything until you reboot.

Docker Desktop is a VM because it allows you to run Linux containers. If it weren't a VM then you can onlu use it to run macOS containers (which don't exist thanks to the lack of necessary kernel primitives) or Windows containers.

Both Kata Containers and UTM support virtio-fs, so this is not strictly true. The former can be used as a stand-in replacement for the runtime used by docker desktop[1]. With the latter, one could use a UTM-backed guest as a docker runtime in macOS[2] or run docker directly on the guest[3].

[1] https://github.com/kata-containers/documentation/blob/master...

[2] https://www.codeluge.com/post/setting-up-docker-on-macos-m1-...

[3] https://www.lifeintech.com/2021/11/03/docker-performance-on-...

Is this an issue with dynamic languages in general? Are Java/Kotlin and Golang, for example, not affected?

When using Java, with say, jib and skaffold, when a change is detected the image is rebuilt with some fairly smart cacheing being done to minimize the build time.

In more interesting setups, the class files aren't in the image but rather mapped in - much the same way one would with dynamic and then a hot reload - https://docs.spring.io/spring-boot/docs/1.3.8.RELEASE/refere...

> Spring Loaded goes a little further in that it can reload class definitions with changes in the method signatures. With some customization it can force an ApplicationContext to refresh itself (but there is no general mechanism to ensure that would be safe for a running application anyway, so it would only ever be a development time trick probably).

And this way, the container can remain the same with the class files being changed underneath it.

https://github.com/spring-projects/spring-loaded

It depends what you need to do. If you build a golang binary in a container and run go mod tidy, you get hit by it. If you build a java app with, say, maven, you will pull deps into a volume mount and you get hit by it. Of course, you can mount a host dir to avoid the problem to a certain extent.