Path: utzoo!utgpu!news-server.csri.toronto.edu!rpi!think.com!zaphod.mps.ohio-state.edu!pacific.mps.ohio-state.edu!linac!att!ucbvax!ucsd!celit!dave
From: dave@fps.com (Dave Smith)
Newsgroups: comp.unix.internals
Subject: Re: Shared libraries are not necessary
Keywords: ISC i386 shared libraries
Message-ID: <17941@celit.fps.com>
Date: 22 May 91 18:58:58 GMT
References: <201@titccy.cc.titech.ac.jp> <1991May17.053735.2123@kithrup.COM> <210@titccy.cc.titech.ac.jp> <1991May21.170435.22610@kithrup.COM> <223@titccy.cc.titech.ac.jp>
Sender: daemon@fps.com
Reply-To: dave@fps.com (Dave Smith)
Organization: FPS Computing Inc., San Diego CA
Lines: 39

In article <223@titccy.cc.titech.ac.jp> mohta@necom830.cc.titech.ac.jp (Masataka Ohta) writes:
>1.5Mbyte per X application? The code segment size of fully linked xterm
>(a rather large application) is less than 600KB on SONY NWS3860 (the
>machine, on which I measured FACTS and post the result with sufficient
>figures). On sun4 (SunOS3.2), it is about 450KB.
>
>So far, What I write is fact.
>

Excuse me?  SunOS 3.2 on a Sun 4 (i.e. SPARC?)?  I don't think so.  The
statically linked X11R4 xterm for SunOS 3.4 on a 3/50 is 524288 bytes.
On a Sun 4 running SunOS 4.1.1 the X11R4 xterm, dynamically linked is
188416 bytes.  This is a significant difference in my opinion.  I don't
have a statically linked Sun4 xterm lying about, so I can't do an apples
to apples comparison, but I think we can all agree that SPARC code tends
to be bigger than 680x0 code.

Furthermore, a du of /usr/bin/X11 on the Sun 3 reveals 14M of executables
and a du /usr/bin/X11 on the Sun4 reveals 3.7 M of executables, with 3
additional executables in the Sun4 directory!

This debate has gone off the edge of silliness.  Masataka, we do not live
in fantasyland where we can dismiss things because they are inelegant.
X is here to stay and so are dynamic libraries.  You can bemoan this
fact all you like, but it is nonetheless true.  The computer market
is just that, a market, driven by market forces.  The market dictates
that X is the way to do graphics.  X is large and X is bloated so the
market once again whines about disk and memory usage which dictates 
shared libraries.

I believe that we could probably develop better solutions than X and
shared libraries.  However they are SOLUTIONS.  Your "solutions" like
"Don't use such a bloated window system" solve nothing and are rightly
dismissed as being frivolous and arrogant.
--
David L. Smith
FPS Computing, San Diego        ucsd!celit!dave or dave@fps.com
"It was time to stop playing games.  It was time to put on funny hats and
eat ice cream.  Froggie played his oboe" - Richard Scarry