From owner-freebsd-current@FreeBSD.ORG Fri Nov 21 15:38:51 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 3A6FC16A4CE for ; Fri, 21 Nov 2003 15:38:51 -0800 (PST) Received: from kientzle.com (h-66-166-149-50.SNVACAID.covad.net [66.166.149.50]) by mx1.FreeBSD.org (Postfix) with ESMTP id 2135443FB1 for ; Fri, 21 Nov 2003 15:38:50 -0800 (PST) (envelope-from kientzle@acm.org) Received: from acm.org ([66.166.149.54]) by kientzle.com (8.12.9/8.12.9) with ESMTP id hALNcnkX035319; Fri, 21 Nov 2003 15:38:49 -0800 (PST) (envelope-from kientzle@acm.org) Message-ID: <3FBEA209.20006@acm.org> Date: Fri, 21 Nov 2003 15:38:49 -0800 From: Tim Kientzle User-Agent: Mozilla/5.0 (X11; U; FreeBSD i386; en-US; rv:1.4) Gecko/20031006 X-Accept-Language: en-us, en MIME-Version: 1.0 To: Leo Bicknell References: <200311182307.hAIN7Wpm000717@dyson.jdyson.com> <20031118164905.R35009@pooker.samsco.home> <20031119141059.GA14308@madman.celabo.org> <20031119141950.GA95734@ussenterprise.ufp.org> In-Reply-To: <20031119141950.GA95734@ussenterprise.ufp.org> Content-Type: text/plain; charset=us-ascii; format=flowed Content-Transfer-Encoding: 7bit cc: freebsd-current@freebsd.org Subject: Re: Unfortunate dynamic linking for everything X-BeenThere: freebsd-current@freebsd.org X-Mailman-Version: 2.1.1 Precedence: list Reply-To: kientzle@acm.org List-Id: Discussions about the use of FreeBSD-current List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Fri, 21 Nov 2003 23:38:51 -0000 Leo Bicknell wrote: > To boot a machine into single user mode you need a kernel, init, > and /bin/sh (minimally). It would seem to me that alone is a good > argument for those three things to be static. You need a static shell, yes. That does not have to be /bin/sh. init does prompt, and /rescue/sh is (and always will be) static. As I pointed out earlier, some of the heat here comes from the fact that /bin/sh is currently overloaded: * It is the default system script interpreter, used by the rc scripts and many other things. As such, it must start quickly. * It is the default user shell for many users. As such, it must support NSS. So far, I haven't seen anyone in this thread seriously argue against either of these points. Today, these two issues are somewhat contradictory. Right now, NSS requires dlopen() which requires dynamic linking which negatively impacts startup. There have been a lot of proposed solutions: * Rewrite NSS to not require dlopen(). A lot of people have suggested this, but Jacques made an important point about long-term support. In short, this would probably just gaurantee that our NSS is perpetually out-of-date, since it would become a major headache to port existing NSS modules. * Rewrite dlopen() to not require dynamic linking. There were some patches for this submitted at one point. As I recall, the people who looked at them were not entirely comfortable with them. (I'd be concerned about version conflict problems with this approach: what happens when a dynamically-loaded NSS module refers to a libc function? Does that get resolved to the already statically-linked version? Or does another copy of libc get dynamically linked with potential version conflicts? Does anyone know?) I personally think this is worth researching, though I have my doubts. * Don't support NSS in /bin/sh. This essentially amounts to: Don't use /bin/sh as an end-user shell. Given the number of commits to improve command-line usage of /bin/sh, I think it's clear that a lot of people do rely on /bin/sh as a user shell. * Change the default script interpreter for rc and such. (e.g., use a statically-linked, optimized /sbin/sh for that purpose.) Again, not particularly attractive, and it certainly breaks a lot of administrator's assumptions. * Make dynamic linking faster. As many people have pointed out, FreeBSD's dynamic linking is slower than it should be. Advances here would benefit Mozilla, OpenOffice, KDE, Gnome, Apache, Perl, bash, TCL, Python, PHP, etc. (I believe these are all slower to start on FreeBSD than on Linux, for example.) This is a major end-user experience issue that I find much more compelling than anything mentioned so far. I personally find OpenOffice only barely usable on FreeBSD, in large part because it takes so long to open. I suspect that most of our users would gladly give up a few seconds booting (or a few minutes from portupgrade or buildworld) if they could have Mozilla and OpenOffice open a few seconds faster. Benchmarks do not necessarily reflect user experience. As many people have pointed out, there are other advantages and disadvantages to dynamic linking: library upgrades are simplified, disk requirements are reduced, memory usage is less efficient, system upgrade and repair is more complicated, etc., but I think the above summarizes the issues that people seem to really care about. Tim