> 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[1]) 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[2]) 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.

Actually, I think that the route that NetBSD seems to be taking makes
more sense.  By including support for other OS executable formats and
interfaces, we have taken much of the burden off the applications
developers by giving them a consolidated target zone.

Our Sun users can use SunOS executables (right?)

Our 680x0 users can use whatever 680x0 executables are out there now.

Our i386 users can do a lot of the same thing with the SysV
compatability modes.  We also support the Linux ABI and other
'contemporary Free BSD systems'.

> 
> 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.)
> 

The apparent method seems to be to use the published ABIs for commercial
Unices, and provide a compatability mode.  Netscape is a good example.
We can safely use the BSDI version, or the Linux version (if one
exists).  

With -current now, we have two choices.  We can (I presume) use the BSDI
version, or we can use the Linux version.  It depends on the
compatability that is built into the system.

This area is part of what I refer to in the FAQ as the 'horizontal' nature
of NetBSD.  In addition to supporting multiple platforms, the system
provides compatability with many other executable formats.  

ObDiscaimer: This is certainly not to say that FreeBSD will never
support multiple operating system binary interfaces or anything of the
sort.  I am simply saying that this type of thing seems to be well
within the nature of what many of YOU have told me that NetBSD is all
about.  (Hi, Jordan)

> 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.
> 
> 
> [1] 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).
> 

With the exception of the original 386BSD 0.1 (and TOPS-20) we do share
a common ABI.  The BSDI executable format works well for most of our
needs.  I understand that it is possible to compile and statically link
a program (I'm not sure of the options) that will run under NetBSD,
FreeBSD, and BSDI.

I would be more concerned about the shared library implementations.  The
Linux compatability mode seems to work OK with their shared libraries,
but the formats between NetBSD and FreeBSD are different enough that we
can't run theirs (correct me if I'm wrong).  There are other issues
(like leading edge directory services, like you mentioned in your
original message) that need to be resolved, but it is not because WE are
behind the other vendors; on the contrary, I think we are well AHEAD of
many of the commercial vendors in providing the latest in technology.
>From that point of view, NetBSD has grown from being a simple vehicle
for research to one for USABLE research....