Path: utzoo!utgpu!news-server.csri.toronto.edu!rpi!zaphod.mps.ohio-state.edu!swrinde!elroy.jpl.nasa.gov!jarthur!nntp-server.caltech.edu!toddpw
From: toddpw@nntp-server.caltech.edu (Todd P. Whitesel)
Newsgroups: comp.sys.apple2
Subject: Re: The GS Axe is Not Falling
Message-ID: <1991Apr8.035012.20436@nntp-server.caltech.edu>
Date: 8 Apr 91 03:50:12 GMT
References: <51235@apple.Apple.COM> <1991Apr5.224048.29496@kuhub.cc.ukans.edu> <1991Apr6.102920.22598@nntp-server.caltech.edu> <15744@smoke.brl.mil>
Organization: California Institute of Technology, Pasadena
Lines: 78

gwyn@smoke.brl.mil (Doug Gwyn) writes:

>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,

I don't think it is. That's why it bothers me.

>>What happened to elegance and truly innovative solutions?

>Maybe first you should revise your assessment of the situation.

I'm not assessing YOUR situation, I'm assessing the microcomputer and low
workstation situation. You can plug away on supercomputer unix systems owned
by somebody else for as long as you want. Nothing I say needs to apply to them
although sometimes I swear it would help.

>I know of no significant virtual memory implementation that has an
>overhead per access anything like one (instruction) cycle.

Oh? Then what IS the overhead? The 68851 PMMU has a fixed overhead of 1 clock
cycle.

>are many advantages to virtual memory, such as being able to isolate

Of course it does! I'm not arguing against virtual memory as a feature, just
the high-overhead implementation it often has.

> Surely you don't think they ought to pop up an AppleSoft BASIC interpreter
>when they can't load their operating system?

Not Applesoft, but why the hell not? I really think enough of the O/S should
be in ROM already so that you only need to go tto disk for add-on hardware
or O/S revisions. Trying to use a computer under very nonideal conditions
can make you appreciate how self-contained the Apple II is compared to most
machines. If all my drives go down, I can still use my Apple as a calculator
and a BASIC engine for small tasks. Which is more than I can say for nearly
any other computer in existence (besides the ARM).

> 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.

I'm talking about high-priority for lightweight tasks handling the user
interface, things like ensuring the cursor gets changed to a watch and things
react to your clicking them and so on. Try using a NeXT sometime.

>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.

Good for you. You've got loads of money to blow on hardware that makes those
things possible. I'm nowhere near as pampered, nor would I want to be.

>Until
>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.

I quite agree.

>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.

The developments I'd like to see aren't so much radical as unfettered by
excessive compatbility constraints. The NeXT actually has the right idea
when it comes to development, but their implementation seems to be just
as bloated as unix usually is.

Unlike Intel, I don't think you can hide an infinite number of transistors on
the head of a pin. It's about time people looked into implementing the tried
and tested hardware and software concepts (like virtual memory, graphic
interfaces, and multitasking) more cleanly and with less overhead.

Todd Whitesel
toddpw @ tybalt.caltech.edu