[ On Saturday, February 26, 2000 at 20:42:22 (-0800), Greywolf wrote: ]
> Subject: Re: fix for databases/rrdtool
>
> # This wouldn't be an issue if the pkg system
> # allowed multiple versions of sub-components to be installed
> # simultaneously, but it doesn't (/opt here we come! ;-).
> 
> /opt has nothing to do with this.  You're thinking about the System V
> pkg* tools which _can_ maintain multiple instances of a package (if
> their config file allows it -- and not many do.)

/opt, or something very much like it (i.e. a scheme where every package
is stored in a unique directory that identifies not only the package
name, but also the release identification of said package) has
*everything* to do with allowing multiple versions of sub-components to
be installed simultaneously!  :-)  There's nothing special about the
SysV pkg* tools, or Sun's more pedantic use of them here -- lots of
software installation and distribution management systems use this same
kind of scheme.

> If /opt shows up, to be frank, I'll be among those blowing serious chunks.

Got any better ideas?  Ones that actually work in practice?  ;-)

The only solutions I've ever thought of involved having total and
complete control over the full configuration management, build, and
installation processes of all software products in use on the system.
In the end they all end up using versioning support in the filesystem or
better integrated schemes of file and directory naming schemes that
include the release identification.

In order to allow for differences in approaches taken by different
application authors you pretty well have to build them separate
sandboxes to play in (and to allow for the evolution of those processes
over time you have to have separate sandboxes for every release too) or
else you end up tearing everything they do apart and starting over from
scratch anyway.

Not only that but every "proof by working code" example of such a system
works this way (at least so far as I've ever been able to find, and I
have looked and I keep looking!).

Having some at least minimally functional form of the Plan-9 bind(2)
system call supported would make /opt-like schemes a bit more palatable,
I think....

> I would think that shared libs would help processing overall because the
> relevant pieces of oft-used code would be always in the cache.  That doesn't
> happen with static binaries (or does it?  Is the caching code smart enough
> to sum chunks of code and check against what's in core?).

I've read^Wskimmed a couple of highly technical papers recently that
seem to suggest that the processor cache is less useful than one might
think it could be in general purpose computers.

In any case on a busy system where actually sharing code pages amongst
un-related processes would seem to buy you anything at all (i.e. you'd
be paging otherwise or some such) it's extremely unlikely that you'll
ever have enough processes using the same routines often enough from the
shared pages in shared libraries to make any difference.  I.e. if your
load average is over 3 and if any of the waiting processes is not using
the same libraries as the others (and if your processor cache isn't in
the megabytes :-) then you're probably invalidating the cache on every
context switch anyway.

-- 
							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>