Hacker News Reader

Comment by eckza | Hacker News Reader

Soooo does this mean that Docker will suck less on macOS, Real Soon Now?

I believe the main issue is file syncing between macOS and the container host OS.

I don’t have a M1 mac, but on my Mac a standard Linux VM has no impact on performance or battery life. The minute I use Docker the machine become sluggish and halves (literally) the batter life, I now avoids is as much as possible.

Have you tried enabling "Use the new virtualization framework" in experimental features? This removed the background CPU usage for me.

Try out Colima with the experimental 9p mount type. Network performance is improving. It's as good as it will likely get on the platform.

I have a M1 Macbook Pro with 16 GB RAM, and qemu ballons in RAM when I try to stand up our backend microservice stack locally - it uses RAM until there's none left, and falls over. My teammates running Linux report ~30mb of RAM usage by the Docker processes to run the same containers.

Vagrant solved most of my problems. Docker Desktop was unusable to me as well.

This can't boot x86-64 containers, but you can create an arm64 container and run x86-64 code in it.

I have to admit to a little bit of trepidation about the Rosetta mount point. Will this work for Docker without explicitly passing that mount point through to the containers?

Yeah I'm not entirely sure how they're going to make this work, but I kind of understand why it's so weird, because there's really not any very good way to communicate between macOS userspace and some arbitrary kernel running inside the VM…

The way this would work is Docker would be setting this up for you (maybe through some option to switch between qemu and Rosetta).

The containers should not need the mount. What happens is Rosetta gets registered with the kernel (binfmt_misc) to execute x86 binaries. The is the same mechanism that allows seamless qemu support.

Docker on macOS already has some kind of qemu based solution for running x86_64 containers on m1.

Potentially this could be used as an alternative?

It's QEMU emulation. It's slow. It also segfaults a lot. I am able to run a select few containers on it, but I needed to sort out native arm64 for the vast majority.

The main reason for segfaults is that not all syscalls (syscalls on linux are different per architecture - not even 32bit and 64bit x86 use the same) are implemented in a 100% compatible way.

Yes, this is exactly what Apple has done - created Rosetta that handles Linux ELF binaries, translates code and syscalls.

Yes, Docker on macOS can switch from qemu-user to this. It uses the same binfmt mechanism, so it should be mostly a drop-in replacement.

This is only available in combination with Virtualization.framework, but Docker is already migrating from Hypervisor.framework to Virtualization.framework.

I don't think that's right - containers are just userspace code, nothing to boot.

By my reading of TFA, your container runtime (eg Docker for Mac) should be able to provide an ARM VM, and use this Rosetta feature to run amd64 containers directly.

Containers that you and everyone else think of use Linux distros as a base, so yeah, anything else than Linux actually had to boot a VM to use them. That’s what eg Docker does on macOS.

Why does the rosetta binfmt_misc setup exclude starting amd64 containers? It's the same functionality the Docker desktop arm64 VM currently uses to run the process for an amd64 container via qemu (or any non arm64 container).

Reply on news.ycombinator.com