Path: utzoo!utgpu!news-server.csri.toronto.edu!rpi!zaphod.mps.ohio-state.edu!mips!news.cs.indiana.edu!uceng!minerva!dmocsny
From: dmocsny@minerva.che.uc.edu (Daniel Mocsny)
Newsgroups: comp.arch
Subject: Re: Will NeXT survive? Grow with the times?
Message-ID: <8323@uceng.UC.EDU>
Date: 5 May 91 03:26:17 GMT
References: <1991Apr29.144421.19819@oakhill.sps.mot.com> <1991May1.160128.1367@sono.uucp> <8283@uceng.UC.EDU> <1991May4.011456.25729@borland.com>
Sender: news@uceng.UC.EDU
Organization: University of Cincinnati, Cin'ti., OH
Lines: 43

In article <1991May4.011456.25729@borland.com> sjc@borland.com (Steve Correll) writes:
>In article <8283@uceng.UC.EDU> dmocsny@minerva.che.uc.edu (Daniel Mocsny) writes:
>>Also, consider
>>that very few individual users are able to keep even a '386 machine
>>busy all the time.
>Gee, from my experience, X windows can keep any processor saturated without any
>action whatsoever on the part of the individual user. :-)

Out of curiosity, how many individual users can set up and
maintain *their own* computer running X? (The ideal answer should
be: all of them.)

That was my point, anyway. Some of my best friends are RISC users,
you know. :-)

Must I now pay with my life, my fortune, and my sacred (?) net.honor
for having egregiously blown the shibboleth of comp.arch? (I.e., by
daring to speculate that a 386 could in any sense suffice for anyone.)

>2. It is an illusion that the 80x86 PC world has fewer compatibility problems
>  than the RISC world. 80x86 PC software vendors expend enormous effort to
>  preserve this illusion for the benefit of their users: they support multiple
>  graphics options, multiple mice, 80386 real-versus-protected mode, various
>  add-on memory managers, Microsoft Windows versus straight DOS versus OS/2
>  versus 32-bit DPMI, various 80x86 subroutine calling conventions, tiny
>  versus small versus huge memory models (and on and on).

Yes, but they can do this (in principle) from one box, and they can
propagate their success to other 80x86 box programmers in the form
of libraries that mask most of the fragmentation. Illusion or not,
it's led to the largest pile of software that customers want to run,
so badly they buy lots of inferior hardware to run it.

The only incompatibilities that matter are those which the *application
programmer* can't hide from. That's where the productivity evaporates,
when the application coders have to get sidetracked by all this garbage.




--
Dan Mocsny				
Internet: dmocsny@minerva.che.uc.edu