From owner-freebsd-current@FreeBSD.ORG Tue Nov 18 18:53:14 2003 Return-Path: Delivered-To: freebsd-current@freebsd.org Received: from mx1.FreeBSD.org (mx1.freebsd.org [216.136.204.125]) by hub.freebsd.org (Postfix) with ESMTP id EA54616A4CE; Tue, 18 Nov 2003 18:53:14 -0800 (PST) Received: from dyson.jdyson.com (dsl-static-206-246-160-137.iquest.net [206.246.160.137]) by mx1.FreeBSD.org (Postfix) with ESMTP id 1DA8343FA3; Tue, 18 Nov 2003 18:53:13 -0800 (PST) (envelope-from toor@dyson.jdyson.com) Received: from dyson.jdyson.com (localhost [127.0.0.1]) by dyson.jdyson.com (8.12.8/8.9.3) with ESMTP id hAJ2rAXQ001199; Tue, 18 Nov 2003 21:53:10 -0500 (EST) (envelope-from toor@dyson.jdyson.com) Received: (from toor@localhost) by dyson.jdyson.com (8.12.8/8.12.8/Submit) id hAJ2rAWO001198; Tue, 18 Nov 2003 21:53:10 -0500 (EST) Message-Id: <200311190253.hAJ2rAWO001198@dyson.jdyson.com> In-Reply-To: <200311190021.hAJ0Lj5e000832@dyson.jdyson.com> from "dyson@iquest.net" at "Nov 18, 2003 07:21:45 pm" To: dyson@iquest.net Date: Tue, 18 Nov 2003 21:53:10 -0500 (EST) From: dyson@iquest.net X-Mailer: ELM [version 2.4ME+ PL54 (25)] MIME-Version: 1.0 Content-Type: text/plain; charset=US-ASCII Content-Transfer-Encoding: 7bit cc: dyson@iquest.net cc: current@freebsd.org cc: "M. Warner Losh" Subject: Re: Unfortunate dynamic linking for everything X-BeenThere: freebsd-current@freebsd.org X-Mailman-Version: 2.1.1 Precedence: list Reply-To: dyson@iquest.net List-Id: Discussions about the use of FreeBSD-current List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 19 Nov 2003 02:53:15 -0000 Gang, I suspect that my position has been expressed adequately. Further discussion might become divisive, but a decision that incurs the overhead of performance or a rebuild on the default user base seems wrong (JUST MY OPINION.) It took ALOT of WORK (person years) to make FreeBSD perform as well as it does. BOTH the add-on crew and the general user base can have the performance and feature set without rebuilding, but the decision was apparently made to impose the cost of performance or rebuild and binary maintenance on the default user base. It makes more sense to have appropriately upgraded the system (by the NSS project) to avoid the performance hit by others and also provide the feature set. Apparently (I haven't fully analysed this) implementing the dlopen stuff for non-dynamic programs would have helped to mitigate this issue. (It might have put more burden on the NSS/PAM/whatever addon projects, but those are indeed addons that shouldn't take ANYTHING away from the rest of the project.) I am suggesting that the NSS crew and those who are concerned about performance can BOTH have the results that they wish for. 'All or nothing' creates divisiveness, and in these discussions it is TOO EASY to fall into that trap. I am not suggesting the loss of the new NSS stuff, but also suggest that ANY loss of performance when it can be avoided, is unwise. My opinion is known, and hopefully the loss of hard earned performance with person-years of work won't happen as time goes on. A little loss isn't that bad, but how much loss is too much loss (esp when not necessary?) John