7 ms·

That’s brutal.. I wonder why the Apple Silicon transition seemed so much smoother in comparison.

by brokencode 1y ago

bitwize 1y ago
Because it was handled by the only tech company left that actually cares about the end user. Not exactly a mystery.
- okanat 1y ago
  Having a narrow product line helped Apple a lot. Similarly being able to deprecate things faster than business-oriented Microsoft. Apple also controls silicon implementation. So they could design hardware features that enabled low to zero overhead x86 emulation. All in all Rosetta 2 was a pretty good implementation. Microsoft is trying to retain binary compatibility across architectures with ARM64EC stuff which is intriguing and horrifying. They, however, didn't put any effort into ensuring Qualcomm is implementing the hardware side well. Unlike Apple, Qualcomm has no experience in making good desktop systems and it shows.
  - andsoitis 1y ago
    > Apple also controls silicon implementation. People sometimes say that as if came without foresight or cost or other complexities in their business. No, in the end they are hyper strategic and it pays off.
    - okanat 1y ago
      I didn't say otherwise. They probably realized they can pull a complete desktop CPU design off at the latest with iPad, probably earlier. They were probably not happy using Intel chips and their business strategy has always been controlling and limiting HW capabilities as much as possible.
- cmxch 1y ago
  Given how Apple makes it maintenance hostile and secures against their end customers, no.
kwanbix 1y ago
Because Apple controls verything vs Windows/Linux world where hundres (thouthands?) of OEM create things?
- leidenfrost 1y ago
  I agree with you on the Windows side. Linux is different. Decades of being tied to x86 made the OS way more coupled with the processor family than one might think. Decades of bugfixes, optimizations and workarounds were made assuming a standard BIOS and ACPI standards. Specially on the desktop side. That, and the fact that SoC vendors are decades behind on driver quality. They remind me of the NDiswrapper era. Also, a personal theory I have is that have unfair expectations with ARM Linux. Back then, when x86 Linux had similar compatibility problems, there was nothing to be compared with, so people just accepted that Linux was going to be a pain and that was it. Now the bar is higher. People expect Linux to work the way it does in x86, in 2025. And manpower in FOSS is always limited.
  - daoistmonk 1y ago
    my asahi linux m1 mac book air would disagree with you
  - BoredPositron 1y ago
    You are talking out of your ass here. If you make bold statements like this you need to provide evidence. Linux works fine on many platforms...
  - close04 1y ago
    > Decades of being tied to x86 This doesn't pass the smell test when Linux powers so many smart or integrated devices and IoT on architectures like ARM, MIPS, Xtensa, and has done so for decades. I didn't even count Android here which is Linux kernel as first class citizen on billions of mostly ARM-based phones.
  - StopDisinfo910 1y ago
    Linux runs perfectly on MIPS, Power, Sparc, obviously ARM - cue the millions of phone running Linux today, RiscV, and at least a dozen other architectures with little to no user. It's absolutely not tied to x86.
viraptor 1y ago
Did it? From that list: SQL server doesn't work on Mac and there's no Apple equivalent, virtualisation is built into the system so that kind of worked but with restrictions, games barely exist Mac so a few that cared did the ports but it's still minimal. There's basically no installation media for Macs in the same way as windows in general. What I'm trying to say is - the scope is very different / smaller there. There's a tonne of things that didn't work on Macs both before and after and the migration was not that perfect either.
- electroly 1y ago
  Out of the gate, Apple silicon lacked nested virtualization, too. They added it in the M3 chip and macOS 15. Macs have different needs than Windows though; I think it's less of a big deal there. On Windows we need it for running WSL2 inside a VM.
  - pjmlp 1y ago
    On Windows nested virtualization already existed before WSL, all the kernel and device drivers security features introduced on Windows 10, and made always enabled on Windows 11, require running Hyper-V, which is a type 1 hypervisor. So it is rather easy having to deal with nested virtualization, even those of us that seldom use WSL.
    - electroly 1y ago
      Yes, nested virtualization has existed for a long time... on Intel. On Windows, it is not supported on ARM. For a long time it wasn't even supported on AMD! They added AMD nested virtualization support in Windows Server 2022! Note that when the Windows host is invisibly running under Hyper-V, your other Hyper-V VMs are its "siblings" and not nested children. You're not using nested virtualization in that situation. It's only when running a Hyper-V VM inside another Hyper-V VM. WSL2 is a Hyper-V VM, so if you want to run WSL2 inside a Windows Hyper-V VM which is inside your Windows host, it ends up needing to nest.
  - fulafel 1y ago
unconed 1y ago
Apple already went through this before with PowerPC -> x86. They had universal binaries, Rosetta, etc. to build off of. And they got to do it with their own hardware, which includes some special instructions intended to help with emulation.
- musicale 1y ago
  > Apple already went through this before with PowerPC -> x86 Not to mention 68K -> PowerPC. Rhapsody supported x86, and I think during the PowerPC era Apple kept creating x86 builds of OS X just in case. This may have helped to keep things like byte order dependencies from creeping in.
wmf 1y ago
For one thing Apple dropped 32-bit before they transitioned to ARM while Windows compatibility goes back 30 years.
- rock_artist 1y ago
  Actually, the Macho file format was multiarch by design (On Windows we're still stuck with Program Files (x86)).. Anyway, before dropping 32bit, they've dropped PowerPC. Another consideration, Apple is the king of dylib, you're usually dynamically linking to the OS frameworks/libs. so they can actually plan their glue smarter so the frameworks would still work in native arch. (that was really important with PPC->Intel where you also had big endian...)
  - winocm 1y ago
    You also get "Program Files (ARM)" (including a complementary "SysArm32") on older arm64 systems too.
bdcravens 1y ago
The first few months were a little tricky depending on what software you needed, but it did smooth out pretty quickly.
someNameIG 1y ago
Every Mac transitions to ARM, only a very small amount of Windows PCs are running ARM. SO right now there's not an large user base to incentivise software to be written for it.
- chithanh 1y ago
  You are right that Windows on ARM cannot be called a success. But if you make Windows/macOS cross platform software then your software needs to be written for ARM anyway. So if you support macOS/x86, macos/ARM, and Windows/x86, then the additional work to add Windows/ARM is rather small, unless you do low-level stuff (I remember Fortnite WoA port taking almost a year from announcement to release due to anticheat).
magic_hamster 1y ago
Apple had a great translation layer (Rosetta) that allows you to run x64 code, and it's very fast. However, Apple being Apple, they are going to discontinue this feature in 2026, that's when we'll see some Apple users really struggling to go fully arm, or just ditch their MacBook. I know if Apple does follow through with killing Rosetta, I'll do the latter.
- menaerus 1y ago
  It's a transpiler that takes the x86-64 binary assembly and spits out the aarch64 assembly only on the first run AFAIK. This is then cached on storage for consecutive runs.
  - timschmidt 1y ago
    Apple also implemented x86 memory semantics for aarch64 to allow for simpler translation and faster execution.
    - menaerus 1y ago
      In HW?
      - antonvs 1y ago
        Not OP, but I don’t think so. Rosetta inserts ARM barrier instructions in its generated code to emulate x86 memory ordering.
      - timschmidt 1y ago
        Yup! See here: https://www.sciencedirect.com/science/article/pii/S1383762124000390 https://www.sciencedirect.com/science/article/pii/S138376212...
  - Findecanor 1y ago
    Apple silicon also has special hardware support for x86-64's "TSO" memory order (important for multithreaded code) and half-carry status flag. BTW. A more common term for what Rosetta does is "binary translation". A "transpiler" typically compiles from one high-level language to another, never touching machine code.
ndiddy 1y ago
One reason is that Apple sold subsidized devkits to developers starting around 6 months before Apple Silicon launched, while the X Elite devkit was not subsidized, came with Windows 11 Home (meaning that you had to pay another $100 to upgrade to Pro if you were an actual professional developer who needed to join the computer to your work domain), and didn't ship until after months after X Elite laptops started shipping. As a result, when the X Elite launched basically everything had to run under emulation. I think another reason is Apple's control over the platform vs Microsoft's. Apple has the ability to say "we're not going to make any more x86 computers, you're gonna have to port your software to ARM", while Microsoft doesn't have that ability. This means that Snapdragon has to compete against Intel/AMD on its own merits. A couple months after X Elite launched, Intel started shipping laptops with the Lunar Lake architecture. This low-power x86 architecture managed to beat X Elite on battery life and thermals without having to deal with x86 emulation or poor driver support. Of course it didn't solve Intel's problems (especially since it's fabricated at TSMC rather than by Intel), but it demonstrated that you could get comparable battery life without having to switch architectures, which took a lot of wind out of X Elite's sails.

That’s brutal.. I wonder why the Apple Silicon transition seemed so much smoother in comparison.

bitwize 1y ago

Because it was handled by the only tech company left that actually cares about the end user. Not exactly a mystery.

okanat 1y ago
Having a narrow product line helped Apple a lot. Similarly being able to deprecate things faster than business-oriented Microsoft. Apple also controls silicon implementation. So they could design hardware features that enabled low to zero overhead x86 emulation. All in all Rosetta 2 was a pretty good implementation. Microsoft is trying to retain binary compatibility across architectures with ARM64EC stuff which is intriguing and horrifying. They, however, didn't put any effort into ensuring Qualcomm is implementing the hardware side well. Unlike Apple, Qualcomm has no experience in making good desktop systems and it shows.
- andsoitis 1y ago
  > Apple also controls silicon implementation. People sometimes say that as if came without foresight or cost or other complexities in their business. No, in the end they are hyper strategic and it pays off.
  - okanat 1y ago
    I didn't say otherwise. They probably realized they can pull a complete desktop CPU design off at the latest with iPad, probably earlier. They were probably not happy using Intel chips and their business strategy has always been controlling and limiting HW capabilities as much as possible.
cmxch 1y ago
Given how Apple makes it maintenance hostile and secures against their end customers, no.

kwanbix 1y ago

Because Apple controls verything vs Windows/Linux world where hundres (thouthands?) of OEM create things?

leidenfrost 1y ago
I agree with you on the Windows side. Linux is different. Decades of being tied to x86 made the OS way more coupled with the processor family than one might think. Decades of bugfixes, optimizations and workarounds were made assuming a standard BIOS and ACPI standards. Specially on the desktop side. That, and the fact that SoC vendors are decades behind on driver quality. They remind me of the NDiswrapper era. Also, a personal theory I have is that have unfair expectations with ARM Linux. Back then, when x86 Linux had similar compatibility problems, there was nothing to be compared with, so people just accepted that Linux was going to be a pain and that was it. Now the bar is higher. People expect Linux to work the way it does in x86, in 2025. And manpower in FOSS is always limited.
- daoistmonk 1y ago
  my asahi linux m1 mac book air would disagree with you
- BoredPositron 1y ago
  You are talking out of your ass here. If you make bold statements like this you need to provide evidence. Linux works fine on many platforms...
- close04 1y ago
  > Decades of being tied to x86 This doesn't pass the smell test when Linux powers so many smart or integrated devices and IoT on architectures like ARM, MIPS, Xtensa, and has done so for decades. I didn't even count Android here which is Linux kernel as first class citizen on billions of mostly ARM-based phones.
- StopDisinfo910 1y ago
  Linux runs perfectly on MIPS, Power, Sparc, obviously ARM - cue the millions of phone running Linux today, RiscV, and at least a dozen other architectures with little to no user. It's absolutely not tied to x86.

viraptor 1y ago

Did it? From that list: SQL server doesn't work on Mac and there's no Apple equivalent, virtualisation is built into the system so that kind of worked but with restrictions, games barely exist Mac so a few that cared did the ports but it's still minimal. There's basically no installation media for Macs in the same way as windows in general. What I'm trying to say is - the scope is very different / smaller there. There's a tonne of things that didn't work on Macs both before and after and the migration was not that perfect either.

electroly 1y ago
Out of the gate, Apple silicon lacked nested virtualization, too. They added it in the M3 chip and macOS 15. Macs have different needs than Windows though; I think it's less of a big deal there. On Windows we need it for running WSL2 inside a VM.
- pjmlp 1y ago
  On Windows nested virtualization already existed before WSL, all the kernel and device drivers security features introduced on Windows 10, and made always enabled on Windows 11, require running Hyper-V, which is a type 1 hypervisor. So it is rather easy having to deal with nested virtualization, even those of us that seldom use WSL.
  - electroly 1y ago
    Yes, nested virtualization has existed for a long time... on Intel. On Windows, it is not supported on ARM. For a long time it wasn't even supported on AMD! They added AMD nested virtualization support in Windows Server 2022! Note that when the Windows host is invisibly running under Hyper-V, your other Hyper-V VMs are its "siblings" and not nested children. You're not using nested virtualization in that situation. It's only when running a Hyper-V VM inside another Hyper-V VM. WSL2 is a Hyper-V VM, so if you want to run WSL2 inside a Windows Hyper-V VM which is inside your Windows host, it ends up needing to nest.
- fulafel 1y ago

unconed 1y ago

Apple already went through this before with PowerPC -> x86. They had universal binaries, Rosetta, etc. to build off of. And they got to do it with their own hardware, which includes some special instructions intended to help with emulation.

musicale 1y ago
> Apple already went through this before with PowerPC -> x86 Not to mention 68K -> PowerPC. Rhapsody supported x86, and I think during the PowerPC era Apple kept creating x86 builds of OS X just in case. This may have helped to keep things like byte order dependencies from creeping in.

wmf 1y ago

For one thing Apple dropped 32-bit before they transitioned to ARM while Windows compatibility goes back 30 years.

rock_artist 1y ago
Actually, the Macho file format was multiarch by design (On Windows we're still stuck with Program Files (x86)).. Anyway, before dropping 32bit, they've dropped PowerPC. Another consideration, Apple is the king of dylib, you're usually dynamically linking to the OS frameworks/libs. so they can actually plan their glue smarter so the frameworks would still work in native arch. (that was really important with PPC->Intel where you also had big endian...)
- winocm 1y ago
  You also get "Program Files (ARM)" (including a complementary "SysArm32") on older arm64 systems too.

bdcravens 1y ago

The first few months were a little tricky depending on what software you needed, but it did smooth out pretty quickly.

someNameIG 1y ago

Every Mac transitions to ARM, only a very small amount of Windows PCs are running ARM. SO right now there's not an large user base to incentivise software to be written for it.

chithanh 1y ago
You are right that Windows on ARM cannot be called a success. But if you make Windows/macOS cross platform software then your software needs to be written for ARM anyway. So if you support macOS/x86, macos/ARM, and Windows/x86, then the additional work to add Windows/ARM is rather small, unless you do low-level stuff (I remember Fortnite WoA port taking almost a year from announcement to release due to anticheat).

magic_hamster 1y ago

Apple had a great translation layer (Rosetta) that allows you to run x64 code, and it's very fast. However, Apple being Apple, they are going to discontinue this feature in 2026, that's when we'll see some Apple users really struggling to go fully arm, or just ditch their MacBook. I know if Apple does follow through with killing Rosetta, I'll do the latter.

menaerus 1y ago
It's a transpiler that takes the x86-64 binary assembly and spits out the aarch64 assembly only on the first run AFAIK. This is then cached on storage for consecutive runs.
- timschmidt 1y ago
  Apple also implemented x86 memory semantics for aarch64 to allow for simpler translation and faster execution.
  - menaerus 1y ago
    In HW?
    - antonvs 1y ago
      Not OP, but I don’t think so. Rosetta inserts ARM barrier instructions in its generated code to emulate x86 memory ordering.
    - timschmidt 1y ago
      Yup! See here: https://www.sciencedirect.com/science/article/pii/S1383762124000390 https://www.sciencedirect.com/science/article/pii/S138376212...
- Findecanor 1y ago
  Apple silicon also has special hardware support for x86-64's "TSO" memory order (important for multithreaded code) and half-carry status flag. BTW. A more common term for what Rosetta does is "binary translation". A "transpiler" typically compiles from one high-level language to another, never touching machine code.

ndiddy 1y ago

One reason is that Apple sold subsidized devkits to developers starting around 6 months before Apple Silicon launched, while the X Elite devkit was not subsidized, came with Windows 11 Home (meaning that you had to pay another $100 to upgrade to Pro if you were an actual professional developer who needed to join the computer to your work domain), and didn't ship until after months after X Elite laptops started shipping. As a result, when the X Elite launched basically everything had to run under emulation. I think another reason is Apple's control over the platform vs Microsoft's. Apple has the ability to say "we're not going to make any more x86 computers, you're gonna have to port your software to ARM", while Microsoft doesn't have that ability. This means that Snapdragon has to compete against Intel/AMD on its own merits. A couple months after X Elite launched, Intel started shipping laptops with the Lunar Lake architecture. This low-power x86 architecture managed to beat X Elite on battery life and thermals without having to deal with x86 emulation or poor driver support. Of course it didn't solve Intel's problems (especially since it's fabricated at TSMC rather than by Intel), but it demonstrated that you could get comparable battery life without having to switch architectures, which took a lot of wind out of X Elite's sails.