Path: utzoo!utgpu!news-server.csri.toronto.edu!cs.utexas.edu!sun-barr!olivea!decwrl!pa.dec.com!wsl.dec.com!mcnally
From: mcnally@wsl.dec.com (Mike McNally)
Newsgroups: comp.unix.internals
Subject: Re: Shared Libraries YO!!!
Message-ID: <1991Jun19.085451@wsl.dec.com>
Date: 19 Jun 91 15:54:51 GMT
References: <1991Jun10.154811.11965@infonode.ingr.com> <4945@skye.ed.ac.uk> <337@titccy.cc.titech.ac.jp>
Sender: news@pa.dec.com (News)
Reply-To: mcnally@wsl.dec.com
Distribution: comp
Organization: DEC Western Software Lab
Lines: 69

Why can't I resist this stupid thread?

In article <337@titccy.cc.titech.ac.jp>, mohta@necom830.cc.titech.ac.jp (Masataka Ohta) writes:
|> So far, no one has shown any usable data on how much code is shared with
|> shared libraries under their usual load.

Well, Masataka, *you* might not be able to use the numbers, but I guess I'm
not surprised at that.  Several people have posted numbers that seemed 
pretty clear to me.

|> So, perhaps, shared libraries dose not help to decrease memory consumption
|> so much.

Perhaps, perhaps not.  I like that hard, purely technical wording 
too: "not...so much".

|> 
|> On the other hand, I showed a measurement result of increase of memory
|> consumption based on some configuration (not my own configuration
|> but other people's typical configuration).

You never convinced me that your sample set was representative of
typical usage.  You ask everybody to "be technical", so now I want
some evidence that your survey of workstation users is meaningful.

|> As for the software upgrade flexibility, its only example, /etc/hosts to
|> DNS, was denied . . . 
|> So, it should be concluded that there is no usable software upgrade
|> flexibility in shared libraries.

Geez.  OK, here's another example.  I was working on debugging a system
that had a malloc/free problem.  There were several programs that 
exhibited the problem, and all were big.  I was greatly aided in the
debugging effort by being able to re-build libc over and over again with 
versions of malloc which included debug scaffolding.  The time it took 
to rebuild the shared libc was minimal compared to the time it took
to re-link all the programs.

Using your reasoning, we're back to "no conclusion", I guess.  If I find 
another example, I'll be up 2-1; will it them be appropriate that there is
a usable software upgrade flwexibility?

This seems so obvious it's amazing that you don't believe it.  Do you think
it's impossible that a vendor might make performance enhancements to a 
standard library?  If so, wouldn't it be a lot easier to ship just the
library rather than all applications?  Have you ever been in a position to
worry about distribution costs, or, indeed, given this statement:

|>           Are there any natural and common configuration where disk
|> consumption really matters?

have you ever been in a position to worry about costs at all?  Did you buy
the machine you're using?  What's the budget of the organizatioon that did?
Is it infinite?

There are lots of people in this world (LOTS) using small 386-based PC systems.
From real experience, I know that many of these people are *very* price
sensitive.  If a vendor can deliver a big operating system like UNIX and
use substanntially less disk space, these people are happy; they might be
able to get away with *one* disk partitioned for UNIX and DOS.

Oh, but I guess you'll say these configurations are "unnatural"; I doubt you
can say they're uncommon.

-- 
* "In the Spirit as my automatics,  *                              Mike McNally
* Lystra and Zelda were one third   *                                    Coolie
* as large as the infinite Cosmos." *                  DEC Western Software Lab
*              --- D. S. Ashwander  *                       mcnally@wsl.dec.com