Relay-Version: version B 2.10 5/3/83; site utzoo.UUCP
Path: utzoo!mnetor!uunet!husc6!cmcl2!brl-adm!adm!bzs@bu-cs.bu.EDU
From: bzs@bu-cs.bu.EDU (Barry Shein)
Newsgroups: comp.unix.wizards
Subject: Free Software Foundation (was: Re: Mach, the new standard?)
Message-ID: <9455@brl-adm.ARPA>
Date: Wed, 23-Sep-87 15:00:02 EDT
Article-I.D.: brl-adm.9455
Posted: Wed Sep 23 15:00:02 1987
Date-Received: Sat, 26-Sep-87 04:02:33 EDT
Sender: news@brl-adm.ARPA
Lines: 29


This is really becoming a silly argument, it's obvious the two
sides have completely different things in mind.

Those justifying larger programs are envisioning more utility
and thus hoping to save people-time over cpu-time or kilocore
clicks.

Those bashing larger programs are making the observation that much of
the largeness in programs is just due to bad design or a brain-damaged
idea about what people "need". I'd be the first to agree that many,
many programs in the past got bloated just to sell it to non-technical
manager types who had final budgetary decision and little or no idea
about the real goals (oooh, good error messages! [too bad it doesn't
*do* anything.])

On the other hand it's hard for me to see how a program with, for
example, a sophisticated bitmap/mouse/window interface is going to be
kept tiny relative to one which doesn't have such an interface,
obviously the trade-off in terms of actual utility has to be examined.

Certainly the first is a seductive rationalization for anything while
the second is a cold, hard reality that people have a lot of trouble
dealing with. But it seems silly to say one holds more truth in it
than the other.

Summary: It's breath mint! It's a candy mint!

	-Barry Shein, Boston University