How are you dealing with the M1/ARM migration?

I got an M1 MacBook Pro from work last year, and expecting to pay the price for being an early adopter, I set up my previous Intel-based MBP nearby in case I ran into any problems or needed to run one of my existing virtual machines. (I do varied development projects ranging from compiling kernels to building web frontends.)

In reality I have hardly turned on the Intel MBP at all since I got it. At all.

Docker and VMware Fusion both have Apple Silicon support, and even in "tech preview" status they are both rock solid. Docker gets kudos for supporting emulated x86 containers, though I rarely use them.

I was able to easily rebuild almost all of my virtual machines; thanks to the Raspberry Pi, almost all of the packages I use were already available for arm64, though Ubuntu 16.04 was a little challenging to get running.

I also had to spend an afternoon updating my CI scripts to cross-compile my Docker containers, but this mostly involves switching to `docker buildx build`.

Rosetta is flawless, including for userland drivers for USB and Bluetooth devices, but virtually all of my apps were rebuilt native very quickly. (Curious to see what, if anything, is running under translation, I just discovered that WhatsApp, the #1 Social Networking app in the App Store, still ships Intel-only.)

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

There are many comments here that goes: "we had to do all sorts of configuration for this to work, but it's been great and we like it".

As a primarily Linux user these feel like very familiar stories.

It's kinda refreshing to hear those stories from mac users. Maybe we are not so different after all.

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.

For now I'm ignoring it, I'm usually about two to three years behind the curve and by then the bugs have typically been ironed out. I won't be running macOS anyway, but will wait until a fully supported version of Debian is out there that uses all of the peripherals properly. They call it the bleeding edge for a reason and I see no reason to spend extra effort that isn't driven by an immediate need. I like tech, I can't stand fashion.

Simple: I never target specific CPUs to begin with ;)

I'm only half joking. I'm of the group of people who know that Docker is a security nightmare unless you're generating your Docker images yourself, so wherever I've had to support that, I insist on that. If you don't use software that's either processor centric (and therefore buggy, IMHO) or binary-only, then this is straightforward and a win for everyone.

Run x86 and amd64 VMs on real x86 and amd64 servers, and access them remotely, like we've done since the beginning of time (teletypes predate stored program electronic computers).

Since Docker is x86 / amd64 centric, treat it like the snowflake it is, and run it on x86 / amd64.

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.

Over at Airbyte, we had a project this quarter to update all of our build & publish processes over to building multi-arch (AMD and ARM) docker images. As Airbyte runs entirely within docker, getting a smooth local experience for folks on M1/(2?) Macs was important. We had a long lived support thread (1) where you can see us grow through all the phases - from "nothing works", to "our deps don't work", to "the platform works" and finally to "the connectors work"!

Assuming your base images are themselves already multi-arch, most of the tooling we needed was already built into the `dockerx` build tool, which is awesome - check it out if you haven't (2). Docker has bundled all the tooling and emulation packages (qemu) needed into a single docker image that can publish multi-arch docker images for you! You run docker to emulate docker to publish docker... There are some interesting things that you'll need to do if you publish multi-stage builds, like publish a tmp tag and delete it when you are done, but it's not /too/ terrible. Since Airbyte is OSS, you can check out our connector publish script here (3) to see some examples.

I'd recommend that spending the time to work your multi-arch tooling - not only does it make the local dev experience faster/better, it:

1. unlocks ARM cloud compute, which can be faster/cheaper in many cases (AWS)

2. removes a class of emulation bugs when running AMD images on ARM - mostly around networking & timing (in the JAVA stack anyway)

Links:

1. https://github.com/airbytehq/airbyte/issues/2017

2. https://docs.docker.com/buildx/working-with-buildx

3. https://github.com/airbytehq/airbyte/blob/master/tools/integ...

Early reviews said that even the base 8GB RAM models were snappy, despite the small amount of RAM. I went in believing that, but turns out it was anything but. Maybe it was my specific usage (Firefox with tons of tabs, Electron apps open all the time) but it feels much more sluggish than my previous 2013 iMac. Next one I get is definitely going to have 16GB minimum, maybe 24GB.

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/

I work at a SaaS vendor.

We are completing a project to upgrade to Java 11 for most of our micro services. This will also mean we do multiarch container builds for our entire pipeline. Once that is complete, we will begin developing against ARM as the primary target for devs. This is needed because we are in the middle of a hardware refresh so by EOY, something like 80% of devs will be running on M1 Pro.

This should end up saving us money long term as we move all the cloud workloads to Graviton2/3 and Ampere A1 hosts.

We'll be multiarch for many years to come. I also don't see a timeline for us to sunset x86 support considering we also do on-prem installs and ARM rack mount servers are nearly impossible to source.

The 8GB M1 versions don't have enough RAM for a lot of dev work, doing pretty ordinary things created a lot of RAM pressure when I had one. I later bought Max with 64GB, and that has been brilliant. I gave up on the idea of using Docker almost immediately.

Early on there were major issues if you were targeting x86-64 systems code in C++. A lot of common tooling was broken for months on end. Time has solved some of these problems but ultimately I wrote code to support native ARM targets as first-class code citizens. There was a significant learning curve (I was not fluent in ARM64 ISA) but now that everything is ported, running native, and the tooling has finally started to catch up, it works pretty smoothly and I don't have much to complain about. The x86 emulation has limitations so native is the only way to go for many things, and you'll still want to test some code on real x86 server hardware.

That said, the latest OS on (at least) the M1 is noticeably buggy. Lots of behavioral artifacts that I wouldn't expect. Not sure if it is the hardware or the software, or both. Nothing catastrophic, just annoying.

Just 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.

It's been silk smooth for native desktop (macOS) and mobile (iOS/Android) development. I make it a point to keep the projects I'm responsible for running with the latest toolchains, though.

The amount of trouble that some seem to be having with backend dev on M1 makes me wonder if maybe it wasn't the best idea for the industry to put its collective eggs in the single basket of trying to perfectly match dev and prod environments. If nothing else, it feels weird for progress and innovation in the world of end-user/developer-facing computing to be held back by that of the server world.

I don't use Docker so I have had no problems whatsoever. Getting all the Mac apps I code on building for Arm was easy.

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 happy with it.

Here's a tip for anyone with docker compatibility problems: If you add `platform: "linux/amd64"` to your docker-compose (there's also a similar command for Dockerfile iirc), it just gets the x64 images and emulates those.

There is emulation overhead of course, but it's not perceivable in my experience, compared to running native images.

Vagrant + 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.

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.

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.

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.

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.

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.

Same experience,

Maybe this will help:

https://arstechnica.com/gadgets/2022/06/macos-ventura-will-e...

I 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 think it has been mentioned a few times already but ARM64 on servers is also quite compelling (Graviton on AWS and Ampere Altra in Azure). I've actually seen a few customers that couple the move to new M1 MacBooks for their devs with a move to ARM in production as well to retain that same "the same container image runs on both" that they were used to even if they go multi-arch just incase.

In one case the devs were given the condition of getting their containers working on ARM to get the new MacBooks they wanted - and the cost savings of moving to ARM in cloud even subsidised the cost of them a bit too...

I’m working on re-factoring a developer environment from using vagrant/virtualbox and docker to only docker.

The prior goal was to mock production as closely as possible.

The realization is that macos as a host machine for orchestration is close enough to build. More strict validation can be done in CI and a staging env.

So for this project, the forced transition away from virtualbox Has actually led to simplification and asking questions about why it was “required” previously.

It is a bit of a pain only because some team members will need more support than others so the entire setup kind of needs to be clean and carefully documented when there is other stuff to do.

received my M1 last week , my dev workflow is Alacritty->tmux->neovim+lsp+debuggers.Do mostly golang work,installed delve and it went fine followed all steps and compiled from source.Followed same for neovim and compiled from source as i use the lua instead of vimscript. All lsp setups works fine ,unfortunately native delve debugger is not able to communicate with neovim using native back end.As if now for debugging am relying on only terminal based debug not using neovim specifically.In a rabbit hole now as this is neither neovim nor delve so thinking might be new apple arch M1.Not sure if any one else stumbled on the same. with regards to docker as the workplace have licenses i use them with no issue.Entire team is using only mac no other operating system allowed in so safe till now.

We had an engineer in India get an M1 MBP last month and most things worked, but the docker container for MS SQL had big issues and he had to get an Intel MBP to be able to work. I suspect that those issues will dissipate with time. Right now, I find it annoying that the only OTP auth apps that are available for the Mac require Apple Silicon as they're essentially iPhone apps with new skins. I really want to be able to get something like Google Auth in my menu bar so I don't have to pull out my phone every time I need a code for Okta.

We prioritized a well working dev env on M1 half a year ago and made our Docker images multi arch, etc. It mostly just works nowadays, only one small niche service needs x86 still and it’s in the process of being replaced. We also started taking advantage of ARM machines on AWS as part of the transition. Granted it was easier to justify this as a younger faster growing company because it doesn’t take as long for the majority of developers to be on M1s and less “stuff” has accumulated over less years.

We had a customer testing our video player application recently and asked whether M1 support was there. It was embarrassing to realize we hadn't formally tested on the M1.

Our application is Gstreamer based, which means it uses highly optimized codecs that eventually render to OpenGL. I was very worried it wouldn't work on the M1.

It works flawlessly. Rosetta is amazing. I'm not an Apple fanboy at all but Apple has done an amazing job with M1 and this is true even though many applications are just running x86 code via Rosetta.

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.

For me it's been mostly painless. I've even used Time Machine to migrate from a 2012 Intel iMac to an Apple Silicon Mac Mini and it worked perfectly!

The two pain points:

1. No support for running older virtualized macOS. I like to test back to 10.9 and need an Intel Mac to do that.

2. One Python wheel which doesn't have Apple Silicon builds and doesn't build cleanly: https://github.com/CoolProp/CoolProp/issues/2003

Oracle sucks.

I mean in general, but they have also not released ARM instantclient or even an ARM version of Java. I think its crazy that I'm using Microsoft's version of ARM java.

I'm also using Windows 11 ARM in Parallels, which does seamless emulation of Oracle instantclient / Java / PL/SQL Developer. So most of my workflow has not been interrupted.

Still, just another excuse to move to a better database. Now all I have to do is convince our heavily bureaucratic IT department to move away from Oracle. It'll be easy, right?

Higher Education IT here. For our users that we support, it's been great on the whole... except for those who need to use a VM for the occasional Windows-only desktop app. UTM[1] seems to be the best option (everything else is in technical preview or not supported?) but it's slow as a dog to emulate x86. ARM Windows isn't great either if you want to just virtualize. Suggestions welcome!

1. https://getutm.app/

Software is constantly evolving, so any worldview based on “if it ain’t broke, don’t fix it” is absent of reality when it comes to software.

My philosophy on most things is: if nobody else has done it, I’ll go first. I started compiling and bundling my Go applications as multi-platform universal binaries for macOS.

Last week, I spent a few hours learning how to build multi-architecture Docker images, and push them into Artifactory. That knowledge came in handy yesterday when one of the developers on another team got a new M1 Mac and could no longer build his Docker images.

Over winter break, I started putting together a build matrix for compiling RPMs, DEBs, and Alpine APKs for some software that some developers were building as part of their CI pipeline. We’ve been curious about the ARM-based EC2 Graviton instances for a while, and I only had to update a handful of lines of code to begin building arm64 versions of those same packages.

In short, necessity is the mother of invention. I enjoy inventing things. If nobody else has started adding support for arm64 to your internal pipelines, then you should go first.

If 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.

Waiting for GitHub actions to have ARM.

No problems here. Node, php, apache, mariadb, postgresql run native out of the box via homebrew. Java11 and Java17 have native aarch64 builds via homebrew and/or temurin (or the oracle openjdk project, which unfortunately doesn't seem to care about being a responsible security patch vendor at all). Android studio is fine except they don't support androidtv emulators yet. UTM with an aarch64 debian host runs mssql (azure edge sql) in docker natively, as well as anything you'd expect from a high quality debian distribution. UTM with windows 11 arm64 even runs vs2022 through its fairly efficient x64 usermode translator (WPF apps and everything). Xcode and the iOS simulator works great as expected, too.

Even the x64 java8 SDK for macOS runs without a glitch, I mean how impressive is that, with JIT and everything? Mind blown.

I didn't even understand the point of the new macOS 13 ventura linux rosetta thing until I realized some people are still running x64 docker containers. (why, though?)

We had already eliminated Docker from our CI/CD and live deployments (using Kaniko for CI/CD and containerd for live), so we just modified our container build pipeline to run Kaniko twice (once for x86_64 and once for arm64) and then use manifest-tool to build and upload the multi-arch container manifest. I think we had it working within a day, and then it took a week or so to test and validate all our images, and one or two needed some attention due to having dependencies that weren't already multi-arch. Overall it was really painless.

For testing container builds on developer machines most people are either using Docker on macOS which already handles multi-arch cleanly, or using buildah on Linux which also handles multi-arch automatically if you set up qemu binfmt support. So that has been pretty painless too.

I would say if you are doing a lot of horrible workarounds, it's probably time to step back and look at improving the processes (like your pipelines).

I use m1 max in work and personal projects and have done so since November. I primarily work in *ops, choose your flavor (dev/sec/ml/net).

The only issues I have ever really ran into were:

RKE had issues on arm early-on. Random containers didn't have arm image support. This went away quickly as an issue for me.

No nested virt. This one was painful for a few reasons, particularly when I was attempting to use the Canonical tooling to create preinstalled Ubuntu images, which I was doing in a vm via Multipass. Maybe M2/M3?

That's about it, really. I had to buy two Safari extensions when moving from Windows, but they were cheap and worth it (dark reader and some other one I can't remember rn)

I currently run Rancher Desktop every day as a replacement for Docker Desktop. Works spectacularly for me, and I can just not care about the environment. Just works.

I use Multipass when I need linux environments, and it's been spectacular.

Universal control has been the greatest enhancement in my workflow (and general daily use)

Our entire dev team switched from MacBooks to laptops running linux.

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

If this were a Debian machine, you could probably just crossgrade your existing amd64 install to arm64 and everything would continue to work. The process would involve qemu user mode until you move the SSD over to the new machine. Once the work of the Asahi Linux folks reaches Debian this will likely be possible for M1 machines, can they accept non-Apple SSDs?

https://wiki.debian.org/CrossGrading https://www.qemu.org/docs/master/user/ https://asahilinux.org/

We went multi-arch for Graviton a while back so our pipes are multi-arch anyway, not much of a problem. The tooling is mostly Go-based so after Go got ARM on M1 it was a reasonable switch. We had switched to podman too but once rancher is M1-ready we'll use that. So not much of a change here, except for some Electron-based apps that were slow to update in the beginning.

Most of the problems were foreseen because we had AIX and PowerPC systems in the past where we had to have multi arch pipelines already, I suppose most of the problems with the M1 were around monoculture setups that we see much more often around the world. Same architecture, same OS, everywhere. But that's actually much less 'normal' over the existence of computers than people think.

Two big issues with my workflow caused by M1:

-occasional Postgres failures (i/o errors, especially with parallelization)

-kernel panics when connecting an external Sandisk ssd (known issue according to Apple forums)

It’s a shame because the machine is so much faster and energy efficient than my 16” intel MacBook Pro

Haven’t had any major issues since switching. Still easily able to get on with my day job and toy around as I always would.

Glad that the world is catching up a little but it’ll take time like anything else.

Biggest issue for me early on was android emulator, once an M1 version was released it was all easy going.

I don't like using Apple computers, and don't have an M1, but I've been having similar fun with a Microsoft Surface Pro X (running insiders build of Windows 11 which has x86-64 emulation for NT processes, and runs Android applications, but doesn't support emulation in WSL2). Overall much the same experience with things assuming the only execution environment is inside an x86 docker container. I also found that the "stock stack" Haskell development toolchain install (in WSL2) won't work, again due to lack of build runners at GitHub. Eventually I was able to find workarounds for all the annoyances, mostly involving building components myself.

You say your job is DevOps work so you probably feel the pain more than most people do.

Not being able to run amd64 containers hit me hard. I fought it until I just gave in and made sure that everything we built could be built under amd64 or arm64. For specific builds on a specific architecture, GitHub action runner on a cloud box. (Or pick your flavor of CI/CD).

Once I looked past my machine into an ecosystem and embraced the arm as just another build artifact it was easier.

I also reject testing locally as a measure of working software. So that eliminates some pain. If your coverage is high then this is an easy shift. Have a dev environment that you can test that matches your assumed architecture, toolchain wise.

Mine has been great, but it's not a fair comparison. I write native apps for Apple stuff in Swift, so I'm pretty much who the new stuff was optimized for.

I have noticed that some apps can get "hangy," including Xcode, SourceTree, and Slack. I sometimes need to force-quit the system (force-quitting apps seems to now have about a 25% success rate). SourceTree also crashes a lot. A lot of this happened after I got my MBPMax14. I don't know if it would happen with any other machine.

These are not showstoppers (I've been having to force-quit for years. Has to do with the kind of code I write), but it is quite annoying. I have faith that these issues will get addressed.

I just had a leap of faith and god an M1 MBA with 8GB of RAM in January 1st around 1 month after its release

And I never had any problems with it up until now. I use Chrome (Vivaldi) with tons of tabs and VS code with NodeJs and Java development and it was all snappy all the way

The main problem I had was at that time whether there will be application support for ARM and almost all the apps I use started supporting ARM as soon as the M1 came out

I only had to use Rosetta few times and NodeJS also started supporting ARM architecture as well

But next time I’ll be going for a higher RAM than 8gb for longevity

But I think I’ll be using this for couple more years and I think I’ll be skipping M2 since my M1 is good for now

I do most of my work in Go (with the very occasional splash of Swift or Kotlin) and the move to M1 has been utterly seamless for me. So much so that I often forget I'm working on an ARM64 machine until I forget to set GOARCH when compiling and then try to copy a binary to a remote machine.

The majority of Docker images that I use are available for ARM and the few that aren't perform fine under Docker for Mac emulation (although the big performance boost that I saw ultimately came from enabling VirtioFS accelerated directory sharing).

Just about all of the tools that I use are now available as universal binaries, but before that, Rosetta was utterly seamless.

I really can't complain.

I think I've commented before on this but I've had great success using VSCode Remote Containers. Essentially using the M1 as a frontend to an x86 environment.

Works great and I can move between a local and cloud servers depending on requirements

I just have a headless x64 linux machine running docker and use the docker cli from my mac to interact with the remote docker (via docker context), and use a synced directory structure for any funky volume mounts I need. Works great.

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.

Not a Mac user but from running ARM64 both on servers and desktops for some years now, 99% of friction came from having to source-build projects which don't provide precompiled binaries. For me this is mostly a positive since it helped making me more consistent in actually building all container images and as much of the software I use as possible from source.

With good habits, it's rarely an issue anymore (though there is the occasional project when it turns out to be a hassle, usually something with an obscure node-gyp build).

If you rely on closed-source software it's a different story, I guess.

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.

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

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.

I am the only Mac user on a small team of web-based tool devs for my company. Everyone else is on Linux.

I occasionally have to do exploratory processes where I have to figure out how to setup the same environment locally that my teammates are using. It can be time consuming, but overall I’m able to replicate it just fine. We’re far enough into the transition that most stuff is supported out of the box.

I admit I don’t know much about what’s going on under the hood. I used podman for containers so far.

The 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

In our small backend engineering team, which also takes care of the DevOps work, we just have a multiarch docker image that we use as a base image to build the ARM local dev images and the CI/CD (running on amd64) builds the production images. Everything works flawlessly, docker knows what architecture to build in each case. There was some work we had to put into the base image to make it build multiarch, but then we basically forgot about it

Intel Mac -> M1 Mac this week.

Almost perfect, but I did switch development tools from Xcode/Swift/SwiftUI -> VSCode/Dart/Flutter at the same time. So I am having a lot of problems! But nothing mush unexpected.

I copied my system over with timemachine. I think that a lot of binaries got copied that I should reinstall.

> none of our pipelines yet do multi-arch Docker builds, so everything we have is heavily x86-64 oriented

Another data point for the fundamental principal: Portability matters

We had the same issue and ended up using remote docker.

Pros: - Setup is very simple. - It can run dozens of containers without overloading local machine. - Its stable. - SSL is working.

Cons: - I got issues with web sockets support. - Some times I get file conflicts.

I actually got ready solution for running remote docker with Mac but It need a bit of work. If someone would like to support project some front-end work, and a bit of docker/nginx work, please get in touch.

Maybe this should be a wakeup call to stop using docker and virtualization for DevOps. They have their place in CI but should not be used for local development.

It wasn't clear from the post, but do you work with things that actually depend on the architecture a lot? I'm dealing with the opposite (still on x86, applications get deployed on arm) and the answer was: pretend it isn't happening. If there are obvious issues, they'll be caught by the CI which is running the target architecture. If there are non obvious problems, I can spin up a vm in AWS immediately.

Recently got an M1 Mac, I couldn’t be happier. I use it all day every day for dev (ruby, node, react)

Everything was far easier than I expected it to be, the only issues I had was with installing python (a few cli Utils required it) but everything else has been smooth sailing and a much better experience than running things on my 2019 MBP

I’m not a huge docker user, but I run it for a few things and again, it was all smooth sailing.

My first task at my current job I had to port our local dev environment to M1, out of necessity. Docker was relatively straightforward but I ran into a hell of sorts trying to get deps to compile on my aarch64 container, especially for stale projects like leveldb and eleveldb.

In short it was painful but once you get over the attrition of compiling (mainly C) deps it's smooth sailing from there on out.

Dropped docker for local development and I just run stuff natively relying on tests and CI to catch any issues but I haven't really had any.

I still have trouble figuring out how Docker works on M1 (I don't have one and I'm not sure it it meets my demands, infinite loop). Can I just pull a random image and expect Rosetta to do its thing without worrying? I can understand that 90% will work without issues, but it's always the remaining 10% that will suck up all of your time.

When 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.

> Then there's just other annoyances, like having to run a VM in the background for Docker all the time because 'real' Docker is not possible on macOS.

As far as I know, this has nothing to do with the M1 or ARM. This has always been the case. How else would you run Linux containers on a non-Linux OS?

I keep an x86 Mac mini to run my VMs. One of the VMs is an old version of OS X that runs some 32-bit programs that won't run on newer versions that I am still converting data from[0]. Apple is awful about running old programs.

0) still converting some stuff in Lineform. Shame there wasn't a 64-bit version before they stopped selling it.

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

Some of our 3rd party dev packages don't have M1 support, and docker cross-compilation for M1 has been a nightmare. 8GB RAM is too low as well. Our team is staying on just Intel mac/win/linux computers until we have the resources to address the M1 issues.

If you need to work with amd64 Docker images on an M1, just SSH to an amd64 AWS instance and do the builds there while things get ironed out. Otherwise, you can do the builds with `docker build --platform linux/amd64` but it'll be slower since it's emulated.

Multipass for an Ubuntu arm64 vm. Podman inside of there to create and run x86 docker images.

After reading those comments, I am so glad I did upgrade my old mbp 2015 to a razer laptop. Battery life is horrible, but I don't care.runnkng out of battery in Bed coding, or bar coding forces me to take a pause anyway.

So so glad, running plasma.

We resorted to building multiple images manually and pushing them to ECR. Then just have an override compose file that people with M1s have to use. Fortunately, have only had to do that with a couple images that aren’t updated all that often.

React Native/iOS dev here. Everything working flawless here. Also some backend coding in Parallels + Windows 11 ARM + Visual Studio 2022. Runs great.

I also semi-professionaly use Photoshop, Sketch, DaVinci Resolve, XD, After Effects.

All butter smooth.

Losing eGPU really hurts.

I had three-up before, and now I’m back to the laptop and one central display.

I could get a cheap DisplayLink hub but the performance is poor and I’m not happy with granting their driver screen recording permission. Or trusting it at all tbh.

TL;DR - I tried it when the first m1's came out and it was a huge pain, ended up going back to x86 for my primary machine.

I got an m1 right when they came out because I started a new gig right around that time, literally happened the same week. Trying to get all my dev tools installed became a rat's nest of issues. I work as a backend / dist sys / systems engineer for my day job and so I have to write and use things that are fairly close to bare-metal. Brew hadn't been forked yet, so that added a whole new layer of issues.

Docker still doesn't work, Rust libs compile in weird ways... just all kinds of stuff that I'm not smart enough or paid well enough to figure out. My title is "Developer", not "M1 developer advocate" so after about a month of running into issue after issue, I went back and found a used MBP with an intel chip. I'm excited about the future of Apple silicon, and ARM as a whole, but it needs another couple years of refinement.

I will say that I've been using an m1 mac mini for general office work as apart of my side business and it's quite good.

I just learned how to run our apps outside of docker and virtual box. Setting up two Postgres DBs, a NodeJS process and a Python process wasn't completely trivial, but it wasn't all that difficult either.

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

At my company, we have been using Github Codespaces for development and it has been quite nice, since it offloads all your actual development to a simple VM (and uses VSCode's remote feature for that)

I 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.

iOS dev here. Things have been pretty smooth for my team except for some differences with where homebrew installs packages on ARM64 and that we still have to run the iOS simulator via rosetta due to some of our 3rd party frameworks not providing ARM64 builds for iOS-simulator.

In my personal hobby stuff I do miss being able to virtualize x86 machines but have been able to get by with arm versions of Windows 11 and Linux running in parallels, and qemu for operating systems that don't have arm builds.

I've been using an M1 since it came out, I'm a platform / automation engineer, lots of aws, cdk, typescript, golang, terraform etc... I haven't had any problems at all.

I do a lot of devops work and never had any issue. If I have doubts I just use a VM on datacenter or an EC2 through ssh. I guess maybe some people don't have access to these resources.

M1 has meant shifting some dependencies, slower builds that need to build from source, updating databases out of band, and container crashes from poor x86 emulation.

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

Vagrant + parallels on m1 and intel. Works beautifully.

It's still a year or two away for things to be ready to own an M1 for development with the types of topics listed above.

There are comments with a lot of detail here. I’m just sitting here annoyed that I can’t use Bootcamp to dual boot windows.

Adopting m1 has been virtually pain-free for us. Projects are all rust, just specify the cpu-target in the docket builds.

Worst thing I've had to deal with is Terraform Providers not supporting ARM64

I've had 0 issues. Everything has worked for me out of the box, so to speak.

Here's a few pain points I had:

* Virtual VM's don't solve my problem everytime. There's software that still requires x86 and a VM isn't going to solve that problem in a few cases. I wish I could get into more details here but I'm kind of a noob in this realm. (TLDR: I need to use something called UAExpert and to resolve this, I have both a separate Linux machine and Windows machine in case I need it)

* Have to install homebrew and an x864 version of homebrew to run the right software. Homebrew does not document this so this solution was based off stack overflow posts.

* While docker states that it supports multiple architectures, I don't find that to be fully true. For our codebase, I need to push up x86 docker images but accidentally pushed up arm64 ones instead. There's a solution for it but it's definitely not an out-of-the-box solution at the moment.

Overall, still pretty happy with it. My older macbook pro had gotten sluggish so the tradeoff for me was worth it.

I did buy MacBook M1.

Installed Asahi Linux, it made possible to keep OS running all the time, keep HexChat IRC running, and not shutdown when away from keyboard like on macOS.

But that M1 did only last 4 days. Then it did not boot anymore. So I returned it to warranty repair, and canceled buying it.

GDB still doesn't work on MacOS M1.

I miss counter strike 1.6

Its simple: I dont