Path: utzoo!utgpu!news-server.csri.toronto.edu!rpi!zaphod.mps.ohio-state.edu!uakari.primate.wisc.edu!caen!uwm.edu!psuvax1!hsdndev!cmcl2!adm!smoke!gwyn
From: gwyn@smoke.brl.mil (Doug Gwyn)
Newsgroups: comp.sys.apple2
Subject: Re: The GS Axe is Not Falling
Message-ID: <15744@smoke.brl.mil>
Date: 7 Apr 91 01:55:34 GMT
References: <51235@apple.Apple.COM> <1991Apr5.224048.29496@kuhub.cc.ukans.edu> <1991Apr6.102920.22598@nntp-server.caltech.edu>
Organization: U.S. Army Ballistic Research Laboratory, APG, MD.
Lines: 48

In article <1991Apr6.102920.22598@nntp-server.caltech.edu> toddpw@nntp-server.caltech.edu (Todd P. Whitesel) writes:
>It constantly bugs me that the market trend has been towards brute-force
>hardware and software that is way too complex for the average mortal to
>ever hope to comprehend. (never mind independent programmers.)

The Macintosh approach was to simplify the user interface even though it
added immense complexity to the program/system interface.  If one assumes
that that trade-off is necessary, then the answer becomes obvious -- it
was done to increase the market for computing, to raise it from the level
of the dedicated hobbyist to that of a consumer appliance.

>What happened to elegance and truly innovative solutions?
>They're buried under virtual memory hardware that has a fixed 1 cycle penalty,
>or brain-dead bootstrap ROMs that leave the machine useless if no boot volume
>is available, or operating systems that have severely skewed I/O models or no
>concept of interactive vs. batch execution. The latest MIPS wonder is simply
>expected to run the same old O/S's better and faster and everybody happily
>throws gobs of money at the problem of technological obsolesence.
>Someday somebody's going to break that cycle.
>I hope they hire me.

Maybe first you should revise your assessment of the situation.
I know of no significant virtual memory implementation that has an
overhead per access anything like one (instruction) cycle.  There
are many advantages to virtual memory, such as being able to isolate
multiple concurrent applications from each other and to streamline
code generation and linking.  The common notion that virtual memory
is useful for increasing the effective address space of a process is
usually wrong; most applications that rely heavily on that feature
perform very poorly (for technical reasons not worth going into here).
Machines that are inteded to run significant operating systems really
cannot do anything useful if they are unable to bootstrap an operating
system (or at least some diagnostic software).  Surely you don't think
they ought to pop up an AppleSoft BASIC interpreter when they can't
load their operating system?  As to interactive vs. batch, many of us
don't know what such a distinction would be, since we can use our
systems to accomplish either, using the same mechanisms for both.
The "same old O/S" actually tends to evolve and acquire important new
features; for example, our latest acquisitions support true parallel
computation in multiple threads sharing common address spaces.  Unless
you can come up with a new system that is SO much better in SO many
ways that it is worth the hassle of converting existing applications
to work with it, you would better spend your time figuring out how to
improve the operating environments that are already being happily used.

Indeed, there is research toward radically different computing methods,
but most such developments in recent years have not been commercially
successful, because they aren't meeting real needs.