Return to BSD News archive
Newsgroups: comp.os.386bsd.misc Path: sserve!newshost.anu.edu.au!harbinger.cc.monash.edu.au!newshost.marcam.com!news.mathworks.com!noc.near.net!monk.proteon.com!jfw From: jfw@proteon.com (John Woods) Subject: Re: To Merge or Not to Merge *BSD. What does it really mean? Message-ID: <D2KKxB.Euq@proteon.com> Sender: news@proteon.com Nntp-Posting-Host: kerplop.proteon.com Organization: Proteon, Inc., Westborough, Ma. References: <3enogm$5l7@fw.novatel.ca> <3f1h83$hgl@newshost.lanl.gov> <3f253c$es0@agate.berkeley.edu> <3f9hst$q8n@idiom.com> <3fbgok$s0i@ivory.lm.com> Date: Tue, 17 Jan 1995 21:55:59 GMT Lines: 28 peterb@telerama.lm.com (Peter Berger) writes: >In article <3f9hst$q8n@idiom.com>, David Muir Sharnoff <muir@idiom.com> wrote: >>The FreeBSD camp should consider it a bug whenever a NetBSD program >>fails to compile or its binary to run. >>The NetBSD camp should consider it a bug whenever a FreeBSD program >>fails to compile or its binary to run. >This is the single most intelligent thing that has been said in the >entire discussion. The problem with the above statement is that both NetBSD and FreeBSD camps plan to do some of their own innovations, which will probably eventually lead to enough divergence that there will exist NetBSD programs that it is impractical for FreeBSD to support and vice versa. What makes more sense is for both camps to agree on a common Application Binary Interface, so that it will be practical to run common applications on either OS platform; kernel system calls that aren't developed jointly (or at least quickly adopted by the other platform) should be kept out of the common ABI, and some effort should be made to ensure that applications don't use such extensions casually (hence, try not to invent a "better" open() system call). It's unfortunate that the shared library implementations are different, since that's a cool way to achieve a clean ABI (IMHO, anyay). Actually, several ABIs are required, since neither port is limited to the 386. In terms of compilation, both camps have (I believe) the same committment to maintain and improve the POSIX compliance of 4.4BSD, so for the most part that should take care of itself.