🚀 go-pugleaf

In article <nevin-0809950319040001@mac-nevin.cs.arizona.edu>,
Nevin ":-]" Liber <nevin@CS.Arizona.EDU> wrote:
>In article <DEJ81J.2JK@frobozz.sccsi.com>, kevin@frobozz.sccsi.com (Kevin
>Brown) wrote:
>
>I might think of them as inexperienced, but I'll
>> think of them as "dumb" only if they end up asking the same question
>> repeatedly after having been told the same answer repeatedly.
>
>Even then, I tend to either consider the problem being either 
>
>a) my inability to communicate the solution to them in terms that they can
>grasp, or
>
>b) a fundamental design problem in the system they are trying to
>understand.

Those are definite possibilities, but there does come a point when you
can hardly come to any conclusion other than that the user is dumb or
doesn't give a shit...

>In other words, I am trying to understand *why* they keep asking the same
>question.

Yup, I do this too.  I try to make sure the person I'm talking to
understands what I'm saying before he goes away.  If he says he
understands when he knows he actually doesn't understand, then he
qualifies as a "stupid user".

>> Of course, prior to Windows, 99% of the people who used computers had
>> been without GUIs for decades.  That some large group of people
>> managed to do without a particular capability for a long period of
>> time in no way implies that the capability isn't useful or won't
>> become essential.
>
>I didn't mean to imply that the PMT might not be useful in some or even
>many situations.  People used computers without GUIs (or non-programming
>type interfaces, for that matter) because of cost and the unavailability
>of systems with good interfaces (among lots of other things, such as
>software availability).  That is why the Apple ][, Commodore 64, and the
>original IBM PC thrived.  When the choice is a cheap computer for
>programmers vs. no computer at all, the choice is obvious.  As computers
>got more powerful by orders of magnitude with the price dropping, users
>had a new choice:  a computer for users vs. a computer for programmers. 
>The computers for programmers (Amiga, NeXTStep, etc.), with the exception
>of Unix (more on why later), lost.  It is my firm belief that these
>machines didn't fail because of bad marketing; they failed because they
>didn't have much of a market to begin with.

I think it's more complex than that.

The IBM PC succeeded almost exclusively because of the IBM name.  When
it got popular enough in the business community, people figured out
ways to clone them, and that sent the price through the floor, which
increased the rate of growth of the market, which made it viable among
the home computer crowd.  By the time clones came out, the market was
large enough that compatibility was a major consideration in the
market.

The Mac succeeded partly because of the Apple name and partly because
it ended up catering to a very specific niche in the market that grew:
the desktop publishing market.  It also succeeded in part because of
timing: it hit the market before compatibility was the be-all and
end-all of computing.

The Amiga actually did reasonably well up until the 386 was introduced
(at which time the PC was fast enough and cheap enough that the Amiga
lost much of the advantage its hardware gave it).  It failed primarily
because Commodore marketing and management was so bad that they
couldn't sell 1-carat finely-cut diamonds for 10 cents apiece if they
tried.  The Amiga did as well as it did *despite* Commodore, not
because of them, which says a lot about just how good a machine it
really was.  The Amiga's probably the only machine that's good enough
to see a restart of production after the demise of its parent company.
I hope it succeeds.

OS/2 failed (relative to its primary competitor, M$) partly because of
its initial hardware requirements (which is no more a problem for it
now than it is for Windows 95), but primarily because IBM is about as
bad at marketing to the masses as Commodore.

NeXTStep never had a chance.  At the time it was introduced, it
required workstation-class hardware to run it reasonably well, ran on
only one brand of hardware (NeXT's) and that hardware was too
expensive for anything but the workstation market.  No surprise that
the NeXT systems never got very popular.  By the time PC-class
hardware was beefy enough to run NeXTStep, it was too late: Microsoft
had captured most of the market with Windows and managed to get it
past the point where compatibility is everything.  Oh, did I mention
that NeXTStep's still too expensive?  (Educational discounts don't
count, because the market isn't big enough if its primary population
is students)

Until the advent of free Unixes, Unix was never a contender in the
personal marketplace to begin with.  It was always too expensive both
in terms of hardware requirements and/or money for the actual OS.  Now
that free versions of Unix for PC-class hardware are widely available
(and will run on the same class hardware that Windows 95 will run on),
Unix (Linux in particular) actually has a shot at the desktop market.
But because (as I mentioned above) compatibility is now the primary
buying consideration in the marketplace, it will probably take a while
for Unix to become a major player (it will require compatible native
apps).  It will certainly take more development of the user interface,
as that's one of the "compatibility" issues.

>> There's no good excuse for any modern
>> OS to use CMT over PMT.
>
>Whew; I know that we had to disagree somewhere. :-)  

Oh, but see the end of this article.  :-)

>There is one very,
>very compelling reason (and it isn't a technical one) for the MacOS in
>particular to use CMT over PMT, and that is backwards compatibility.

Compatibility is rarely affected by CMT versus PMT.  The only
applications that will require CMT over PMT are those that actually
depend on CMT to make certain internal operations atomic.  Everything
else ends up going through the OS, which eliminates the distinction.
I dare say that the vast majority of applications have no such
requirement, but I could, of course, be wrong.

If direct modification of global state (as opposed to the use of a
well-defined system call interface) is the rule and not the exception
under MacOS, then MacOS doesn't qualify as a "modern OS" but instead
belongs in the "broken kludge" category.  Even DOS, the most backward
of "operating systems" ever to grace the modern computing world, has a
well-defined system call interface, even if it is very
hardware-dependent.

>Almost all computers that were designed from the ground up since the early
>80s that could not run existing software have failed in the
>marketplace. 

Yes, but that's primarily due to market inertia and the fact that once
a market is monopolized past a certain point and grows past a certain
size, compatibility becomes more important than any other
consideration.

>The Mac is an exception, primarily because the Apple ][ was able to
>support the company for a long enough time to attract enough developers
>and users to make it a successful product.

That probably helped.  I suspect, though, that the primary reason the
Mac has succeeded is timing.  In particular, the Mac got started
*before* compatibility became a stranglehold issue.

>  What company (other than
>startups) can afford to do that today?

Well, as you say, startups.  But, of course, if a startup can do it,
so can a larger company.  The question is whether or not the
beancounters will approve, meaning that just because a larger company
*can* do it doesn't mean that it will want to.

>This is one of the main reasons that Unix has stuck around for so long. 
>If you were trying to design a good OS from scratch, you certainly
>wouldn't come up with Unix.

Well, which Unix are you thinking of?  Or are you thinking of the
basic design principles that went into the design of Unix?  Or are you
not thinking of the OS at all, but of the applications (programs) it
runs?  These are all very different things.

>  The scheduler is bad.  

In what way?  It's quite good for its intended purpose, namely
multiuser use.  I admit it's probably not ideal for single-user
multimedia use.  For that, you want a scheduler like the Amiga's.

>The UI performance is bad.

Fortunately, you don't have to throw Unix out along with the UI,
because they're separate things.

>  The pipe mechanism is very inefficient (2 copies per byte of data,
>minimum) 

This is highly implementation-dependent.  And, in any case,
inefficient in comparison to what?

>and makes it hard to tightly integrate tools (hence we get
>monoliths like trn, Netscape, etc.).  

...if the kind of integration you need doesn't fit the pipe paradigm.
Why should this be any surprise?  There isn't any one-size-fits-all
IPC mechanism, just like there isn't any one-size-fits-all scheduler.

Look: the tighter the integration between applications, the more each
application has to know about the other (the implication being that
it's impossible to design a generic IPC mechanism that enable tight
and transparent integration).  The pipe mechanism was intended at the
outset to be a means by which *loose* integration could be achieved.
It provides nothing but a one-way data stream.  Sockets provide a
means of arranging a two-way data stream, or you can use two pipes,
but that won't provide you with "tight" integration either because it
doesn't define data formats and other things that are required for
that kind of integration.

What makes pipes special is their simplicity and generality.  They're
simple enough that you can connect programs together on the command
line using them (and that why they are so prevalent in the Unix
world).  Their semantics are simple enough that you don't have to
worry about deadlocks in a loopless pipeline (a pipeline lockup means
that at least one of the programs is hung on some non-pipe condition).

Anything more complex than that will require automatic deadlock
resolution (a problem for which there is no general resolution as far
as I know), arbitrary limits on the behavior of the participants,
arbitrary limits built into the communications mechanism, additional
complexity in the application above and beyond the simple reads and
writes that would be sufficient with a simpler mechanism, or some
combination thereof.

In any case, because the IPC mechanisms provided by Unix are general,
other more specific mechanisms can be built on top of them.

>It is hard to keep secure (either a
>person has no system privledges as a regular user or all of them as root;
>in practice, there is very little middle ground).  

This is highly installation-dependent.  I'll be the first to admit,
though, that setting up Unix so that you can get away with giving
different administrative permissions to different people takes some
thought and work.

>Tools are inconsistent.

True.  And this is partly because many tools don't *have* a user
interface (you just run them, and give them arguments), and partly
because there was no definitive UI style guide (along with the
appropriate libraries, of course) to aid developers.

>The masses want evolution, not revolution.

The masses don't want, or care about, either.  They want compatibility
and features, and that's *all*.

>  The masses also seem to care
>about, from highest to lowest:
>
>i) applications
>ii) cost
>iii) user interface
>iv) operating systems
>
>PMT won't fundamentally change things by itself.  It is up to developers
>to come up with stuff that they would not have in a CMT environment,
>because it was too hard to do in the first place or just too difficult to
>get right.

I couldn't agree more.  Here we go again.  :-) :-)

Note that the same thing is true of the GUI: developers had to come up
with stuff that wasn't possible or practical in a text-only
environment before the GUI became "essential".

With the Internet, background processes, daemons, etc., all becoming
more common in the personal computing world, I don't think it'll be
too terribly long before the limitations of CMT become obvious to the
general population.

-- 

				Kevin Brown
                      SGI Customer Support Engineering