Relay-Version: version B 2.10 5/3/83; site utzoo.UUCP
Posting-Version: version B 2.10.1 6/24/83; site mit-eddie.UUCP
Path: utzoo!watmath!clyde!burl!ulysses!mhuxr!mhuxn!ihnp4!mit-eddie!barmar
From: barmar@mit-eddie.UUCP (Barry Margolin)
Newsgroups: net.micro.mac
Subject: Re: Re: A Finder Suggestion
Message-ID: <5025@mit-eddie.UUCP>
Date: Sun, 18-Aug-85 06:03:32 EDT
Article-I.D.: mit-eddi.5025
Posted: Sun Aug 18 06:03:32 1985
Date-Received: Fri, 23-Aug-85 21:17:31 EDT
References: <251@sask.UUCP> <2197@sdcrdcf.UUCP> <1771@reed.UUCP> <787@mcvax.UUCP> <1792@reed.UUCP>
Reply-To: barmar@mit-eddie.UUCP (Barry Margolin)
Distribution: net
Organization: MIT, Cambridge, MA
Lines: 49

In article <1792@reed.UUCP> nathan@reed.UUCP (Nathan Wilson) writes:
>There's another suggestion.  Why not have a "not available" button on
>the "please insert disk: ^0" dialog.

I second this!  We have two Macs sitting side-by-side at work, and
sometimes a disk that was ejected from one machine is in use in the
other when the first decides that the only thing it can think about is
loading that disk.

> This would actually make the
>VolumeName:FileName syntax generally usable since if you tried
>to write to a Volume that doesn't exist you could cancel it.

My belief is that Apple is trying to phase that out, not make it
"generally usable."

>  The
>only problem I see is during those painful multidisk swaps that
>usually only happen on a 128k machine (yes, Apple they do still
>exist).

Hear, hear!  They can get VERY annoying when using the Switcher
(especially if you accidentally configure the task's memory size too
small).  There is nothing worse than a thrashing computer in which the
paging is MANUAL.

>  This would also reduce the punishment for the simple
>error of ejecting the wrong disk when your copying a large file, or
>other such operations.

On a related note, why does the Mac always choose the wrong drive to
eject on two-drive systems?  I haven't really investigated extensively,
but I think it ejects the disk most recently loaded.  This usually is
the wrong disk to eject, as many applications like to alternate reading
stuff from the application disk and the system disk (the Hearts game I
use alot loads a system window template, then loads its own menu bar,
then loads the Desk Accessories menu, then loads its menu items, etc).
If both disks are inserted when I start the application then everything
runs fine, but if not, I end up swapping disks a half-dozen times.  For
years we have known that LRU is the closest approximation to the optimal
replacement algorithm (when there is no a priori information about usage
patterns), yet the MAC seems to use an MRU mechanism.  Are the
applications I have been using violating a convention (first load
private resources, then load system resources) that the Mac programmers
optimized for?
-- 
    Barry Margolin
    ARPA: barmar@MIT-Multics
    UUCP: ..!genrad!mit-eddie!barmar