> (let the flood gates open)

Well, good thing I stopped at the gas station on the way home...  8-)


More seriously, I think this is a problem that should be solved, and I
lean towards solution 3 as well.  It's the most sane long-term, in my
opinion.


At Fri, 21 Dec 2001 01:20:14 +0000 (UTC), "Luke Mewburn" wrote:
>   3. Dynamically link everything against /lib
> 
> 	Provide /lib, which contains /lib/ld.elf_so and all of the
> 	.so* files from /usr/lib.  /usr/lib still contains the .a,
> 	_p.a, and _pic.a libraries.  Convert /usr/libexec/ld.elf_so
> 	to a symlink to /lib/ld.elf_so.

uh, well, if keeping consistent w/ the filenames used in the rest of
the system, why not /libexec/ld.elf_so?


> 	Dynamically link all of /bin and /sbin and the other bits of
> 	the tree which are currently statically linked, against /lib.

uh, excluding what?  there _have_ to be _some_ exclusions, like i'd
bloody well hope 'init' isn't dynamically linked.  8-)

That does restrict 'init' from e.g. knowing about some mechanisms of
getting passwords (no PAM for root for secure console access! 8-), but
if you don't do this I don't see how you can have sane recovery.


> 	Provide an optional recovery mechanism such as /stand/{,s}bin
> 	which contains statically linked versions of some (or all) of
> 	the programs in /{s,}bin.

what's the thought of how to invoke the recovery mode?  (can't invoke
sh for rc, time to recover?)  I think the possibility of a special
'recovery kernel' is losing.  (If you're the klutz who rm'd libc.so,
what are the odds you've got a correct recovery kernel?  8-)

I think some thought has to be put into the set of programs for
recovery.  Maybe it's the current set of /sbin & /bin, maybe it's more
or less.


> 		- many people have concerns about this based on prior
> 		  experience (or folklore) about trashing ld.elf_so
> 		  and resulting in an unusable system. This is what
> 		  providing recovery tools helps.

These are valid concerns, and (at least in my case) based on
experience rather than folklore.  8-)


> 		- dynamic linked applications apparently run slower
> 		  than statically linked applications.
> 		  Adding support for "prebinding" (in the newer
> 		  binutils toolchain for some platforms) alleviates
> 		  most (if not all) of this.

s/apparently//

Does pre-binding do anything to touch the 'runs slower' problem?  (I
thought it just helped -- but did not completely address -- the
'starts slower' problem.)



From where I sit, just to be up front about it:

* the system needs to continue supporting creation of new
statically-linked binaries which have normal basic functionality
(i.e. passwd file and group lookups, DNS, etc.) that you'd expect.  At
the very least, you probably want people to be abile to run SPEC
statically-linked.  8-)

* (with the same caveat) it should remain possible to build a complete
system statically, or to build parts of the system statically as is
currently done.  (You don't like it?  Don't do it.  Oh, you wanted
those fancy new features?  You chose to not enable them; feel free to
enable them at your convenience.  8-)



Personally, on some systems (mostly, systems where i've got root on
NFS), I've been using completely dynamically linked systems for years,
and loving it.  As long as you're careful (i have rm aliased to rm -i
everywhere 8-) it's a good choice for an individual user, and if good
recovery tools are provided I think it's a fine choice for the system
as a whole.

Really, I don't think _I'd_ mind if we wanted to move in the direction
of / & /usr on same partition.  However, I suspect I'd have little
company there, and people with ancient, small disks would howl (for
good reason, I suppose; it's probably hard to replace some of them, at
this point)...


chris