Shared Libraries YO!!!

[Masataka Ohta]

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

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

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

>Argue syntax all you want.  I'd prefer to call it a "performance enhancement"
>rather than a bug fix

OK. Anyway, it is not software upgrade such ans /etc/hosts to DNS.

With shared libraries, you can do "minor improvement of libraly" (including
minor bug fix and performance enchancement) with relatively small amount of 
distributed storage.

But, amount of distributed storage dose not matter so much. Announcement,
provision, installation and customer support cost much more than media
especially with CDROMs.

>Anyhow, the point is, shared libraries may make
>distribution easier.  Bug fixes and performance enhancements happen at *every*
>release; major new pieces of functionality are relatively rare.  You tell me
>which is more important to handle transparently.

I can't understand why you mention transparency here.

You can do bug fixes and performance enhancements at *every* release without
losing transparency.

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

>Wait a minute here.  Are you saying /usr/bin/X11 consumes only 20MB with things
>built with archive libraries?  Sounds like you've just gone through it and
>deleted everything just to make your point.

No. I have four vendor standard installation options:

	1) not install X11 at all
	2) install core of X11
	3) install a little more of X11
	4) fully install X11

I choose 4, partly because someone else might want to use X11 and partly
becuase I have enough disk.

The measurement is done with SONY's NEWS-OS 4.0C. SONY is a rather active
member of X consorcium and will, I think, provide standard tools of X11.

% du /usr/bin/X11
20742	/usr/bin/X11
% ls -l /usr/bin/X11
X		muncher		startx		xev		xmj
Xnews		mwm		tterm		xeyes		xmkmf
appres		oclock		twm		xfd		xmodmap
atobm		plaid		uil		xfontsel	xmon2cfg
bdftosnf	puzzle		viewres		xgc		xpr
bitmap		resize		xauth		xgraph		xprev
bmtoa		ripxrtmetric	xbiff		xhost		xprop
editres		sessreg		xcalc		xinit		xrdb
hterm		showrgb		xcdp		xkill		xrefresh
ico		showsnf		xclipboard	xload		xsed
imake		sjx		xclock		xlogo		xset
jterm		sjxdemo		xcutsel		xlsatoms	xsetroot
listres		snmpxbar	xditview	xlsclients	xstdcmap
makedepend	snmpxconn	xdm		xlsfonts	xterm
maze		snmpxmon2	xdmshell	xlswins		xvmap
mkdirhier	snmpxperf	xdpr		xmag		xwd
mkfontdir	snmpxperfmon	xdpyinfo	xman		xwininfo
mterm		snmpxrtmetric	xedit		xmh		xwud

>My server's /usr/bin/X11 is close
>to 10 MB even with shared libraries.

Perhaps because shared libraries dose not save so much disk space, or perhaps
because your /usr/bin/X11 is deseparetely bloated with totally unnecessary
tools.

Anyway, my /usr/bin/X11 is sufficient for you as it even has xclock.

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

>Right, but again, just because no one took the trouble to do so doesn't mean
>there is never a benefit.

The problem is not that no one post the measurement result but that no one
seemed to have measured the actual merit of shared libraries on memory
saving.

Have you measure it, or are you just thinking someone should have measured it,
or are you merely using your common sense (to be scientific, you shouldn't
rely on your common sense)?

>No one denies shared libraries are unnecessary if you live your life around
>saving memory and disk space in all other ways.

I am saving memory and disk space, of course.

>There is a similar flame war in rec.bicycles over whether
>or not people should need cars.  The analagous statement being made there is,
>just make sure you live within a few miles of where you work, move every time
>your work location changes, don't engage in any social behavior that might
>require you to get from point A to B at speeds over 30 MPH, or have to cover
>distances of more than 100 miles in a day, and you'll never need a car.

Bicycles? No. I am not saying you should use slow workstations. We should
use the state of the art hardware in a reasonable way.

Haven't you played SimCity?

Using shared libraries for X is like building highways for cars.
You can't solve traffic jam problem that way. So use railways. With the
same technology level, railways have much more transportation capability.

The reality of life in Tokyo (and urban area in Japan) is that you had
better use railways (especially metros) than cars. Railways are much faster
transport than cars in Tokyo. I have had simlar experience also in Boston,
though Boston is much smaller city than Tokyo. The distance between home
and office is longer than 50 miles for large amount of people.

For longer distance, Tokyo and Osaka is connected by super express Hikari
with 250Km/h (while maximum legal speed on freeway by car in Japan is only
100Km/h), in 3 hours, which is often even faster than air plains as transport
between point A and B because airports are often located at inconvenient
locations (if you play SimCity you can understand why airports should be located
far from the center of the city).

It should be noted that cars and X promote to waste resources.

>For most people, however, that's simply not practical.

Just because a major (in case of SimCity and most cities in USA) or a vendor
(in case of window systems) dose not recognize what is good for thier
citizens or customers (some short-sighted vendors might think that
shared libraries are profittable for them becuase it accelerate waste
of resources).

						Masataka Ohta