by homeworld.cygnus.com with SMTP; 29 Nov 1998 21:23:02 -0000
	by lorax.ubergeeks.com (8.8.8/8.8.8) with SMTP id QAA00881;
	Sun, 29 Nov 1998 16:22:39 -0500 (EST)
	(envelope-from adrian@lorax.ubergeeks.com)
Date: Sun, 29 Nov 1998 16:22:39 -0500 (EST)
From: ADRIAN Filipi-Martin <adrian@ubergeeks.com>
Reply-To: Adrian Filipi-Martin <adrian@ubergeeks.com>
To: cyber@ecst.csuchico.edu
cc: grog@lemis.com, netbsd-advocacy@NetBSD.ORG, FreeBSD-advocacy@FreeBSD.ORG,
        advocacy@openbsd.org
Subject: Re: Merging Net/Free/Open-BSD together against Linux
In-Reply-To: <19981129182228.29992.qmail@measles.ecst.csuchico.edu>
Message-ID: <Pine.BSF.3.96.981129161738.867A-100000@lorax.ubergeeks.com>
MIME-Version: 1.0
Content-Type: TEXT/PLAIN; charset=US-ASCII

On Sun, 29 Nov 1998 cyber@ecst.csuchico.edu wrote:

> ADRIAN Filipi-Martin wrote:
> ] 
> ] 	Compatability at the ports level could surely be improved, but
> ] don't you think improving compatability at the /usr level would ease
> ] improving the compatability of the ports area?  Without addressing /usr,
> ] you are faced with manging several sets of patches for many ports. 
> ] Unifying /usr would restrict the multiple patch problem to kernel/system
> ] API specific packages. 
> ] 
> 
> NOTE: I dont even necessarily support this off the cuff scheme:
> 
> One approach that would realisticly improve chances could be as follows:
> 
> 1. Agree on a new API
> 	Adjust toolchains/kernel/libs to support this API
> 	This API would exist as a binary emulation where appropriatee.
> 	The same API would then exist across all platforms and
> 	binaries written on one would work on all.
> 	(Note: we havent modified any programs yet.)

	While, I think the rest of the points in the list were fine, I
really want to stay away form anything kernel related.  This would also
include the toolchain to some degree.  The toolchain could be just as deep
a bog as the kernel with respect to generating a consensus.

	I'm thinking more along the lines of libc level compatability.  If
some code uses a system specific syscall, it would have to be left upto
the particular core team to take care of it.  That's not a huge burden. 
They are already doing this.
	
	Adrian
--
[ adrian@ubergeeks.com -- Ubergeeks Consulting -- http://www.ubergeeks.com/ ]