Relay-Version: version B 2.10 5/3/83; site utzoo.UUCP Path: utzoo!mnetor!seismo!rutgers!mit-eddie!genrad!decvax!ucbvax!jade!eris!mwm From: mwm@eris.BERKELEY.EDU (Mike (My watch has windows) Meyer) Newsgroups: comp.sys.amiga Subject: Re: Shells. Message-ID: <3287@jade.BERKELEY.EDU> Date: Thu, 23-Apr-87 21:59:53 EST Article-I.D.: jade.3287 Posted: Thu Apr 23 21:59:53 1987 Date-Received: Sat, 25-Apr-87 18:37:34 EST References: <50@f.gp.cs.cmu.edu> <1213@ulowell.cs.ulowell.edu> Sender: usenet@jade.BERKELEY.EDU Reply-To: mwm@eris.BERKELEY.EDU (Mike (My watch has windows) Meyer) Organization: Missionaria Phonibalonica Lines: 45 In article <1213@ulowell.cs.ulowell.edu> page@ulowell.cs.ulowell.edu (Bob Page) writes: >In effect, it is a better idea if _you_ figure out what commands you >use all the time and want quick activation for. Put them someplace >in your ram disk - say RAM:C, and point the CLI (via the PATH command) >to look there first. It is dynamic, can be shared across CLIs >without problems, can be added to or deleted from easily. There's an even better way, that several people (me among them) have pointed out. It's called a "disk cache." Instead of having the CLI buffer commands, you have the disk driver buffer tracks - in fast ram, if needed. This solves the problems of two CLI's saving copies of a file, etc. I think the product WOW! is supposed to be this. It's also supposed to have a dialable cache size. Optimally, it floats the cache with memory useage, so if I do something large, the cache gets flushed so I can use it as real memory. Likewise, this is better than ram:. Instead of copying things to ram, they get put in the disk cache. Things you tend to use stick to the disk cache, things you don't use very often get flushed out. Which is (probably) what you want. I ran a z80 system with 1/2Meg of cache and two floppies, and got better edit/compile cycles than people running off of hard disk. Seems that the right things stuck to the disk between phases. In other words, I think that a disk cache is in all ways better than ramdisk. Unless you've got something you don't plan on touching very often, but want to _always_ be there. vd0: does that quite nicely, though. The only other lossage is that temp files might get "written through" to disk, even if they are never read off the disk. Well, you can't win them all. >The best idea, however is to rewrite AmigaDOG. I've never run into an OS for which that isn't true. But caching vital things can overcome a _lot_ of problems. Just ask anyone who's kicked the Unix disk cache from 15-30 buffers to 100+ buffers.