NetNews Usenet Archive 1992 #31/NN_1992_31.iso/spool/comp/sys/amiga/advocacy/32295

Internet Message Format | 1992-12-29 | 5.7 KB

Path: sparky!uunet!crdgw1!rdsunx.crd.ge.com!michelotti!mrmike
From: [e-mail] ("Mr. Mike" Passaretti)
Newsgroups: comp.sys.amiga.advocacy
Subject: Re: Future Amiga chipsets
Message-ID: <[e-mail]>
Date: 28 Dec 92 23:08:01 GMT
References: <[e-mail]>
    <[e-mail]>
Sender: [e-mail] (Required for NNTP)
Reply-To: Mike Passaretti <[e-mail]>
Organization: GE Aircraft Engines, Cincinnati OH
Lines: 80
In-Reply-To: [e-mail]'s message of 28 Dec 92 21:04:22 GMT
Nntp-Posting-Host: michelotti.ae.ge.com

# In article <[e-mail]>,
# [e-mail] (Jerry Shekhel) writes: NNTP-Posting-Host:

jerry> Even if I were "just an applications programmer" (and
jerry> I'm not), why am I any less qualified than you to say
jerry> what is and what is not an operating system?  Is a
jerry> driver any less qualified than a mechanic to say what
jerry> is and what is not a car?

First, my apologies if I misread your posting on your
programming experience.  I meant no disrespect.  Day care
teachers are responsible for more of the future's shape than
OB/GYNs any day, they just work in different fields.  No
"just" an app programmer was written, and none should have
been read.  Onward...

A person who uses a car to its fullest potential and exploits
all its features is more qualified to comment on the utility
of any car than someone who steers and listens to the factory
supplied radio.  They both get what they want out of the car,
but from an underlying design perspective I'd expect to get
more useful information out of the enthusiast than the fellow
who treats it like an appliance.  A mechanic, or more properly
for my metaphor an automotive designer, understands the
trade-offs involved in automobile design better than a driver
and is more qualified to judge the relative merits of many
automobiles.

Many drivers are very happy with cars based on outdated
technology and some modern improvements.  The Mustang comes to
mind.  It's fast in a line, but not real stable under hard
cornering without some suspension tweaks and the braking is
abysmal.  By modern standards it is not a well designed car.
The Miata, on the other hand, although slow and not very
popular with the muscle car crowd is much more nimble, brakes
better and is, overall, a more integrated design.  Driving the
two is like night and day, but a lot of folks still say "A car
is a car.  Four wheels and it gets me where I'm going."  The
new Corvette or Viper would be an example of modern design
with something to satisfy most enthusiasts, but the Viper has
no cup holder and would thus get panned by Consumer Reports,
while the Corvette does everything but wash its own windows.

A personal Example:

My 1965 Triumph, as a system, is better designed than my 1989
Dodge.  The first is (IMHO) a good example of automotive
design and the second is an appliance.  There is nothing on
the TR that doesn't belong and everything that is there fits
well (modulo the quirky convertible top (hood) design).  It's
a performance car with some refinements for touring/commuting.
The Dodge, on the other hand, has little bits grafted on that
are obviously afterthoughts.  The turbo engine is too strong
for the suspension (even though it is uprated for this model
from the base), leading to some odd galumphing under heavy
acceleration, and it really needs to be lowered a bit for roll
stability in cornering.  It plows like a Land Rover.  It is a
commuter car which has performance options grafted onto it.
It does have a cup holder, though.  I drive the Dodge a lot
more than the TR, but I like the TR a lot better and would
drive it all the time if I could.

jerry> OS's don't exist for OS developers; they exist for
jerry> application programmers and users; *they* are the ones
jerry> who define what goes into an OS, not you.

** Bzzzzt ** Thank you for playing.  The OS developer, by
definition, decides what goes in his OS.  The API is all that
matters to the applications programmer, and the applications
are all that matter to the user.  90% of what they interact
with on a computer on a daily basis is so far removed from the
OS as to be unimportant from that level.  If I put a minimal
UN*X API on MSDOS (which is what many libraries for MSDOS C
compilers do, effectively), that might make it easier to
program, but it wouldn't make it UN*X.  It might succeed in
getting some apps ported, but that still wouldn't make it
UN*X.  The OS/API/GUI/Apps are nowhere nearly as tightly
coupled as you appear to believe.  A UN*X user need not know
anything about inodes or sockets, but I care about both or
those and about hash tables, global optimizers, device
drivers, backplane arbitration and I/O bandwidth (to name a
few OS and other considerations most users never think about).

The implementation of, for instance, sleep() on a machine is
not important to the app programmer, the compiler or library
author has taken care of it.  If the OS directly supports such
an idea, then Bob's your uncle.  If not, then it's a hassle
for all concerned to provide this functionality.  If the OS
does not support a good way to obtain a timer and release it,
you must fudge some more.  The average app programmer never
sees this, but I care about it a lot.  The user only cares
that his screen updates every 5 seconds, and most of the time
a busy-wait will do him just fine.  Polled keyboard routines
were, for instance, the norm in MS-DOS software for a long
time because nobody provided a good, efficient hook in the OS
to get the info out to the API.
                                                        - MM
--
[e-mail]           {whatever}!crdgw1!copernicus!passaret
[e-mail]     {whatever}!crdgw1!copernicus!michelotti!mrmike