6 ms·

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 liqui

• saagarjha 11mo ago
  It’s basically just a recompile though.
  • WanderPanda 11mo ago
    Until it isn't
  • RossBencina 11mo ago
    Can you enable TSO for ARM executables?
    • saagarjha 11mo ago
      Yes but I don't see how that is relevant
  • 0x0 11mo ago
    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.
    • saagarjha 11mo ago
      This is <1% of the total code that Apple writes
      • AdamN 11mo ago
        Yeah, the most important, least readable, and oldest code. It's exactly the stuff that's expensive to maintain.
        • saagarjha 11mo ago
          It's not that expensive.
• zaphirplane 11mo ago
  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
  • rs186 11mo ago
    Closer to 5 years old
• swiftcoder 11mo ago
  > 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.
• bayindirh 11mo ago
  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.).
  • cactusplant7374 11mo ago
    If they hadn't deprecated 32 bit we would still be able to play Halo on mac.
    • bayindirh 11mo ago
      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.
      • cactusplant7374 11mo ago
        What has been so impressive about the last 5 years of MacOS releases?
        • johnebgd 11mo ago
          How much worse they make things.
        • wslh 11mo ago
          ARM/Apple-Silicon support?
        • bayindirh 11mo ago
          I'm not very well versed in macOS internals, but I was a tech lead of a Debian derivative. I also write HPC software and manage relevant infrastructure from metal to user , so I believe I know some details about processor architectures, general hardware, Linux and *NIX systems in general. The user-visible layer of an operating system is generally one of the simpler layers when it comes to code and maintain since it's build upon abstractions. However, the libraries powering these layers, esp. math-heavy and hardware-interacting ones are much more complex due to the innate complexity of the hardware in general. Keeping multiple copies of a library, in two different architectures (even if it only changes in bit-length), where this simple bit-change needs different implementation strategies to work correctly is a pain by itself (for more information, ask Linux Kernel devs since they're also phasing out x86). Moreover, x86 and x86_64 is a completely different mode on the processor. On top of that, x86 only mode is called "protected mode" and x86_64 is called "long mode", and running x86 under x86_64 is a sub-mode of "long mode", and is already complex enough at silicon level. Same complexities apply to ARM and other processor architectures. Silicon doesn't care about the ISA much. We have seen the effort of increasing performance on superscalar, out of order processors opened a new, untapped family of side-channel/speculative attacks already. So processors are complex, software is complex, and multiple architectures on the same hardware is exponentially complex. If you want to see how the sausages made, you can also research how Windows handles backwards compatibility problem (hint: by keeping complete Windows copies under a single Windows installation in ELI5 terms). So, the impressive thing was making these multi-arch installations running for quite some time. We need to be able let things go and open some software and hardware budget for new innovations and improvements. Addenda: Funnily, games are one of the harder targets for multi-arch systems since they are both math-heavy and somewhat closer to the hardware than most applications and are very sensitive to architecture changes. Scientific/computational software is also another family, and this interestingly contains databases and office software. Excel also had a nasty floating point bug back in time, and 32/64 bit installations of Microsoft Office has some feature differences since the beginning.
• thw_9a83c 11mo ago
  > ...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.
  • bayindirh 11mo ago
    I don't think the ability to cross-compile things will go away when Rosetta is phased out, though.
    • thw_9a83c 11mo ago
      But how can you test it if your ARM-based Mac cannot run it? Most software vendors will simply stop making x86_64 builds.
      • bayindirh 11mo ago
        Keep older hardware at hand?
        • thw_9a83c 11mo ago
          Sure! The point is that it wasn't necessary because of Rosetta. For example, I no longer have an Intel-based Mac, but I still want to build and test for x86_64.
          • bayindirh 11mo ago
            I understand where you are coming from and commend you for trying to support your users (I'd do the same!), but I don't think Apple marketed Rosetta 2 as a permanent solution after the transition. Another aspect is, a Mac stops getting software updates after ~7 years, and then the API level starts to drift between the latest macOS releases. So, after 10 year mark, you can't get the latest versions of the applications already since the features developers use aren't available in the older macOS versions and you can't run the software anyway.
• nottorp 11mo ago
  > including large changes like liquid glass They could just revert all that large change with no loss to the users.
  • dwaite 11mo ago
    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.
    • nottorp 11mo ago
      Seriously? Why would they revert it just on desktops? Phones should remain unreadable?
• rangestransform 11mo ago
  System library calls from x86 don’t get converted into arm64 by Rosetta? I coulda sworn Microsoft’s emulator did that
• zer0zzz 11mo ago
  Best take
• somanyphotons 11mo ago
  > Or make room for a new fat binary for a future "arm64v2" :) Or, one can dream: RVA23