folta@tove.umd.edu (Wayne Folta) (05/12/89)
I sincerely hope that the virtual memory in 7.0 IS NOT one large space shared by all processes--just like my present Mac but with more memory. That is the one thing I HATE HATE HATE about the Mac (which I am otherwise crazy about :-)). One errant program crashes the entire system. To come home from UNIX (with harmles core dumps) to the Mac (with heart-wrenching system bombs) can be traumatic. And even worse: you cannot tell which program caused the crash! It might have been caused by a program you ran a half hour ago (or at least that is my experience). I would rather have the system and applications protected from each other without any virtual memory than have TONS of virtual space with crashes being that much more spectacular. Wayne Folta (folta@tove.umd.edu 128.8.128.42)
miller@CS.ROCHESTER.EDU (Brad Miller) (05/12/89)
Date: 11 May 89 17:22:34 GMT
From: folta@tove.umd.edu (Wayne Folta)
I sincerely hope that the virtual memory in 7.0 IS NOT one large space
shared by all processes--just like my present Mac but with more memory.
Lest this go by without an opposing view:
(Opinion) One of the stupidest things about current UNIX systems is that a
multiuser OS is being pressed into service as a singleuser multiprocessing
system. The issues are quite different. Developers and users are strangled
by too much protection offered by the kernel to "protect the user from
themself". Let the luser hang themselves by their own rope. The hacker will
thank you!
A single large address space makes IPC easier
A single large address space makes it easier for one process to debug
another (currently running process)
Protection issues needed to support multiple users aren't an issue with
single users.
A single large address space makes it easier to ADVISE or modify system
functions on the fly.
In short: for software development, I think a single large address space is
the way to go.
One may ask what this has to do with the MAC, since the MAC is clearly
anything BUT a software development environment. BUT... I'm becoming
convinced it may be a good cheap one, if you run the right software. With
APPLE now supporting and marketing Allegro CL (the first halfway decent
development environment for the MAC I'm aware of, at any rate -- blatent
opinion) the MAC may indeed become a contender in this area; particularly if
APPLE's intent is to compete with higher level workstation offerings by,
e.g. SUN. A unified address space really is the only way to do a lisp
workstation right...
Reams can be written on this subject, and already have been. The original
complaint was short, so this will be too.mce@tc.fluke.COM (Brian McElhinney) (05/16/89)
In article <1989May11.193812.2552@cs.rochester.edu> miller@CS.ROCHESTER.EDU (Brad Miller) writes: > >Protection issues needed to support multiple users aren't an issue with >single users. That's hard to swallow. So it isn't an issue that a bug in my word processor can crash my machine? Taking my spreadsheet, drawing program, and everything else with it? I would personally (almost!) trade all the new features in System 7.0 for memory protection. I've heard that "well-written software doesn't crash." I don't believe it. Writing software is hard. People are involved. There is never enough time. Mistakes *will* be made. Brian McElhinney mce@tc.fluke.com
d88-jwa@nada.kth.se (Jon W{tte) (05/17/89)
In article <8288@fluke.COM> mce@tc.fluke.COM (Brian McElhinney) writes: >[Stuff deleted] I would personally (almost!) trade all the new features in >System 7.0 for memory protection. I SURELY and ABSOLUTELY would. Anyone tried to set the processor in protected mode? See what happened? Maybe Apple has something to say about this? System 8.0 getting ready to ship right after we've gotten used to 7.0 maybe ? >Mistakes *will* be made. Yeah. I make them every day :-) >Brian McElhinney -- h+@nada.kth.se <>,, "Hmm. What's this green fish called? I think I will Jon W{tte (:))))=- call it Lunch. Hi, Lunch!" -- A fish called Wanda Oh NO! A bug! <>'' -Say Kids, what time is it? -It's Time For A House. Dizco me to XtaC! -OH LA LAAA! -- Jack to the sound of the underground
stores@unix.SRI.COM (Matt Mora) (05/17/89)
In article <8288@fluke.COM> mce@tc.fluke.COM (Brian McElhinney) writes: >In article <1989May11.193812.2552@cs.rochester.edu> miller@CS.ROCHESTER.EDU (Brad Miller) writes: >> >>Protection issues needed to support multiple users aren't an issue with >>single users. > >That's hard to swallow. So it isn't an issue that a bug in my word processor >can crash my machine? Taking my spreadsheet, drawing program, and everything >else with it? I would personally (almost!) trade all the new features in >System 7.0 for memory protection. Its been along time since I used switcher, but I recall that it had excellent crash protection. Its seemed more robust than multi-finders. Back then I guess things were much more simpler :-) Just my $0.02 worth. -- ___________________________________________________________ Matthew Mora SRI International stores@unix.sri.com ___________________________________________________________
phil@Apple.COM (Phil Ronzone) (05/17/89)
In article <17452@mimsy.UUCP> folta@tove.umd.edu.UUCP (Wayne Folta) writes: >I sincerely hope that the virtual memory in 7.0 IS NOT one large space >shared by all processes--just like my present Mac but with more memory. > >That is the one thing I HATE HATE HATE about the Mac (which I am otherwise >crazy about :-)). One errant program crashes the entire system. To >come home from UNIX (with harmles core dumps) to the Mac (with heart-wrenching >system bombs) can be traumatic. If you have the hardware resources, have you considered A/UX? I develop all my Mac applications under A/UX, including XCMDs. If I want an actual Mac binary, I transfer the source over to LSC. A/UX is also more stringent in 32-bit clean, no-no memory accesses and priviliged instructions etc. -- helps keep your app inline for 7.0 and later releases. +-----------------------------------------------------------------------------+ |Philip K. Ronzone, Apple Computer, 10440 Bubb Rd, MS 58A, Cupertino, CA 95014| |{amdahl,decwrl,sun,voder,nsc,mtxinu,dual,unisoft,...}!apple!phil | +-----------------------------------------+-----------------------------------+ | All "IMHOs" disclaimed and copyrighted. | Self defense is a human right ... | +-----------------------------------------+-----------------------------------+
pasek@ncrcce.StPaul.NCR.COM (Michael A. Pasek) (05/19/89)
In article <8288@fluke.COM> mce@tc.fluke.COM (Brian McElhinney) writes: >In article <1989May11.193812.2552@cs.rochester.edu> miller@CS.ROCHESTER.EDU (Brad Miller) writes: >>Protection issues needed to support multiple users aren't an issue with >>single users. >That's hard to swallow. So it isn't an issue that a bug in my word processor >can crash my machine? Taking my spreadsheet, drawing program, and everything >else with it? I would personally (almost!) trade all the new features in >System 7.0 for memory protection. I must agree with Brad (sort of). Where you NEED memory protection is where there may be MULTIPLE programs that have a GOOD probability of failing, and where that failure CANNOT be tolerated. If you choose to use a word processor that continually crashes your system, then you MUST be prepared to tolerate the outages. The big reason that I see for NOT doing memory protection is the expense, both in hardware AND software. The only way to do TRUE memory protection is to provide each application with a unique storage key. The storage key of the current application is then matched with the storage key of the memory which the application is trying to access, and if they don't match, the application the "unexpectedly" quits. The expense in hardware is adding the storage key memory and the comparison logic. The big expense in software is in doing I/O. For the most part, all data to be transferred in/out of the system would have to be COPIED from/to the application memory space by the OS, before/after the I/O occurs. This would especially be true for AppleTalk, since there is no way to know the socket (application) that the data is destined for until after it is received. Personally, I'd rather see memory with parity (or better yet, ECC) before I would even WANT memory protection. M. A. Pasek Switching Software Development NCR Comten, Inc. (612) 638-7668 CNG Development 2700 N. Snelling Ave. pasek@c10sd3.StPaul.NCR.COM Roseville, MN 55113
miller@CS.ROCHESTER.EDU (Brad Miller) (05/19/89)
In article <8288@fluke.COM> mce@tc.fluke.COM (Brian McElhinney) writes: >In article <1989May11.193812.2552@cs.rochester.edu> miller@CS.ROCHESTER.EDU (Brad Miller) writes: >> >>Protection issues needed to support multiple users aren't an issue with >>single users. > >That's hard to swallow. So it isn't an issue that a bug in my word processor >can crash my machine? Taking my spreadsheet, drawing program, and everything >else with it? I would personally (almost!) trade all the new features in >System 7.0 for memory protection. [Sorry for the late reply] If a bug in a word processing program crashes your machine, protected memory won't necessarily help your other applications. What I think you mean to say is that memory protection can intercept a certain class of bugs and prevent a possible machine crash, or other memory corruption. The problem is that while this is perfectly true, this protection disallows a class of IPC that may well be to the user's benefit. Consider the sorts of issues that occur when an incremental compiler wants to replace the definition of a function currently being used by another process. This redefinition may well be intentional; it is exactly what the user wants to do. The point is that presumably in a single-user multi-process situation, all the processes are working FOR that user, and should be allowed to freely intercommunicate. A single large address space enhances this communication, if memory protection doesn't prevent access. Incremental compilation you may consider to be esoteric, but the same issues come up in debuggers, parallel programming, coroutining (consider the routines accessing a single array), and a variety of other situations. That doesn't mean that a particular application shouldn't be able to protect itself from outside access, or even protect others from itself; given you know the machine has an MMU you can do just that. I just don't think it's something the OS should provide by fiat, because it would prevent writing a large interesting class of applications. (And besides, it would slow the machine down. :-) If you DO want some sort of OS level protection, then it should be done at the OBJECT/TYPE level (e.g. tags) rather than at the memory address level. That would allow, say, multiple threads to properly use/invoke functions, etc. but not e.g. randomly write. (It also allows shared libraries to be implemented and protected against misuse). Bottom line: I don't think simple memory protection is worth the cost in a single user machine; good type & use checking is expensive and isn't likely to occur in 7.0; and you really need hardware support which the MAC line doesn't have. (68050 anyone?)
jimm@amiga.UUCP (Jim Mackraz) (05/19/89)
)>[Stuff deleted] I would personally (almost!) trade all the new features in
)>System 7.0 for memory protection.
)
)I SURELY and ABSOLUTELY would. Anyone tried to set the processor in
)protected mode? See what happened?
Yeah, that's the ticket: it's a hardware problem. All you 8.0
guys can take the rest of the week off.
)>Mistakes *will* be made.
)Yeah. I make them every day :-)
jimm
--
Jim Mackraz, I and I Computing "He's hidden now, but you can see
{cbmvax,well,oliveb}!amiga!jimm The bubbles where he breathes."
- Shriekback
Opinions are my own. Comments are not to be taken as Commodore official policy.