From owner-freebsd-hackers Sun Feb 26 14:35:58 1995 Return-Path: hackers-owner Received: (from majordom@localhost) by freefall.cdrom.com (8.6.9/8.6.6) id OAA08897 for hackers-outgoing; Sun, 26 Feb 1995 14:35:58 -0800 Received: from trout.sri.MT.net (trout.sri.MT.net [204.182.243.12]) by freefall.cdrom.com (8.6.9/8.6.6) with ESMTP id OAA08889 for ; Sun, 26 Feb 1995 14:35:53 -0800 Received: (from nate@localhost) by trout.sri.MT.net (8.6.9/8.6.9) id PAA02352; Sun, 26 Feb 1995 15:38:35 -0700 Date: Sun, 26 Feb 1995 15:38:35 -0700 From: Nate Williams Message-Id: <199502262238.PAA02352@trout.sri.MT.net> In-Reply-To: terry@cs.weber.edu (Terry Lambert) "Re: Binary compatibility with NetBSD" (Feb 26, 1:41pm) X-Mailer: Mail User's Shell (7.2.5 10/14/92) To: terry@cs.weber.edu (Terry Lambert) Subject: Re: Binary compatibility with NetBSD Cc: jbeukema@hk.super.net, freebsd-hackers@FreeBSD.org Sender: hackers-owner@FreeBSD.org Precedence: bulk > > > > To not maintain binary compatability *including* shared images would > > > > be folly. > > > > > > Bravo! I agree completely. We do not need one more fragmented, > > > incompatible flavour. > > > > I'm certain that Jordan would be willing to let you do all the work > > required to keep the differnt OS's libraries in sync with the FreeBSD > > versions. I suspect it would only amount to 4-6 hours/day on the avg. > > guaranteeing there are no inconsitancies and making sure the changes > > made don't break anything. > > > > Those who 'agree' must also be willing to put in the time necessary to > > make those agreements happen. > > Far be it for me to be the one to blindly suggest that either NetBSD > or FreeBSD give up control of libc to one camp or another. Let's assume for a moment that one group or the other 'gives up control' on ALL (remember, even things like libkvm are still shlibs). That means the one person *must* at all times follow each and every commit message that is done by NetBSD (since we don't have the ability to track the changes except by seeing the commit messages) and merge those changes into FreeBSD. If that isn't done, there is no way of tracking errors, and with something so absolutely critical to the system like the libraries, it is essential that changes can be tracked. After these changes are integrated into the FreeBSD libraries, then this person must guarantee that the libraries changes do not require any changes to the corresponding utilities. And those differences don't require changes to .... All of a sudden we've got 2 full-time people tracking NetBSD library changes and nothing else. Are you willing to be one of the two people? > Is this is technical issue (if so, what are the pro's and con's) or > is this nothing but a control issue? It's much more than a control issue. As I understand it, FreeBSD's internationalization support is much better than NetBSD's. There will always be better things in the FreeBSD libraries and worse things. Giving one up for the other is simply asking for more work than it is worth. Nate