Relay-Version: version B 2.10 5/3/83; site utzoo.UUCP
Path: utzoo!utgpu!water!watmath!clyde!rutgers!ames!xanth!kent
From: kent@xanth.UUCP
Newsgroups: comp.arch,comp.unix.wizards,comp.os.misc
Subject: Re: Free Software Foundation (was: Re: Mach, the new standard?)
Message-ID: <2473@xanth.UUCP>
Date: Thu, 17-Sep-87 16:27:55 EDT
Article-I.D.: xanth.2473
Posted: Thu Sep 17 16:27:55 1987
Date-Received: Sat, 19-Sep-87 10:06:57 EDT
References: <1665@ncr-sd.SanDiego.NCR.COM> <8579@utzoo.UUCP> <6886@eddie.MIT.EDU>
Reply-To: kent@xanth.UUCP (Kent Paul Dolan)
Organization: Old Dominion University, Norfolk Va.
Lines: 56
Keywords: cost of bloated programs
Xref: utgpu comp.arch:2090 comp.unix.wizards:3988 comp.os.misc:178
Summary: better metric

In article <6886@eddie.MIT.EDU> jbs@eddie.MIT.EDU (Jeff Siegal) writes:
>In article <8579@utzoo.UUCP> henry@utzoo.UUCP (Henry Spencer) writes:
>>[...]
>>To pick a non-GNU example, graphing the size of the ls(1) command versus
>>time is an interesting exercise, not to be recommended if you are susceptible
>>to nausea and vomiting.  To pick an example that is ready at hand, the Sun
>>3.2 ls(1) is four times the size of the V7 ls(1).  It's not four times as
>>good; the improvement in functionality might charitably be put at 25%.
>
>However, a more meaningful exercise would be to graph the cost of the
>memory used by ls(1) versus time.  This is not recommended, if you are
>likely to be nauseated by the failure of Unix developers to take best
>advantage of available "resources".
[...]
>Jeff Siegal


Not that I love jumping onto Henry's side of the fence; I still think his
criticism of RMS was out of line, but...

Here at school, and at every other facility I've used over 2.5 decades,
the system is always constrained by storage resources.  A program four
times as big costs four times as much to store, and while it may be a
nickel or a dime for ls(1), when creeping bloatitis overtakes all the
software, you get nicke-dimed to death.

Second, another correspondent noted that in ten million process activations
on his system, 98% took less than two seconds of cpu time.  This means that
loading them was a significant fraction of all the work done in executing
them.  Because system bandwidth (Gee, an architectural issue in comp.arch!)
increases drive up the cost of a whole system and almost all its components
dramatically, this is the area where improvements are slowest.  Tying up
precious bandwidth to load unused portions of over-featured programs is a
big loser, and I think this tips the scales to Henry's side of the argument.
We are rapidly headed toward being I/O bound simply due to program load
costs.

To put it another way, graph the time to load ls(1) versus date of the
version for the versions mentioned and the systems on which they run,
and weep.

For an example close to home, my Amiga is doing good if it can drag
programs off a hard disk at 30K bytes/second over an SCSI interface.
Even though, given the money, I can expand the system to 12.5
megabytes of memory, and put a 760 megabyte hard disk on it, waiting
15 seconds for a 0.5 megabyte editor to load from hard disk is a real
drag.

Kent, the man from xanth.

"His expression lit up.  'Hey, you wouldn't be a dope smuggler, would you?'

Rail looked confused.  'Why would anyone wish to smuggle stupidity when
there is so much of it readily available?'"

		-- Alan Dean Foster, GLORY LANE