🚀 go-pugleaf

i have to agree with Robert on implementation points, but i really disagree
on the utility of Multi-tasking in any form without real memory protection.
(By the way, Robert, Unix was designed as a single-user system and abstracted
 out to what it is today.)  He and i have had this argument several times
before; might as well move it into a public forum.

Robert talks about the Stride "Multi-user" BIOS that allows more than one
task at a given terminal (all tasks must be same OS) and more than one active
terminal at a time (each terminal may be running a different OS).  i, too,
have one of these machines and i, too, am running CP/M-68K.  Now, it should
be noted that none of the (what are, in my opinion) faults of this setup
are because of that selection of OS.  Instead, they are caused by the
underlying *real* OS, the Multi-user BIOS.

Many times i have been running simultaneous foreground/background processes
and had memory trashed in one process because of a stray pointer (from that
1 last bug) in the other process.  i have gotten to the point that i just
don't do code development with more than one process running.  i have
experienced just about every possible bad side-effect of this that one
could imagine.  It is aggravated by the fact that the MU-bios runs
separate kernels for each process (how else can you run Pick, MoSys, P-system,
and CP/M-68K all at the same time?) and that there is no way to safely write
in directories from 2 processes.  Robert's stated solution is the only one
that makes sense -- don't write-share directories.

Now, with OS/9 or Minix or even Micro RTX (ever heard of the Beckemeyer
MT C-Shell?) , you of course don't have the directory problem but you still
have the risk of one process interfering with another and in practice i find
this unacceptable.  Maybe Amiga users get used to booting their machine when
one program goes wild, but that is not my idea of a usable operating system.

For this reason, i have been in "grin and bear it" mode for a while, just
waiting for Stride to realize they should sell me their 68010 + MMU
"daughter board" for the 68000 socket without making me buy their Unix
and for Project GNU to actually get enough work done on the Trix kernel
that i can hook my BIOS drivers into it and do some parallel development.
i have also had pointers to the German mag "c't", who are supposedly
doing a 68020 + MMU daughter board, but i haven't checked it out.

i can't see using OS/9 or Minix, because of the reasons and experiences
mentioned above.  The only way to be to get the level of protection that
i would want is to do as someone else suggested and keep only one process
resident at a time, swapping them to disk at each context switch.  Granted,
i have a fast hard disk, but either i would be spending all my time swapping
for large processes or wasting most of my 4Mb memory on small processes.

							-neville


~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~
U.S. Mail:  Neville D. Newman
	    Advanced Decision Systems
	    201 San Antonio Circle, Suite 286
	    Mountain View, CA  94040-1289

Phone:	    (415) 941-3912
Net mail:   neville@ads.arpa	(internet-relative)