6 ms·

Well this kinda screws me over running docker on macos. Not all images I use have an arm version.

tobyjsullivan 1y ago
How does this work currently? I was under the impression that Docker for Mac already ran containers in an x86 VM. Probably outdated info, but I’m curious when that changed.
- cpuguy83 1y ago
  Docker on Mac runs containers in a VM, but the VM is native the cpu architecture and takes advantage of hardware virtualization. You can of course always use qemu inside that vm to run non-native code (eg x86 on Apple Silicon), however this is perceived as much slower than using Rosetta (instead of qemu).
hakube 1y ago
Doesn't Orbstack or Colima solve this?
- p0w3n3d 1y ago
  if you run x86 code without rosetta (probably using the qemu) it will work painfully slow
saagarjha 1y ago
That won’t be going away, none of that requires any support from the host OS.
swiftcoder 1y ago
This isn't about the virtualisation support - it's about all the Mac system frameworks being available in the rosetta environment
- nicce 1y ago
  The performance that makes containers usable currently depends on Rosetta on Linux as well. Removing the support makes them much less usable.
  - swiftcoder 1y ago
    The announcement doesn't actually say they are removing the Rosetta emulation. Rosetta 2 as a complete snapshot of macOS system frameworks is not the same thing as what is now called the virtualisation framework
    - deleted 1y ago
      [deleted]
    - nicce 1y ago
      Generally speaking of Rosetta means Rosetta 2 since Rosetta 1 is deprecated. It is very difficult to say what they are meaning. The deprecation is mentioned in the context of Rosetta translation environment [1]. Rosetta for Linux uses same wording [2]. For example, Docker at least used to use this same binary translation internally year ago (the same tech as deprecation is mentioned). I don't know how it is today. [1]: https://developer.apple.com/documentation/apple-silicon/about-the-rosetta-translation-environment/ https://developer.apple.com/documentation/apple-silicon/abou... [2]: https://developer.apple.com/documentation/virtualization/running-intel-binaries-in-linux-vms-with-rosetta https://developer.apple.com/documentation/virtualization/run...
ehutch79 1y ago
Ask the maintainers to build arm images. Realistically they should be, unless the project uses lots of x86 assembly.
- jamesgeck0 1y ago
  It's not just images; any software the images pull down must also support ARM64 now as well. For example, the official Google Chrome binaries used by Puppeteer for headless browsing/scraping don't have a Linux ARM build.
mxey 1y ago
It doesn’t say if that is going away. The message calls out another part as sticking around: > Beyond this timeframe, we will keep a subset of Rosetta functionality aimed at supporting older unmaintained gaming titles, that rely on Intel-based frameworks. Since the Linux version of Rosetta requires even less from the host OS, I would expect it to stay around even longer.
wmwragg 1y ago
Yes that was my first thought as well, and as the images aren't designed to be run on a mac specifically, like a native app might be, there is no expectation for the developers to create a native apple silicon version. This is going to be a pretty major issue for a lot of developers
- TimTheTinker 1y ago
  Case in point - Microsoft's SQL Server docker image, which is x86-only with no hint of ever being released as an aarch64 image. I run that image (and a bunch of others) on my M3 dev machine in OrbStack, which I think provides the best docker and/or kubernetes container host experience on macOS.
- mxey 1y ago
  Apple Silicon is ARM64 which is supported by Linux and Docker.
  - coldtea 1y ago
    Parent doesn't want to merely run ARM64 Linux/Docker images. They want to run Intel images. Lots of reasons for that, from upstream Docker images not available to ARM64, to specific corporate setups you want to replicate as close as possible, or who aren't portable to ARM64 without huge effort.
  - wmwragg 1y ago
    I'm aware, I use ARM images all the time, I was trying to indicate that the usual refrain that the developers have had years to migrate their software to apple silicon, doesn't really apply to docker images. It's only the increase in use of ARM elsewhere (possibly driven by the great performance of macs running apple silicon) which has driven any migration of docker images to have ARM versions
  - deleted 1y ago
    [deleted]
  - wmf 1y ago
    Yeah but many people are using x86-64 Docker images because they deploy on x86-64. Maybe ARM clouds will be more common by that time.
physicsguy 1y ago
https://github.com/apple/container https://github.com/apple/container They released this a while ago which has hints of supporting amd64 beyond the Rosetta end date.
- dur-randir 1y ago
  Believing in hints from Apple about software? Sweet summer child.
  - khalic 1y ago
    Still waiting for ZFS on OS X
    - djxfade 1y ago
      It was implemented in some of the earlier Leopard beta's iirc. Possible speculation from my side, but it was probably removed due to licensing once Oracle expressed interest in acquiring Sun Microsystems.
    - BirAdam 1y ago
      This mostly died because Apple's new security framework doesn't allow for unsigned kexts or writable root. This also killed most fuse implementations and therefore kneecapped stuff like SSHFS.
      - embedding-shape 1y ago
        Maybe Apple should consider looking into those sort of things before they promise it'll be in the OS, and even ship some barely working version of it. This was maybe around 2008 sometime so I might misremember how broken what they shipped as preview was.
lostlogin 1y ago
Are you running this via that travesty of a desktop app?
juancn 1y ago
Back to the QEMU dark ages
ChocolateGod 1y ago
Surely, as it is on Linux, QEMU can take over here in running the x86 images on ARM. Is it slow? Absolutely. But you'd be insane to run it in production anyway.
- coldtea 1y ago
  Wanting it to be fast is not just about "running it on production". A test suite that becomes 10x slower is already a huge issue. That said, it doesn't seem llike Rosetta for container use is going anywhere. Rosetta for legacy Mac applications (the macOS level layer) is.

How does this work currently? I was under the impression that Docker for Mac already ran containers in an x86 VM. Probably outdated info, but I’m curious when that changed.

cpuguy83 1y ago
Docker on Mac runs containers in a VM, but the VM is native the cpu architecture and takes advantage of hardware virtualization. You can of course always use qemu inside that vm to run non-native code (eg x86 on Apple Silicon), however this is perceived as much slower than using Rosetta (instead of qemu).

hakube 1y ago

Doesn't Orbstack or Colima solve this?

p0w3n3d 1y ago
if you run x86 code without rosetta (probably using the qemu) it will work painfully slow

saagarjha 1y ago

That won’t be going away, none of that requires any support from the host OS.

swiftcoder 1y ago

This isn't about the virtualisation support - it's about all the Mac system frameworks being available in the rosetta environment

nicce 1y ago
The performance that makes containers usable currently depends on Rosetta on Linux as well. Removing the support makes them much less usable.
- swiftcoder 1y ago
  The announcement doesn't actually say they are removing the Rosetta emulation. Rosetta 2 as a complete snapshot of macOS system frameworks is not the same thing as what is now called the virtualisation framework
  - deleted 1y ago
    [deleted]
  - nicce 1y ago
    Generally speaking of Rosetta means Rosetta 2 since Rosetta 1 is deprecated. It is very difficult to say what they are meaning. The deprecation is mentioned in the context of Rosetta translation environment [1]. Rosetta for Linux uses same wording [2]. For example, Docker at least used to use this same binary translation internally year ago (the same tech as deprecation is mentioned). I don't know how it is today. [1]: https://developer.apple.com/documentation/apple-silicon/about-the-rosetta-translation-environment/ https://developer.apple.com/documentation/apple-silicon/abou... [2]: https://developer.apple.com/documentation/virtualization/running-intel-binaries-in-linux-vms-with-rosetta https://developer.apple.com/documentation/virtualization/run...

ehutch79 1y ago

Ask the maintainers to build arm images. Realistically they should be, unless the project uses lots of x86 assembly.

jamesgeck0 1y ago
It's not just images; any software the images pull down must also support ARM64 now as well. For example, the official Google Chrome binaries used by Puppeteer for headless browsing/scraping don't have a Linux ARM build.

mxey 1y ago

It doesn’t say if that is going away. The message calls out another part as sticking around: > Beyond this timeframe, we will keep a subset of Rosetta functionality aimed at supporting older unmaintained gaming titles, that rely on Intel-based frameworks. Since the Linux version of Rosetta requires even less from the host OS, I would expect it to stay around even longer.

wmwragg 1y ago

Yes that was my first thought as well, and as the images aren't designed to be run on a mac specifically, like a native app might be, there is no expectation for the developers to create a native apple silicon version. This is going to be a pretty major issue for a lot of developers

TimTheTinker 1y ago
Case in point - Microsoft's SQL Server docker image, which is x86-only with no hint of ever being released as an aarch64 image. I run that image (and a bunch of others) on my M3 dev machine in OrbStack, which I think provides the best docker and/or kubernetes container host experience on macOS.
mxey 1y ago
Apple Silicon is ARM64 which is supported by Linux and Docker.
- coldtea 1y ago
  Parent doesn't want to merely run ARM64 Linux/Docker images. They want to run Intel images. Lots of reasons for that, from upstream Docker images not available to ARM64, to specific corporate setups you want to replicate as close as possible, or who aren't portable to ARM64 without huge effort.
- wmwragg 1y ago
  I'm aware, I use ARM images all the time, I was trying to indicate that the usual refrain that the developers have had years to migrate their software to apple silicon, doesn't really apply to docker images. It's only the increase in use of ARM elsewhere (possibly driven by the great performance of macs running apple silicon) which has driven any migration of docker images to have ARM versions
- deleted 1y ago
  [deleted]
- wmf 1y ago
  Yeah but many people are using x86-64 Docker images because they deploy on x86-64. Maybe ARM clouds will be more common by that time.

physicsguy 1y ago

https://github.com/apple/container https://github.com/apple/container They released this a while ago which has hints of supporting amd64 beyond the Rosetta end date.

dur-randir 1y ago
Believing in hints from Apple about software? Sweet summer child.
- khalic 1y ago
  Still waiting for ZFS on OS X
  - djxfade 1y ago
    It was implemented in some of the earlier Leopard beta's iirc. Possible speculation from my side, but it was probably removed due to licensing once Oracle expressed interest in acquiring Sun Microsystems.
  - BirAdam 1y ago
    This mostly died because Apple's new security framework doesn't allow for unsigned kexts or writable root. This also killed most fuse implementations and therefore kneecapped stuff like SSHFS.
    - embedding-shape 1y ago
      Maybe Apple should consider looking into those sort of things before they promise it'll be in the OS, and even ship some barely working version of it. This was maybe around 2008 sometime so I might misremember how broken what they shipped as preview was.

lostlogin 1y ago

Are you running this via that travesty of a desktop app?

juancn 1y ago

Back to the QEMU dark ages

ChocolateGod 1y ago

Surely, as it is on Linux, QEMU can take over here in running the x86 images on ARM. Is it slow? Absolutely. But you'd be insane to run it in production anyway.

coldtea 1y ago
Wanting it to be fast is not just about "running it on production". A test suite that becomes 10x slower is already a huge issue. That said, it doesn't seem llike Rosetta for container use is going anywhere. Rosetta for legacy Mac applications (the macOS level layer) is.