lindsay@MATHOM.GANDALF.CS.CMU.EDU (Donald Lindsay) (05/27/90)
In article <3300131@m.cs.uiuc.edu> gillies@m.cs.uiuc.edu writes: >There is a very >beautiful paper by Butler Lampson, I believe, called "An open >Operating System for a Single-User Machine" (circa 82-84). Basically, >Lampson observes that the advent of the personal computer allows us to >return to the golden days of the 1950's, with a single programmer, a >library, and a dedicated machine. Apple's OS is a very close >approximation of lampson's ideal environment. >Some of the things that are important in a single-user operating >system are: > 2. no protected kernel, to allow easy modification of software > 3. single address space, to maximize modifiability of software I realize that Butler convinced some PARC people of the correctness of this view. I have a great deal of respect for these people: but on this point, I consider them to be naive and deluded. Not everyone out there is a PARC-quality researcher, and not every user out there will run only sanctified applications. The hardware cost argument has gone away, and any speed argument has gone away. Plus, that famous "bloat" leaves me with 65 processes on my workstation as I type. Don't ask me what they all do. Do I trust that they are all debugged? Hah! I KNOW that some of them aren't, and I don't trust the rest. Nor do I want the nightmare of making "easy modifications" to these intricate, hard-to-test things. Is this "golden age" going to simplify them, going to reduce this bloat? Would you like to buy this bridge I own in Brooklyn? In summary: if my workstation had a single address space, I'd sell it and buy something adequate. (Sorry, Ed.) > 7. overlay loader (because early macs (& Alto) had no VM) I'm old enough to remember when overlays were the way you built applications on minicomputers. They were a god-awful source of bugs and grief, and a horrendous waste of effort. In summary: bletch. -- Don D.C.Lindsay Carnegie Mellon Computer Science
barmar@think.com (Barry Margolin) (05/27/90)
In article <9437@pt.cs.cmu.edu> lindsay@MATHOM.GANDALF.CS.CMU.EDU (Donald Lindsay) writes: >In summary: if my workstation had a single address space, I'd sell it >and buy something adequate. (Sorry, Ed.) Actually, one of the best reasons for a single address space is to simplify sharing of data between applications, which promotes integrated software. MIT-descended Lisp Machines are a good example of this. The debugger can display source code from the editor, the editor has access to the compiler warning database, etc. It's true that integrated software can be written when the applications have walls between them, but it's harder and rarely very extensible. A protocol has to be provided, and you are usually restricted to the forms of communication that are preconceived by the designers; if all the applications are designed together this may be good enough, but if they have differing heritages you may be out of luck. Many Macintosh utilities take advantage of the single address space. For example, there's an auto-save utility, which periodically causes the application to invoke its "Save" menu item; it has to look around in the application's address space to find the identity of the menu entry. >> 7. overlay loader (because early macs (& Alto) had no VM) >I'm old enough to remember when overlays were the way you built >applications on minicomputers. They were a god-awful source of bugs >and grief, and a horrendous waste of effort. In summary: bletch. Remember, the article was written in the early 80's, when VM on personal computers was almost unthinkable (indeed, hard disks on personal computers were considered a luxury -- I think the Winchester disk is probably one of the most important computer technologies of the 80's). If overlays are automated, as is done on the Mac, then bugs are reduced. It's a reasonable compromise, but it's certainly not as nice as VM with demand paging. -- Barry Margolin, Thinking Machines Corp. barmar@think.com {uunet,harvard}!think!barmar
ian@sibyl.eleceng.ua.OZ (Ian Dall) (05/28/90)
In article <36849@think.Think.COM> barmar@nugodot.think.com (Barry Margolin) writes: > >Actually, one of the best reasons for a single address space is to simplify >sharing of data between applications, which promotes integrated software. "Forces", I would have said. >warning database, etc. It's true that integrated software can be written >when the applications have walls between them, but it's harder and rarely >very extensible. A protocol has to be provided, and you are usually >restricted to the forms of communication that are preconceived by the >designers; if all the applications are designed together this may be good >enough, but if they have differing heritages you may be out of luck. If you are using a shared address space as your means of IPC you are even more out of luck if the applications are not designed together. There are many "proofs of existance" to show that a single shared address space for OS and processes can work. That is not to say that it is a desirable environment. Many people (myself included) use a multiuser operating system predominantly with only one active user. I cannot count the number of times I have had a process die with a SIGSEGV. Count each of those as a probable system crash. No thanks! I have 34 processes running on this machine at the moment and I am the only user. Some of those (esp emacs), have some state dependent on what I am currently doing. It would be a major inconcenience to loose that state every time I try and debug a program. 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. -- Ian Dall life (n). A sexually transmitted disease which afflicts some people more severely than others.
jesup@cbmvax.commodore.com (Randell Jesup) (05/28/90)
In article <9437@pt.cs.cmu.edu> lindsay@MATHOM.GANDALF.CS.CMU.EDU (Donald Lindsay) writes: > Plus, that >famous "bloat" leaves me with 65 processes on my workstation as I >type. Don't ask me what they all do. Do I trust that they are all >debugged? Hah! I KNOW that some of them aren't, and I don't trust >the rest. Nor do I want the nightmare of making "easy modifications" >to these intricate, hard-to-test things. Is this "golden age" going >to simplify them, going to reduce this bloat? Would you like to buy >this bridge I own in Brooklyn? > >In summary: if my workstation had a single address space, I'd sell it >and buy something adequate. (Sorry, Ed.) Sure, every one here (or their company) can afford full-blown workstations, but not everyone can. The speed issues you blew off do still exist: an Amiga 3000 or 2500/030 running AmigaDos is a hell of a lot snappier than the same machine running SysV Rel4. For less capable machines, like 68000-based ones (A2000HD, A500), running anything with more overhead would be VERY painful (I know, I have a Sun-2). :-( Human-factors research indicates that if response time is more than a very small value (a few tenths of a second, I think), productivity drops considerably. So keeping a "snappy" feel to a machine (both interface and actual applications) is quite important. Second, remember that 'single address space' and protection (and VM) are all separate issues, especially on a single-user machine. A single address space is VERY useful in speeding up interactions between pieces of software, and simplifying the writing of multi-threaded programs (think of why threads have become popular). The Amiga FS (as has been mentioned here) is fast, even when compared to much larger and faster machines. (With cheap, small, 40 MB quantums Amigas can easily hit 700K/s through the filesystem (largely disk rotation limited)). The single address space makes this easier to achieve. Note: I'm not arguing for Lambert's OS proposal, just over a few of the items on the list. Nor do I say the AmigsOS is perfect; it's far from it. However, it's pretty well-adapted to the marketplace and hardware it's aimed at. The challenge is in adapting it to more powerful hardware without losing the strengths it has. AmigaDos 2.0 (and the A3000) is a big step in that direction. -- Randell Jesup, Keeper of AmigaDos, Commodore Engineering. {uunet|rutgers}!cbmvax!jesup, jesup@cbmvax.cbm.commodore.com BIX: rjesup Common phrase heard at Amiga Devcon '89: "It's in there!"
henry@utzoo.uucp (Henry Spencer) (05/28/90)
In article <36849@think.Think.COM> barmar@nugodot.think.com (Barry Margolin) writes: >>In summary: if my workstation had a single address space, I'd sell it >>and buy something adequate. (Sorry, Ed.) > >Actually, one of the best reasons for a single address space is to simplify >sharing of data between applications, which promotes integrated software... >... It's true that integrated software can be written >when the applications have walls between them, but it's harder and rarely >very extensible... There is no problem in writing integrated software on a multi-space machine, you just do it all in one space and pretend that the walls don't exist. On the other hand, a one-space machine with flimsy protection makes it very difficult to write multiple programs that are guaranteed *not* to interfere with each other. If you look at the software on the Alto, the system from which much of the one-space mythology is descended, you find that there is no notion of non-interfering parallel processes at all -- all parallelism has to be preplanned -- and the only interprocess-communication method that works between independently-written programs is the file system. The very "wide" interface made possible by sharing all memory is a two-edged sword. It is very powerful for programs that want to cooperate and are willing to work at it. But it makes it very difficult for programs to work together without such advance planning, precisely *because* the inter-program interface is so versatile and powerful and demands that so many choices be made. The Unix approach, with independent programs plugged together by a simple command interpreter, simply does not exist on many such systems. The interfaces are too rich and too powerful for random programs to talk to each other easily. -- As a user I'll take speed over| Henry Spencer at U of Toronto Zoology features any day. -A.Tanenbaum| uunet!attcan!utzoo!henry henry@zoo.toronto.edu
philip@Kermit.Stanford.EDU (Philip Machanick) (05/29/90)
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
barmar@think.com (Barry Margolin) (05/29/90)
In article <643@sibyl.eleceng.ua.OZ> ian@sibyl.OZ (Ian Dall) writes: >There are many "proofs of existance" to show that a single shared >address space for OS and processes can work. That is not to say that >it is a desirable environment. Many people (myself included) use a >multiuser operating system predominantly with only one active user. I >cannot count the number of times I have had a process die with a >SIGSEGV. Count each of those as a probable system crash. No thanks! OK, maybe I should qualify my point and say that a single address space is reasonable when there's a decent language/runtime system. Almost all the system failures we get on Symbolics Lisp Machine are due to hardware problems. The hardware, Lisp language and runtime system make it difficult to scribble randomly on memory. Sure, if a program were to manipulate the scheduler's data structures directly and make a mistake it could bring the system to its knees, but it's inlikely to happen to a program that isn't *trying* to manipulate the OS, and patching the OS is likely to crash any system. When ordinary application programs do get errors (and Lisp Machines do lots more error checking, such as number and types of arguments, than most other systems) they just invoke the debugger, abort, or invoke programmed condition handlers. So, I would say that the problem with the Mac is not that it has a single address space, but that its typical language and runtime systems don't provide adequate for this mode. Address space protection on multiuser systems exists for security; programmers are still responsible for writing programs that follow the rules, e.g. only address memory you have allocated, pass appropriate arguments when calling library routines or system calls, etc. -- Barry Margolin, Thinking Machines Corp. barmar@think.com {uunet,harvard}!think!barmar
rcd@ico.isc.com (Dick Dunn) (05/30/90)
barmar@think.com (Barry Margolin) writes: [in response to complaints about overlays and overlay loaders] > Remember, the article was written in the early 80's, when VM on personal > computers was almost unthinkable... Something's wrong with the time scale here. In the early 80's (starting around 82) I was working with a company that was thinking very seriously, and in fact starting to build, machines that had VM and were intended for individuals. The company was not that farsighted, either. There was nothing unthinkable about it. There were some tough cost issues right then, but everyone saw they'd work out in time. The 68010 was out and lots of different groups were lamenting the lack of a standard MMU for it...as they set out making their own MMU's to keep the world safe for incompati- bility. BSD was available and had VM. The obvious thing to do was to take BSD and put it on a 68010 machine--and lots of folks did. >...(indeed, hard disks on personal computers > were considered a luxury -- I think the Winchester disk is probably one of > the most important computer technologies of the 80's)... A slight adjustment here: Winchester is a '70's technology. Its impact on personal computers, true, was in the 80's. -- Dick Dunn rcd@ico.isc.com uucp: {ncar,nbires}!ico!rcd (303)449-2870 ...Simpler is better.
gillies@p.cs.uiuc.edu (05/30/90)
> If you look at the software on the Alto, the system from which much of the > one-space mythology is descended, you find that there is no notion of > non-interfering parallel processes at all -- all parallelism has to be > preplanned -- and the only interprocess-communication method that works > between independently-written programs is the file system. They solved this problem in the Xerox/Pilot OS, see "Experience with Processes and Monitors in MESA, CACM, 1978". Since every module in the machine is a reentrant program, and every module may enforce mutual exclusion via monitoring, sharing is well-supported. It seems from looking at the source code in UNIX, that correctness and robustness are halfway down the list of programmer priorities for that system. The programmer expects that the separate address spaces gives him artistic license to write flakey software. He expects to be saved (from a system crash) by a process crash. He has no clue that the system can run out of (swap, file) space. Sure you need separate address spaces under UNIX, because the system software is of such low quality. Do you presume that because there are 65 processes on your machine, that they must all be necessary? In fact, most of them are probably kluges to deal with the separate address space problem in UNIX. The UNIX philosophy is, "we care enough to have a process sniffing at it every half hour" (or N seconds). While this would work in the old days, when there was only a very slow Cron(8) demon, today workstations talk to networks and are unbuffered interactive devices. There is no sanctioned way (under UNIX) to write software that notifies all interested parties (unknown at compile-time) in the system. On the other hand, in a single address-space machine, it is easy for the I/O module to make a notification procedure call, which chains along, notifying all interested entities in the address space. On my old DLion, if the prettyprinter wrote a new version of a MESA source file, then all editors would notice and replot the file window immediately (if no changes had been made). Try THAT under UNIX. Don W. Gillies, Dept. of Computer Science, University of Illinois 1304 W. Springfield, Urbana, Ill 61801 ARPA: gillies@cs.uiuc.edu UUCP: {uunet,harvard}!uiucdcs!gillies
tucker@Neon.Stanford.EDU (Andy Tucker) (05/31/90)
In article <1990May30.042930.9261@ico.isc.com> rcd@ico.isc.com (Dick Dunn) writes: >barmar@think.com (Barry Margolin) writes: >[in response to complaints about overlays and overlay loaders] >> Remember, the article was written in the early 80's, when VM on personal >> computers was almost unthinkable... >Something's wrong with the time scale here. The Lampson&Sproull paper being referred to here ("An open operating system for a single-user machine") was first presented at the 7th SOSP in December 1979 (Operating Systems Review 13(5)). -- Andy Tucker tucker@cs.stanford.edu ...!decwrl!cs.stanford.edu!tucker
peter@ficc.ferranti.com (Peter da Silva) (05/31/90)
The most complete personal O/S on a PC is AmigaOS. It's a tight message passing operating system with a small kernel. Scheduling is pre-emptive on a strict priority basis (i.e., real-time oriented). Intertask communication is via message queues allocated from a single heap, and via shared memory. The windowing system is fast and responsive, even on a 7.14 MHz 68000. The file system is a task under the kernel, and several file systems are available. The machine came with two: the Original File System, a disk-based system, and a Ram-disk that allocated files on the heap. The graphic user interface hasn't been as well-developed as on the Mac, but it's still better integrated than X. And since it doesn't depend on cooperation from the applications it's very fast: switching between applications is virtually instantaneous. The new GUI elements in AmigaOS 2.0 are much prettier: it looks like Motif without the speed penalty. Just to let people know that a personal operating system doesn't have to be limited, slow, or kludgy. -- `-_-' Peter da Silva. +1 713 274 5180. <peter@ficc.ferranti.com> 'U` Have you hugged your wolf today? <peter@sugar.hackercorp.com> @FIN Dirty words: Zhghnyyl erphefvir vayvar shapgvbaf.
amos@taux01.UUCP (Amos Shapir) (05/31/90)
In article <76700219@p.cs.uiuc.edu> gillies@p.cs.uiuc.edu writes: |It seems from looking at the source code in UNIX, that correctness and |robustness are halfway down the list of programmer priorities for that |system. The programmer expects that the separate address spaces gives |him artistic license to write flakey software. He expects to be saved |(from a system crash) by a process crash. He has no clue that the |system can run out of (swap, file) space. | |Sure you need separate address spaces under UNIX, because the system |software is of such low quality. That's a gross exaggeration to say the least. Most of the software that constitutes Unix is well written and debugged, mainly because programmers did not have to worry about crashing the system by the slightest typing error. | | |Do you presume that because there are 65 processes on your machine, |that they must all be necessary? In fact, most of them are probably |kluges to deal with the separate address space problem in UNIX. The |UNIX philosophy is, "we care enough to have a process sniffing at it |every half hour" (or N seconds). While this would work in the old |days, when there was only a very slow Cron(8) demon, today |workstations talk to networks and are unbuffered interactive devices. |There is no sanctioned way (under UNIX) to write software that |notifies all interested parties (unknown at compile-time) in the |system. The fact that *you* don't know how to do it, doesn't mean that it cannot be done. There are a lot of ways for user-level processes to be informed of events without resorting to the common address space quagmire. A separate address space is a "problem" only for those who don't know how to use it. -- Amos Shapir amos@taux01.nsc.com, amos@nsc.nsc.com National Semiconductor (Israel) P.O.B. 3007, Herzlia 46104, Israel Tel. +972 52 522408 TWX: 33691, fax: +972-52-558322 GEO: 34 48 E / 32 10 N
csimmons@jewel.oracle.com (Charles Simmons) (06/02/90)
In article <36861@think.Think.COM>, barmar@think.com (Barry Margolin) writes: > From: barmar@think.com (Barry Margolin) > Subject: Re: Personal OS > Date: 29 May 90 01:38:16 GMT > > In article <643@sibyl.eleceng.ua.OZ> ian@sibyl.OZ (Ian Dall) writes: > >There are many "proofs of existance" to show that a single shared > >address space for OS and processes can work. That is not to say that > >it is a desirable environment. Many people (myself included) use a > >multiuser operating system predominantly with only one active user. I > >cannot count the number of times I have had a process die with a > >SIGSEGV. Count each of those as a probable system crash. No thanks! > > OK, maybe I should qualify my point and say that a single address space is > reasonable when there's a decent language/runtime system. Almost all the > system failures we get on Symbolics Lisp Machine are due to hardware > problems. The hardware, Lisp language and runtime system make it difficult > to scribble randomly on memory. Sure, if a program were to manipulate the > scheduler's data structures directly and make a mistake it could bring the > system to its knees, but it's inlikely to happen to a program that isn't > *trying* to manipulate the OS, and patching the OS is likely to crash any > system. When ordinary application programs do get errors (and Lisp > Machines do lots more error checking, such as number and types of > arguments, than most other systems) they just invoke the debugger, abort, > or invoke programmed condition handlers. > > So, I would say that the problem with the Mac is not that it has a single > address space, but that its typical language and runtime systems don't > provide adequate for this mode. Address space protection on multiuser > systems exists for security; programmers are still responsible for writing > programs that follow the rules, e.g. only address memory you have > allocated, pass appropriate arguments when calling library routines or > system calls, etc. > > -- > Barry Margolin, Thinking Machines Corp. > > barmar@think.com > {uunet,harvard}!think!barmar We can, of course, argue this from the other point of view. The problem with non-single address space systems is not their lack of a single address space, but the lack of tools which allow the information in multiple protected address spaces to be easily accessed from any of the protected address spaces. We might envision, for example, an object-oriented language where a sufficient number of primitives are implemented on each object to allow each object to efficiently and safely share the abilities of other objects. -- Chuck
yodaiken@freal.cs.umass.edu (victor yodaiken) (06/03/90)
In article <76700219@p.cs.uiuc.edu> gillies@p.cs.uiuc.edu writes: > >> If you look at the software on the Alto, the system from which much of the >> one-space mythology is descended, you find that there is no notion of >> non-interfering parallel processes at all -- all parallelism has to be >> preplanned -- and the only interprocess-communication method that works >> between independently-written programs is the file system. > >They solved this problem in the Xerox/Pilot OS, see "Experience with >Processes and Monitors in MESA, CACM, 1978". Since every module in >the machine is a reentrant program, and every module may enforce >mutual exclusion via monitoring, sharing is well-supported. > "Solved" is a bit of an overstatement. The Mesa compiler will catch many errors that can arise in a shared workspace environment, but it cannot possibly catch all. It is always possible to cause a program to make unpredictable memory references. Architectural support for private workspaces ensures that such errors will have only local consequences. And architectural support of private workspaces does not require use of a single programming language or extensive (slow) run-time support.