> > I think it's inappropriate that NetBSD trumpets its commercial-system
> > binary emulation capabilities so loudly when it falls so far short of
> > actually providing useful and complete emulation for those systems.
> 
> I don't.  We _do_ emulate SCO, BSDI, etc.  I use BSDI's netscape version
> all the time.  It works perfectly (well, as perfectly as Netscrape can...)
> so I claim the binary compatibility is working.

"Congratulations!  You now have one working application."

The point here is that, to emulate an OS with complete generality, you
_need_ to, for instance, be able to run third-party shared-lib
binaries for that OS.

As time passes, i'm willing to bet that the number of
statically-linked BSDI applications is going to either stay a small,
relatively constant number, or will drop to zero.  There's a reason
why people like shared libraries...  8-)

As that happens, as a percentage, fewer and fewer BSDI binaries will
be capable of running with NetBSD's emulation.


Until a proper solution to the shared library/shared loader problem is
implemented, people can run a constant (perhaps large, but nonetheless
a constant) number of the commercial applications that are shipping
for each emulated system.

When a proper solution to the problem is implemented, people will be
able to run a fraction (based on the quality of the emulation and
libraries, and the functionality used by applications) of the
application base for the given systems.


As long as the application you want to run happens to be one of the
'constant' number of applications that are statically linked (and
therefore that you have a chance of running under either scheme),
either scheme looks equally good.

However, if you're claiming the ability to emulation a given system's
binaries, that gives Joe Bob the User the expectation of being able to
pick up a random off-the-shelf commercial application for the system,
and being able to run it.

That may work for some applications, but because of the shared
library/shared loader problem it doesn't work for a large class
(perhaps "the largest class") of applications.  Therefore, claiming to
be able to run a system's binaries under emulation without "doing the
right thing" w.r.t. shared libs & shared loaders gives users false
expecatations of what they can do with the system... and intentionally
giving them that false expectation is effectively lying.


That latter point, by the way, is why:

	(1) even though the OSF/1 emulation which can be used on the
	    Alpha port could possibly be made to work for certain,
	    statically linked binaries, and could even be made to work
	    for dynamically linked binaries with appropriate fixes to
	    NetBSD/alpha machine-dependent code, i don't really push
	    it as a viable emulation,

	(2) the OSF/1 emulation code's directory contains the various
	    README* files which attempt to go into detail about what
	    (specific to the OSF/1 emulation, like mach traps, and
	    not generic to all emulations, like the shlib problem)
	    will not work under emulation, and why. 


cgd