From owner-freebsd-current@FreeBSD.ORG Wed Nov 19 06:11:05 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 EB9D416A4CE for ; Wed, 19 Nov 2003 06:11:04 -0800 (PST) Received: from gw.celabo.org (gw.celabo.org [208.42.49.153]) by mx1.FreeBSD.org (Postfix) with ESMTP id EBFB643FD7 for ; Wed, 19 Nov 2003 06:11:00 -0800 (PST) (envelope-from nectar@celabo.org) Received: from madman.celabo.org (madman.celabo.org [10.0.1.111]) (using TLSv1 with cipher DHE-RSA-AES256-SHA (256/256 bits)) (Client CN "madman.celabo.org", Issuer "celabo.org CA" (verified OK)) by gw.celabo.org (Postfix) with ESMTP id 6A3665489C for ; Wed, 19 Nov 2003 08:11:00 -0600 (CST) Received: by madman.celabo.org (Postfix, from userid 1001) id 0ABC16D455; Wed, 19 Nov 2003 08:11:00 -0600 (CST) Date: Wed, 19 Nov 2003 08:10:59 -0600 From: "Jacques A. Vidrine" To: current@freebsd.org Message-ID: <20031119141059.GA14308@madman.celabo.org> References: <200311182307.hAIN7Wpm000717@dyson.jdyson.com> <20031118164905.R35009@pooker.samsco.home> Mime-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline In-Reply-To: <20031118164905.R35009@pooker.samsco.home> X-Url: http://www.celabo.org/ User-Agent: Mutt/1.5.4i-ja.1 Subject: Re: Unfortunate dynamic linking for everything X-BeenThere: freebsd-current@freebsd.org X-Mailman-Version: 2.1.1 Precedence: list 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 14:11:05 -0000 [cc: dropped] I suppose I should comment on this thread, since I'm closely related to at least two of the rationales mentioned for moving towards an all-dynamically-linked system. (I would prefer to stay out of this thread. In my mind we've had all these arguments in various forums months ago and the issue was put to rest.) On Tue, Nov 18, 2003 at 05:06:06PM -0700, Scott Long wrote: > 2. NSS support out-of-the-box: Again, this is a user-experience issue > in that forcing NSS users to recompile world was seen as a potential > roadblock to them. Some followups mentioned that a different implementation of NSS would not require dynamically linked binaries. This is technically true. Certainly, I explored that avenue. But practical considerations made that alternative a poor choice. Supporting NSS really also means supporting (in as much as possible) the existing base of NSS modules. These modules were all designed to be loaded by libc and invoked in-process. (nscd doesn't do what some seem to think it does, and in practice it is not well-loved.) Existing NSS modules also shaped some other decisions that I made (such as API entry points and thread awareness or lack thereof). Breaking with the fundamental designs of NSS as found on Solaris and Linux means practically starting from scratch when `porting' NSS modules. I'm sure someone more clever and with more time could make it work out-of-process. Based on my experience, I think the result would be overengineered. *shrug* Finally, if we could call `dlopen' from statically-linked binaries, this wouldn't be an issue. I'd really like to see dlopen support for statically-linked binaries, for NSS and many other applications. > 3. Binary security updates: there is a lot of interest in providing a > binary update mechanism for doing security updates. Having a dynamic > root means that vulnerable libraries can be updated without having to > update all of the static binaries that might use them. Actually, not only binary security updates but any security updates, or bug fixes for that matter. If there is a bug in a library, fixing that bug on your system is much more straightforward if everything is dynamically linked. It is much easier to rebuild libc or libcrypto and restart applications then to have to go through an entire `make world'. It can be hard for many administrators to avoid `make world', because it is not always easy to ascertain what applications are using what APIs and libraries. There's been a lot of talk about performance, but for my environment all the workhorse applications are already dynamically linked. I'd guess that is the case for most FreeBSD users. And of course, most FreeBSD binaries--- in the base system, in ports, and commercially available--- are already dynamically linked. For the minority of users that it actually has a performance impact (show of hands?), of course they are sophisticated enough to build the affected binaries statically. Unless we are talking about /bin/sh, they probably already have to go through special measures to get a statically linked binary. Cheers, -- Jacques Vidrine NTT/Verio SME FreeBSD UNIX Heimdal nectar@celabo.org jvidrine@verio.net nectar@freebsd.org nectar@kth.se