2 ms·

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 wei

by 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.

by nkurz 6y ago

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.