Date: Sun, 29 Nov 1998 10:22:28 -0800 (PST) From: cyber@ecst.csuchico.edu To: adrian@ubergeeks.com 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 Message-ID: <19981129182228.29992.qmail@measles.ecst.csuchico.edu> 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
next in thread | previous in thread | raw e-mail | index | archive | help
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. To Unsubscribe: send mail to majordomo@FreeBSD.org with "unsubscribe freebsd-advocacy" in the body of the message
Want to link to this message? Use this URL: <https://mail-archive.FreeBSD.org/cgi/mid.cgi?19981129182228.29992.qmail>