8 ms·

Right, lots of confusion in this thread. A12Z/DTK: HW does not support virtualization at all. Apple M1 / New Apple Products: HW does support virtualization

Right, lots of confusion in this thread. A12Z/DTK: HW does not support virtualization at all. Apple M1 / New Apple Products: HW does support virtualization for ARM64 guests (both windows and linux demonstrated). What about x86 software in the guestOS? Not with Rosetta. Instead, the guest OS will have to provide its own translation (such as windows/arm's current x86->arm64 or upcoming x86_64->arm64 feature). I'm not familiar if there is any usable high performance x86_64->arm translation available for linux. Docker w/ arm images: needs some work to be able to work on mac/arm virtualization, but it's coming. Docker w/ arm linux kernel + x86 userland images: Any translation solution would be found within the linux guestOS, not macOS. I don't know if any candidates exist. Maybe qemu? Docker w/ full x86 image (incl. kernel): I don't think this is possible?

LeSaucy 6y ago
This was a huge reason why I decided to go with a 16" MBP with an i9 vs the M1 today. I assume this will get worked out eventually, but as massive as Apple's gravity is in their ecosystem to pull apps along, they will have a much harder time against the massive library of x86 docker images.
- zhengyi13 6y ago
  Apropos of yesterday's thread(s?) around running a k3s cluster on Raspberry Pis - when I tried to do something similar, I very quickly ran out of steam trying to find manifests and charts that didn't have some random x86_64 image hardcoded somewhere inside them. I spent more time trying to figure out ways to get the right images than I did learning k8s, so I kinda put the project down. I do think this is exactly the sort of thing though that will start to flush that out, long term.
- floatingatoll 6y ago
  You did the right thing. This is not the right time for software developers to experiment with Apple Silicon, unless they’re willing to help develop software to work with Apple Silicon.
  - ogre_codes 6y ago
    Largely depends on what kind of software developer you are. Not all developers rely on x86. Our app is React/ Typescript and we don't use Docker/ x86 virtualization at all. I do need MySQL and a few other tools, but I don't expect they will be long coming (or maybe already running in Homebrew is there Homebrew ARM?) If you make your living writing Mac or iOS software, this is a gift. Might be worth waiting for the next generation with more RAM and even beefier CPUs, but otherwise this is ideal.
    - Hackbraten 6y ago
      > is there Homebrew ARM? There is but it’s highly experimental still, with 50 % of formulae not working yet. Better to run Homebrew with Rosetta for now.
      - planb 6y ago
        In my experience it's always python and/or ruby that's causing the failues. As soon as they are fixed, most formulae will compile just fine.
        floatingatoll 6y ago
        One of the formula not working in Homebrew’s core functionality is the gcc compiler, which they expect might be ready by mid-2021. Another is Go, which iirc they’re expecting will begin working around January. Rust and Erlang aren’t ready, MySQL doesn’t even get past the build phase, and Python is only partially working. You can track progress here. Be advised that packages listed as ‘check again when XYZ is fixed’ may themselves have issues that can’t yet be discovered. https://github.com/Homebrew/brew/issues/7857 https://github.com/Homebrew/brew/issues/7857
      - ogre_codes 6y ago
        > Better to run Homebrew with Rosetta for now. For some reason I'd completely forgotten this was an option. Looking at the discussions on the home-brew boards, it looks like this will be the way to run home-brew for some time.
- waheoo 6y ago
  I switched off Mac years ago. My servers run Linux. Not bsd. Having to deal with this sort of stuff is just a waste of time. Mac's don't have a monopoly on quality, haven't for a long time. And since it's a usual response, anyone claiming Linux is too fiddly haven't used it in a long time. And while it can be if you want to roll your own DE its completely optional. Using something like fedora you can literally do almost everything non developer based with point and click.
  - fakedang 6y ago
    I moved to Linux last month. I currently run Windows, Linux and MacOS VM on my machine. From being a Windows guy through all the years, I've found myself increasingly using Linux in this span of time. The only thing preventing me from a complete switch is MS Office. I barely used MacOS, except to diagnose issues on MacOS and run XCode.
    - edelacruz 6y ago
      May I ask what linux you are using and how you got a Mac VM running? I tried myself and was able to get Catalina running on Ubuntu 20.04 using Openboot. But then Catalina updated itself and crashed after that. I wasn't able to reinstall MacOS successfully anymore, even starting from scratch. If you could help me out by pointing out which products/technologies you used and maybe a website describing step by step, that would be great.
      - fakedang 6y ago
        Ubuntu system. Firstly, I disabled updates, not because of Mac in particular, but I've had issues with Windows updates crashing before, so I don't eagerly update. Apart from that, standard QEMU process. This was the guide I used: https://www.funkyspacemonkey.com/how-to-install-macos-catalina-on-linux https://www.funkyspacemonkey.com/how-to-install-macos-catali...
        edelacruz 6y ago
        Thanks. I'll give it another try.
- angrygoat 6y ago
  I guess the flip side is that, hopefully, the Docker ecosystem will start getting a lot better at multi-arch, at least for x86-64 and ARM. I just ordered an M1 MBP and I'll be quite happy to start thwacking bugs in images and upstreaming the fixes.
  - nomel 6y ago
    I naively assumed, until today, that the whole point of using linux in docker was that you get the multi-arch goodness of linux for free!
    - Polylactic_acid 6y ago
      Not at all. Docker on a raspberry pi is a massive pain in the ass. Half the images are not compiled for ARM.
      - vocram 6y ago
        Not a bit deal. Building ARM images from Dockerfiles is trivial. And it has the benefit of not having to trust an upstream image content. If you want to go the extra mile, contribute to the project to provide multi arch images support.
    - caymanjim 6y ago
      What multi-arch goodness of Linux? Linux can't magically run code from any architecture even without Docker in the mix, and unless someone is maintaining packages for your specific architecture, you're building them yourself.
      - unethical_ban 6y ago
        As a non-processor geek, isn't M1 an arm chip? How long will it take arbitrary software to target it?
        neurostimulant 6y ago
- takeda 6y ago
  I find it quite ironic that solution that supposed to make things portable it is now standing in a way of portability. Yes, I understand why, but still...
  - FPGAhacker 6y ago
    Apple has only ever used portable to refer to their own platforms. Which is a bit of a stretch of the term considering what it means to the rest of the technical world, but there you have it. Per their own definition they have improved portability among their own platforms.
- girvo 6y ago
  Same reason why I chose the 2020 13” with the highest end Intel I could put in it. In another 3-4 years all this will be worked out and I’ll be happy to move to Apple Silicon
lloeki 6y ago
> Docker w/ arm linux kernel + x86 userland images: I don't what existing projects might me candidates, but any translation solution would be found within the linux guestOS, not macOS. That could be something doing dynarec like box86, which is mindboggingly the only way to run (x86) Zoom on a arm7hf Linux atop a Raspberry Pi 4 (I tried it on a Pi3B: it works but it’s way too slow) https://github.com/ptitSeb/box86 https://github.com/ptitSeb/box86
black3r 6y ago
> Docker w/ arm linux kernel + x86 userland images as mentioned in the issue comments: Docker x86 version already supports running ARM images via qemu out of the box on Windows and Mac, so x86 images via qemu on ARM host should not be a problem...
- jcelerier 6y ago
  > Docker x86 version already supports running ARM images via qemu out of the box on Windows and Mac it "works", but on my overpowered i7, running a raspberry pi docker image that way with qemu-user-static is... only marginally faster than running the code on an actual rpi 3, which is pretty much potato-levels of power.
  - pvorb 6y ago
    Yep, so if you're a developer and buy a Macbook with the M1, all the potential performance gains would be lost when depending on common Docker images. That's quite sad. (It would at least be a huge problem for me. I mostly develop server software that runs on Kubernetes on AMD64 machines.)
    - throwaway894345 6y ago
      Why not just run the ARM images instead of the x64? Granted not everyone makes ARM images, but in a year or so I fully expect that all serious Docker images will have ARM support (not because of Mac, but rather because of ARM’s progress in the server space). And in the meanwhile, building the image yourself isn’t that hard.
      - pvorb 6y ago
        Why would your employer pay you to build and test ARM images when the server they're running on is AMD64? Okay, let's be realistic: they'll probably never find out. But still this is wasted effort when you could just as well use a regular x86 machine for development. Cross compilation will lead to many small problems that add up over time...
p1necone 6y ago
X86 software running in a VM hosted ARM Windows/Linux env, but using Apples translation layer is not something I would expect to work anyway - seems like a weird thing for them to try to do to me.
ahoka 6y ago
All of this already works on Windows in the other direction: PS C:\Users\hokaa> docker run -it --platform aarch64 ubuntu root@aaf35d3fd9de:/# uname -a Linux aaf35d3fd9de 4.19.128-microsoft-standard #1 SMP Tue Jun 23 12:58:10 UTC 2020 aarch64 aarch64 aarch64 GNU/Linux And yes, AFAIK it uses qemu's binary translation.
_alex_ 6y ago
you should be able to run x86 vms through qemu. Just like running arm vms on x86 today

LeSaucy 6y ago

This was a huge reason why I decided to go with a 16" MBP with an i9 vs the M1 today. I assume this will get worked out eventually, but as massive as Apple's gravity is in their ecosystem to pull apps along, they will have a much harder time against the massive library of x86 docker images.

zhengyi13 6y ago
Apropos of yesterday's thread(s?) around running a k3s cluster on Raspberry Pis - when I tried to do something similar, I very quickly ran out of steam trying to find manifests and charts that didn't have some random x86_64 image hardcoded somewhere inside them. I spent more time trying to figure out ways to get the right images than I did learning k8s, so I kinda put the project down. I do think this is exactly the sort of thing though that will start to flush that out, long term.
floatingatoll 6y ago
You did the right thing. This is not the right time for software developers to experiment with Apple Silicon, unless they’re willing to help develop software to work with Apple Silicon.
- ogre_codes 6y ago
  Largely depends on what kind of software developer you are. Not all developers rely on x86. Our app is React/ Typescript and we don't use Docker/ x86 virtualization at all. I do need MySQL and a few other tools, but I don't expect they will be long coming (or maybe already running in Homebrew is there Homebrew ARM?) If you make your living writing Mac or iOS software, this is a gift. Might be worth waiting for the next generation with more RAM and even beefier CPUs, but otherwise this is ideal.
  - Hackbraten 6y ago
    > is there Homebrew ARM? There is but it’s highly experimental still, with 50 % of formulae not working yet. Better to run Homebrew with Rosetta for now.
    - planb 6y ago
      In my experience it's always python and/or ruby that's causing the failues. As soon as they are fixed, most formulae will compile just fine.
      - floatingatoll 6y ago
        One of the formula not working in Homebrew’s core functionality is the gcc compiler, which they expect might be ready by mid-2021. Another is Go, which iirc they’re expecting will begin working around January. Rust and Erlang aren’t ready, MySQL doesn’t even get past the build phase, and Python is only partially working. You can track progress here. Be advised that packages listed as ‘check again when XYZ is fixed’ may themselves have issues that can’t yet be discovered. https://github.com/Homebrew/brew/issues/7857 https://github.com/Homebrew/brew/issues/7857
    - ogre_codes 6y ago
      > Better to run Homebrew with Rosetta for now. For some reason I'd completely forgotten this was an option. Looking at the discussions on the home-brew boards, it looks like this will be the way to run home-brew for some time.
waheoo 6y ago
I switched off Mac years ago. My servers run Linux. Not bsd. Having to deal with this sort of stuff is just a waste of time. Mac's don't have a monopoly on quality, haven't for a long time. And since it's a usual response, anyone claiming Linux is too fiddly haven't used it in a long time. And while it can be if you want to roll your own DE its completely optional. Using something like fedora you can literally do almost everything non developer based with point and click.
- fakedang 6y ago
  I moved to Linux last month. I currently run Windows, Linux and MacOS VM on my machine. From being a Windows guy through all the years, I've found myself increasingly using Linux in this span of time. The only thing preventing me from a complete switch is MS Office. I barely used MacOS, except to diagnose issues on MacOS and run XCode.
  - edelacruz 6y ago
    May I ask what linux you are using and how you got a Mac VM running? I tried myself and was able to get Catalina running on Ubuntu 20.04 using Openboot. But then Catalina updated itself and crashed after that. I wasn't able to reinstall MacOS successfully anymore, even starting from scratch. If you could help me out by pointing out which products/technologies you used and maybe a website describing step by step, that would be great.
    - fakedang 6y ago
      Ubuntu system. Firstly, I disabled updates, not because of Mac in particular, but I've had issues with Windows updates crashing before, so I don't eagerly update. Apart from that, standard QEMU process. This was the guide I used: https://www.funkyspacemonkey.com/how-to-install-macos-catalina-on-linux https://www.funkyspacemonkey.com/how-to-install-macos-catali...
      - edelacruz 6y ago
        Thanks. I'll give it another try.
angrygoat 6y ago
I guess the flip side is that, hopefully, the Docker ecosystem will start getting a lot better at multi-arch, at least for x86-64 and ARM. I just ordered an M1 MBP and I'll be quite happy to start thwacking bugs in images and upstreaming the fixes.
- nomel 6y ago
  I naively assumed, until today, that the whole point of using linux in docker was that you get the multi-arch goodness of linux for free!
  - Polylactic_acid 6y ago
    Not at all. Docker on a raspberry pi is a massive pain in the ass. Half the images are not compiled for ARM.
    - vocram 6y ago
      Not a bit deal. Building ARM images from Dockerfiles is trivial. And it has the benefit of not having to trust an upstream image content. If you want to go the extra mile, contribute to the project to provide multi arch images support.
  - caymanjim 6y ago
    What multi-arch goodness of Linux? Linux can't magically run code from any architecture even without Docker in the mix, and unless someone is maintaining packages for your specific architecture, you're building them yourself.
    - unethical_ban 6y ago
      As a non-processor geek, isn't M1 an arm chip? How long will it take arbitrary software to target it?
      - neurostimulant 6y ago
takeda 6y ago
I find it quite ironic that solution that supposed to make things portable it is now standing in a way of portability. Yes, I understand why, but still...
- FPGAhacker 6y ago
  Apple has only ever used portable to refer to their own platforms. Which is a bit of a stretch of the term considering what it means to the rest of the technical world, but there you have it. Per their own definition they have improved portability among their own platforms.
girvo 6y ago
Same reason why I chose the 2020 13” with the highest end Intel I could put in it. In another 3-4 years all this will be worked out and I’ll be happy to move to Apple Silicon

lloeki 6y ago

> Docker w/ arm linux kernel + x86 userland images: I don't what existing projects might me candidates, but any translation solution would be found within the linux guestOS, not macOS. That could be something doing dynarec like box86, which is mindboggingly the only way to run (x86) Zoom on a arm7hf Linux atop a Raspberry Pi 4 (I tried it on a Pi3B: it works but it’s way too slow) https://github.com/ptitSeb/box86 https://github.com/ptitSeb/box86

black3r 6y ago

> Docker w/ arm linux kernel + x86 userland images as mentioned in the issue comments: Docker x86 version already supports running ARM images via qemu out of the box on Windows and Mac, so x86 images via qemu on ARM host should not be a problem...

jcelerier 6y ago
> Docker x86 version already supports running ARM images via qemu out of the box on Windows and Mac it "works", but on my overpowered i7, running a raspberry pi docker image that way with qemu-user-static is... only marginally faster than running the code on an actual rpi 3, which is pretty much potato-levels of power.
- pvorb 6y ago
  Yep, so if you're a developer and buy a Macbook with the M1, all the potential performance gains would be lost when depending on common Docker images. That's quite sad. (It would at least be a huge problem for me. I mostly develop server software that runs on Kubernetes on AMD64 machines.)
  - throwaway894345 6y ago
    Why not just run the ARM images instead of the x64? Granted not everyone makes ARM images, but in a year or so I fully expect that all serious Docker images will have ARM support (not because of Mac, but rather because of ARM’s progress in the server space). And in the meanwhile, building the image yourself isn’t that hard.
    - pvorb 6y ago
      Why would your employer pay you to build and test ARM images when the server they're running on is AMD64? Okay, let's be realistic: they'll probably never find out. But still this is wasted effort when you could just as well use a regular x86 machine for development. Cross compilation will lead to many small problems that add up over time...

p1necone 6y ago

X86 software running in a VM hosted ARM Windows/Linux env, but using Apples translation layer is not something I would expect to work anyway - seems like a weird thing for them to try to do to me.

ahoka 6y ago

All of this already works on Windows in the other direction: PS C:\Users\hokaa> docker run -it --platform aarch64 ubuntu root@aaf35d3fd9de:/# uname -a Linux aaf35d3fd9de 4.19.128-microsoft-standard #1 SMP Tue Jun 23 12:58:10 UTC 2020 aarch64 aarch64 aarch64 GNU/Linux And yes, AFAIK it uses qemu's binary translation.

_alex_ 6y ago

you should be able to run x86 vms through qemu. Just like running arm vms on x86 today