Path: utzoo!utgpu!news-server.csri.toronto.edu!mailrus!ames!eos!shelby!neon!Kermit.Stanford.EDU!philip
From: philip@Kermit.Stanford.EDU (Philip Machanick)
Newsgroups: comp.arch
Subject: Re: Personal OS
Message-ID: <1990May28.214121.29814@Neon.Stanford.EDU>
Date: 28 May 90 21:41:21 GMT
References: <643@sibyl.eleceng.ua.OZ> <402@newave.UUCP> <3300131@m.cs.uiuc.edu> <9437@pt.cs.cmu.edu> <36849@think.Think.COM>
Sender: news@Neon.Stanford.EDU (USENET News System)
Reply-To: philip@pescadero.stanford.edu
Organization: Computer Science Department, Stanford University
Lines: 36

In article <643@sibyl.eleceng.ua.OZ>, ian@sibyl.eleceng.ua.OZ (Ian Dall)
writes:
> Even running "debugged" official applications ("MacWrite" etc), I have
> seen Macs get into a state where they have to be reset. Ditto with
> MSDOS machines. The rapid reboot which was quoted as being necessary
> in a single user operating system is due to the frequency of the crashes
> in such a system.
> 
> Of course, processes get into "stuck" states on a multi-tasking OS as
> well.  The difference is that you can normally recover with only the
> death of that one process.
> 
Rather than all this "what's wrong with the Mac" stuff, I think this
thread should be leading to "what's wrong in the area of OS?" -
remembering that this group is supposed to be about architecture.

OS architectures currently in use were designed with very different hardware
constraints to those which apply today. Unix was designed as an efficient,
simple multi-user system with dumb terminals, as a response to the poor
performance of systems like Multix. The Mac was designed to make it possible
to get a decent windowing interface to run responsively on 7MHz 68000 with
128K of RAM. Since then, these things have grown as the hardware realities
have changed underneath them. The result? Unix needs 16M of RAM and a fast
RISC processor to run clunkier windowing systems than the Mac's (e.g., X),
and the Mac has horrendous memory management, with multitasking
implemented as an indescribable bunch of hacks. I could name a worse example...

So, given current / likely future hardware realities, could we do a lot
better? For example, the relative speeds of CPUs / levels of memory hierarchy
(on-chip cache, second-level cache, RAM, hard disk) are changing in ways
that should suggest different design decisions.

Anyone like to design an OS in their spare time?

Philip Machanick
philip@pescadero.stanford.edu