That this is 'M1' is relevant for me personally, as my current Mac is dead old, I 'need' a Mac for iOS development, the Intel ones are a dead end and seem to run hot often, and it is unclear if all my dev needs will be met by the M1.

Any piece of information that untangles this mess is helpful to me. Of course this may not be the same for others, but it could be 'what's going on here'.

We’re going through the transition at the moment - tried to find info online but decided the only route was to try it on a real machine to see what works / doesn’t work.

Have built an Ubuntu 18 environment running through UTM (https://getutm.app/ - running qemu). Took a bit of tomfoolery where I had to install using a console only display and then flick back to full graphics to get the machine to boot.

Use port forwarding to talk to the machine - haven’t figured out a way to do bridge mode like I can with virtual box.

We’ve got a bunch of crazy dependencies that I’m in the process of rebuilding. Most seem to be ok. There’s a third party one we’re a bit trapped with but we’re running that emulated x86 within the vm. You can also use docker the same way within the vm.

Performance wise the arm vm is blazing fast. Seems to be about 20x faster than an x86 vm on my old MacBook 2015. It’s about 2x the speed of an 8 core graviton2. When running emulated x86 code, the speed drops to about 1/4 the speed of my old 2015 MacBook. Not ideal but in our case we’ve only got a single non arm dependency and it’s not used often, so it works for us.

It’s a bit of a leap, and if you have more crazy binary dependencies like we do, you will have do to a little work to get things running.

Having said that, the machine itself is _amazing_. It’s a real joy to be on a machine with this level of responsiveness.

I weep for you.

As an alternative could you use React Native and borrow an Apple product during compile day?

Rebuilding your app in a completely different technology that you may or may not know seems like overkill for short-term computer woes.

Fair point. I find Front End theraputic so it doesn't seem daunting to me.

It's definitely a long term strategy, but people love eating Candy even if it gives you a stomach ache.

> Wouldn't simple running a docker instance both be less cumbersome, far more resource efficient, and quick to iterate, than literally installing an OS on a virtual disk?

On Mac, docker works by installing a VM- so the two aren't so different.

I (not the author) prefer using a VM as a development environment, because at some point I'll want to run a container and nested containers are tedious.

Docker isn't portable. Docker runs on Linux and only on Linux.

All the Docker pseudo-ports just run a Linux VM on the host OS and set up Docker inside it, for you.

Think you forgot about Windows: https://hub.docker.com/_/microsoft-windows-base-os-images

No. Can you run those images on Linux? :-)

Docker images are not portable, they run on Linux or on Windows, but they can never run on both.

Is this because you consider WSL2 to be Linux, and not Windows?

> Windows requires the host OS version to match the container OS version. If you want to run a container based on a newer Windows build, make sure you have an equivalent host build. Otherwise, you can use Hyper-V isolation to run older containers on new host builds. You can read more on Windows Container Version Compatibility in our Container Docs.

https://hub.docker.com/_/microsoft-windows-base-os-images

And WSL2 is Linux running in a VM on Windows.

Ah, my bad. I thought you meant not being able to run linux based images in docker when run with wsl2. There is also a significant difference between the vmware like implementation and wsl2. Spinning up a linux machine in VMware and running docker on that, as mentioned in the article, is quite a different ballpark. Especially when considering the limited CPU and ram resources.

> Seems like the idea is to run the whole dev environment is in a virtual disk in a VM

Pretty much.

I had bad experiences running Docker directly on MacOS. The IO latency was unbearable. I know they are working hard on it so maybe it's better now, but this setup works well for me.

I run Oracle DB (which is a scary piece of software) inside Docker on an Intel Mac. It runs perfectly fine.

What exactly are you guys running that causes it to be "unbearable"?

Are most of the database's files within the container's filesystem (as opposed to a volume mount)?

Most of the performance issues with Docker on Mac happen in setups where source code or other files are volume mounted from the Mac filesystem into the container filesystem.

As far as I can see everything goes into the massive ~/Library/Container folder. No volumes.

"but the upside is that there is no noticeable IO latency issues like when running Docker for Mac"

Docker on Mac can be dog slow. This is appealing to me.