Ask HN: How do your teams deal with a mix of AMD and ARM chips? | Hacker News Reader

Ask HN: How do your teams deal with a mix of AMD and ARM chips?

4 pointswillsmith723 comments

This is the 2nd time now I'm in an organization with a mix of chips, with around 50% using older macbooks, 40% windows/linux, and 10% appple silicon chips, and once again, it's really difficult to make sure everything works on both, including full development environments.

Even when people finally put all the effort into getting things right on both, something will change as versions are changed or new libraries are included, and suddenly it's broken again.

Has anyone got a good way around this? At this point, I just want to spin up an ec2 instance for my dev, but it's a total waste of the brand new machine and all its processing power.

View on HN

I found that on my current team, with most people using Docker, there were a few changes that needed to happen (if you're building DockerFiles)

1) Use the TARGETARCH variable in your DockerFile to replace the arm64 or amd64 string in whichever wget urls for unregistered packages you have. They tend to follow a pretty consistent naming scheme, and simply doing that replacement made a big difference.

2) As a frontend person, I noticed that it took a little while to figure out that certain backend packages like mqtt were using exact versions that didn't yet have an arm64 build, so I just incremented the version on my local machine.

These changes would presumably work on any machine, because the TARGETARCH variable just prints the architecture, it's up to the package maintainer to produce builds for the different architectures and keep the naming consistent.

I have no issues with this set up working between my m1 mac and intel mac, but ideally we'd bump the versions of the packages so it's less cumbersome.

It's always good to have canaries. Installs with up-to-the-minute versions of everything to make sure that, when the actual fleet starts to update, you'll have advanced warning.

With Ubuntu and Red Hat, you can have private mirrors of external repos you update when everything works in continuous (or, at least, regular) automated testing environments. Corporate installs of Windows can postpone individual updates as well until they can be certified. I'm sure Apple has something similar for macOS fleets.

This is literally the use case for docker. If you want to develop within the environment, you can easily use VSCode remote ssh extension to develop straight on containers.

Reply on news.ycombinator.com