Path: utzoo!attcan!uunet!sco!seanf
From: seanf@sco.COM (Sean Fagan)
Newsgroups: comp.misc
Subject: Re: A tirade about inefficient software & systems
Message-ID: <8539@scolex.sco.COM>
Date: 2 Nov 90 08:58:44 GMT
References: <9886@milton.u.washington.edu> <1990Nov1.002513.8984@ico.isc.com>
Sender: news@sco.COM
Reply-To: seanf (Sean Fagan)
Organization: The Santa Cruz Operation, Inc.
Lines: 68


In article <1990Nov1.002513.8984@ico.isc.com> rcd@ico.isc.com (Dick Dunn) writes:
>Sorry, wrong.  Leave out the bells and whistles, and you'll be an obit
>entry in next month's business section.  And the fewer bells and whistles
>you have, the *more* marketing you need!

True.  And this *is* a problem!  If I can:  Xenix 2.3 (for the '386) was a
nice little OS.  The OS fit on 4 or 6 floppies, I believe (for SCO-familiar
people, the X and N disks).  It ran quite well in 2Mb of memory (for 2
people or so), and with 4, it was ecstatic.

At the time we released Xenix 2.3, UNIX 3.2 was also being worked on and
released by other people (the exact timeframe for everything is a bit hazy,
but I'm sure hundreds of people will jump on me if I'm wrong 8-)).  Because
3.2 had more *features*, people wanted it!  Even if they were only going to
do the same thing that they were currently doing on the Xenix 2.2 systems,
or if 2.3 fit all of their needs, they wanted *3.2*.  Features, mah boy!

Stock 3.2 (from *any* vendor) is larger and slower than 2.3, and has a lot 
less history than xenix does (at least on the intel architecture).  So why
go with it?

(You already know the answer 8-).)

People who pay attention know the beating SCO got for coming out so late
with our version of UNIX 3.2.  We'd spent some time before getting XENIX 2.3
ready to be shipped, and in a good and usable state.

End of anecdote... 8-;

>My challenge to you, speaking as software-producer to software-user, is to
>tell us how to teach everyone that feature-madness is doing us all in.

One of the reasons I like Mach, or at least it's potential, is that the
"features" everyone wants can be added as user-level programs.  That is,
they can be swapped out, run only when needed, removed from the disk if you
don't want it, etc.  (Some of the features everyone wants are built in, such
as the VM, task switching, etc.  Others, such as unix compatability [which
unix? you ask 8-)] can be made seperate modules, as can device drivers.
Including networking.)

Keep it small and simple, and try to allow for generalities.  One of the
nicest things to come from AT&T in recent history was the STREAMS stuff.  If
a STREAMS module could be added without reconfiguring the kernel (and
rebooting), and could optionally run in user-mode, it would be *wonderful*.
(As it is, it's only nifty-keen 8-).)

How does this fit into the thread?  Well, like programming, if you keep your
programs and/or utilities small and simple, there is less chance of things
breaking (or, when they do, you will [hopefully] have a better chance of
understanding and fixing the code).  By splitting the various services into
different programs, and documenting the interface, someone can decide to
throw in new features of their own, or replace existing ones (as people do
already with shells [ksh vs. csh vs. sh vs. bash etc]).

As Dick said (or implied, whatever), we need people working on "fixing" the
current code, to make the product better.  We also need people working on
adding features, to actually be able to sell it to the public.  And the
latter wins, a lot of the time...

Anyway, just my opinions, even if I am awfully vocal about them 8-).

-- 
-----------------+
Sean Eric Fagan  | "Quoth the raven,"
seanf@sco.COM    | "Eat my shorts!"
uunet!sco!seanf  |     -- Lisa and Bart Simpson
(408) 458-1422   | Any opinions expressed are my own, not my employers'.