neville@ADS.ARPA.UUCP (02/14/87)
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)
mwm@VIOLET.BERKELEY.EDU.UUCP (02/14/87)
[I've got an Amiga, which has the multi-tasking, non-protected "problem".] >> 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. Ah, but what is usable is very flexible. I'm willing to put up with stray crashes (but see below) in return for a multi-tasking OS, and wouldn't go back to CP/M in any flavor except at gunpoint. I'm willing to put up with having a program being debugged crash things that aren't, in return for being able to run those other things. For instance, right now I have 4 running user tasks (I stopped loading the workbench a while back, otherwise it'd be 5). The ability to drop back into a CLI to check something relating to what I'm typing now is invaluable. >> 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. Yes, but 99+% of the times it happens to me, it's been during program development. The following reboot is more painful, but the environment it's rebuilding is more complicated than CP/M-68K. Of course, I'd like to have an MMU. I'd also like to have a 68020 @ 25MHz. Nobody seems to be building boxes in my price range with those features, so I'll live with what I've got. Bottom line: If you can get hardware/software that does what you want with an MMU, grab it. If not, I'll take a multi-tasking OS w/out protection. I won't recommed that someone do development on one while other people are trying to use it for work, though. I'd be leary of suggesting it for any kind of multi-user work at all. <mike