by homeworld.cygnus.com with SMTP; 29 Nov 1998 18:22:30 -0000
Message-ID: <19981129182228.29992.qmail@measles.ecst.csuchico.edu>
From: cyber@ecst.csuchico.edu
Subject: Re: Merging Net/Free/Open-BSD together against Linux
To: adrian@ubergeeks.com
Date: Sun, 29 Nov 1998 10:22:28 -0800 (PST)
Cc: grog@lemis.com, netbsd-advocacy@NetBSD.ORG, FreeBSD-advocacy@FreeBSD.ORG,
  advocacy@openbsd.org
In-Reply-To: <Pine.BSF.3.96.981129104704.388A-100000@lorax.ubergeeks.com> from "ADRIAN Filipi-Martin" at Nov 29, 98 11:07:52 am
MIME-Version: 1.0
Content-Type: text/plain; charset=US-ASCII
Content-Transfer-Encoding: 7bit

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

2. Get vendors to support this API
   Migrate the best of the best programs to this API.
	We get unified vendor support.  Vendors only have to support 
	the *BSD format.
	Note: programs that understand the low lying bits would need
	an abstraction layer (which should have been there anyway).
	Users now have a choice between different versions of a
	program.  i.e.: NetBSD ftp vs FreeBSD ftp.

3. Migrate the ports (packages under NetBSD) to the new API
	Migrate the old and put all the new under this API.
	This will reduce the overall work necessary to get programs
	for the *BSD community.
	We should start seeing critical mass here.
	Note: vendor support was pushed early due to their ramp up
	times.  The selling point to them is one API for 3 OSs.

4. As we get more programs under the new API it will then be selected
	as the default by the toolchain (OSs not fully ported would just
	add top level flags to specify the old behavior until everything
	is ported.  Yes, this will require a lot of makefile changes.)

Can this fail? Yes, most definitely.
Can this work? Maybe.

The difference is engineering factors vs developer factors.  A
technically feasible solution will not always be implementable.
NIH continually gets in the was as well as different design goals.

However, even if it only makes it as far as #2 its a win.  We get
unified vendor support, which is what we want.  Even if there are
subtle differences to the userland if i can go out and buy
WordPerfect and only have to tell them i need it for *BSD/i386
without them worrying about will my subcamp of BSD have enough mass
to make it worth their while to support it specifically, then
its a win.

-=erik.


-- 
Hack the Media.                                       Life is an illusion.