🚀 go-pugleaf

In article <nevin-0809950153300001@mac-nevin.cs.arizona.edu>,
Nevin ":-]" Liber <nevin@CS.Arizona.EDU> wrote:

>Think back to the very first time you drove a car.  Weren't you just a
>little apprehensive?  Were your parents irresponsible enough to just hand
>you the keys that day hoping you'll figure it out on you own, or did they
>train you/enroll you in a driver's education class for a few weeks/months
>before they would let you risk their $10-50K car/$1-2K insurance rate/your
>life?  Would you be willing to give the keys to your car to a 14 year old
>kid who has never been behind the wheel of a car and let them go drive it
>unsupervised?  If not, why not?  If so, put your car where your mouth is.

Maybe they should make an intuitive car with a graphical user interface.
We might start seeing three-year old toddlers on the road!

Why don't you put YOUR car where your mouth is!  You accept that the use
of cars requires require training and not be intuitive, but god forbid
that some newbie should be sat behind the "wheel" of some powerful,
but unwieldy, computer program. That would be a grave injustice, indeed.

To have such a newbie put you to shame would be unbearable.

>Definition of indispensable:  essential, absolutely necessary (source: 
>Webster's Ninth New Collegiate Dictionary).  Proof that PMT isn't
>indispensable:  Assume PMT is indispensable.  We've been using personal
>computers w/o PMT for nearly two decades.  The world hasn't ended, and we

Yes, and for at least half of that time, many people plodded on machines
like Trs-80's, Apple II's and C-64's. For the remainder of the era,
they had to put up with unreliable, buggy, crashy graphical pseudo-operating
systems.

For over two decades, people used computers with punched-card interfaces
without video display terminals, therefore we should continue in the
tradition.

>still manage to get our jobs done.  PMT is neither essential nor necessary
>to do computing.  Therefore, PMT is *not*indispensable.  Q.E.D.
>
>As for your other point, sure there are specialized applications where PMT
>is more desireable than CMT; I've never asserted otherwise.  You still
>haven't even given one example where PMT is essential and absolutely
>necessary (the definition of indispensable) and CMT and interrupts
>absolutely, positively, would not work at all, let alone shown it for
>every single computing application in existence, which was your original
>assertion.  You seem to weaken it every time you post.

Ok, but first show me one example where video terminals are absolutely
essential and hard-copy terminals and punched cards positively would not
work at all. After all, I can write a whole Fortran program onto punched
cards, debug it, and collect its results on a paper printout.

>I have a little secret for you:  the only difference between CMT and PMT
>is how tasks get swapped; ie, the whether scheduling is under application
>control or OS control.  Neither solution is perfect.  CMT apps have to

You know very well that there is more to it than that, because certain
programming paradigms break down when you introduce pre-emption. You know
very well that it's more than just a matter of turning on a timer.

In any case, PMT is only one aspect of it. You certainly can't debate
that protected, virtual memory is an advantage in an interactive system
running a heterogeneous mix of programs (as opposed to an embedded system
running closely related threads). PMT is something that just comes freely
with systems that employ protected, virtual address spaces. Operating systems
that have such management schemes make cooperative multi-tasking
pointless, since so much of the machine is virtualized already that
preemption goes without saying. These other things are more important
than the pre-emptive scheduling. Virtual, protected memory is useful even in a
single-tasking system. Pre-emptive scheduling without the protection features
is probably more harmful than good, because you are introducing an element
of uncertainty into an already precarious situation. (Just look at the
Amiga).

>If you only have one CPU you are only running one task at a time;
>everything else is an illusion.  Since when did 1/2 a second become the
>definition of what is/is not a multitasking system??

Right. But in a cooperative system, that one task can hold everything else up.
In a multi-user system, the hold-up means that nobody gets anything done.

>Right now on my Mac, I am doing two concurrent file transfers via
>Anarchie, printing a document, letting Eudora fetch my email, playing an
>audio CD, surfing the Web with Netscape, and writing this message waiting
>for some of the other stuff to finish (I need the files to do some work). 
>Oh, and did I mention that I have a clock in the menubar merrily going
>along, and it gets resynced via NTP every hour, just like those big PMT
>Unix boxes?  I suppose I could go into my office and do this on a PMT
>system with 3x as much horsepower as my Mac at about 5x the initial cost
>(not counting the maintenance / lab staff), but the UI response is
>pathetic compared to my Mac (and I'm the only one on the damn machine),
>and the tools take much more work on my part to do the same job.

You could also do it on a 386SX/16 with FreeBSD or Linux---what's your point?

>So, why don't you tell us *how* PMT is going to make our lives oh so much
>better, instead of emptily asserting it without proof or justification
>that it will.

I believe that PMT together with protected, virtual memory and
asynchronous, interrupt-driven IO is required in the implementation of
distributed systems, which are the way of the future.  Distributed
systems are inherently multi-user, whether or not any single machine
supports remote login sessions, or whether it merely exports distributed
services.  A cooperative system without protected memory is not a
reliable building block for constructing distributed systems, despite
fault-tolerance and performance enhancing measures such as replication
of resources and services.

A system without virtual, protected memory just isn't reliable and
robust enough to run a heterogeneous set of services and applications.
The more you try to do at once, the more the likelihood exists that
something will bomb, fragment the memory heap or use up all available
RAM. This means that the resources and services normally offered by
the machine are no longer available, unless they are replicated 
by another machine.

A system without pre-emptive multitasking will allow one of the
applications and services to seize control of the machine and prevent
it from being used as an access point to the distributed systems,
and from offering its resources and services to other nodes. Since
much of the applications are already distributed and therefore
coping with issues of real, physical concurrency, it is pointless
to make them "cooperative aware". Future programming systems may
include more and more tools which hide the distinction between
what happens concurrently and what happens sequentially, or what
happens locally versus what happens remotely. Software components
that are normally combined into monolithic executables may exist
on separate computers, or even migrate.

A system without asynchronous completion of input/output operations
isn't appropriate for distributed systems. It allows processes that
perform network or disk I/O to waste computing time to the point of
severely degrading interactive performance for the user who is using the
computer to access the distributed system. 

For these reasons, paradigms like "cooperative" multitasking, although
they have a place in specialized applications, have no place in a
modern interactive operating system.
-- 
Finger c2a192@keats.ugrad.cs.ubc.ca for PGP public key. Or contact
one of the public key servers -- the key id is 0xD3C7995D.
Microsoft users: crash test dummies?