4 ms·

The only real advantage is you don't have to worry about which binary to pick on the download page.

by timw4mail 6y ago

sanxiyn 6y ago
This is an enormous advantage, so it's not to be disregarded lightly.
- nkurz 6y ago
  Yes, having a user manually choose a binary to download from a web browser is poor, but certainly there are technological solutions to this that are lighter weight than doing a full download of a fat binary for everyone. Perhaps you download a shim installer that tests your processor and chooses the correct download? Perhaps instead of a generic web browser downloads are done within a framework that already knows the correct architecture? Especially if you are Apple, and if the goal is simply choosing the right version initially, it seems like there would be many better solutions.
  - gruez 6y ago
    > Perhaps you download a shim installer that tests your processor and chooses the correct download? Wouldn't that only work if the shim itself was a universal/fat binary? Otherwise you still run into the same problem. You can sort of work around on unix-like systems by using the shebang, and on windows by having the executable in .net.
    - nkurz 6y ago
      Sure, it could be a universal binary, or something interpreted, or bytecode using an existing VM. But the shim would be something small, and could probably be reused as a standard installer for many programs. My argument wouldn't be that a universal binary is never the right approach, but that it seems wasteful to make every binary support multiple architectures instead of using a more targeted approach.
  - masklinn 6y ago
    > Yes, having a user manually choose a binary to download from a web browser is poor, but certainly there are technological solutions to this that are lighter weight than doing a full download of a fat binary for everyone. In the average application, the binary is only a minor contributor to bundle size, assets are the vast majority of it. For instance on my system Delicious Library 3 is a 110MB bundle. The binary is under 4MB. Same observation with Keka (30MB / 344K), xACT (15MB / 960K) or unicode checker (10MB / 500K) Fat binaries were not an issue during the last transition, they're even less so now.
- wolrah 6y ago
  It's an enormous advantage in one specific case, where you have enough non-technical users who would otherwise need to manually choose a binary. That was a big deal for Apple during their two previous transitions, but not as much these days where as I understand it a significant portion of Mac software distribution happens through the official App Store platform. We see the same in the Linux world, where fat binary support has been developed and proposed on multiple occasions but has never really caught on because the number of users who don't know their CPU architecture but want to install software from outside their distro's package manager is effectively negligible.
  - selectodude 6y ago
    Universal Binaries were barely an issue fifteen years ago, either. Sure, they were a bit larger but only the actual compiled code changed. Any assets used were the same and the difference in package size wasn't particularly significant.
  - Wowfunhappy 6y ago
    > as I understand it a significant portion of Mac software distribution happens through the official App Store platform It's not that significant. I'd guess the amount that goes through the app store is almost certainly less than half, and very possibly much less.
  - musicale 6y ago
    It's an enormous advantage: - to restore your apps onto a new machine using Migration Assistant and have them "just work" at full performance - to have a single app that you can drag and drop install on your old and new hardware - in campus environments to have a single image and archive for all local software

The only real advantage is you don't have to worry about which binary to pick on the download page.

sanxiyn 6y ago

This is an enormous advantage, so it's not to be disregarded lightly.

nkurz 6y ago
Yes, having a user manually choose a binary to download from a web browser is poor, but certainly there are technological solutions to this that are lighter weight than doing a full download of a fat binary for everyone. Perhaps you download a shim installer that tests your processor and chooses the correct download? Perhaps instead of a generic web browser downloads are done within a framework that already knows the correct architecture? Especially if you are Apple, and if the goal is simply choosing the right version initially, it seems like there would be many better solutions.
- gruez 6y ago
  > Perhaps you download a shim installer that tests your processor and chooses the correct download? Wouldn't that only work if the shim itself was a universal/fat binary? Otherwise you still run into the same problem. You can sort of work around on unix-like systems by using the shebang, and on windows by having the executable in .net.
  - nkurz 6y ago
    Sure, it could be a universal binary, or something interpreted, or bytecode using an existing VM. But the shim would be something small, and could probably be reused as a standard installer for many programs. My argument wouldn't be that a universal binary is never the right approach, but that it seems wasteful to make every binary support multiple architectures instead of using a more targeted approach.
- masklinn 6y ago
  > Yes, having a user manually choose a binary to download from a web browser is poor, but certainly there are technological solutions to this that are lighter weight than doing a full download of a fat binary for everyone. In the average application, the binary is only a minor contributor to bundle size, assets are the vast majority of it. For instance on my system Delicious Library 3 is a 110MB bundle. The binary is under 4MB. Same observation with Keka (30MB / 344K), xACT (15MB / 960K) or unicode checker (10MB / 500K) Fat binaries were not an issue during the last transition, they're even less so now.
wolrah 6y ago
It's an enormous advantage in one specific case, where you have enough non-technical users who would otherwise need to manually choose a binary. That was a big deal for Apple during their two previous transitions, but not as much these days where as I understand it a significant portion of Mac software distribution happens through the official App Store platform. We see the same in the Linux world, where fat binary support has been developed and proposed on multiple occasions but has never really caught on because the number of users who don't know their CPU architecture but want to install software from outside their distro's package manager is effectively negligible.
- selectodude 6y ago
  Universal Binaries were barely an issue fifteen years ago, either. Sure, they were a bit larger but only the actual compiled code changed. Any assets used were the same and the difference in package size wasn't particularly significant.
- Wowfunhappy 6y ago
  > as I understand it a significant portion of Mac software distribution happens through the official App Store platform It's not that significant. I'd guess the amount that goes through the app store is almost certainly less than half, and very possibly much less.
- musicale 6y ago
  It's an enormous advantage: - to restore your apps onto a new machine using Migration Assistant and have them "just work" at full performance - to have a single app that you can drag and drop install on your old and new hardware - in campus environments to have a single image and archive for all local software