Path: utzoo!utgpu!news-server.csri.toronto.edu!cs.utexas.edu!sun-barr!decwrl!pa.dec.com!bacchus!mwm From: mwm@pa.dec.com (Mike (My Watch Has Windows) Meyer) Newsgroups: comp.sys.amiga.misc Subject: Re: True Multitasking Message-ID: Date: 11 Feb 91 19:50:14 GMT References: <42598@nigel.ee.udel.edu> <678@tnc.UUCP> <187@lsw.UUCP> Sender: news@pa.dec.com (News) Organization: Missionaria Phonibalonica Lines: 79 In-Reply-To: gjc@lsw.UUCP's message of 9 Feb 91 20:25:18 GMT In article <187@lsw.UUCP> gjc@lsw.UUCP (Greg) writes: In article , mwm@pa.dec.com (Mike (My Watch Has Windows) Meyer) writes: > No - I'm simply stating a definition for the term "real computer". > Whether any particular machine meets the definition is immaterial. > On that note, all I am trying to say is that operating systems are written by people, people are fallable and therefore so are operating systems. Yes, they are. I'm not trying to say that the definition implies that no application can crash the system; merely that when that happens, it's considered a bug in the system, not the application. By your definition quite a few of todays computers would not be real computers. For example... by using direct addressing I could erase all the memory locations in a Prime minicomputer/mainframe, or by moving a zero to a particular register (using a non-privileged account) you can crash a VAX/VMS minicomputer. It's been a long time since I looked at a PR1ME, but given what I saw then, I wouldn't be surprised if what you describe is considered a feature. Which would indeed make a PR1ME not meet that definition of real computer - which matched the conclusions of the time I looked at it. We bought a VMS system instead. On the other hand, our VAX/VMS people assure me that the bug you describe is a bug in the OS, and fixed on our systems. And the list would go on and on... I dunno - most of the hardware I've worked on don't provide features that allow non-privileged users to crash the system. Most of them had _bugs_ that let that happen. The systems people were trying to fix them. If the systems people had been trying to convince me that the applications program was at fault, then I would have said they didn't have a real computer. It would be very nice if a microcomputer operating system could accomplish this, but it would have to be *very* robust and have a high price. That statement was true 10 years ago, and probably true five years ago. I don't believe it's true now. An A3000UX would qualify (I know of no features in Unix that allow applications to crash the system). I am not refutinge the fact that there may be some OSs out there which are totally bulletproof, but I have yet to see one. I'm not saying that a computer has to have a bulletproof OS to meet that definition; I'm saying that the OS design has to have the _goal_ of being bulletproof to meet that definition. BTW, you might consider saying "real operating system" since what you referred to in your first note was concerning the OS not the computer. Look at the topic. Think about the history of the discussion. Contrary to what you might think the OS has very little to do with the computer it's running on. A primary example of this would be UNIX which currently runs on DEC, Apple Mac, Amiga,some 386s, some 286s, etc. Contrary to what you might think, SOME os's are very much tied to the computer they're on. A primary example of this would be AmigaDOS, which has to have a 680x0 based processor, and a nice set of custom silicon as well. Also, the OS expects to see some set of capabilities from the hardware, and won't run without that. But yeah, you're right - hardware can run multiple OSs, and some of them have being bulletproof as a goal; others don't. It can be argued (and has been previously in this thread) that a Mac running AUX is in some way different from a Mac running finder, as the users see radically different behavior.