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.
Ask HN: How are you dealing with the M1/ARM migration?
81–90 of 284 posts
Re: Ask HN: How are you dealing with the M1/ARM migration?
#82For 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.
Re: Ask HN: How are you dealing with the M1/ARM migration?
#83GDB still doesn't work on MacOS M1.
Re: Ask HN: How are you dealing with the M1/ARM migration?
#84[deleted]
Re: Ask HN: How are you dealing with the M1/ARM migration?
#85For 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 ca…
You will be waiting far more than 3 years.
Re: Ask HN: How are you dealing with the M1/ARM migration?
#86No post body was provided.
Re: Ask HN: How are you dealing with the M1/ARM migration?
#87I don't use Docker so I have had no problems whatsoever. Getting all the Mac apps I code on building for Arm was easy.
It is quite interesting scrolling through other comments and seeing a large majority of problems are with Docker pipelines (hard coded to x86_64 images that must be emulated, tools), in other words, problems extrinsic to the platform/OS and the actual program code/dependencies.
Re: Ask HN: How are you dealing with the M1/ARM migration?
#88I 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.
Re: Ask HN: How are you dealing with the M1/ARM migration?
#89I 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.
Of those I feel python is the big problem, at least if one deals with multiple projects needing different versions. When you've finally got the paths and venvs correctly set up, many packages won't be installed correctly because there is no wheel for M1 / your architecture. So then you have to compile everything yourself, which then fails on some new steps.
Re: Ask HN: How are you dealing with the M1/ARM migration?
#90I'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…
> It is interesting how much impact GitHub has had by not having Apple Silicon support Putting on my tin-foil hat for a sec: GitHub is owned by Microsoft, who would really stand to benefit from slowing down Apple Silicon adoption a bit...
Alternative theory: Apple doesn't offer an M1 server. Github doesn't offer an M1 build server because M1 servers don't exist.