Subject: Re: Netscape.
To: None <current-users@NetBSD.ORG>
From: John F. Woods <firstname.lastname@example.org>
Date: 03/10/1995 08:28:00
This might actually be a good opportunity to raise an issue that came up
on netnoise recently.
It yet another interminable "Why not merge FreeBSD/NetBSD/BSDI/386BSD/TOPS-20"
discussion, someone suggested that what the BSD camps really needed was a
common Application Binary Interface (ABI); an executable format (and set of
kernel facilities) that all of the camps agree to provide support (and
development tools) for. At the moment, the old 386BSD format seems to
provide this on the x86, but partially by accident; all it takes is for
some key system call to be changed (or a really, really nifty one to be
added) by one camp that the other camp loathe beyond measure, and it
becomes much more difficult to do cross-development without formal planning.
The non-x86 NetBSDs lean on commercial UNIXes for their "ABI"s, which change
relatively infrequently, hence make easier targets to track. I think, though,
that the 386 BSD world is headed for the same market fragmentation problem
that was well understood by the commercial UNIX world by 1988.
As someone who used to work on an "off-brand UNIX semiclone", I know
ALL TOO WELL the difficulties faced in getting commercial application
support for a platform. At the very least, an application developer
has to at least have table space for one system of each platform they
plan to properly support (no, having one system and periodically
formatting the disk and re-installing ISC or FreeBSD or NetBSD or Linux
of ITS-386 is just not an option), they have to have enough staff-hours
available to have someone baby-sit all the compiles (to say nothing of
the eventual compilation errors that have to get fixed!), and for commercial
shrink-wrap software they have to manufacturer N extra lots of software,
raising their costs and uncertainty at the same time. (For Netscape, they'd
have to blow a few extra megabytes on their FTP server; maybe they have it
to spare--and maybe they don't.)
It's not just that someone might make up the expense doing a NetBSD-specific
port (and don't count on it, they're going to have to buy hardware and blow
big bucks on salaries -- QA people have to eat, too). From their standpoint,
they can make a h*ck of a lot **more** by spending that same time and money
on their DOS port. You need to lower the development costs as much as
possible -- not pepper developers with insults.
 What's the right ld option to generate a 386BSD format executable, by the
way? Options, I guess, since it also has to be statically linked (sigh).
 Do the traditional system calls always behave sensibly when presented
with whiteout "files"? If it's already necessary for even slightly clever
programs to include whiteout calls, this battle may already be lost. (And
heaven knows what FreeBSD and BSDI are doing right now...)