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.
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.
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.
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.
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
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.
I’ve worked in DevOps and companies I’ve worked for put the effort in when M1 came out, and now local images work fine. I honestly doubt it will have a huge impact. ARM instances on AWS, for example, are much cheaper, so there’s already lots of incentive to support ARM builds of images
In our small shop, I definitely made sure all of our containers supported aarch64 when die M1 hit the scene. I'm a Linux + Thinkpad guy myself, but now that I've got an x13s, even I am running the aarch64 versions!
It depends. Mostly it is choosing the right base image architecture. For rust and golang we can trivially cross compile and just plunk the binary in the appropriate base image. For JVM based apps it is the same because we just need to have the jars in the right place. We can do this on either architecture.
The only hold out is GraalVM which doesn’t trivially support cross compilation (yet).
We're mostly a PHP / JS (with a little Python on the side) shop, so for our own code it's mostly a matter of the right base image. Building our own images is done on an x86-64 machine, with the aarch64 side of things running via qemu.
It has a huge impact if you need to run the exact same container as in production. This kills Macs in those shops. And there are more than you might think.
But Docker images don't necessarily have ARM64 support. If you are exclusively targeting x64 servers, it rarely makes sense to support both ARM64 and AMD64 platforms for development environment/tests, especially if the product/app is non-trivial.
Every port I've done to a new hardware or software platform has shaken loose at least a handful of bugs or assumptions that were well worth ironing out. And in the case of a port to Apple Silicon, you get a very fast development environment at the end of it. This library also helped with 90% of the work:
And it looks like Rosetta 2 for containers will continue to be supported past macOS 28 just fine. It's Rosetta 2 for Mac apps that's being phased out, and not even all of that (they'll keep it for games that don't need macOs frameworks to be kept around in Intel format).
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.
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
Yep, this is another reason I've needed the use of x86-64 images, as although they should be technically the same when rebuilt for ARM, they aren't always, so using the same architecture image which is run in production, will sometimes catch edge case bugs the ARM version doesn't. Admittedly it's not common, but I have had it happen. Obviously there is also the argument that the x86-64 image is being translated, so isn't the same as production anyway, but I've found that to have far less bugs than the different architecture
> Obviously there is also the argument that the x86-64 image is being translated, so isn't the same as production anyway
I've never seen this make a practical difference. I'm sure you can spot differences if you look for them (particularly at the hardware interface level) but qemu has done this for decades and so has apple.
That's not really the point though right? It means that pulling and using containers that are destined for x86 will require also building arm64 versions. Good news is buildx has the ability to build arm64 on x86, bad news is people will need to double up their build steps, or move to arm in production.
What they talk about is Rosetta's macOS frameworks compiled for Intel being kept around (which macOS Intel apps use, like if you run some old <xxx>.app that's not available for Apple Silicon).
The low-level Rosetta as a translation layer (which is what containers use) will be kept, and they will even keep it for Intel games, as they say in the OP.
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
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.
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.
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.
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).
https://github.com/apple/container
They released this a while ago which has hints of supporting amd64 beyond the Rosetta end date.
Believing in hints from Apple about software? Sweet summer child.
Still waiting for ZFS on OS X
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.
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.
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.
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.
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
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.
I’ve worked in DevOps and companies I’ve worked for put the effort in when M1 came out, and now local images work fine. I honestly doubt it will have a huge impact. ARM instances on AWS, for example, are much cheaper, so there’s already lots of incentive to support ARM builds of images
In our small shop, I definitely made sure all of our containers supported aarch64 when die M1 hit the scene. I'm a Linux + Thinkpad guy myself, but now that I've got an x13s, even I am running the aarch64 versions!
How do you build multi-arch in CI? Do you cross-compile or do you have arm64 runners?
It depends. Mostly it is choosing the right base image architecture. For rust and golang we can trivially cross compile and just plunk the binary in the appropriate base image. For JVM based apps it is the same because we just need to have the jars in the right place. We can do this on either architecture.
The only hold out is GraalVM which doesn’t trivially support cross compilation (yet).
We're mostly a PHP / JS (with a little Python on the side) shop, so for our own code it's mostly a matter of the right base image. Building our own images is done on an x86-64 machine, with the aarch64 side of things running via qemu.
It has a huge impact if you need to run the exact same container as in production. This kills Macs in those shops. And there are more than you might think.
Apple Silicon is ARM64 which is supported by Linux and Docker.
But Docker images don't necessarily have ARM64 support. If you are exclusively targeting x64 servers, it rarely makes sense to support both ARM64 and AMD64 platforms for development environment/tests, especially if the product/app is non-trivial.
Every port I've done to a new hardware or software platform has shaken loose at least a handful of bugs or assumptions that were well worth ironing out. And in the case of a port to Apple Silicon, you get a very fast development environment at the end of it. This library also helped with 90% of the work:
https://github.com/DLTcollab/sse2neon
Or, if you just want to create multi-arch images for your project, on your Mac...so that your non-Mac customers can use them.
I guess now it makes sense. Got 3 years to turn on ARM builds.
No, it still doesn't make sense.
And it looks like Rosetta 2 for containers will continue to be supported past macOS 28 just fine. It's Rosetta 2 for Mac apps that's being phased out, and not even all of that (they'll keep it for games that don't need macOs frameworks to be kept around in Intel format).
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.
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
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.
Yep, this is another reason I've needed the use of x86-64 images, as although they should be technically the same when rebuilt for ARM, they aren't always, so using the same architecture image which is run in production, will sometimes catch edge case bugs the ARM version doesn't. Admittedly it's not common, but I have had it happen. Obviously there is also the argument that the x86-64 image is being translated, so isn't the same as production anyway, but I've found that to have far less bugs than the different architecture
> Obviously there is also the argument that the x86-64 image is being translated, so isn't the same as production anyway
I've never seen this make a practical difference. I'm sure you can spot differences if you look for them (particularly at the hardware interface level) but qemu has done this for decades and so has apple.
Many container images are multi-arch, although probably not ones that are built in-house.
We built our in-house images multi-arch precisely for this reason!
That's not really the point though right? It means that pulling and using containers that are destined for x86 will require also building arm64 versions. Good news is buildx has the ability to build arm64 on x86, bad news is people will need to double up their build steps, or move to arm in production.
W/o rossetta i can't build x86_64 images anymore. Today i can setup OrbStack amd64 linux and build native amd64 images on my mac to put on my servers.
What they talk about is Rosetta's macOS frameworks compiled for Intel being kept around (which macOS Intel apps use, like if you run some old <xxx>.app that's not available for Apple Silicon).
The low-level Rosetta as a translation layer (which is what containers use) will be kept, and they will even keep it for Intel games, as they say in the OP.
This isn't about the virtualisation support - it's about all the Mac system frameworks being available in the rosetta environment
The performance that makes containers usable currently depends on Rosetta on Linux as well. Removing the support makes them much less usable.
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
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/abou...
[2]: https://developer.apple.com/documentation/virtualization/run...
Ask the maintainers to build arm images. Realistically they should be, unless the project uses lots of x86 assembly.
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.
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.
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).
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.
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.
Doesn't Orbstack or Colima solve this?
if you run x86 code without rosetta (probably using the qemu) it will work painfully slow
That won’t be going away, none of that requires any support from the host OS.
Are you running this via that travesty of a desktop app?
Back to the QEMU dark ages