[ On Sunday, March 18, 2001 at 04:19:22 (-0800), Charles M. Hannum wrote: ]
> Subject: Re: why /bin and /sbin static
>
> Of course there's another cost nobody has mentioned here.  Having all
> of /bin and /sbin statically linked means that upgrading libc -- e.g.
> to fix a bug or deficiency in glob(3) or fts(3) -- requires relinking
> all of those program.  Which means compiling them all from source.
> This begins to seem like a real (and quite unnecessary) pain in the ass
> after a while.

On the contrary it's far easier and safer, especially with the *BSD
build system, to re-build and re-install statically linked binaries than
it is to upgrade a shared library especially when there's little or no
absolute control over library versioning

Take for example the fear some, even experienced, developers have of
upgrading libc's major number.  There have been so many times where a
major number upgrade has been necessary due to API changes but some
developers are so paranoid about doing such an upgrade that they'd
rather introduce stupid and complex invisible interface naming tricks to
avoid what they see as a painful hassle.

Now we're stuck with a library that's got an very much more complex and
hidden internal interface than necessary and much extra crap that's not
needed on a fresh new install.  Talk about second guessing admins!

-- 
							Greg A. Woods

+1 416 218-0098      VE3TCP      <gwoods@acm.org>      <robohack!woods>
Planix, Inc. <woods@planix.com>; Secrets of the Weird <woods@weird.com>