Path: utzoo!utgpu!news-server.csri.toronto.edu!rpi!zaphod.mps.ohio-state.edu!swrinde!elroy.jpl.nasa.gov!lll-winken!sun-barr!ccut!wnoc-tyo-news!cs.titech!titccy.cc.titech!necom830!mohta
From: mohta@necom830.cc.titech.ac.jp (Masataka Ohta)
Newsgroups: comp.unix.internals
Subject: Re: Shared Libraries YO!!!
Message-ID: <343@titccy.cc.titech.ac.jp>
Date: 24 Jun 91 05:03:57 GMT
References: <1991Jun10.154811.11965@infonode.ingr.com> <18370003@hpfcso.FC.HP.COM>
Sender: news@titccy.cc.titech.ac.jp
Organization: Tokyo Institute of Technology
Lines: 82

In article <18370003@hpfcso.FC.HP.COM>
	mjs@hpfcso.FC.HP.COM (Marc Sabatella) writes:

>> So, it should be concluded that there is no usable software upgrade
>> flexibility in shared libraries.

>OK, a potential real example:
>
>In comp.sys.hp, people have been noticing printf() prints floating point
>numbers really slowly on a 68040.  This is because the conversion routines use
>the old packed decimal instructions that no longer exist.  To fix this problem,
>all we will need to do is ship a new shared C library - no need for customers
>to recompile or relink.

It is rather a minor bug fix than a software upgrade like /etc/hosts to DNS.

I don't deny shared libraries are sometimes (but not always) useful for
minor bug fix.

>This is because the conversion routines use the old packed decimal
>instructions that no longer exist.

The real bug here is that HP used assembler (I don't think C compiler
generate packed decimal instrucitons) for the conversion in printf.

The real fix is to use C.

>>           Are there any natural and common configuration where disk
>> consumption really matters?
>
>Have you ever had to make purchasing decisions?

I am working in the campus computer center and investigating what to buy
next is one of my main job.

>  My guess is no, since this is
>incredibly common.

We think fast (and redundant) network and large (and redundant) file
servers is the way to go. On the way, we don't need shared libraries.

>Again, considering most of the world really does use X,

Consider most of the world really does use X with fast network.

>we
>are talking about an order of magnitude size savings here.  This makes a HUGE
>difference.

I personally have a workstation, on which, X11R4 is fully installed as
supplied by the vendor. Still, /usr/bin/X11 consumes only 20MB. My home
directly consumes 200MB, most of which is data (but not disk consuming
picture data). So, order of magnitude size saving on 20MB dose not matter
at all.

Moreover, I think, if disk consumption is somewhat lessed by shared
libraries, much more unnecessary X tools will be distributed by vendors,
which cancels any saving.

>As for the memory savings, well, I am still unconvinced either way.  You've
>shown one set of numbers suggesting the savings doesn't exist if all you use is
>xterm.  I have no trouble believing that.  I am one one of those who fits that
>category (OK, I also have an xclock in the corner), so I probably don't get
>that benefit.

What benefit?

What I showed is demerit of shared libraries in some cases, not lack of
benefit. On the other hand, no one showed shared libraries have benefit on
memory savings.

BTW, don't rely on xclock especially on leap year.

>But looking around me, I see that I am atypical - most people
>around here really do have lots of whizzy things up at once.

So what? In the old days, many untalented OS designers and most users of
non-UNIX OSes (that is, most users of computers) blindly beleived that file
types and logical record length and many other complicated things are good
things. They are now blindly using UNIX with thier own way.

						Masataka Ohta