pla@zippy.eecs.umich.edu (Paul Anderson) (01/01/70)
In article <597@trwspf.TRW.COM> knurlin@trwspf.UUCP (Scott Karlin) writes: >In article <582@zippy.eecs.umich.edu> pla@zippy.eecs.umich.edu (Paul Anderson) writes: >>to the Apollos. I am in the process of porting about 150,000 of those >>lines (Berkeley's Magic, written in C) to the Amiga. I have found that > ^^^^^^^^^^^^^^^^ >This is very exciting! Please tell us more. Availability, etc... >> >-- >Scott Karlin >TRW Data Systems Lab >Internet: knurlin@trwspf.trw.com >ARPA: knurlin%trwspf@trwrb.trw.com >USENET: ...!trwrb!trwspf!knurlin Our commercially supported version of Magic for the Apollos is available now. Our version for the Amiga is running now, but I need beta testers for it. The Amiga version of Magic and the related tools will be available in some form by late Q1 1988. Price for the Amiga version is tenatively set at $1295, some discount can be expected for quantity and for University sites. For more info, feel free to mail, e-mail, or phone me. Paul Anderson pha@caen.engin.umich.edu pla@zippy.eecs.umich.edu Sandhill Systems PO Box 3159 Ann Arbor, MI 48106 (313) 475-7394
rogerh@arizona.edu (Roger Hayes) (11/12/87)
There have been some folks clamoring for virtual memory for the next
generation. I would like to speak up on the other side of the issue.
Some of the things that makes the Amiga so nice to use and to program for
are the extremely low latency of task switching and the extremely low
overhead of message passing. Both of these are likely to go down the
drain if memory protection is added.
As an extreme example, look at Sun workstations -- it takes tens of
seconds to open a window, because you have to make several trips down
through Unix and back up into the application code to get the job
done. On my Sun at work (a 2-50), I can easily drag a window faster
than the display can keep up, so that the window outline chases around
the screen for 10 seconds after the mouse is still. This is because
Sun task switching is slow -- thanks to Unix and virtual memory.
The latest work in distributed operating systems is tending towards a
lightweight process model -- just what we have in the Amiga. This is,
IMHO, because a distributed OS is at heart a real-time I/O handler for
the network and display devices. The Amiga does a great job at this
now. Let's not lose it in an effort to gain ground that the pioneers
are deserting.
You want more security? Well, I might accept memory *protection*
hardware, as long as the additional cost in task-switching was
recoverable from elsewhere. Or we could make the software do it --
write programs in a secure language. This is similar to the RISC
approach to pipeline delays. The rationale is that compilation is a
one-time cost, while hardware complexity hurts every time you run a
program. (And that's disregarding the production cost entirely.)
Roger Hayes
rogerh@arizona.edujbn@glacier.STANFORD.EDU (John B. Nagle) (11/13/87)
1. Given the way that RAM prices are declining while
disk access times are not improving, virtual memory
looks like an idea whose time has passed. Most newer
systems with virtual memory use it as an excuse for
fat software. Sun and Symbolics are the worst offenders
in this regard. (Sun users: try "size /bin/ps". Then
try to think of what could possibly make it that big.)
2. "Lightweight processes" are an old idea, not a new one.
EXEC 8 for the Univac 1108 and its successors have had them
since 1969; so have some other mainframe systems. It's
merely the fact that the operating systems whose
internals are well-known in the academic community,
TOPS-20 and UNIX, don't have them that makes people
think that they have invented something new.
3. Memory protection is desirable, but a true protected operating
system would require that the operating system keep track of
all the resources requested by a user program and be able
to take them back when a program exited abnormally. Tripos
(alias AmigaDos) does not do the bookeeping to allow this.
Neither does the system in the Mac line. We don't yet have
a widely used example of an efficient operating system for
small machines that provides proper protection. However,
OS/2 for the IBM PS/2 supposedly meets this criterion.
We will have to see. Note that if it does, users will soon
find it intolerable for their machine to crash all the
time like present generation systems. All the other vendors
will then have to catch up with IBM.
John Nagleharald@ccicpg.UUCP ( Harald Milne) (11/16/87)
In article <2785@megaron.arizona.edu>, rogerh@arizona.edu (Roger Hayes) writes: > There have been some folks clamoring for virtual memory for the next > generation. I would like to speak up on the other side of the issue. > Some of the things that makes the Amiga so nice to use and to program for > are the extremely low latency of task switching and the extremely low > overhead of message passing. Both of these are likely to go down the > drain if memory protection is added. I am glad somebody finally said this. The Amiga does not have the massive context switch overhead involved with user space and virtual memory maps. Thank god. That is why there is low latency, nothing to switch in context. Virtual UNIX on the Amiga or the Sun or the Mac II will suck, and cost a lot. Not to mention the added overhead of purging translation buffers. Although the Amiga is multitasking, and not multiuser, this is an advantage. There is no reason to support the multiuser feature of UNIX on the Amiga, simply since it isn't. (After all, it is MY machine) I call it multitasking without the excess baggage! > As an extreme example, look at Sun workstations -- it takes tens of > seconds to open a window, because you have to make several trips down > through Unix and back up into the application code to get the job > done. On my Sun at work (a 2-50), I can easily drag a window faster > than the display can keep up, so that the window outline chases around > the screen for 10 seconds after the mouse is still. This is because > Sun task switching is slow -- thanks to Unix and virtual memory. That is a very good example. Suns die like dogs doing anything UNIX. Not to mention ack, gack, wheeze. To bad this is the street Apple is walking down on for the Mac II. Boy do they have a few suprises! I won't even mention the astronomical costs to accomplish this! UNIX on micros is silly, unless you like waiting or paying for the performance. Considering the Amiga does very well without, is a point in its favor. -- Work: Computer Consoles Inc. (CCI), Advanced Development Group (ADG) Irvine, CA (RISCy business! Home of the CCI POWER 6/32) UUCP: uunet!ccicpg!harald
phil@titan.rice.edu (William LeFebvre) (11/16/87)
In article <2785@megaron.arizona.edu> rogerh@arizona.edu (Roger Hayes) writes: >There have been some folks clamoring for virtual memory.... >extremely low latency of task switching and the extremely low >overhead of message passing. Both of these are likely to go down the >drain if memory protection is added. Memory protection != virtual memory >As an extreme example, look at Sun workstations -- it takes tens of >seconds to open a window, because you have to make several trips down >through Unix and back up into the application code to get the job >done. Tripos != Unix. Also: sizeof(Tripos) < sizeof(Unix) A mathematician would write: |Tripos| << |Unix| ("<<" means significantly less than) >On my Sun at work (a 2-50), I can easily drag a window faster than the >display can keep up.... This is because Sun task switching is slow -- >thanks to Unix and virtual memory. No, this is almost completely the fault of SunView and Sunwindows. They are huge monolithic monsters that make unreasonable demands of the system's resources. Every SunView process must carry at least 300K of library routines with it in order to run in the environment. After the so-called kernel takes its 400K chunk and each SunView process takes its share, there is very little memory left for the virtual memory system to play with. No virtual memory system is going to be successful when there is less than half a meg of real memory left. Ever seen X run on a Sun? Ignore the bugs, just look at how fast it can move the windows around. That should help demonstrate that the fault is primarily with SunView and NOT just with Unix. >The latest work in distributed operating systems is tending towards a >lightweight process model -- just what we have in the Amiga. Absolutely. And this is exactly what you do NOT have with Unix! I think that comparing Unix+VM to AmigaOS+VM is like comparing apples with stems to pears with stems. >You want more security? Well, I might accept memory *protection* >hardware, as long as the additional cost in task-switching was >recoverable from elsewhere. I think the Amiga really *needs* this. Unpriviledged processes already run with the supervisor bit off. That's the first step. I get tired of non-robust programs walking all over memory because they forgot to check if their last memory alloc returned success. I really think memory *protection* is one of the features that separates a true workstation from a mere home computer/toy. >Or we could make the software do it -- write programs in a secure >language....compilation is a one-time cost, while hardware complexity >hurts every time you run a program. Ahhh, but does the "secure" programming environment encur any extra run-time software overhead? Compilation may be a one-time cost, but (for example) array-subscript-bound-checking also hurts every time you run a program. I'm not saying that I want virtual memory in AmigaOS. Then again, I'm not saying I don't. I have grown to love VM, but I see that it could very easily destroy the real-time performance of the Amiga. But if the next generation isn't going to have virtual memory, at least give us more than 8 meg of room in the memory map! William LeFebvre Department of Computer Science Rice University <phil@Rice.edu>
daveh@cbmvax.UUCP (Dave Haynie) (11/17/87)
in article <461@ra.rice.edu>, phil@titan.rice.edu (William LeFebvre) says: > Summary: no no no no no no > > In article <2785@megaron.arizona.edu> rogerh@arizona.edu (Roger Hayes) writes: >>There have been some folks clamoring for virtual memory.... >>extremely low latency of task switching and the extremely low >>overhead of message passing. Both of these are likely to go down the >>drain if memory protection is added. > > Memory protection != virtual memory Glad someone finally mentioned that, it's true! Both of these are things best done with a hardware MMU; both have been done to some extent in the past in software only. I think both are potentially important, though not equally so, or equally simple to implement in the Amiga OS. In any case, you'll be getting an MMU with the 68020 card for those who are interested, so now at least it makes sense to talk about these things. >>On my Sun at work (a 2-50), I can easily drag a window faster than the >>display can keep up.... This is because Sun task switching is slow -- >>thanks to Unix and virtual memory. UNIX task switching certainly can be a pig, and the slowness may be based on the virtual memory of your system. But chances are, without the VM, you wouldn't be complaining, because the window dragging wouldn't even be a possibility. This must be a general problem with workstations; I've noticed on our Apollo systems here too. They do VM; great! But they have very large tasks to swap around, and not enough real memory. My office A2000 has 5 megs of RAM; most of our Apollos have 2 megs. I never run out on either, though of course my Amiga isn't VMing right now. >>Or we could make the software do it -- write programs in a secure >>language....compilation is a one-time cost, while hardware complexity >>hurts every time you run a program. > > Ahhh, but does the "secure" programming environment encur any extra > run-time software overhead? Compilation may be a one-time cost, but (for > example) array-subscript-bound-checking also hurts every time you run a > program. Really. I could say the same about software VM. Sure I could do it, write a library to AllocVirtual(), LockVirtual(), FreeVirtual(), etc. But that's much more overhead and much less efficiency than a hardware VM system. You might get away with such a thing in the context of DB or text data, but you're certainly not going to profit from swapping in/out code chunks driven by software, unless you load when needed/dump when unused, as the Amiga OS does now, and that's hardly VM. > I'm not saying that I want virtual memory in AmigaOS. Then again, I'm not > saying I don't. I have grown to love VM, but I see that it could very > easily destroy the real-time performance of the Amiga. But if the next > generation isn't going to have virtual memory, at least give us more than > 8 meg of room in the memory map! Personally, I'd like to do both. A properly implemented VM system isn't going to have any effect on performance as long as you've got enough real memory to use. Once you run out of real memory, you're either dead (no VM), or you can page to disk and run the thing that's larger than your real memory. Now, I'd consider the ability to run something an advantage over not being able to run it at all, even if it does incur a performance hit of some kind. > William LeFebvre > Department of Computer Science > Rice University > <phil@Rice.edu> -- Dave Haynie Commodore-Amiga Usenet: {ihnp4|caip|rutgers}!cbmvax!daveh "The B2000 Guy" PLINK : D-DAVE H BIX : hazy "Computers are what happen when you give up sleeping" - Iggy the Cat
daveh@cbmvax.UUCP (11/17/87)
in article <5294@ccicpg.UUCP>, harald@ccicpg.UUCP ( Harald Milne) says: > Summary: On the mark > Although the Amiga is multitasking, and not multiuser, this is > an advantage. There is no reason to support the multiuser feature of UNIX > on the Amiga, simply since it isn't. (After all, it is MY machine) > I call it multitasking without the excess baggage! I'm REAL GLAD someone mentioned this too. Every time someone starts to talk about how neat it would be to run multiuser stuff on their Personal Computers, be they Amigas, Macs, or 386 machines, I really start to wonder about that person. After all, you buy a Personal Computer so that you can get away from the overloaded Minis. And they were bought to get away from the overloaded Mainframes. Such computers are cheap enough that you should get more of them if more folks need access to them. Want to share resources, hook them up to a LAN. But don't run lots of people on a poor Amiga, or even a future real powerful Amiga. These things cost less today than many a VT100-type terminal did a few years ago. And you can get the VT100 emulator for free. So don't multi-user, even if it's possible. Think of it as you think of IBM or C64 emulators -- they're neat in concept, and are cool to show off to your friends. But you don't really want to use them for anything more than that. Multiuser is the same kind of thing. If you can't use all the power of your Personal Computer yourself, get a cheaper PC.
dclemans@mntgfx.mentor.com (Dave Clemans) (11/17/87)
Having virtual memory DOES NOT mean that there will be large overheads in opening windows, dragging windows, etc. (the example given in the referenced message was tens of seconds to open a window on a Sun 2/50, system unable to keep up with cursor movement when dragging windows, etc). As an example you might want to look at a current Apollo system, which does use virtual memory, processes in different address spaces, etc. It does not exhibit any of the timing problems described in the previous message (window opens are essentially instantaneous, ...). Part of this comes from having windowing, mousing, etc. tightly integrated into the system. Another part has to do with the order that operations are done in; from the description in the previous message it sounds like on that persons Sun that the window is created last, after the new process is forked. On the Apollo the window is created first. dgc
fnf@mcdsun.UUCP (Fred Fish) (11/17/87)
In article <2803@cbmvax.UUCP> daveh@cbmvax.UUCP (Dave Haynie) writes: >in article <5294@ccicpg.UUCP>, harald@ccicpg.UUCP ( Harald Milne) says: >> Although the Amiga is multitasking, and not multiuser, this is >> an advantage. There is no reason to support the multiuser feature of UNIX >> on the Amiga, simply since it isn't. (After all, it is MY machine) >> I call it multitasking without the excess baggage! > >I'm REAL GLAD someone mentioned this too. Every time someone starts to talk >about how neat it would be to run multiuser stuff on their Personal Computers, > [stuff deleted...fnf] >Multiuser is the same kind of thing. If you can't use all the power of your >Personal Computer yourself, get a cheaper PC. Well, in general I agree with the premise that a personal computer should be allocated to a single individual, but this really doesn't mean that having multiuser capabilities isn't useful. Very often you want to use the multiuser protection features to protect you from yourself, to set up alternate environments for doing different sorts of things, etc. For example, even though I have a Sun-3 all to myself at work, I still have several different logins that I use depending upon what I want to work on at the time. Each provides a slightly different environment and different permissions for what can and can't be done with the system. Running a multitasking system without multiuser capabilities is equivalent to running as root all the time on a Unix system, something that VERY few experienced Unix people would do. Thus just because the computer has multiuser capabilities doesn't mean that you have to have more than one user active at a time. -Fred -- # Fred Fish hao!noao!mcdsun!fnf (602) 438-3614 # Motorola Computer Division, 2900 S. Diablo Way, Tempe, Az 85282 USA
ugevan@sunybcs.uucp (Evan Kahn) (11/17/87)
I was at a local C-A dealer yesterday and spoke to an official rep from
Commodore. Specifically, I wanted to know when KS 1.3 would be available and
found out thatit isn't schedualed for release until late next quarter (March).
At any rate we got to talking and I mentioned to him that I was in support of
bootable firmware as opposed to it being in ROM. He concurred and informed me
that there is speculation that future Amigas may have EEPROMS to hold KS.
^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^
Apparently, a reason why KS was put into ROM was to quell fears of
software producers, after all, why should they produce a package for an OS that
is rather variable; they will forever be providing patches. But this solution
is so exciting because the intention here is that an old program need only re-
boot the old version of KS and run the application that was released under it.
One could conceivably partition a hard disk into sections for each new version
of KS. An advanced OS could be smart enough to load the particular version of
KS for a particular application; Or you could just get latest releases and not
worry about reloading the firmware each time you run an application.
Do you guys out there think that such an EEPROM card could be made for
the 2000 ?
Evan.jpdres10@usl-pc.UUCP (Green Eric Lee) (11/17/87)
In message <17218@glacier.STANFORD.EDU>, jbn@glacier.STANFORD.EDU (John B. Nagle) says: > 1. Given the way that RAM prices are declining while > disk access times are not improving, virtual memory > looks like an idea whose time has passed. Only if you have a single-tasking operating system. Certainly you can get enough physical memory nowadays to run ANY respectable program. But what if you have FIFTEEN 2 megabyte programs loaded up? Sure, they probably aren't all going to run at once... the other 14 are most probably just going to be sitting there, hung waiting for input, inactive. But virtual memory, in this case, is just providing the book-keeping so that you don't have to manually shuttle those other 14 programs in and out of memory (i.e. via exiting each one of them and losing your place in whatever you were doing in them -- in other words, exactly what multitasking was supposed to eliminate). > 3. Memory protection is desirable, but a true protected operating > system would require that the operating system keep track of > all the resources requested by a user program and be able > to take them back when a program exited abnormally. Tripos > (alias AmigaDos) does not do the bookeeping to allow this. We hashed over this eons ago on the net. Most of us agree that, with fairly minor alterations to the memory manager and i/o libraries, it CAN be done with TRIPOS. The problem is that without a memory management unit, it would be VERY expensive. A memory management unit would allow this book-keeping to be handled much more transparently than it currently could be.... One very good scheme for AmigaDOS/TRIPOS would be to have half the virtual memory globally mapped, i.e. so that all the processes could pass messages to each other, and the other half locally mapped, for your actual program and its data. -- Eric Green elg@usl.CSNET from BEYOND nowhere: {ihnp4,cbosgd}!killer!elg, P.O. Box 92191, Lafayette, LA 70509 {ut-sally,killer}!usl!elg "there's someone in my head, but it's not me..."
UH2@PSUVM.BITNET (Lee Sailer) (11/18/87)
In article <5294@ccicpg.UUCP>, harald@ccicpg.UUCP ( Harald Milne) says: > > Although the Amiga is multitasking, and not multiuser, this is >an advantage. There is no reason to support the multiuser feature of UNIX >on the Amiga, simply since it isn't. (After all, it is MY machine) With an important exception. There are situations where two or more users take turns using a "single user" machine. Often, it would be very nice if (1) files could be "owned", (2) different startup-sequences could be defined for different users, and (3), users in general could stay out of each other's way. You can fake these things using cli scripts, and so on, but not well. lee
hsgj@batcomputer.tn.cornell.edu (Dan Green) (11/18/87)
In article <2803@cbmvax.UUCP> daveh@cbmvax.UUCP (Dave Haynie) writes: >I'm REAL GLAD someone mentioned this too. Every time someone starts to talk >about how neat it would be to run multiuser stuff on their Personal Computers, >be they Amigas, Macs, or 386 machines, I really start to wonder [...] >[...] Want to share resources, hook them up to a LAN. A group of us have an A1000, are planning on getting an A2000, and may even possibly also get an A500. Which LAN would you suggest we use so we could "share resources"? The reason I ask is that I have not seen any advertisements for LANS in the amiga journals. The primary need would be for file sharing. Optimally, setting up the 2000 with a massive hard disk for use as a server, and having the 1000 and 500 as "diskless" (well they'd have their floppy, but you know what I mean) would be really nice and cost effective. But I have not seen any software/hardware that could do this. Of course, we could get that Ethernet board ($500 ?) that has been mentioned on the net, and hook the amigas up to our Unix box. But that is really not a very attractive idea because the unix box has very little disk space, and the boards are just too expensive. What would be nice would be some sort of serial-port lan, such as are advertised for the IBM PC and such. These connect all serial ports in a ring, and have software to route files and such from the server through each machine until it gets to the requesting machine. Is anything like this available? Summary: We want info on a cheap LAN, or in fact any LAN for amigas. Thanks in advance for any information. -- Dan Green -- ARPA: hsgj@tcgould.tn.cornell.edu UUCP: ihnp4!cornell!batcomputer!hsgj BITNET: hsgj@cornella
ugmiker@sunybcs.uucp (Michael Reilly) (11/18/87)
In article <516@mcdsun.UUCP> fnf@mcdsun.UUCP (Fred Fish) writes: >In article <2803@cbmvax.UUCP> daveh@cbmvax.UUCP (Dave Haynie) writes: >>in article <5294@ccicpg.UUCP>, harald@ccicpg.UUCP ( Harald Milne) says: >>> Although the Amiga is multitasking, and not multiuser,........ >>> I call it multitasking without the excess baggage! >> >>I'm REAL GLAD someone mentioned this too. Every time someone starts to talk >>about how neat it would be to run multiuser stuff on their Personal Computers, >> [stuff deleted...fnf] >>Multiuser is the same kind of thing. If you can't use all the power of your >>Personal Computer yourself, get a cheaper PC. > >Well, in general I agree with the premise that a personal computer should >be allocated to a single individual, but this really doesn't mean that >having multiuser capabilities isn't useful. . .[stuff deleted about sun logins ] . >Thus just because the computer has multiuser capabilities doesn't mean >that you have to have more than one user active at a time. > >-Fred Fred, wouldn't this really be equal to bootoing up with a different "startup-sequence" each time you want to "protect" yourself?? Or even better, just have a different ".login" sourced for each different "person" you want to be :-)... This way, you can have, lets say 3 shells running 3 different "people", but all you, and all with different protection levels, and priority setups.... when you use the sun with different "people" do you usually have more than one of these logged on at a time, or just different windows, you open or close depending on how much protection you want , or how much of the system you want to limit yourself from messing up :-). "Multiusing" is cool, and good, but it is nice to have an amiga all to myself... mike p.s. I have a few different people using my amiga, a programmer, a person who uses it as a terminal, a person who uses it as a game machine, and a person who gets on it and HACKS... and they all are me..... just differenet disks to boot up with.... Michael (what am I wood??) Reilly University of Buffalo Computer Science -------------------------------------- CSNET: ugmiker@buffalo.CSNET INTERNET: ugmiker@{joey,marvin}.cs.buffalo.edu UUCP: ..!{nike|watmath,alegra,decvax}!sunybcs!ugmiker BITNET: ugmiker@sunybcs.BITNET <-OR-> ACSCMPR@ubvmsc.BITNET
grr@cbmvax.UUCP (George Robbins) (11/18/87)
In article <6594@sunybcs.UUCP> ugevan@joey.UUCP (Evan Kahn) writes: > > I was at a local C-A dealer yesterday and spoke to an official rep from > Commodore. Specifically, I wanted to know when KS 1.3 would be available and > found out thatit isn't schedualed for release until late next quarter (March). > At any rate we got to talking and I mentioned to him that I was in support of > bootable firmware as opposed to it being in ROM. He concurred and informed me > that there is speculation that future Amigas may have EEPROMS to hold KS. > ^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^ Maybe the distant future. EEPROM technology still lags other memory technologies by quite a bit. A single 64 K-bit EEPROM chip costs more than a 2 M-bit ROM, and even assuming cost/density parity with static ram (256 K-bit) it would add several hundred dollars to the retail price of the system. > Apparently, a reason why KS was put into ROM was to quell fears of > software producers, after all why should they produce a package for an OS that > is rather variable; they will forever be providing patches. Sure the developers wish the software/hardware would *NEVER* change, but the real reason is simply a cost issue. A WCS approach is nice, but the cost to every user has to be weighed against the benefit to the average user and the actual cost/difficulty of implementing a ROM based upgrade. Future versions of the operating system could have support for both replacing ROM resident modules with updated versions with RAM and/or running Kickstart entirly from RAM. It should be pointed out the the A1000 was originally designed to contain Kickstart in ROM and that the RAM/ROM tower aka WCS was only added because software development was lagging far behind hardware development and there was little hope of delivering a stable/ROMable release of the operating software by the launch date. Deification of the WCS as one of the Amiga's golden features developed after the fact. > Do you guys out there think that such an EEPROM card could be made for > the 2000 ? It's not hard to develop an EEPROM, or more affordably a battery- backed-up CMOS RAM or EPROM tower or MMU-slot card to replace the Kickstart ROM. The question is really whether this is an appropriate and cost effective solution to a general problem, or just a useful tool with limited general appeal. -- George Robbins - now working for, uucp: {uunet|ihnp4|rutgers}!cbmvax!grr but no way officially representing arpa: cbmvax!grr@uunet.uu.net Commodore, Engineering Department fone: 215-431-9255 (only by moonlite)
phil@titan.UUCP (11/18/87)
In article <5294@ccicpg.UUCP> harald@ccicpg.UUCP ( Harald Milne) writes: > I am glad somebody finally said this. The Amiga does not have the >massive context switch overhead involved with user space and virtual memory >maps. Context switching virtual memory need not be expensive. It's just that the way Berkeley implemented it, it is. >Virtual UNIX on the Amiga or the Sun or the Mac II will suck, and cost ^^^ ^^^^ ^^^^ >a lot. Assuming that you mean Unix with virtual memory (and not virtual-machine Unix :-), that has existed on the Suns for as long as Sun 2's have existed. And it doesn't "suck" unless your workstation has less than 4 meg of real memory (Suns that support more than one or two users need more like 8 or 16 meg). > Although the Amiga is multitasking, and not multiuser, this is >an advantage. There is no reason to support the multiuser feature of UNIX >on the Amiga, simply since it isn't. (After all, it is MY machine) Once you have multitasking, multiuser is trivial. Provided you are willing to take the ITS route and dispense with useless formalities like userids and file ownership. All you need is an intelligent SER: driver (note that the standard one is NOT very intelligent) and some serial lines. >> As an extreme example, look at Sun workstations... > That is a very good example. No, it is a bad example. See my previous posting on this subject. >To bad this is the street Apple >is walking down on for the Mac II. Boy do they have a few suprises! I >won't even mention the astronomical costs to accomplish this! You mean, like an 80 meg hard disk, an MMU, an extra 4 meg of memory, and the actual OS itself? >UNIX on micros is silly Correct! But remember: Unix is a poor example of a virtual memory operating system, and SunView is a poor example of a Unix-based windowed environment workstation. William LeFebvre Department of Computer Science Rice University <phil@Rice.edu>
sean@ms.uky.edu (Sean Casey) (11/19/87)
In article <468@ra.rice.edu> phil@Rice.edu (William LeFebvre) writes: [without providing a shred of supporting evidence] >Correct! But remember: Unix is a poor example of a virtual memory >operating system, and SunView is a poor example of a Unix-based >windowed environment workstation. My experience with the former has been the opposite. Perhaps Mr. LeFebvre would care to support his statements with some proof. -- -- Sean Casey sean@ms.uky.edu, {rutgers,uunet,cbosgd}!ukma!sean -- (the Empire guy) sean@ms.uky.csnet, sean@UKMA.BITNET -- University of Kentucky in Lexington Kentucky, USA -- "Inconceivable!"
harald@ccicpg.UUCP (11/19/87)
In article <516@mcdsun.UUCP>, fnf@mcdsun.UUCP (Fred Fish) writes: > In article <2803@cbmvax.UUCP> daveh@cbmvax.UUCP (Dave Haynie) writes: > >in article <5294@ccicpg.UUCP>, harald@ccicpg.UUCP ( Harald Milne) says: > >> Although the Amiga is multitasking, and not multiuser, this is > >> an advantage. There is no reason to support the multiuser feature of UNIX > >> on the Amiga, simply since it isn't. (After all, it is MY machine) > >> I call it multitasking without the excess baggage! > > > >I'm REAL GLAD someone mentioned this too. Every time someone starts to talk > >about how neat it would be to run multiuser stuff on their Personal Computers, > > [stuff deleted...fnf] > >Multiuser is the same kind of thing. If you can't use all the power of your > >Personal Computer yourself, get a cheaper PC. > > Well, in general I agree with the premise that a personal computer should > be allocated to a single individual, but this really doesn't mean that > having multiuser capabilities isn't useful. Very often you want to use > the multiuser protection features to protect you from yourself, to set > up alternate environments for doing different sorts of things, etc. I have yet to this day ever had a need to do this. Could you elaborate as to why you would do this with UNIX? Ok, you guessed my previous responsibilities. Yes, system administrator for a bunch of UNIX neophytes. Under NFS, you can mount filesystems to different USER ID's and the proper user protections apply. As a previous administrator, I know a bit about system security. As for protecting me from myself, that's not possible. I have instantaneous acces to root priviledges without su'ing or knowing the root password. Don't ask me how, it's just that BIG security hole in UNIX! You just have to be root once! 8^) Not hard on a multiuser system! Anyway that's not the point. The point is delete privileges. > For example, even though I have a Sun-3 all to myself at work, I still have > several different logins that I use depending upon what I want to work on > at the time. Each provides a slightly different environment and different > permissions for what can and can't be done with the system. Covered under NFS. And even more elegantly! > Running a multitasking system without multiuser capabilities is equivalent > to running as root all the time on a Unix system, something that VERY few > experienced Unix people would do. That's not true. Just use the rarely used "deletable" file protection and you can rm * to your hearts content, it won't happen. Again we are into notions of users, and there is NO protection of DELETION in UNIX from yourself Not to mention root privileges. If this isn't enough, I've run the shell tied to the AUX: port with special filtering, it's like multiple terminals I have at work, they just don't window! It's kinda of multiuser (that is you can use 2 terminals at the same time) meaning I can type on 2 consoles at the same time. 8^) > Thus just because the computer has multiuser capabilities doesn't mean > that you have to have more than one user active at a time. Again, under NFS it's no problem. Mutiple rlogins. I don't need a SUN to do that! > -Fred > -- > # Fred Fish hao!noao!mcdsun!fnf (602) 438-3614 > # Motorola Computer Division, 2900 S. Diablo Way, Tempe, Az 85282 USA -- Work: Computer Consoles Inc. (CCI), Advanced Development Group (ADG) Irvine, CA (RISCy business! Home of the CCI POWER 6/32) UUCP: uunet!ccicpg!harald
joe@dayton.UUCP (11/20/87)
In article <5537@ccicpg.UUCP> harald@ccicpg.UUCP ( Harald Milne) writes: >In article <516@mcdsun.UUCP>, fnf@mcdsun.UUCP (Fred Fish) writes: [ stuff deleted -jpl ] >> Very often you want to use >> the multiuser protection features to protect you from yourself, to set >> up alternate environments for doing different sorts of things, etc. > > I have yet to this day ever had a need to do this. Could you elaborate >as to why you would do this with UNIX? > [ more stuff deleted ] > As for protecting me from myself, that's not possible. I have >instantaneous acces to root priviledges without su'ing or knowing the root >password. Don't ask me how, it's just that BIG security hole in UNIX! You >just have to be root once! 8^) Not hard on a multiuser system! Anyway that's >not the point. The point is delete privileges. > [ ditto ] >> Running a multitasking system without multiuser capabilities is equivalent >> to running as root all the time on a Unix system, something that VERY few >> experienced Unix people would do. > > That's not true. Just use the rarely used "deletable" file protection >and you can rm * to your hearts content, it won't happen. Again we are into >notions of users, and there is NO protection of DELETION in UNIX from yourself >Not to mention root privileges. > I think Harald isn't taking into consideration the fact that accidentally deleting a file isn't the only sort of protection from oneself one might like. For instance: o Overwritting a file with garbage isn't deleting a file. o Crashing the system 'cause you forgot to initialize a pointer... There are a variety of subtle differences of the second one. I'd hate to have a program running in the background, doing something useful for me, while another program is accidentally fiddling in the 1st guy's memory. Long hours could be spent debugging the wrong program. I'd also like to point out that the UNIX OS isn't the greatest thing since 3rd generation languages. It's better than most of the OS's I've used, at least from my point of view, but there are some things that aren't done "right". So if someone says "Porting some of the UNIX multi-user features..." doesn't mean "Porting only those features from UNIX..." Nothing wrong with adding the "DELETE" bit. Also nothing wrong with adding "SYSTEM" privs similar to those in VMS. (You have world, group, user, and system sets of bits, although those with system privs can usually bypass all checking if they really *want* to...) In any case, having the operating system protect you from programming bugs isn't as good as not having programming bugs, but it sure can help in the development phase if the machine doesn't crash every time your program would otherwise "core dump" in UNIX. -- UUCP: rutgers!dayton!joe Dayton Hudson Department Store Company ATT : (612) 375-3537 Joe Larson/MIS 1060 (standard disclaimer...) 700 on the Mall Mpls, Mn. 55402
peter@sugar.UUCP (Peter da Silva) (11/21/87)
Even if you don't want to run a BBS, it's always nice to be able to phone home and get something like this: # ATDT*70,1-713-933-2440 # CONNECT # # Eat or be eaten. # System name: sugar. # # (new bbs users enter new) login: peter # Password: <you gotta be kidding, right?> # # The few. The proud. The programmers. # # You have mail. # Meditation for the day: # # The Ranger isn't gonna like it, Yogi. -- -- Peter da Silva `-_-' ...!hoptoad!academ!uhnix1!sugar!peter -- Disclaimer: These U aren't mere opinions... these are *values*.
peter@sugar.UUCP (Peter da Silva) (11/22/87)
In article <360@usl-pc.UUCP>, jpdres10@usl-pc.UUCP (Green Eric Lee) writes: > In message <17218@glacier.STANFORD.EDU>, jbn@glacier.STANFORD.EDU (John B. Nagle) says: > > 1. Given the way that RAM prices are declining while > > disk access times are not improving, virtual memory > > looks like an idea whose time has passed. > Only if you have a single-tasking operating system. Certainly you can > get enough physical memory nowadays to run ANY respectable program. > But what if you have FIFTEEN 2 megabyte programs loaded up?... Swap them. I know swapping is not as chic as paging, but it should be possible. It requires fewer smarts on the part of the operating system, because the working set for any program is either in or out of memory. It also doesn't incur the overhead of page faulting. On the other hand, it does require a lot more I/O per swap. Here's my fantasy for the Amiga: 68020 with MMU. NO VM. Task address space: 0-1M Chip memory, shared and private. 1M-16M I/O and Shared fast memory. 16M+ Mapped (managed) private memory. Not all of 0-16M is addressible by every task, of course. Just stuff that's MEMF_PUBLIC. The stuff in private memory can be swapped out. The program won't know or care if it's in a different place in real memory when it gets back. Give it a signal (SIGB_SWAPPED) when it gets back in, so it can handle any cleanup. Of course this may all be really running in whatever memory you have, both inside and outside 16M. Add another Alloc bit. MEMF_SYSTEM. Like MEMF_PUBLIC but not shared by other tasks unless they've got the system flag set in their TCB. This should be completely compatible with existing software, so long as it has been scrupulous about MEMF_PUBLIC. -- -- Peter da Silva `-_-' ...!hoptoad!academ!uhnix1!sugar!peter -- Disclaimer: These U aren't mere opinions... these are *values*.
jdh@bsu-cs.UUCP (John Hiday) (11/23/87)
In article <2252@dayton.UUCP> joe@dayton.UUCP (Joseph P. Larson) writes: >> > [...] >I think Harald isn't taking into consideration the fact that accidentally >deleting a file isn't the only sort of protection from oneself one might like. >For instance: > > o Overwritting a file with garbage isn't deleting a file. > [...] Reading about protecting me from myself has reminded me of a VMS feature which I sorely miss on my Amiga -- version numbers on files. For those of you unfamiliar with VMS, all file names are suffixed with a version number. In this way, when you create a new version of a file you simply bump the version number up by one. Your old file is still there and is still called by the same name (not renamed to .BAK or moved to the t: directory or some other kludge). When accessing a file you do not have to remember what is the highest version number nor do you have to go to the trouble of giving the filename and version number. A reference to a file by just the name (no version specification) will get you the highest version. Of course if you want to play with a version which is not the highest you can explicitly state what version you want. To keep things tidy (so that you don't fill an entire disk with every version of a file made in the past 10 years) the number of backup versions that the system should retain is a user controllable file attribute. For example: $ EDIT IMPORTANT.FILE *delete begin:end *exit 0 lines written to IMPORTANT.FILE;2 $ DIR/SIZE IMPORTANT.FILE IMPORTANT.FILE;2 0 IMPORTANT.FILE;1 1000 $ TYPE IMPORTANT.FILE (defaults to highest version which is empty) $ DELETE IMPORTANT.FILE;2 (deletes just the new, empty version) $ TYPE IMPORTANT.FILE (the old ;1 now the highest) Important stuff still here... I realize this would mean adding another special character and that it might cause problems with the way filenames are hashed, but I think that it would be a useful feature to at least consider. -- == John Hiday UUCP: <backbones>!{iuvax,pur-ee,uunet}!bsu-cs!jdh == Ball State University / University Computing Services GEnie: JDHIDAY == Muncie, IN 47306
daveh@cbmvax.UUCP (11/23/87)
in article <2946@batcomputer.tn.cornell.edu>, hsgj@batcomputer.tn.cornell.edu (Dan Green) says: > Summary: We want info on a cheap LAN, or in fact any LAN for amigas. > Thanks in advance for any information. You already know about the AmeriStar Ethernet/Arcnet stuff, which certainly qualifies as a LAN, though not CHEAP, for the Amiga. This does do Amiga-to- Amiga as well as Amiga-to-Sun, so it does what you want, only not as cheaply. I know of at least two third party groups working on LANs that would definitely fit the cheap category, and of at least two more that sound like they are thinking in this direction. I can't say anything about these until they're publicly announced, which probably means not until AmiExpo time at the earliest. > -- Dan Green -- Dave Haynie Commodore-Amiga Usenet: {ihnp4|caip|rutgers}!cbmvax!daveh "The B2000 Guy" PLINK : D-DAVE H BIX : hazy "I can't relax, 'cause I'm a Boinger!"
phil@titan.rice.edu (William LeFebvre) (11/23/87)
In article <7731@g.ms.uky.edu> sean@ms.uky.edu (Sean Casey) writes: >In article <468@ra.rice.edu> phil@Rice.edu (William LeFebvre) writes: > >[without providing a shred of supporting evidence] > >>Correct! But remember: Unix is a poor example of a virtual memory >>operating system, and SunView is a poor example of a Unix-based >>windowed environment workstation. > >My experience with the former has been the opposite. Perhaps Mr. LeFebvre >would care to support his statements with some proof. Ok. I'll be more specific. Berkeley 4.x Unix is a poor example of a virtual memory implementation. Do you want exmaples of what is better? How about VMS? Forget the lousy user interface---I'm talking strictly virtual memory handling. Does Unix use a working set model? Does it make any attempt to prevent humongous Lisp and Prolog jobs from destroying everyone's performance? Not in my experience. But VMS does. And what about swapping strategies? Some would argue that you don't need to handle swapping separatly from paging. I might be inclined to agree. But that's beside the point. BSD does swapping, but it allocates swap space using the "buddy block" system. Can you say "massive fragmentation"? I knew you could. When VMS gets memory constrained, it just gets slow, penalizing the larger proccesses. But when Unix gets memory constrained, it gets unusable! We have had horrible experiences here at Rice with just 10 people trying to use the same Vax 750 running BSD: the students are working on Modula II programs, they all use Gosling's emacs to edit, and two people cannot reliably compile at the same time. Even with 8 megabytes (the most memory you can put in a 750). And what about Mach? I'm sure that it will have pretty much the latest and greatest in a virtual memory implememtation. Unfortunately, I don't have more information about it. Do you think that all research work in virtual memory systems stopped when BSD came out? Come on! It only makes sense that something better exists today, simply because of progress in the field. This has really diverged. Forgive me. William LeFebvre Department of Computer Science Rice University <phil@Rice.edu>
pla@zippy.eecs.umich.edu (Paul Anderson) (11/24/87)
>Swap them. >I know swapping is not as chic as paging, but it should be possible. certainly is, but you might as well go the rest of the way. > >Here's my fantasy for the Amiga: >68020 with MMU. NO VM. There is no point in providing an MMU if tasks can still nuke each other. >-- Peter da Silva `-_-' ...!hoptoad!academ!uhnix1!sugar!peter >-- Disclaimer: These U aren't mere opinions... these are *values*. I have lots of respect for your fantasies, but the major thing that separates a multi-tasking machine like my Amiga from a multi- tasking machine like my Apollo is interprocess *protection*. The whole point of a MMU is to allow potentially buggy programs to run without making other programs crash. While protected memory can do this, you might as well go whole hog and add virtual (address remapping) memory capability. And, if you are going to do that, you might as well add paging, too, since it is a good way of insulating you from memory shortages, especially ones that might be transient in nature. Granted, that isn't going to fix disk space shortages, but those are generally cheaper to deal with than memory shortages, anyhow. The Amiga is a wonderful machine, given its lack of a MMU, but if it is going to try and compete in functionality with Suns and Apollos, it is really going to have to take full advantage of something like the 68851 PMMU. My feeling is that it is a complete waste of time to talk about adding an MMU without removing the need for MEMF_PUBLIC, since no amount of address translation is going to overcome this "security" hole. I don't mind having publicly accesible memory, mind you, but if the OS depends on it, that is bad news. Sorry for the length... Paul Anderson
daveh@cbmvax.UUCP (Dave Haynie) (11/25/87)
in article <517@zippy.eecs.umich.edu>, pla@zippy.eecs.umich.edu (Paul Anderson) says: > My feeling is that it is a complete waste of time to talk > about adding an MMU without removing the need for MEMF_PUBLIC, > since no amount of address translation is going to overcome > this "security" hole. I don't mind having publicly accesible > memory, mind you, but if the OS depends on it, that is bad news. You can't have everything. If you want purely protected tasks with no MEMF_PUBLIC associated with them, then you have to pass messages by value instead of by reference. Then all of a sudden, your nice, fast AmigaOS starts turning into a slow pig like the things that run on Apollos and Suns. Maybe as an option. Or maybe someone will port one of the other OSs over for folks who want it; they say nearly any popular OS will run on an '851 based system. > Paul Anderson -- Dave Haynie Commodore-Amiga Usenet: {ihnp4|uunet|rutgers}!cbmvax!daveh "The B2000 Guy" PLINK : D-DAVE H BIX : hazy "I can't relax, 'cause I'm a Boinger!"
dragon@trwspf.TRW.COM (Roger Vossler) (11/26/87)
In article <1570@bsu-cs.UUCP> jdh@bsu-cs.UUCP (John Hiday) writes:
*Reading about protecting me from myself has reminded me of a VMS
*feature which I sorely miss on my Amiga -- version numbers on files.
*
[deleted explanation of how version numbers worked]
*
*To keep things tidy (so that you don't fill an entire disk with every
*version of a file made in the past 10 years) the number of backup
*versions that the system should retain is a user controllable file
*attribute.
The trouble was that users tend not to delete anything until forced
to do so at gunpoint. The result was that disks filled up quickly
and systems administrators went mad trying to stem the tide. I
sincerely hope I never see a version number on a file again. But
that's only my opinion - no flames, please.
Actually, version numbers were invented by DEC marketing types in
the hopes of selling more disk drives. They succeeded beyond their
wildest imagination! 8-)
--
-- Roger Vossler
TRW, Bldg O2-1395, One Space Park, Redondo Beach, CA 90278
BIX: rvossler UseNet: dragon@trwspf.trw.com
ATT: 213.535.2804 ....!sdcrdc!trwrb!trwspf!dragonroot@sbcs (Root) (11/26/87)
In article <2846@cbmvax.UUCP>, daveh@cbmvax.UUCP (Dave Haynie) writes: > in article <2946@batcomputer.tn.cornell.edu>, hsgj@batcomputer.tn.cornell.edu (Dan Green) says: > > Summary: We want info on a cheap LAN, or in fact any LAN for amigas. > > Thanks in advance for any information. > > You already know about the AmeriStar Ethernet/Arcnet stuff, which certainly > qualifies as a LAN, though not CHEAP, for the Amiga. This does do Amiga-to- > Amiga as well as Amiga-to-Sun, so it does what you want, only not as cheaply. > If you look at the prices for IBM Ethernet cards with companion software, I think you'll find that the Ameristar Ethernet product is cost competitive. The example I like to use is Sun's PC-NFS product: it's about $900 or so with Ethernet controller card. > I know of at least two third party groups working on LANs that would definitely > fit the cheap category, and of at least two more that sound like they are Let's consider the usual alternatives for "low cost" networks - at least the ones I've seen: o Serial port networking: usually limited to a two node network due to the limitations of RS-232. Can be expanded by going RS-422 or by using a multi-port serial board as a hub. Physical layer costs -------------------- Serial port, 2 nodes: $15 for a cable Serial port, 8 nodes: ~$500 (8 port hub) + $15/node (cable) Appletalk: ~$174 (board) + ~$20/node (cabling) Comments: --------- I've seen at least one IBM PC product that manages ~113 kBits/sec by hanging the machine in a polling loop catching the bytes as they come off the port - with multitasking on the Amiga, this is not an an option. From the experiments I've run on the machine, you would probably be hard pressed to get beyond ~25kbits/sec using the standard Amiga serial hardware. You'll probably find that transparent file services at 25 kBits/sec are very unacceptable. The answer to both speed and device count problems is to go Appletalk, but this requires some (limited) hardware. Eventually, you'll find out what the Mac people already know - Appletalk's ~200 kBit/sec speed just doesn't satisfy the needs of classroom size installations that use file servers. o Parallel port networking: I've heard (over the years) of a couple groups working on parallel port based networks. All the the efforts are pretty limited in scale (distance & device count), due to cable & signal level problems. I few weeks back, Matt Dillon (sp?) at Berkeley claimed to be working on a 2 node network of this type. Cost: ~$25 for a cable between 2 nodes. Comments -------- For small networks, parallel ports are probably the way to go, as you have enough handshaking to do flow control. Haven't looked at the Amiga parallel port hardware to see whether it can be scaled beyond 2 nodes (ie if the ports are open drain, they probably can be scaled) network. Of course, inter node distance would be a killer since shielded multiconductor cable is very expensive. o SCSI port networks: requires hardware, is distance & number of devices limited. Expensive cabling (especially if you're a real company and have to worry about passing FCC). Cost: ~$100 (how much is CLtd's board??) + $45 (cable, per node) Comments -------- Same as parallel port network, but with guaranteed expandability to at least 7 other nodes. Same (or worse) problem with cabling. o Arcnet network: requires hardware, is limited to ~20 nodes for certain types of transceivers. Cost: ~$400 + ~$15 (cable + "T") Comments -------- Arcnet is very much like a *fast* serial port network - each byte is sent as 11 bits; the extra 3 bits are framing, like you see in RS-232 communications. Max bandwidth (theoretical) is therefore 8/11 * 2.5 mBits/sec. Arcnet is nice because of the variety of transceiver types - cheap transceivers do 4 nodes using a resistor hub, the ones we use allow a bus architecture of 20 nodes, and there are fiber optic transceivers and hubs available for noisy environments. Arcnet is popular in Europe. o Ethernet network: requires hardware, is limited to ~30 nodes (cheapernet) or 100 nodes/seg (Ethernet). Cost: $699 + ~$15 (cable + "T") [cheapernet] $699 + ~$60 (drop cable) + ~$200 (xcvr) [ethernet] Comments -------- The folks buying Ethernet are generally doing so because they have such networks installed in house, and need compatibility. Cost is generally not a factor, since they tend to buy more than one and get a price break on software/hardware. Of course, there are many other media options available, eg 'PC token ring, Starlan, etc, but I've kept the list to projects I've heard about. Also note that the above costs are for the physical media. The software is almost always charged "per node" and tends to run from ~$50/node to >$300/node. From the above table, the lowest cost solution for reasonably sized networks is to go with Appletalk or something very similar. I arrived at the $174 figure by considering the hardware support for Appletalk: Amiga bus I/F: $8 (pal, buffer, comp, latch) Circuit board: $20 (double sided, moderate quan) 8530 SCC: $10 422 xcvrs: $5 misc: $15 (connectors, resistors, etc) ---- $58 End cost to customer (* 3 to cover assembly, test, profit, overhead): $174 Software, per node: ~$25 ---- $199 Of course, it is possible to trim the costs back a bit if there is sufficient volume. Let's be generous and say that a card could be sold for ~$125. Now the big question is: can I make money at such a price point? Let's say there are 1 million machines out there and a whopping 1% need to be networked: .01 * 1000000 = 10000 machines to be networked. Let's be wildly optimistic and say we'll capture 1/2 the network market for the Amiga. That's now 5000 machines that I can sell to. So we have: 5000 * .70 * ($125 + $25) = $612500 (gross) ^-- dealers discount is 30 % of list.. Let's say we can do that in a year. Our hypothetical gross profit on sales of $612500 looks like this: $612500 ($20000) (office, power, electricity, maintenance, 1 year) ($10000) (telephone, 1 year) ($20000) (advertising, couple mags, 1 year) ($10000) (3 shows, 2 people, 1 year) ($5000) (support services, BBS costs, etc) ($306000) (cost to produce 5100 boards - at $40 parts cost, $10 assembly, $10 misc. The extra 100 units are your spares, show units, evaluation units, and yield) ($5000) (Misc office expenses, eg mailings, UPS, etc) ------- $236500 ($25000) (Amortized engineering costs, ie board layout, FCC testing, development hardware/software, licenses if any, personnel time, etc) ------- $211500 ($9000) (secretary, 1 year @ $4/hr) ($75000) (2 engineers @ $30K + 25% overhead) ------- $127500 (not too bad, but what are you doing next year? How much of this will be committed to capital equipment, R&D, support salaries, etc). The above figures vary quite a bit depending on the organization, locale, etc. They also neglect some important areas, eg interest expense. Anyways, you can begin to see why any low volume products cost a lot of money - and, let me tell you from experience, the market for networking products isn't close to 10000 (or even 5000) units per year. The long term solution to low cost networking is to get Commodore to include something like Appletalk or Arcnet as a motherboard option on the next machine. With the media problem out of the way, software will pretty much take care of itself, especially if they would provide a cheap transport protocol with the OS. From my experience with the characteristics of the Amiga network product market, I doubt you'll see hw/sw package for less than ~$150 or so, especially if you want more than ~5 machines in one network. Rick Spanbauer SUNY/Stony Brook (& Ameristar)
peter@sugar.UUCP (Peter da Silva) (11/28/87)
In article <517@zippy.eecs.umich.edu>, pla@zippy.eecs.umich.edu (Paul Anderson) writes: > >Here's my fantasy for the Amiga: > >68020 with MMU. NO VM. > There is no point in providing an MMU if tasks can still nuke each > other. Again, VM != mapped memory or protected memory. > I have lots of respect for your fantasies, but the major thing that > separates a multi-tasking machine like my Amiga from a multi- > tasking machine like my Apollo is interprocess *protection*. One major thing that seperates Suns & Apollos from my Amiga is they don't guarantee any degree of binary object portability. We can't go to a new machine if it means nuking all the software currently out. Not on a consumer box. Some design flaws are now cast in concrete. It's a pity, but it could be a lot worse. Look at the design flaws IBM has to deal with. So: interprocess protection, yes. > The whole point of a MMU is to allow potentially buggy programs > to run without making other programs crash. While protected > memory can do this, you might as well go whole hog and add > virtual (address remapping) memory capability. OK. Let's call what US have been calling VM paged memory. and what Y'ALL have been calling VM mapped memory. Deal? ALL the current software out there requires that memory not be remapped, so that's out. Paging, it seems, may not be. > And, if you > are going to do that, you might as well add paging, too, > since it is a good way of insulating you from memory shortages, > especially ones that might be transient in nature. Paging is a LOT more work than memory protection. However, C= seems to have a good paging scheme in mind. ModifyIDCMP(MMU, MMU->IDCMPFlags | WAIT_AND_SEE); > My feeling is that it is a complete waste of time to talk > about adding an MMU without removing the need for MEMF_PUBLIC, > since no amount of address translation is going to overcome > this "security" hole. I don't mind having publicly accesible > memory, mind you, but if the OS depends on it, that is > bad news. Well, you're not gonna get rid of MEMF_PUBLIC without breaking all the software currently out there. -- -- Peter da Silva `-_-' ...!hoptoad!academ!uhnix1!sugar!peter -- Disclaimer: These U aren't mere opinions... these are *values*.
bakken@hrsw2.UUCP (David E. Bakken) (11/30/87)
In article <1570@bsu-cs.UUCP>, jdh@bsu-cs.UUCP (John Hiday) writes: > > Reading about protecting me from myself has reminded me of a VMS > feature which I sorely miss on my Amiga -- version numbers on files. > Please don't do that CA. I back up my work directories every 3-4 hours to a floppy and that seems to do quite fine. If version numbers are added please make them optional - I don't want to pay the disk space for this. -- Dave Bakken uw-beaver!ssc-vax!shuksan!tahoma!hrsw2!bakken (boring) disclaimer: these views are my own, not my employers.
pla@zippy.eecs.umich.edu (Paul Anderson) (12/01/87)
In article <1131@sugar.UUCP> you write: >In article <517@zippy.eecs.umich.edu>, pla@zippy.eecs.umich.edu (Paul Anderson) writes: >> >Here's my fantasy for the Amiga: >> >68020 with MMU. NO VM. >> There is no point in providing an MMU if tasks can still nuke each >> other. ... more and more VM discussion eliminated for brevity My point of view is as follows: I have ported something close to .5 million lines of C and FORTRAN code to the Apollos. I am in the process of porting about 150,000 of those lines (Berkeley's Magic, written in C) to the Amiga. I have found that as the architecture of micro computers gets more sophisticated (Amiga graphics, for example), people like myself find it easier and easier to port workstation or mainframe code down to the smaller machines. One significant thing I've learned from these efforts, is that in general, as the machine becomes more sophisticated, people will expect more of it. That typically is going to mean larger and larger programs, such as Magic. Unfortunately, as programs, like Magic, become larger and larger, it gets a whole lot harder to verify that these programs are bug free. Introducting a system that has the added expense (chip cost, board space, extra wait states) of Virtual memory, but without one of the most important benefits is ludicrous. Building a machine *with* virtual memory capabilities but *without* interprocess protection is, in my opinion, a contradiction in terms. My experience has been that many other people share this opinion, as well. The Apollo provides a wonderful goal for the Amiga to emulate: it is a high quality workstation with Extremely good software development faculities, and has many features that are a very significant improvement over Unix. Some of these are related to file system extensibility (which the Amiga should do quite nicely at, too), and others relate to the run time library linking that allow for dealing with large libraries in a quite sensible manner. Now I don't for a minute think that you can have an Apollo for the price of an Amiga, but it would be nice to have some of the more important features namely: full interprocess protection, which to me implies using the full functionality provided by the 68851 PMMU (paged memory management unit). Peter, I understand your points about paging, swapping and VM, but I'd like you to understand my point that anything less than virtual memory+paging+interprocess protection is a hack. It isn't completely useless, otherwise I would not have bothered porting Magic to the Amiga, but charging me and thousands of others for an MMU, and then not using it properly is bad news. For you others concerned about performance of Apollos and Suns, I suggest you try using an Amiga and an Apollo side by side for a year or two. My experience is that the Amiga is about 1/4 the effective system speed of my Apollo DN3000. An awful lot of this has to do with the quality of the software on the system, including compilers, debuggers, unix-type utilities, and other related things. Anyone that thinks that the quality of the software on the Amiga even remotely approaches the quality of the system software on the Apollo really should try porting 10 or 15 megabytes of software to both before claiming it as fact. I know little about Suns, so I won't pretend to speak for them. I don't know anything about real-time computing, either, so don't take this paragraph in that context. > Your comment about software breaking without MEMF_PUBLIC is well taken, also. Someone earlier (lost the article, sorry) mentioned that message passing OS are wonderful. Well, they are, but things like MEMF_PUBLIC are part of the price we paid for AmigaDOS. My personal suggestion is for Commodore to forget trying to slowly add virtual memory to AmigaDOS, simply so that you can say you have it - it just isn't enough. It would be better to freeze what we know as AmigaDOS, and attempt to either make porting AmigaDOS programs to Unix as easy as possible, or create a new, or highly modified true virtual memory, paged operating system that also allows for the existence of one address space running a number of AmigaDOS processes. >-- >-- Peter da Silva `-_-' ...!hoptoad!academ!uhnix1!sugar!peter >-- Disclaimer: These U aren't mere opinions... these are *values*. Paul Anderson (standard disclaimer stuff, of course)
knurlin@trwspf.TRW.COM (Scott Karlin) (12/02/87)
In article <582@zippy.eecs.umich.edu> pla@zippy.eecs.umich.edu (Paul Anderson) writes: >to the Apollos. I am in the process of porting about 150,000 of those >lines (Berkeley's Magic, written in C) to the Amiga. I have found that ^^^^^^^^^^^^^^^^ This is very exciting! Please tell us more. Availability, etc... > > Paul Anderson -- Scott Karlin TRW Data Systems Lab Internet: knurlin@trwspf.trw.com ARPA: knurlin%trwspf@trwrb.trw.com USENET: ...!trwrb!trwspf!knurlin
dca@toylnd.UUCP (12/03/87)
> Ok. I'll be more specific. Berkeley 4.x Unix is a poor example of a > virtual memory implementation. Do you want exmaples of what is better? > How about VMS? Forget the lousy user interface---I'm talking strictly > virtual memory handling. Does Unix use a working set model? Does it make > any attempt to prevent humongous Lisp and Prolog jobs from destroying > everyone's performance? Not in my experience. But VMS does. And what > about swapping strategies? Some would argue that you don't need to handle > swapping separatly from paging. I might be inclined to agree. But that's > beside the point. BSD does swapping, but it allocates swap space using > the "buddy block" system. Can you say "massive fragmentation"? I knew > you could. > It is to laugh. I dare you to post this to unix-wizards, they would rip you to shreds. It is pretty easy given any paging system to find cases which will cause poor performance. What lies underneath the points made above is a difference in philosophy. You could argue that VMS's is superior I can and will argue the Unix is superior. By the way, VMS doesn't use the Working set model either since the working set is an idealization which can't be arrived at by static analysis or fixed allocation. Certainly the working set for a running process is frequently time variant. VMS 'working sets' is a statically allocated number of pages which must be available for a process to run and a hard limit on the number of pages which the process is allowed to use. I'm not clear exactly how they come up with these numbers but in my experience they are frequently not very good. > When VMS gets memory constrained, it just gets slow, penalizing the > larger proccesses. But when Unix gets memory constrained, it gets > unusable! We have had horrible experiences here at Rice with just 10 > people trying to use the same Vax 750 running BSD: the students are > working on Modula II programs, they all use Gosling's emacs to edit, and > two people cannot reliably compile at the same time. Even with 8 > megabytes (the most memory you can put in a 750). > How good does VMS run on a 750 with a similar number of people doing similar things. Give me a break! I may not have the I/O bandwidth but I've got more CPU power on the 3b1 I'm typing on. VMS is designed by bean counters for bean counters. Unix is designed by programmers for programmers. Programmers are interested in maximum utilization of the resources of the machine. If there is one job running on the machine then they want it all if there is 100 jobs running on the machine they want their piece of it. VMS is interested in stuffing as many people on a machine as possible and carefully limiting their use of resources. BSD uses a global page scheme where pages are allocated on a LRU basis. If you are the only process on the machine and you need a large amount of memory then you can efficiently utilize the entire machine. BSD will resort to swapping if paging performance degrades beyond a certain point. If you have to share the machine then performance will degrade but the memory of the machine will still be close to maximally utilized. VMS uses a local (yuck!) page scheme where pages are allocated on a FIFO basis (double yuck!). Your so called 'working set' must be available for your process to run and pages in your local set are not available for reuse on a global basis (even if you don't need them anymore). The fact is, a process that hogs memory on a BSD system probably wouldn't even run reasonably on a VMS system (unless of course it was given a hoggy working set size). Further evidence of this bean counter vs. programmer conflict is available in the scheduling priorities of a VMS system. VMS priorities divide processes into groups of 'those that get time' and 'those that get no time' unless there is some time which the 'those that get time' are not using. BSD divides processes into groups of 'those that get more time' and 'those that get less time'. Process niceing can be used on BSD processes to get performance similar to that of a VMS system without causing the negative effects of the fixed resource allocation strategies in VMS. It is ludicrous to be on a unloaded machine with a large process and be paging through a keyhole. On the VMS systems that I used there were large portions of the physical memory which had never seen a process. > > Do you think that all research work in > virtual memory systems stopped when BSD came out? Come on! It only makes > sense that something better exists today, simply because of progress in > the field. > Certainly BSD vm isn't the be all and end all of virtual memory systems. Holding up VMS as superior, however, is a bit odd. Hey, DEC didn't even put a reference bit on the VAX paging system because VMS uses FIFO and didn't need it, talk about neanderthal. David Albrecht
peter@sugar.UUCP (Peter da Silva) (12/03/87)
In article <582@zippy.eecs.umich.edu>, pla@zippy.eecs.umich.edu (Paul Anderson) writes: > Peter, I understand your points about paging, swapping and VM, but I'd > like you to understand my point that anything less than virtual > memory+paging+interprocess protection is a hack... Well, you apparently don't understand it, because I have never said I don't want interprocess protection. I also would like paging if I can safely turn it off (not lock a process into memory... turn it off completely) when I want to run real-time (like, in a video game). During program devlopment and for some soft real-time work it is an absolute win. > My experience is that the Amiga is about 1/4 the effective system > speed of my Apollo DN3000. An awful lot of this has to do with the > quality of the software on the system, including compilers, debuggers, > unix-type utilities, and other related things. An awful lot has to do with the fact that you're using a faster CPU with a faster bus and a faster hard disk, and you're not using TRIPOS. TRIPOS is a bug come to life, and has nothing to do with VM. It's an orthogonal issue. > Anyone that thinks that > the quality of the software on the Amiga even remotely approaches the > quality of the system software on the Apollo really should try porting > 10 or 15 megabytes of software to both before claiming it as fact. I never said nor hinted this. The quality of UNIX software and tools is awesome. Apollo's O/S seems to be in the ballpark. > Your comment about software breaking without MEMF_PUBLIC is well taken, > also. Someone earlier (lost the article, sorry) mentioned that message > passing OS are wonderful. Well, they are, but things like MEMF_PUBLIC > are part of the price we paid for AmigaDOS. I don't see where MEMF_PUBLIC is such a problem. How much of your code is public? What's the chance that in a protected system a bad pointer will hit it before the much larger proportion of protected memory? > My personal suggestion is for Commodore to forget trying to slowly add > virtual memory to AmigaDOS... freeze what we know as AmigaDOS... > [and get AmigaDOS emulator under UNIX, or UNIX/AmigaDOS under some > sort of combined system]. Nope. Get UNIX onto the Amiga, and then let people run with it while you get back to work on fixing AmigaDos. It's got advantages over UNIX. Real-time. Works with floppies only. Etc... Merge them when you KNOW you can do it right. -- -- Peter da Silva `-_-' ...!hoptoad!academ!uhnix1!sugar!peter -- Disclaimer: These U aren't mere opinions... these are *values*.
itkin@stsci.EDU (Elliot Itkin) (12/04/87)
Versions have another use, to prevent losing a file if the system dies at a crucial moment. If you don't have versions and the system should crash just as you are overwriting your old copy, you will lose both the old copy (half trashed) and the new one (only half written). By using the sequence: 1) write new file out to open disk space, 2) update directory, 3) delete old file (with appropriate substeps), no matter when you crash you will either have the old one, the new one or both. This use of versions was used by Univac way back when. The VAX "no version limit" is new. It is also faster than the ".bak" method because you only write the file once, not read-write (old to .bak) then write out new, which is three file traversals. You can achieve the same results by ping-ponging two files but which is the most current if you forget?
page@ulowell.cs.ulowell.edu (Bob Page) (12/11/87)
Wow! UNIX versus VMS wars in the Amiga group! And we used to argue about trivialities like the Atari ST. Let's port VMS to the Amiga. :-) dca@toylnd.UUCP (David C. Albrecht) wrote: >VMS is designed by bean counters for bean counters. Unix is designed by >programmers for programmers. And the Amiga OS? (no need to answer, ok?) ..Bob -- Bob Page, U of Lowell CS Dept. page@ulowell.edu ulowell!page "I've never liked reality all that much, but I haven't found a better solution." --Dave Haynie, Commodore-Amiga
michael@stb.UUCP (Michael) (12/12/87)
In article <1217@sugar.UUCP> peter@sugar.UUCP (Peter da Silva) writes: >I don't see where MEMF_PUBLIC is such a problem. How much of your code >is public? All of it. It was loaded by another process by LoadSeg(), which had to put it into memory accessable by two different processes. Michael -- : Michael Gersten ihnp4!hermix!ucla-an!remsit!stb!michael : sdcrdcf!trwrb!scgvaxd!stb!michael : "Copy Protection? Just say 'Off site backup'. "
peter@sugar.UUCP (Peter da Silva) (12/16/87)
In article <10001@stb.UUCP>, michael@stb.UUCP (Michael) writes: > In article <1217@sugar.UUCP> peter@sugar.UUCP (Peter da Silva) writes: > >I don't see where MEMF_PUBLIC is such a problem. How much of your code > >is public? > All of it. It was loaded by another process by LoadSeg(), which had to > put it into memory accessable by two different processes. Interesting point. I don't think it's unmanagable, though. You would have LoadSeg put the whole program into the parent's adress space until the parent starts it up. At that point the memory would be yanked out of the parent's adress space and stuck into the child's. The memory allocated by LoadSeg would have to be arranged in virtual adress space so this was possible. UnloadSeg would have to be privileged. For programs that didn't want to do this (overlays, for example) you'd have to run some sort of fixhunk over them. Electronic Arts wouldn't care much for this, I suspect. They're pretty big on protecting their badly-behaved software. Getting better, though. Alternatively, you'd implement a NEW loadseg that loaded a protected task, and have the new version of WorkBench and CLI use this. That way most programs would still benefit from protection, without antagonizing EA. > : "Copy Protection? Just say 'Off site backup'. " There you go again, destroying your credibility. -- -- Peter da Silva `-_-' ...!hoptoad!academ!uhnix1!sugar!peter -- Disclaimer: These U aren't mere opinions... these are *values*.