6 ms·

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 ra

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 VMware Fusion both have Apple Silicon support, and even in "tech preview" status they are both rock solid. Docker gets kudos for supporting emulated x86 containers, though I rarely use them. I was able to easily rebuild almost all of my virtual machines; thanks to the Raspberry Pi, almost all of the packages I use were already available for arm64, though Ubuntu 16.04 was a little challenging to get running. I also had to spend an afternoon updating my CI scripts to cross-compile my Docker containers, but this mostly involves switching to `docker buildx build`. Rosetta is flawless, including for userland drivers for USB and Bluetooth devices, but virtually all of my apps were rebuilt native very quickly. (Curious to see what, if anything, is running under translation, I just discovered that WhatsApp, the #1 Social Networking app in the App Store, still ships Intel-only.)

spockz 4y ago
Just to note. You can do `docker buildx install` to make it the default backend of `docker build`. So this precludes you from having to switch commands everywhere. I haven’t figured out how you can let it build multiple architecture by default, so without having to pass the —target flag. On my m1 I see 16x performance differences in builds in favour of native over emulated. Even simple shell script run slow or seem to stall when emulated.
- deleted 4y ago
  [deleted]
Operyl 4y ago
If you open Activity Monitor you can see what processes are running in "Apple" or "Intel"!
0x29aNull 4y ago
..want to get rid of your old intel MBP? The video on my 2017 is dying.
- rgovostes 4y ago
  Unfortunately it belongs to work, and not to me. Good luck finding a replacement, though.
- hansor 4y ago
  why your login is green mate?
  - piinbinary 4y ago
    That just means it is a user who signed up recently
- deleted 4y ago
  [deleted]
- doublepg23 4y ago
  I recommend the r/AppleSwap or r/HardwareSwap subreddit.
pishpash 4y ago
What's also nice is iPhone/iPad ARM apps can run as desktop apps on M1, so when there was no native desktop app replacement sometimes there was that other native app.
eslaught 4y ago
Are there more details on "docker buildx build" that you can point us to? The command line reference doesn't seem especially helpful: https://docs.docker.com/engine/reference/commandline/buildx_build/ https://docs.docker.com/engine/reference/commandline/buildx_... E.g. if I wanted to start building ARM binaries on a x86 host, is that the sort of thing this would enable?
- verst 4y ago
  You can build multiplatform images for x86 and ARM (e.g. M1 Mac) like so: docker buildx build --platform linux/amd64,linux/arm64 . I constantly use buildx to build x86 images on my M1 so that I can run these images in my x86 Kubernetes cluster. https://docs.docker.com/buildx/working-with-buildx/ https://docs.docker.com/buildx/working-with-buildx/
- eslaught 4y ago
  Just to follow up on my own question (though I appreciate the siblings): I found this article with some overview and example command lines: https://www.docker.com/blog/multi-arch-images/ https://www.docker.com/blog/multi-arch-images/ . As best I can tell, you don't actually need a custom builder. You can just skip the `docker buildx create` and go straight to `docker buildx build` after one workaround below. I needed the workaround from this comment to make it work (to install qemu? not sure): https://github.com/docker/buildx/issues/495#issuecomment-754688157 https://github.com/docker/buildx/issues/495#issuecomment-754... Overall a very slick experience for going from zero to multiarch containers. Well done, Docker.
andrekandre 4y ago
vmware on m1 supports x86_64 emulation?
- rgovostes 4y ago
  No, and they've announced they do not plan to support it. However you can use x86_64 containers with Docker and virtual machines through QEMU, Lima.
barkingcat 4y ago
Rosetta is definitely not flawless. This type of jit/translation does have limits. Often times people experience different levels of difficulty using Apple Silicon precisely because my workload is not yours, and yours is different again from OP's So I feel this particular Ask HN is more about wondering how different everyone's workflows are, and how that impacts M1 usage. I envision that workflow options/pathways will start converging into one "way" which is the Apple way. You already are getting shunted into relying purely on Metal for gpu acceleration and you see the various plurality of gpgpu libraries start converging on only the Apple blessed/authorized and optimized version. There are people fighting against this, for example the Linux on Apple Silicon project bringing up the GPU, but it's slow going. Give it another few years, and people will stop using x, y, or z frameworks, and only use whatever API's Apple gives us, because that is the Apple Way. Proceed at your own peril. The future is fast, but there is only one road.
- rgovostes 4y ago
  I use "flawless" in the sense that I have not seen a single incompatibility or even regression in any of the ordinary macOS software I have used under its translation, which is exactly what it was designed to do. It has surprisingly few documented limitations, like lacking AVX vector instructions: https://developer.apple.com/documentation/apple-silicon/about-the-rosetta-translation-environment https://developer.apple.com/documentation/apple-silicon/abou... There are a handful of apps that aren't supported, but few of these are popular apps. Virtualbox is notable, but unsurprising: Rosetta is not designed for x86_64 virtual machines, and Virtualbox doesn't support arm64. (I submitted a correction to the Wine entry, since wine64 has worked under Rosetta 2 for a year.) https://isapplesiliconready.com/for/unsupported https://isapplesiliconready.com/for/unsupported https://liliputing.com/2021/06/wine-6-0-1-lets-you-run-windows-apps-on-apple-silicon.html https://liliputing.com/2021/06/wine-6-0-1-lets-you-run-windo...
tluyben2 4y ago
Hmm, docker is very buggy for my team and myself on m1. Coming from a x220 where it was flawless, on m1 it quite often just ‘dies’. When you paste the message you get when you run any docker command after that into Google, you see that many people have this issue and the fix is; restart docker. This didn’t happen under Linux. I am not sure if it did happen on x86 Mac as I never used docker there.
- rgovostes 4y ago
  To be clear I think the support for Apple Silicon has been solid, but Docker Desktop for Mac regardless of CPU architecture has bugs, and I've had it get stuck as you describe on both. Right now for me it seems incapable of auto-updating, which I assume is unrelated to Apple Silicon.
kcartlidge 4y ago
> Curious to see what, if anything, is running under translation There's a useful app called Silicon Info on Github (https://github.com/billycastelli/Silicon-Info https://github.com/billycastelli/Silicon-Info) and also on the Mac App Store. It adds a menu bar icon that switches according to the currently-focused app's architecture.
sally1620 4y ago
Rosetta's biggest flaw is lack of AVX support. We had to put so much effort to just run things on Rosetta because all of our compiled code had AVX enabled. We also needed to chase down pre-compiled binaries and re-compile them without AVX, we still haven't finished this work.

spockz 4y ago

Just to note. You can do `docker buildx install` to make it the default backend of `docker build`. So this precludes you from having to switch commands everywhere. I haven’t figured out how you can let it build multiple architecture by default, so without having to pass the —target flag. On my m1 I see 16x performance differences in builds in favour of native over emulated. Even simple shell script run slow or seem to stall when emulated.

deleted 4y ago
[deleted]

Operyl 4y ago

If you open Activity Monitor you can see what processes are running in "Apple" or "Intel"!

0x29aNull 4y ago

..want to get rid of your old intel MBP? The video on my 2017 is dying.

rgovostes 4y ago
Unfortunately it belongs to work, and not to me. Good luck finding a replacement, though.
hansor 4y ago
why your login is green mate?
- piinbinary 4y ago
  That just means it is a user who signed up recently
deleted 4y ago
[deleted]
doublepg23 4y ago
I recommend the r/AppleSwap or r/HardwareSwap subreddit.

pishpash 4y ago

What's also nice is iPhone/iPad ARM apps can run as desktop apps on M1, so when there was no native desktop app replacement sometimes there was that other native app.

eslaught 4y ago

Are there more details on "docker buildx build" that you can point us to? The command line reference doesn't seem especially helpful: https://docs.docker.com/engine/reference/commandline/buildx_build/ https://docs.docker.com/engine/reference/commandline/buildx_... E.g. if I wanted to start building ARM binaries on a x86 host, is that the sort of thing this would enable?

verst 4y ago
You can build multiplatform images for x86 and ARM (e.g. M1 Mac) like so: docker buildx build --platform linux/amd64,linux/arm64 . I constantly use buildx to build x86 images on my M1 so that I can run these images in my x86 Kubernetes cluster. https://docs.docker.com/buildx/working-with-buildx/ https://docs.docker.com/buildx/working-with-buildx/
eslaught 4y ago
Just to follow up on my own question (though I appreciate the siblings): I found this article with some overview and example command lines: https://www.docker.com/blog/multi-arch-images/ https://www.docker.com/blog/multi-arch-images/ . As best I can tell, you don't actually need a custom builder. You can just skip the `docker buildx create` and go straight to `docker buildx build` after one workaround below. I needed the workaround from this comment to make it work (to install qemu? not sure): https://github.com/docker/buildx/issues/495#issuecomment-754688157 https://github.com/docker/buildx/issues/495#issuecomment-754... Overall a very slick experience for going from zero to multiarch containers. Well done, Docker.

andrekandre 4y ago

vmware on m1 supports x86_64 emulation?

rgovostes 4y ago
No, and they've announced they do not plan to support it. However you can use x86_64 containers with Docker and virtual machines through QEMU, Lima.

barkingcat 4y ago

Rosetta is definitely not flawless. This type of jit/translation does have limits. Often times people experience different levels of difficulty using Apple Silicon precisely because my workload is not yours, and yours is different again from OP's So I feel this particular Ask HN is more about wondering how different everyone's workflows are, and how that impacts M1 usage. I envision that workflow options/pathways will start converging into one "way" which is the Apple way. You already are getting shunted into relying purely on Metal for gpu acceleration and you see the various plurality of gpgpu libraries start converging on only the Apple blessed/authorized and optimized version. There are people fighting against this, for example the Linux on Apple Silicon project bringing up the GPU, but it's slow going. Give it another few years, and people will stop using x, y, or z frameworks, and only use whatever API's Apple gives us, because that is the Apple Way. Proceed at your own peril. The future is fast, but there is only one road.

rgovostes 4y ago
I use "flawless" in the sense that I have not seen a single incompatibility or even regression in any of the ordinary macOS software I have used under its translation, which is exactly what it was designed to do. It has surprisingly few documented limitations, like lacking AVX vector instructions: https://developer.apple.com/documentation/apple-silicon/about-the-rosetta-translation-environment https://developer.apple.com/documentation/apple-silicon/abou... There are a handful of apps that aren't supported, but few of these are popular apps. Virtualbox is notable, but unsurprising: Rosetta is not designed for x86_64 virtual machines, and Virtualbox doesn't support arm64. (I submitted a correction to the Wine entry, since wine64 has worked under Rosetta 2 for a year.) https://isapplesiliconready.com/for/unsupported https://isapplesiliconready.com/for/unsupported https://liliputing.com/2021/06/wine-6-0-1-lets-you-run-windows-apps-on-apple-silicon.html https://liliputing.com/2021/06/wine-6-0-1-lets-you-run-windo...

tluyben2 4y ago

Hmm, docker is very buggy for my team and myself on m1. Coming from a x220 where it was flawless, on m1 it quite often just ‘dies’. When you paste the message you get when you run any docker command after that into Google, you see that many people have this issue and the fix is; restart docker. This didn’t happen under Linux. I am not sure if it did happen on x86 Mac as I never used docker there.

rgovostes 4y ago
To be clear I think the support for Apple Silicon has been solid, but Docker Desktop for Mac regardless of CPU architecture has bugs, and I've had it get stuck as you describe on both. Right now for me it seems incapable of auto-updating, which I assume is unrelated to Apple Silicon.

kcartlidge 4y ago

> Curious to see what, if anything, is running under translation There's a useful app called Silicon Info on Github (https://github.com/billycastelli/Silicon-Info https://github.com/billycastelli/Silicon-Info) and also on the Mac App Store. It adds a menu bar icon that switches according to the currently-focused app's architecture.

sally1620 4y ago

Rosetta's biggest flaw is lack of AVX support. We had to put so much effort to just run things on Rosetta because all of our compiled code had AVX enabled. We also needed to chase down pre-compiled binaries and re-compile them without AVX, we still haven't finished this work.