Works great and I can move between a local and cloud servers depending on requirements
Ask HN: How are you dealing with the M1/ARM migration?
61–70 of 284 posts
Re: Ask HN: How are you dealing with the M1/ARM migration?
#62Re: Ask HN: How are you dealing with the M1/ARM migration?
#63Re: Ask HN: How are you dealing with the M1/ARM migration?
#64At 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
ARM Geekbench single core on M1 MacOS is 1734. ARM Geekbench single core on WinARM in VM on M1 is 1550. x86 single core on i9 MB Pro MacOS is 1138. x86 in emulation on M1 MacOS is 1254.
Yes, 72% x86 Rosetta vs. M1 Native. However, x86 Rosetta on M1 was faster than the previous i9 2019 Macbook Pro x86 native. I consider that to be performant for running code that was compiled for a very different architecture.
Re: Ask HN: How are you dealing with the M1/ARM migration?
#651. 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.
We were using UTM but have recently switched to Parallels, which is nice.
Our prod stayed on x86 but we’ve started moving to graviton3 which is better bang for buck. Suspect it’ll end up being a common story for others too.
m1s are just such nice machines that I’d go quite out of my way to stay on them now.
Re: Ask HN: How are you dealing with the M1/ARM migration?
#66I don't expect many teams to volunteer to suffer this sort of slowdown and complexity in the near term.
Re: Ask HN: How are you dealing with the M1/ARM migration?
#67Re: Ask HN: How are you dealing with the M1/ARM migration?
#68Here'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?
#69Re: Ask HN: How are you dealing with the M1/ARM migration?
#70Installed 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.