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 VM…
Ask HN: How are you dealing with the M1/ARM migration?
101–110 of 284 posts
Re: Ask HN: How are you dealing with the M1/ARM migration?
#102I'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.
Re: Ask HN: How are you dealing with the M1/ARM migration?
#103As 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.
Re: Ask HN: How are you dealing with the M1/ARM migration?
#104Re: Ask HN: How are you dealing with the M1/ARM migration?
#105Assuming 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...
Re: Ask HN: How are you dealing with the M1/ARM migration?
#106I'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.
Re: Ask HN: How are you dealing with the M1/ARM migration?
#107I 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 VM…
Re: Ask HN: How are you dealing with the M1/ARM migration?
#108I don't use Docker so I have had no problems whatsoever. Getting all the Mac apps I code on building for Arm was easy.
There were a couple libraries my company needed that didn't have ARM support but I ported them and made pull requests to the repos, and now they work alright. It wasn't difficult at all, since lots of stuff already had ARM code because of ARM-Linux, Android or iOS.
I go weeks without turning on my work-provided Intel Mac. I actually only use it for "personal" stuff (I help maintain some open source C/Asm stuff that use multiple OSs and architectures). My boss asked if I want an upgrade tho.
Re: Ask HN: How are you dealing with the M1/ARM migration?
#109We 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.
Re: Ask HN: How are you dealing with the M1/ARM migration?
#110I 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 VM…
..want to get rid of your old intel MBP? The video on my 2017 is dying.