Live data from Hacker News

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

news.ycombinator.com

11–20 of 284 posts

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

#11
post #5

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.

For terraform, I have been using tfenv to manage the different versions, and you can set a flag `TFENV_ARCH=amd64` so you download the Intel versions of terraform.

This will also download the Intel versions of all the providers when terraform executes. Which reduces the problems a ton since there are some providers that are definitely not aarch64, especially when it comes to older versions.

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

#12
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.

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

#13

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.

This works so long as your build isn't compute intensive. From my experience, you need real ARM (or cross compile) for stuff like C++.

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

#15
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.

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

#17
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.

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

#18
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/

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

#19
> 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.

Post reply on HN