
The Super Duper Universal Binary - Wowfunhappy
https://tenfourfox.blogspot.com/2020/06/the-super-duper-universal-binary.html
======
wazoox
Back in OpenStep, it was quite common to have fat binaries with m68k, i386,
SPARC and PA-RISC architectures.

~~~
lukeh
Yes, I think we called them quad-fat back then?

------
nkurz
What's the argument for why fat binaries like this are a good idea, as opposed
to having separate binaries that can be downloaded for different
architectures? It seems like the main advantage would be when there is
(something like) a networked drive simultaneously accessed by incompatible
machines, with a secondary case for when the same drive is transferred from
machine to machine (or when a single machine is upgraded to a different
processor). Is this a large enough use case to drive adoption, or is there
some other major benefit that I'm missing? Or is it that having 2x (or 17x)
larger binaries to distribute isn't actually much of a downside, so even a
small benefit is sufficient justification?

~~~
klodolph
Most apps, 2x binary size is no big deal. This has been true since the 1990s,
when we had fat binaries that were M68K and PowerPC. Nobody’s doing 17x,
that’s just a joke.

Figuring out how to get users to download the correct binary, now that sucks.
Do you add JavaScript to your download page or do server-side sniffing with
the user agent to deliver the correct binary? And do you want to explain to
someone that yes, they downloaded the Mac version but they have an x86 Mac and
can’t download the ARM binary?

~~~
gruez
>And do you want to explain to someone that yes, they downloaded the Mac
version but they have an x86 Mac and can’t download the ARM binary?

Can't you detect the system architecture through the user agent string? eg.
[https://developer.mozilla.org/en-
US/docs/Web/HTTP/Headers/Us...](https://developer.mozilla.org/en-
US/docs/Web/HTTP/Headers/User-Agent/Firefox#Macintosh). I guess it's still an
issue if you're downloading for ARM mac, using a x86 mac, but that's a pretty
rare occurrence and you can work around it by allowing users to select the
architecture manually.

~~~
klodolph
The only advantage that user agent sniffing has over fat binaries is the
decreased size, and usually, it’s a fairly small difference. Small benefit,
big drawback. Plus, there are all the smaller developers or hobbyists who just
want to share the app they made, and maybe don’t want to figure out how to get
user agent sniffing working on their site—or maybe they are just sharing a
link to Google Drive with the game that they made.

Also from my experience, people still share downloaded copies of applications.

We can use thin binaries only when necessary—web browsers, for example.

------
ChrisMarshallNY
This kind of thing is pretty cool, but I’ve learned to avoid them, because
they can result in A) BIG clumps of code, and B) testing issues.

I used to have a special shell script that I wrote, that used lipo to combine
multiple binaries into an aggregate library. I probably still have it around,
somewhere. I was fairly proud of it.

Also, I had to use static libs, which wasn’t a problem, as long as I didn’t
mind a big executable that couldn’t be trimmed.

Over the years, I’ve learned (the hard way, since I’m a stubborn knucklehead)
not to “end run” around Apple’s prescribed methodology.

Now that Apple has wrapped Swift Package Manager into Xcode, it lessens the
need for “clumped” binaries (for internal projects).

------
musicale
> Just build them separately and lipo them together.

Perfect command name. ;-)

------
steviedotboston
A super duper universal binary? Oh you mean a .jar file

~~~
wolrah
Ah yes, Java, with the promise of "write once, run anywhere"...as long as
anywhere has a specific version of the JRE installed that's been EoL since
2007.

Obviously that's not the case for all Java software, but has always amazed me
how seemingly easy Java made it to end up like that. So many legacy Java apps
that are a complete pain to support, and $deity help you if one user needs to
run two different legacy apps with non-overlapping JRE requirements.

And that's not even getting in to the horrors that were the Java plugin,
fortunately that is entirely out of my life and gone for good.

~~~
mikestew
_as long as anywhere has a specific version of the JRE installed that 's been
EoL since 2007._

I just ran into this on a new machine while trying to get Bamboo (Atlassian's
CI product) running. Just download latest? _phhhttt_ It needs a specific
version: 1.8. Wait a minute, WTF? Java is at like v14 now, or something,
right? Ah, because apparently there's some soft link from 1.8 to
$WHATEVER_VERSION. Didn't matter because I downloaded the JRE, but needed the
JDK. Or something. I've eventually got it working, and wrote it down this
time.

I go back so far that I've written software on punch cards. And someone
suggests that we foist this on your average Mac (or for that matter, any OS)
user? Fat binaries, please.

~~~
cesarb
> It needs a specific version: 1.8. Wait a minute, WTF? Java is at like v14
> now, or something, right?

There was a compatibility break between Java 1.8 and Java 9 (the version
number also lost the prefix at the same time, Java 1.8 can be thought of as
"Java 8"). It was not as big as the change from Python 2 to Python 3, but a
lot of software needed changes to not break; as late as last year, I was still
seeing Java libraries adding fixes for compatibility with Java 9. If your
software depends on libraries which have not yet been upgraded to work with
Java 9, you have to require Java 8 (that is, Java 1.8).

It doesn't help that, even today, the default version of Java in some major
Linux distributions is Java 1.8, so not only that's a good reason to keep
compatibility with Java 8, but also it means that there's a good chance that
the server already has Java 1.8 installed. (In a not so distant future,
however, these major Linux distributions will probably have Java 11 as the
default version; the next long-term stable Java version after Java 11 is
probably going to be Java 17, so you are going to see many software require
Java 11 for a while, and later Java 17.)

~~~
mikestew
Thank you for a helpful explanation from a software engineer, but one who is
not steeped in Java all day. It is annoyingly opaque to those of us for whom
Java is just a tool.

------
m0llusk
Perhaps "totally gross" binary would be a more specific and direct
terminology?

~~~
m0llusk
I was serious, but of course immediately received negative feedback. Super
Duper, it is then. Any chance someone will explain why they feel that is the
superior choice? It doesn't seem to be any more precise. If anything it is
just some unrelated expression used for kicks. Or was this just an emotional
reaction unrelated to any particular line of reasoning?

~~~
nkurz
I downvoted it because I thought it was a low effort joke, and I wanted the
comments to focus on the concept rather than the name. Also, I thought you
were suggesting "totally gross binary" as a general replacement for the
established term "fat binary", and it didn't seem like a good idea. I treated
Super Duper as just a sarcastic title for a blog post, and don't think it's
actually any better. Apologies if I misunderstood your intent.

