Actually, having "fat binaries" is definitely not the more sophisticated
approach. In fact, it's arguably a damn stupid thing to do (I haven't heard
any NeXt users say it was actually useful). It only fills up diskspace with
totally useless stuff, and anybody who says "disk is cheap" deserves to be
shot. NOTHING is that cheap.
Fat binaries can in theory be useful for network volumes that are mounted to
different machines, but let's be honest: there are other (better) ways to
handle the same thing. You can have separate directories for different
architecture binaries, mount only the one you need, share the
arch-independent data in another directory. Alternatively just have a wrapper
shell script (even NT must have _some_ kind of architecture-independent
"shell"?) or whatever that dynamically finds the right executable.
> The program loader knows
> the current architecture and runs appropriate code. This is
> non-trivial since all development tools have to be fat aware. The
> resulting fat binary does not bloat the code too much since most
> application programs have a big data sections. It is also nice for
> administrations, software vendors etc.
Umm, it's generally _much_ nicer to just have an intelligent installation
script. It's also a lot easier for the software developer and the tools,
and is generally just the _simple_ approach.
Of course, some people think that "complex" equals "sophisticated", but
my personal opinion is that "complex" equals "stupid". YMMV..