Date: Mon, 2 Jun 2003 15:47:34 -0700 From: Marcel Moolenaar <marcel@xcllnt.net> To: Gordon Tetlow <gordont@gnf.org> Cc: Dag-Erling Smorgrav <des@ofug.org> Subject: Re: Making a dynamically-linked root Message-ID: <20030602224734.GC1345@dhcp01.pn.xcllnt.net> In-Reply-To: <20030602214956.GG87863@roark.gnf.org> References: <20030602171942.GA87863@roark.gnf.org> <xzp4r3844eb.fsf@flood.ping.uio.no> <20030602202947.GE87863@roark.gnf.org> <xzpznl02nry.fsf@flood.ping.uio.no> <200306022125.h52LPhhc002291@apollo.backplane.com> <20030602214956.GG87863@roark.gnf.org>
next in thread | previous in thread | raw e-mail | index | archive | help
On Mon, Jun 02, 2003 at 02:49:56PM -0700, Gordon Tetlow wrote: > On Mon, Jun 02, 2003 at 02:25:43PM -0700, Matthew Dillon wrote: > > > > In anycase, this is a convenience vs performance issue. I think a number > > of solutions should be investigated before people give up and start > > hacking dynamic vs static binaries. For example, a lot of startup delay > > is due to disk waiting (since nothing is in the disk cache at system > > start!). Running certain daemon startups in the background might yield > > a significant overall improvement in startup times. > > Actually, it was a diskless boot, so it was in the system cache. =) I > know this is a rigged demo, but the point is the same, yes, it's slower, > but we also have a huge gain from going to a dynamically linked world. > It would also serve as encouragement to get things like pre-binding and > caching working. Please do not rectify or relativate the performance loss of a 100% shared world by hinting towards pre-binding and/or caching. If the success of a 100% shared world depends on prebinding, then I suggest we abandon the attempt right here, right now. I don't think it is realized how big a wormhole prebinding really is. I support a 100% shared world, but we should not abandon staticly linked /bin and /sbin. Let's just create the mechanics to allow one to choose for whatever reason one might have to choose one way or the other and let's make sure that we nailed it completely. I don't want to see any entries in UPDATING to overcome switching from one to the other or to describe the steps required to do a trivial source upgrade. I suggest we get the functionality in without actually changing the default. We can change the default anytime after that when we are confident that we covered everything and have understanding of the overall impact of switching... My $0.02, FWIW ($0.02 presumably) -- Marcel Moolenaar USPA: A-39004 marcel@xcllnt.net
Want to link to this message? Use this URL: <https://mail-archive.FreeBSD.org/cgi/mid.cgi?20030602224734.GC1345>