From owner-freebsd-hackers  Sat Feb 25 09:28:46 1995
Return-Path: hackers-owner
Received: (from majordom@localhost) by freefall.cdrom.com (8.6.9/8.6.6) id JAA15839 for hackers-outgoing; Sat, 25 Feb 1995 09:28:46 -0800
Received: from localhost (localhost [127.0.0.1]) by freefall.cdrom.com (8.6.9/8.6.6) with SMTP id JAA15828; Sat, 25 Feb 1995 09:28:44 -0800
X-Authentication-Warning: freefall.cdrom.com: Host localhost didn't use HELO protocol
To: Bruce Evans <bde@zeta.org.au>
cc: terryl@CS.Stanford.EDU, freebsd-hackers@freefall.cdrom.com
Subject: Re: Binary compatibility with NetBSD 
In-reply-to: Your message of "Sun, 26 Feb 95 01:27:50 +1100."
             <199502251427.BAA23726@godzilla.zeta.org.au> 
Date: Sat, 25 Feb 1995 09:28:42 -0800
Message-ID: <15825.793733322@freefall.cdrom.com>
From: "Jordan K. Hubbard" <jkh@freefall.cdrom.com>
Sender: hackers-owner@FreeBSD.org
Precedence: bulk

> All bets are off anyway.  The runtime combination of a foreign application
> and foreign shared libries is not very different from the same foreign
> application linked statically.  Foreign syscalls, foreign ioctls, foreign
> database, ... won't work in either case.

Well, compatability on these levels is something we should still be
striving for.  Compatible syscalls (or specialized tables loaded in when
NetBSD/BSDI binaries are run), ioctls, etc.

Becoming incompatible with BSDI would be a serious mistake.  I'm not
all that worried about being compatible with NetBSD (it's a goal, just
a much lower priority one) since they don't really have many (or any)
applications we're interested in running.  The same is most definitely
not true of BSDI.   I don't know what I'd do without my netscape! :-)

					Jordan