Comment by 0x0
6 months ago
I'm guessing they don't want to maintain and build and test x86_64 versions of all the macos libraries like Appkit and UIKit (including large changes like liquid glass) when they are no longer shipping x86_64 macOS versions. Which is not entirely unreasonable as I'm sure it takes a lot of effort to keep the whole ui library stack working properly on multiple archs.
Perhaps that's what they're hinting about with the note about a "subset of Rosetta". So maybe there is hope that the core x86_64 binary translator will stick around for things like VM and emulation of generic (linux? wine?) binaries, but they don't want to maintain a whole x86_64 macOS userspace going forward.
Space savings from not shipping fat binaries for everything will probably also be not insignificant. Or make room for a new fat binary for a future "arm64v2" :)
Apple always phases out these kinds of technologies after some time to keep the ecosystem tidy and give a last push to developers to abandon legacy code.
In this iteration, it might also allow some simplification of the silicon since Mx chips have some black magic to mimic x86 (mostly in memory access IIRC) to allow Rosetta to work that fast. IOW, Rosetta 2 is not a software only magic this time.
I remember using the first Rosetta to play Starcraft on my Intel Mac. It also got deprecated after a year or two.
So leaving things behind despite some pains is Apple's way to push people forward (e.g.: Optical media, ports, Rosetta 1, Adobe Flash, etc.).
If they hadn't deprecated 32 bit we would still be able to play Halo on mac.
This is the perfect comment because 1) it’s true, and 2) it can be read as supportive, a complaint, or just a neutral observation.
1 reply →
The problem is, keeping older architectures alive creates an exponential workload, grinding everything to halt.
So, even though I feel what you are saying, we can't have every nice thing we want, at the same time.
10 replies →
Apple's contempt for compatibility makes for poor game platforms. It's also a drain on developers who have a continual maintenance burden just to keep things running with each year's new edition of iOS.
Is there not an emulator at this point?
3 replies →
Not sure it's only about tidiness. Rosetta 1 was licensed from a third party and Apple didn't want to keep paying the license fees.
I don't know if this is the situation with Rosetta 2.
I read a comment somewhere, possibly here by an ex-Apple engineer who claimed that they optimized the thing mathematically for the performance it exhibits.
So, considering its silicon parts, Rosetta 2 is more of an Apple endeavor and technology.
On the other hand 5-7 years a very typical timespan for Apple. So, I don't think licensing fees were that important while ending support for it.
The original Rosetta was based on technology from Transitive which, as I recall, IBM bought. Don't know where Rosetta 2 fits in and any licensing associated with the original Rosetta was a long time ago.
> It also got deprecated after a year or two.
It was five years, from 2006 to 2011. Rosetta 2 will have been there for seven years (currently at five).
https://en.wikipedia.org/wiki/Rosetta_(software)
To clarify, the complete sentence in my mind was "...after a year or two I got my Intel Mac". I got mine in Q3 2008, just before Unibody ones introduced.
So, I effectively got 2 years out of Rosetta 1, but didn't meant to say Apple supported it for two years only.
Sorry for the confusion.
Looks like I can't edit my comment anymore to clarify.
> ...they don't want to maintain and build and test x86_64 versions...
This feels wrong. Apple sold Intel-based Macs until early June 2023. The last one was the 2019 Mac Pro model.
Ending support for Rosetta in macOS around 2028 also means ending support for any x86_64 versions of software. This means that those unfortunate users who bought an Intel Mac Pro in 2023 only got five years of active usability.
Just because the latest OS isn't able to be installed on older hardware does not mean the hardware in no longer usable. I know people to this day that still run the last 2012 cheese grater MacPros with Snow Leopard as daily work machines. They still use Final Cut 7 on them to capture content from tapes. At this point, they are very fancy dedicated video recorders, but they still run and are money making devices.
You're right; I still have a 2010 MBP w/8GB of RAM and a SSD upgrade I made to it years ago. My mother still uses her similar vintage MBP with the same upgrades. These work just fine for most non-work tasks.
That doesn't mean that I expect these things to be updated or supported 15y after I bought them. I am absolutely certain I made the back $850 I originally paid (edu discount) + the ~$250 in upgrades over the years and I'm entirely ok with just letting it limp along until it physically dies. I think most people have similar expectations.
3 replies →
The last security update for Snow Leopard was in 2013. Friends don't let friends connect software that vulnerable to the internet.
The hardware can be ok, the walled garden is not.
3 replies →
You got it wrong.
Rosetta is the technology that allows Apple Silicon hardware to execute Intel software. When they introduced Apple Silicon with the M1 processor, not many binaries existed for Apple Silicon, so Rosetta2 was a bridge for that problem.
They used the same technology (Rosetta 1) when they switched from PowerPC to Intel.
Pretty much every binary for macOS is distributed as a "Universal Binary", which contains binaries for both x86 and Apple Silicon, so x86 isn't being abandoned, only the ability to run applications on Apple Silicon that hasn't been redistributed / recompiled in 6-7 years.
No, I didn't get it wrong. The moment Apple stops supporting to run x86_64 binaries on ARM (M) CPUs, everyone including Apple will stop making Universal Binaries. Because (among other reasons, like lack of motivation) there will be no easy way to test the x86_64 part of the binary. The Intel MacOS era will be over. Just 5 year after Apple sold the last Intel-based Mac Pro.
1 reply →
I don't think the ability to cross-compile things will go away when Rosetta is phased out, though.
But how can you test it if your ARM-based Mac cannot run it? Most software vendors will simply stop making x86_64 builds.
8 replies →
It's reasonable to say this is wrong. But really, this seems like a tiny subset of users. Who bought a Mac Pro in 2023 after Apple Silicon had been out for 3 years already? Almost nobody, because it wasn't a real performance improvement by that time. For those extremely niche folks for which it was somehow still beneficial, they definitely won't want to still be using such a machine in 2028. They will have moved on to something like an M5 Ultra Mac Studio or whatever form the Mac Pro takes next.
> including large changes like liquid glass
They could just revert all that large change with no loss to the users.
The largest impact would be that the reversion would only affect native macOS apps, while catalyst apps, remote iPhone apps and locally installed iPad apps would still have Liquid Glass UX.
Seriously? Why would they revert it just on desktops? Phones should remain unreadable?
> So maybe there is hope that the core x86_64 binary translator will stick around for things like VM and emulation of generic (linux? wine?) binaries
It's mostly for their game-porting toolkit. They have an active interest in Windows-centric game developers porting their games to Mac, and that generally doesn't happen without the compatibility layer.
System library calls from x86 don’t get converted into arm64 by Rosetta? I coulda sworn Microsoft’s emulator did that
> Or make room for a new fat binary for a future "arm64v2" :)
Or, one can dream: RVA23
It’s basically just a recompile though.
I'm sure there's lots of x86_64 specific code in the macOS userland that is much more than just a recompile - things like safari/javascriptcore JIT, various quartz composer core animation graphics stack and video encoder decoder stack libraries, as well as various objective-c low level pointer tagging and message passing ABI shenanigans and so on. This is probably why 32bit intel mac app support was dropped pretty hard pretty fast, as the entire runtime and userland probably required a lot of upkeep. As just one example, 32bit intel objective-c had "fragile instance variables" which was a can of worms.
This is <1% of the total code that Apple writes
2 replies →
Until it isn't
Can you enable TSO for ARM executables?
Yes but I don't see how that is relevant
Best take
It’s not like they were doing it to make me happy, they are doing it to sell Mac and lock people into the Apple ecosystem. Maybe there is a negligible % of people using it, possible m1 is 6 yrs old iirc
Closer to 5 years old