Date: Tue, 18 Nov 2003 18:27:07 -0700 (MST) From: Scott Long <scottl@freebsd.org> To: Colin Percival <colin.percival@wadham.ox.ac.uk> Cc: current@freebsd.org Subject: Re: Unfortunate dynamic linking for everything Message-ID: <20031118182148.P35215@pooker.samsco.home> In-Reply-To: <5.0.2.1.1.20031119000628.03199b18@popserver.sfu.ca> References: <200311182307.hAIN7Wpm000717@dyson.jdyson.com> <5.0.2.1.1.20031119000628.03199b18@popserver.sfu.ca>
next in thread | previous in thread | raw e-mail | index | archive | help
On Wed, 19 Nov 2003, Colin Percival wrote: > At 17:06 18/11/2003 -0700, Scott Long wrote: > >Our rationale for encouraging Gordon is as follows: > > > >1. 4.x upgrade path: As we approach 5-STABLE, a lot of users might want > > to upgrade from 4-STABLE. Historically in 4.x, the / partition has > > been very modest in size. One just simply cannot cram the bloat that > > has grown in 5.x into a 4.x partition scheme. Of course there is the > > venerable 'dump - clean install - restore' scheme, but we were looking > > for something a little more user-friendly. > > Of course, making / dynamic results in added complication of removing > old libraries from /usr/lib, now that some of them have moved to /lib... The magic for solving this exact problem already exists in the source upgrade path. Fixing this for the binary upgrade path (via sysinstall) is still under investigation. It is mitigated by the fact the systems that are binary-upgraded have their library search path set to look at /lib first. Leaving around stale libraries is of course bad, and we will hopefully come up with a solution soon. > > >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. > > As far as I'm concerned, this is a non-issue. Identifying which static > binaries need to be replaced is now a solved problem, replacing them is > easy, and if binary patches are used, there is effectively no impact on > bandwidth usage either. Bandwidth is still a concern for a lot of people, and this has the potential to save significant bandwidth in many situations. > > On the issue of performance, however: I know people have benchmarked > fork-bombs, but has anyone done benchmarks with moderate numbers of > long-lived, library-intensive, processes? It seems to me that dynamic > linking could have caching advantages. > > Colin Percival > > > I can't comment well here. To my untrained mind, I would think that more sharing of libc would help with memory pressure, but I'm just making simple assumptions. Scott
Want to link to this message? Use this URL: <https://mail-archive.FreeBSD.org/cgi/mid.cgi?20031118182148.P35215>