>> How about the following as a fat binary?  (Obviously the btoa data
>> sections are not for real. :-)

>> #! /bin/sh
>> fn=/tmp/$$.exec
>> case `arch` in
>> 	sun4)	atob << \EOF
[...]

> I hope that ':-)' was intended for the idea.

It wasn't, actually.  I don't consider that really very much grosser
than a traditional fat binary (if a word like "traditional" can be
applied to a relatively new idea like fat binaries).

> What about the /bin/sh, arch, and atob binaries?  The above will only
> work if those binaries are architec. independant.  And if they are,
> why not others?

Depends on what you want fat binaries for.  I haven't heard of a good
use for them yet; even for the much-talked-about distribution CD-ROM,
you need a kernel.  The kernel _could_ be a fat binary, if the boot
block is sufficiently intelligent...but that's just pushing the problem
back - you are then stuck with trying to figure out how to pick which
boot block to use.

The only good use I can think of for them is for binary distributions
of third-party-ware, and leaving aside the question of whether it's
worth going to any effort to support such[%], I can't see how fat
binaries are any better than just including a separate binary for each
architecture (separate tarfiles, separate FTP areas, whatever).

[%] IMO non-source distributions are Evil, and I wouldn't mind a bit if
    NetBSD were overtly hostile towards them.  Not that I expect this
    to happen.

In any case, I can't see any way to make _everything_ fat.  Given that,
I don't consider depending on /bin/sh, arch, and atob a problem.

					der Mouse

			    mouse@collatz.mcrcim.mcgill.edu