Multipass for an Ubuntu arm64 vm. Podman inside of there to create and run x86 docker images.
Ask HN: How are you dealing with the M1/ARM migration?
71–80 of 284 posts
Re: Ask HN: How are you dealing with the M1/ARM migration?
#72I just added creating and publishing ARM64 docker containers to our automated release process and the CI (GitHub Actions) time went from about 10 minutes to an hour and half. I don't expect many teams to volunteer to suffer this sort of slowdown and complexity in the near term.
I've been working on Depot (https://depot.dev) specifically for this reason: it's a hosted Docker builder service that runs BuildKit on managed VMs. When it receives incoming build requests, it routes them to a VM running the target architecture, x86 VMs run in Fly.io, arm64 VMs run in AWS.
Since it's all BuildKit, you can swap `docker buildx build` for `depot build` and it works exactly the same - I made a depot/build-push-action to drop in place of the docker/build-push-action in GitHub Actions.
It also has a persistent SSD cache disk for each builder, that was my other pain with GitHub Actions, time saving and loading layer cache was negating the speedups from cache hits - with a persistent disk, there's no saving or loading.
Anyways, combo of having a local cache and running on real ARM machines gives like an order of magnitude speedup to builds compared to the QEMU emulation.
Still a new project, not yet officially launched, and hosted services aren't for everyone, but exactly as you said, the status quo is amazingly painful.
Re: Ask HN: How are you dealing with the M1/ARM migration?
#73I just added creating and publishing ARM64 docker containers to our automated release process and the CI (GitHub Actions) time went from about 10 minutes to an hour and half. I don't expect many teams to volunteer to suffer this sort of slowdown and complexity in the near term.
That's because there are no arm runners on GitHub actions. So you now emulate arm, thus slow.
You can add hosted arm GitHub runners or register arm hosts for docker and see down to earth build times.
Re: Ask HN: How are you dealing with the M1/ARM migration?
#74Vagrant + vmware vagrant plugin (https://www.vagrantup.com/vmware/downloads) + vmware fusion tech preview (https://communities.vmware.com/t5/Fusion-for-Apple-Silicon-T...).
Currently running a bunch of Ubuntu (arm) virtual machines and my mbp m1 handles it really nice.
Re: Ask HN: How are you dealing with the M1/ARM migration?
#75I tried going from a 2018 MBP to M1 MBA in 2021 and had too many issues to make it my primary machine. Docker and Android development were particularly brutal to get going reliably IIRC. The M1 performed well for the things it could do, but I still needed the MBP (which constantly reached 100% CPU) for other stuff, so I ended up doing a horrible multi-machine setup with Synergy. That was a dark time in my life ;) The…
> The only thing I'm still running in Rosetta is Apple software: XCode and the iOS simulator, but they run smooth, so I don't even think about it.
How old is your version of xcode? From what I can see they added M1 support 1.5 years ago.
Re: Ask HN: How are you dealing with the M1/ARM migration?
#76I switched basically at the very beginning of M1 release. It was an absolute nightmare until I got everything working (was using Docker Desktop extensively), and then I haven't thought about it since.
Re: Ask HN: How are you dealing with the M1/ARM migration?
#77When I started, I had Rosetta for almost everything, and I was able to do my workflow without Docker (super broken that was). Several months later, I reset my Mac and reinstalled everything, this time with far fewer Rosetta parts. Several months later, did it again, and this time was completely free of anything needing Rosetta because everything was native by that point.
Re: Ask HN: How are you dealing with the M1/ARM migration?
#78The desktop user experience has been quite good
Virtualization Framework’s VLAN support is not mature and getting more than 100 machines per rack has proven difficult. The need for additional switches, patch panels, uplinks and cooling makes multi-thousand machine installations slow due to the recent logistics unpleasantness.
Using Studios is hard because of massive delays to orders. Especially the ‘big’ machines in 1,000 unit quantities.
x86 and x86/GPU still seems to be the best approach for prod datacenter use.
Otherwise I am a fan
Re: Ask HN: How are you dealing with the M1/ARM migration?
#79If you bring up a remote VM and set DOCKER_HOST to something like "ssh://root@$IP" and have key auth set up, the local docker CLI works as it always did but using a remote dockerd via ssh. I do all my container builds this way (on remote x64) because hotel/LTE internet sucks and I would rather download 47363367373 npm packages 4700 times on datacenter gigabit.
Re: Ask HN: How are you dealing with the M1/ARM migration?
#80Just my 2cs, results may vary, but my (short) experience with the m1 was so bad I switched back to a dell xps the week after I got it. Things may have gotten better meanwhile ofcourse, my local developer experience was dreaded. Some of the non arm targeted images took ages to start, some didn’t start and others were straight up flaky. I’m not touching the m1 until I know all these issues have been resolved, docker file system api complete, all arch targeted images etc. It also doesn’t make the situation any better that a majority of the images we have been running locally are all really fat Java dependencies likes Kafka etc.