Hacker News Board Hacker News, browsed like a classic message board
Live data from Hacker News

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

news.ycombinator.com

Post reply on HN
Print view View original

141–150 of 284 posts

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

#141

Post by kccqzy »

danudey wrote: post #131
johnklos wrote: post #106

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…

Can you elaborate on what part of docker is a security nightmare?

Dockerd is a daemon that runs with very high privileges and does too many things. People hate using "sudo docker" so they add themselves to the docker group. Now congratulations you are effectively running as root all the time.

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

#142

Post by [deleted] »

vchuravy wrote: post #133
scarface74 wrote: post #125

Earlier quoted context omitted.

Apple also doesn’t offer an x86 “server” yet Azure DevOps offers Mac build servers.

Yes because Microsoft got a special license from Apple that allows for the virtualization of Mac OS on non Apple hardware... The rest of us is still running on racks of Mac Minis

[deleted]

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

#143

Post by scarface74 »

vchuravy wrote: post #133
scarface74 wrote: post #125

Earlier quoted context omitted.

Apple also doesn’t offer an x86 “server” yet Azure DevOps offers Mac build servers.

Yes because Microsoft got a special license from Apple that allows for the virtualization of Mac OS on non Apple hardware... The rest of us is still running on racks of Mac Minis

This isn’t true.

https://devblogs.microsoft.com/devops/cloud-hosted-mac-agent...

> Please be aware that during this preview, our Mac hardware is hosted in third party datacenters in the United States and your build and release data could cross geopolitical lines. After each build completes, its macOS VM is reimaged, leaving no trace of your data on the agent. For more information, see where VSTS data is stored. Our Mac datacenters will expand to other geographies soon

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

#145

Post by oneplane »

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.

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

#146

Post by 3np »

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.

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

#147

Post by jiocrag »

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

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

#148

Post by epolanski »

mdp2021 wrote: post #48
dev_tty01 wrote: post #27

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

> highly performant Last thing I read, 70% of the native performance was shown by running GeekBench through Rosetta (with a few odd results noted). If somebody has better info... Edit: I see that Nov 2020 checks returned an 80% performance, and there was discussion on HN at (at least) https://news.ycombinator.com/item?id=25105597

Those are terrific numbers for emulation.

Anyway I can say that my colleagues M1 using rosetta is faster or equal to my MBP i9 2020.

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

#149

Post by nonethewiser »

tonyhb wrote: post #40

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.

How would you handle docker images in a team where some use M1 and others use intel?
Post reply on HN