Subject: Re: RFC: migration to a fully dynamically linked system
To: None <firstname.lastname@example.org>
From: sudog <email@example.com>
Date: 12/21/2001 09:43:15
> Another pro you haven't mentioned is that the memory usage of programs
> /sbin and /bin will decrease in this scenario. At the moment, each of
> programs has to have a separate in-memory copy of all the bits of libc it
> cares about. If they were dynamically-linked, they could share them with
> each other and with the rest of the system. Since the programs in /bin
> especially are used quite a lot (sh, ls, cp, mv), this should be a
> noticeable win.
Not so noticeable. How many copies are running simultaneously and impact
the memory of critical server software that this would make any useful
difference in large-scale system? Besides, if static copies are noticeably
faster, then why would I (as a rhetorical virtual hoster of masses of
websites, for example) want to take a performance hit just to save a few
megabytes of RAM? I'd rather fork out some extra money for the extra ram,
pump it up to its maximum (however many gigs I can fit and are recognized)
and get the extra performance I need to make my customers happy.
Memory's cheap and can be easily upgraded. There's only so much CPU time
to go around though.
> > - Redhat 6.2 (and other Linux systems?) has /lib
> > populated with the .so files that are used by /bin
> > and /sbin (and /usr/lib contains .so files which
> > are installed in /usr/pkg/lib on NetBSD.)
And I can't count on my hands and feet the number of times that busy
(millions of hits/day) Linux systems under my care have died because
something went bad and puked all over either libc, or libc and the dynamic
linker, making the entire thing useless until someone arrived on-scene
with a boot-disk.
> Actually, I think the usual Linux arrangement is more like your option
> For instance, libcrypto is in /usr/lib on both RHL 7.1 and NetBSD. The
> that most Linux distributions make the "system" rather larger than we do
> > 4. Dynamically link /bin and /sbin against /lib, rest against /usr/lib
> I _think_ this is my preferred option, but not by much.
Linux is Not The Right Way To Do things. Don't take me down the garden
path and bend me over a barrel by going all-dynamic. I'll just migrate my
systems at each upgrade to some other OS.
But then again, that may be just me. :)