Re: Bug#72140: Setting up libraries too slow
This thread has already gone on too long, but I'll chip in my two cents'
worth. Basically, it's a minor, but nice feature. Now, for the reactions...
Previously Simon Richter wrote:
>> Nope, this involves manual action by root.
On Sat, Sep 23, 2000 at 12:21:32AM +0200, Wichert Akkerman wrote:
> Which is bad why?
I would say that the more manual action is necessary to maintain a
system, the less easily maintainable the system is. This seems to
me much like the usage of package managers to automatically resolve
dependencies between various pieces of software.
Previously Simon Richter wrote:
>> Well, this is the way a cache is supposed to work: It speeds up things,
>> but it doesn't get in the way of normal operation.
On Sat, Sep 23, 2000 at 12:21:32AM +0200, Wichert Akkerman wrote:
> Right, so not having the dynamic linker update it doesn't hurt at all.
Previously Simon Richter wrote:
>> I wouldn't consider that "needlessly smart" but a minimal requirement.
On Sat, Sep 23, 2000 at 12:21:32AM +0200, Wichert Akkerman wrote:
> It's not a requirement at all since it's only a cache as you mentioned.
This is largely a matter of taste. I'd tend to fall on the side of
integrating the cache updates into the dynamic linker. I don't have
concrete suggestions as to how this should proceed and so on, but
after dealing with some of the "smarter" dynamic linkers from SGI
and Sun, ldconfig seems very much like a kludge. On the other hand,
I don't actually care that much about it, since most of the work
(outside of /usr/local) is all done by scripts, and I don't bother
watching any of the long-running junk run. Linux multitasks, and
so do I.
Previously Simon Richter wrote:
>> drwxrwsr-t 47 root dist 1536 Jul 26 22:39 /usr/local/dist/DIR/
On Sat, Sep 23, 2000 at 12:21:32AM +0200, Wichert Akkerman wrote:
> I do hope not all users are in that dist group..
I don't want to sound tit-for-tat here (but I don't seem to be able
to avoid it at this rate), but it seems appropriate to me to grant
some level of trust to users. It doesn't take much more than a forkbomb
or excessive disk usage to make a machine unusable in many instances;
a little directory like that doesn't represent a a major upgrade in
the level of trust granted.
Previously Simon Richter wrote:
>> It is supposed to update its cache if it is outdated IMO.
On Sat, Sep 23, 2000 at 12:21:32AM +0200, Wichert Akkerman wrote:
> Point me to any standards doc that says a dynamic linker should do
> anything more then dynamic linking..
Actually, the dynamic linker, aside from the link scriptability, is
pretty bare bones. Various schemes have been devised for integrating
programming language support into linkers, from link-time code
generation to linker support for nonlocal variable access, link-time
typechecking, and link-time class descriptor allocation. Java seems
to do a few of these in its linker/loader whatever. I don't believe
there are many, if any standards on this issue, but to my eyes, cache
invalidation in the dynamic linker seems like a very minor feature.
Again, take this with a grain of salt; I'm not really trying to
advocate it, but rather put a different perspective on it (i.e. that
it's a minor feature, but good thing to have).
Cheers,
Bill
--
"Memory is like an orgasm.... it's better when you don't have to fake it"
-- Seymour Cray
Reply to: