Ask HN: How are you dealing with the M1/ARM migration?

The biggest challenge was getting multi-arch builds sorted. Ended up putting together a layer on top of QEMU to run both x86-64 and aarch64 VMs (https://github.com/beringresearch/macpine). Have pre-baked VMs with LXD installed inside each instance, with main software builds taking place inside LXD containers - works pretty well so far.

It would have made sense to simply ignore the M1 hype altogether since the tools you require do not work / run on ARM, or run worse than on Intel, you're better off staying on Intel to wait until the situation for VMs in Apple Silicon improves first: [0].

For developers using VMs, Docker, multi-pass, etc I think it is more trouble than it is worth to jump on to the new shiny thing and invest time in workarounds that break on a new update. At least you weren't part of the November 2020 launch day chaos otherwise you would be waiting 6 months to do any work if you went all in on the M1.

Looks like Intel is (still) the way to go for VMs until Apple Silicon gets better (eventually).

[0] https://news.ycombinator.com/item?id=26159495

There have definitely been some rough edges (on my end mostly related to terraform modules. don’t have a big docker/vm dependent workflow anymore so that might be why.)

But apart from that it’s been incredibly smooth.

Azure has ARM in preview, and AWS has had it for ages. You should be able to create multi-arch builds in CI.

For actually creating multi-arch, I recommend you stay as far away as possible from Docker and use Podman and Buildah. The latter unbundles some of the Docker manifest commands, giving you far more control over how you create multi-arch images. I wasted 4 months on Docker tooling, and got it right in half a week with Podman. This meant switching from DCT (Podman doesn't support this at all) to Cosign, but Cosign is far more sensible than DCT.

There are a rare few containers that you can get away with running on x86.

Waiting for GitHub actions to have ARM.

Multiarch builds are pretty darn easy to setup in my experience (exclusively Linux based images FYI) so I’d refocus the energy spent on Virtualbox, etc to just setting them up and then problem solved.

For me personally (as a freelancer), it's been a pretty smooth transition. I have a dozen or more projects relying on node-sass (which fails to compile on M1), which has been annoying but easily remedied.

For my 9-5 employer, biggest drawback we've come across is that SQL Server can't be installed on Windows 11 ARM, which is preventing us from having a truly local development environment.

We've gotten everything else working via Azure SQL Edge running via Docker for Mac, but it lacks several features that we require (e.g. full-text search, spatial data types).

Despite a recent announcement (https://blogs.windows.com/windowsdeveloper/2022/05/24/create...) that Visual Studio will soon support ARM, There are no signs that SQL Server 2022 will support ARM.

My employer is still moving forward with provisioning M1 MBPs for developers.

I'm lucky enough that I need high performance and have native dependancies that don't provide m1 binaries. So, I can worry about other problems

I don't own an ARM computer (except the ones running Android, that is) but in my experience Linux tooling should work just fine on ARM if you pick the right distributions. That said, I have run Linux distros on Android a few times so I am somewhat familiar with what's out there.

Running x64 and ARM together on one machine will work through tricks like Rosetta but I don't believe that stuff will ever work well in virtual machines, not until Apple open sources Rosetta anyway.

I'd take a good, hard look at your tech stack and find out what's actually blocking ARM builds. Linux runs on ARM fine, so I'm surprised to hear people have so many issues.

What you could try for running Docker is running your virtual machines on ARM and using the native qemu-static infrastructure Linux has supported for years to get (less efficient than Rosetta) x64 translation for parts of your build process that really need it. QEMU is more than just a virtualisation system, it also allows executing ELF files from other instruction sets if you set it up right. Such a setup has been very useful for me when I needed to run some RPi ARM binaries on my x64 machine and I'm sure it'll work just as well in reverse.

Vagrant + parallels on m1 and intel. Works beautifully.

I'm in much the same boat, and I've coped by just switching to a nice beefy Linux desktop for most things.

I like how ARM is progressing (I owned a second-batch RPi!), and M1 would probably be right for me if I wasn't a technical user, but it's simply too exhausting to fight the machine, architecture, package manager and product all at the same time. Docker is (and has been for a while) loathsome on Mac. Virtualization is usually pretty bad too, which makes regression-testing/experimentation much slower. I might give it another go if Asahi figures out GPU acceleration, but I'm not very hopeful regardless. The M series of CPUs doesn't really make sense to me as a dev machine unless you have a significant stake in the Apple ecosystem as a developer. Otherwise, it's a lovely little machine that I have next to no use-cases for.

> Any tips/tricks?

Here's one (slightly controversial) tip: next time you're setting up a new Mac, ditch Homebrew and use Nix. This is really only feasible if you've got a spacious boot drive (Nix stores routinely grow to be 70-80gb in size), but the return is a top-notch developer environment. The ARM uptake on Nix is still hit-or-miss, but a lot of my package management woes are solved instantly with it. It's got a great package repository, fantastic reproducability, hermetic builds and even ephemeral dev environments. The workflow is lovely, and it lets me mostly ignore all of the Mac-isms of MacOS.

I 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 ;)

Then tried again early this year with a M1Max MBP, and it has been the biggest step change productivity boost of my life. Definitely still some pain points, but the way this thing handles anything I throw at it is incredible.

I'm mostly doing front-end dev (react native). Have a minimum of 2 IDEs, 1 iOS simulator, 1 Android simulator, Windows (ARM) Virtualbox, 2 browsers open at all times. And then add a mix of Docker, XCode, Android Studio, Zoom, Sketch, Affinity apps, Slack, Zoom, etc. I haven't ever heard the fan spin up. I was carefully managing what I had open on the 2018 MBP, and now I don't even think about it.

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.

The MBA setup I was just flailing my way through. For the M1Max setup, I found this guide very helpful in my initial setup (mostly focused on a RN Dev): https://amanhimself.dev/blog/setup-macbook-m1/

> That means other tools that rely on it are also out of the picture, like Molecule

You can run molecule against an ec2 instance or Docker containers. Since you can run x86_64 docker containers on Docker for Mac, you can continue to use molecule. I run molecule tests against Docker containers or LXD in the cloud though just because of how much faster they run on large Ec2 instances.

As for everything else, I haven't really noticed many issues. Most of the work I do is built through CI/CD pipelines so what I use locally to build doesn't affect what is deployed to production.

I almost exclusively use FOSS. Most of it was ported a decade ago at least.

I don't have Mac, I'm a Linux user but many if my colleagues have Macs, some of them are M1. And the arm thing is really a pain, much more than the difference between OSes. Just a random example: we have some app which uses MySQL 5.7, and we use MySQL in docker for integration tests. Unfortunately MySQL 5.7 won't run on arm (current workaround: they use a mariadb image, which is apparently good enough, and the CI would catch any difference). There are many small things like this, I would currently not recommend using those new Macs until things improve if you want to avoid wasting time on uninteresting issues.

Whatever this years macOS version is called includes support for running Rosetta on linux VMs at least which sounds like once VM apps adopt the appropriate APIs that will solve many of the problems in these comments

0 Problems: I'm a JVM developer, all of my tools work as intended. We deploy things as one-jar with no OS dependencies other than ENV variables for configuration.

At some point we're going to have the opposite issue. Stuff will work for ARM but not x86. Thanks Apple.

At least some aspects of this issue are getting better as we speak. The latest Mac OS (in beta) supports virtualizing ARM Linux but also enables the ARM Linux system to use Apple's speedy Rosetta 2 x86 binary compiler and JIT compiler to run x86 programs within the ARM Linux VM. Based on descriptions, it seems that the rest of the hypervisor VM framework has also matured substantially this release.

https://developer.apple.com/documentation/virtualization/run...

https://developers.apple.com/videos/play/wwdc2022/10002/

If you are not familiar, Rosetta is how Apple Silicon Macs run existing Mac x86 binaries and it is highly performant. It does binary pre-compilation and cacheing. It also works with JIT systems. They are now making that available within Linux VMs running on Macs.

I'm an Eng for a startup using Rails, MySQL, ... Next.js.

The only problems we've had is slow performance of Docker for us with our databases. So much so, we've moved those out of Docker and back to the native. Performance is easily 6x faster. MySQL was also a headache because finding a MySQL 5.7 official Docker container didn't exist for ARM so we needed to use the slow emulation through qemu.

We also have a CLI dev tool that is written in Python and distributed in Docker (x86) which has also been slow. Not enough time to build ARM based Docker image.

I'm in a similar boat - love the performance/battery of my M1 MacBook Air, but the ecosystem is just too messy at the moment for me. I have a few tools I need to use that haven't yet been making official Apple Silicon releases due to GitHub actions not supporting Apple Silicon fully yet. The workaround involves maintaining two versions of homebrew, one for ARM and one for x86-64, and then being super careful to make sure you don't forget if you're working in an environment that's ARM and one that's X86. It's too much of a pain to keep straight for me (I admit it - I lack patience and am forgetful, so this is a bit of a "me" problem versus a tech problem).

My solution was to give up using my M1 mac for development work. It sits on a desk as my email and music machine, and I moved all my dev work to an x86 Linux laptop. I'll probably drift back to my mac if the tools I need start to properly support Apple Silicon without hacky workarounds, but until GitHub actions supports it and people start doing official releases through that mechanism, I'm kinda stuck.

It is interesting how much impact GitHub has had by not having Apple Silicon support. Just look at the ticket for this issue to see the surprisingly long list of projects that are affected. (See: https://github.com/actions/virtual-environments/issues/2187)

On the whole it's been good.

I work on scientific software, so the biggest technical issue I face day-to-day is that OpenMP based threading seems almost fundamentally incompatible with M1.

https://developer.apple.com/forums/thread/674456

The summary of the issue is that OpenMP threaded code typically assumes that a) processors are symmetric and b) there isn't a penalty for threads yielding.

On M1 / macOS, what happens is that during the first OpenMP for loop, the performance cores finish much faster, their threads yield, and then they are forever scheduled on the efficiency cores which is doubly bad since they're not as fast and now have too many threads trying to run on them. As far as I can tell (from the linked thread and similar) there is not an API for pinning threads to a certain core type.

1. Run arm-based debian using Parallels, headless using `prlctl`. SSH in and use tmux.

2. Everything you install will be arm based. Docker will pull arm-based images locally. Most every project (that we use) now has arm support via docker manifests.

3. Use binfmt to cross-compile x86 images within prlctl, or have CI auto-build images on x86 machines.

That pretty much does it.