[nerdjon]

Since when has Docker on Intel Mac been crappy? The couples times I have tried to run Docker on Windows I have always stopped before I actually managed to get anywhere out of frustration.

The experience compared to linux is nearly identical (maybe slightly better thanks too a couple shortcuts in the docker for Mac app that are nice for development).

As far as the "laundry list" is concerned... 12 apps were listed. 5 were emulated, 4 were native and only one having a minor issue that was easily fixed. Only one of the apps needed a preview version and that was docker. VSCode worked fine emulated but there was a native version being tested.

I am very confused where you are coming up with there being a ton of hoops or beta software needed for this.

That being said, we are talking about a platform that is 4 or 5 months old at this point. The industry was already experimenting with ARM. Apple has also shown time and time again that they can make a change and it pushes the industry to follow.

[wiredfool]

Anything with lots of host volume mount traffic sucks badly, inotify/watch, sequential reads, random reads, writes. It's all horribly slow.

Sometimes it takes seconds (10) for docker commands to start to run, which is super slow compared to a linux host.

[willcipriano]

> Since when has Docker on Intel Mac been crappy? The couples times I have tried to run Docker on Windows I have always stopped before I actually managed to get anywhere out of frustration.

I had the same experience. The installer has been improved, my grandma could set up Docker on Windows now.

[dolni]

> Since when has Docker on Intel Mac been crappy?

Since forever if you actually try to use it for real development? https://github.com/docker/for-mac/issues/77

> As far as the "laundry list" is concerned... 12 apps were listed. 5 were emulated, 4 were native and only one having a minor issue that was easily fixed. Only one of the apps needed a preview version and that was docker. VSCode worked fine emulated but there was a native version being tested.

I will quote the relevant parts of the article here since you can't be bothered to read the whole thing.

> One issue I encountered on both my M1 laptop and also a MacStadium MacMini instance that we use for Mac testing is that Brew randomly started to complain about git missing.

> The Docker team advise that QEMU is a best-effort approach and that it is best to run images natively as much as possible. I have encountered myself issues with some binaries when I tried to emulate them via QEMU.

> One thing to note is that Docker-in-Docker is not supported by QEMU (abandoned PR here). So you cannot run an arm64 Docker in an amd64 Docker or vice-versa. However, if you run your natively-supported Docker-in-Docker, the inner Docker can still run multi-platform images fine.

> Another issue that I noticed with the Docker preview on the M1 is that there are currently performance issues with multi-processor use - so much so that performance using a single core is sometimes slightly better than the performance of using 8 cores. Or at least that's what @jasmas claims. I've also seen some benchmarks testing the import of a database like MySQL, and it seems that there are some clear performance issues (~25X) with the Apple virtualization API. I've not seen such a drastic difference in common use, but hopefully these are addressed soon.

> An issue I ran into with the amd64 version was that I did not realize that the terminal was also an amd64 process (Again, Rosetta 2 is just that good). In some situations, this led to some strange issues when running Docker, where QEMU was acting up with segmentation faults. After some head-scratching the issue was resolved by switching to the ARM-based VS Code Insiders edition.

> I ran into issues when using the JVM. After investigating online, it seems that OpenJDK is not yet available for the M1. The way this was manifesting for me was that the JVM process would just hang randomly. By using --platform=linux/amd64 in Docker or in Earthly builds, I was able to get OpenJDK to work most of the time, but I'm still seeing random hangs.

All of these bugs after the author _initially_ wrote:

> All the software I need to use "just works". I found that if an ARM-native version is not available for an application, the emulated one works just fine and there's no performance drawback that I can notice.

> I am very confused where you are coming up with there being a ton of hoops or beta software needed for this.

Reading the article rather than skimming it helps a lot.