v132gcnx@ubvmsd.cc.buffalo.edu (John A Feinberg) (11/29/90)
Awhile back, someone said that you could boot off of an internal ROM 'disk' on the Mac Classic by holding cmd-opt-x-o (and waiting awhile) while the machine was starting up. Is this true?? Can you really start up a Classic without a floppy or hard drive? And if you can, does it have Appletalk on the ROM system? If that were true, the Classic could be used as part of the network, and the user wouldn't have to supply the system disk. Also, then the Classic wuold be usable with just one drive and no hard drive, too. John Feinberg SUNY Buffalo
boris@world.std.com (Boris Levitin) (12/02/90)
v132gcnx@ubvmsd.cc.buffalo.edu (John A Feinberg) writes: >Awhile back, someone said that you could boot off of an internal ROM 'disk' on >the Mac Classic by holding cmd-opt-x-o (and waiting awhile) while the machine >was starting up. Is this true?? Can you really start up a Classic without >a floppy or hard drive? And if you can, does it have Appletalk on the ROM >system? If that were true, the Classic could be used as part of the network, >and the user wouldn't have to supply the system disk. Also, then the Classic >wuold be usable with just one drive and no hard drive, too. MacWeek reported that the stripped-down System 6.0.2 in the Classic's ROM comes with client AppleShare. But of course you would not be able to run any INITs and I'm not sure how fonts are handled. Seems to me that this is an idea which needs some work before it becomes viable, and also one that would be attractive only to the most financially-desperate institutional user (given the slow speed of anything running off the server across AppleTalk).
mazu@terre.DMI.USherb.CA (Marc Mazuhelli) (12/05/90)
In article <1990Dec2.093816.26712@world.std.com> boris@world.std.com (Boris Levitin) writes: > >MacWeek reported that the stripped-down System 6.0.2 in the Classic's ROM >comes with client AppleShare. But of course you would not be able to >run any INITs and I'm not sure how fonts are handled. Seems to me that this >is an idea which needs some work before it becomes viable, and also one >that would be attractive only to the most financially-desperate institutional >user (given the slow speed of anything running off the server across >AppleTalk). What about this scenario: you power-up your (diskless) Mac, it boots from its ROM disk, establishes a connection with an AppleShare server (running ApleShare version 3 (or 4 :-)) where your real system folder is (with all its inits, fonts, ...). Then it becomes a bit less obvious... The Mac does a "pseudo-reboot" with the remote system folder, loading all the inits, cdevs, ... and (after a few minutes) you're up and running! That way, the fact that the system on the ROM disk is minimal is no problem, since it's only used to locate your remote system folder on the server. I made most of this up, but I'm pretty sure I read somewhere (don't remember where) that version 3 of AppleShare (will it be released by CLaris or Apple? :-)) could have some features for diskless workstations. Now how about some predictions on the time it would take to boot with 20 or 30 inits and cdevs??? -- { Marc Mazuhelli | professeur } { internet: mazu@dmi.USherb.CA | Departement de math-info. } { <this space intentionaly ... | Universite de Sherbrooke } { ... left blank> | Sherbrooke, Quebec, Canada }
demarsee@gamera.cns.syr.EDU (Darryl E. Marsee) (12/06/90)
> What about this scenario: you power-up your (diskless) Mac, it boots > from its ROM disk, establishes a connection with an AppleShare > server (running ApleShare version 3 (or 4 :-)) where your real system > folder is (with all its inits, fonts, ...). Then it becomes a bit less > obvious... The Mac does a "pseudo-reboot" with the remote system > folder, loading all the inits, cdevs, ... and (after a few minutes) > you're up and running! Would be nice if the ROM disk included something like two current utilities: INITShare and RamDisk+, and stored their configuration data in PRAM much like the ROM AppleShare client does. Then, the ROM disk could boot up, mount the AppleShare server, invoke the INITShare to execute whatever INITs are out on the server, then invoke RamDisk+ to copy a System Folder off of the server to a RAM Disk and then switch to run off the RAM disk. This works fine today if you boot off of a locked floppy, so doing it off of a ROM disk is just a matter of getting the right utilities in ROM and being able to store/retrieve the config data from PRAM.
francis@math.uchicago.edu (Francis Stracke) (12/10/90)
In article <1990Dec4.193225.16330@DMI.USherb.CA> mazu@terre.DMI.USerb.CA (Marc Mazuhelli) writes: >What about this scenario: you power-up your (diskless) Mac, it boots >from its ROM disk, establishes a connection with an AppleShare >server (running ApleShare version 3 (or 4 :-)) where your real system >folder is (with all its inits, fonts, ...). Then it becomes a bit less >obvious... The Mac does a "pseudo-reboot" with the remote system >folder, loading all the inits, cdevs, ... and (after a few minutes) >you're up and running! BLEAH! Major problems. Speed (most obvious, probably crippling just by itself). Unless Apple did some really tough stuff to the System, you'd need a separate copy for every machine on the net. If it were possible to share Systems, then you'd be vulnerable to whatever viruses anybody on the net exposed their Systems to (bec. the System *cannot* be write-protected). If not, you'd need something like 10-15M allocated for an average-sized zone. That is *not* cheap. (Of course, I think the reason for running a diskless-workstation net is not cost, but security--you have to buy the machine with a disk anyway. Again, security goes all to hell if somebody else can install something in your system folder.) >Now how about some predictions on the time it would take to boot >with 20 or 30 inits and cdevs??? It'd be faster to wait for Apple to come out with a handheld costing $50, outperforming a IIfx, and running System 8. It'll happen... eventually. :-) | Francis Stracke | My opinions are my own. I don't steal them.| | Department of Mathematics |=============================================| | University of Chicago | Until you stalk and overrun, | | francis@zaphod.uchicago.edu | you can't devour anyone. -- Hobbes |
doner@henri.ucsb.edu (John Doner) (12/11/90)
In article <1990Dec10.001749.9393@midway.uchicago.edu> francis@math.uchicago.edu (Francis Stracke) writes: >In article <1990Dec4.193225.16330@DMI.USherb.CA> mazu@terre.DMI.USerb.CA >(Marc Mazuhelli) writes: > >>What about this scenario: you power-up your (diskless) Mac, it boots >>from its ROM disk, establishes a connection with an AppleShare >>server (running ApleShare version 3 (or 4 :-)) where your real system >>folder is (with all its inits, fonts, ...). Then it becomes a bit less >>obvious... The Mac does a "pseudo-reboot" with the remote system >>folder, loading all the inits, cdevs, ... and (after a few minutes) >>you're up and running! > >BLEAH! Major problems. Speed (most obvious, probably crippling >just by itself). Unless Apple did some really tough stuff to the >System, you'd need a separate copy for every machine on the net. A better thing for it to do is to copy the system, finder, etc., to a local RAMdisk. I've been using a MacPlus in much this way for some time now. It works pretty well; I keep exactly one floppy by the machine to boot up with, install the RAMdisk, and supply a copy of the system for the RAMdisk. All the applications I use with that machine are out on the server. If the ROM of the MacPlus had the system, finder, etc. plus the code to create the RAMdisk, I wouldn't need the floppy at all. Sure, programs are slower to load than off a hard disk, but probably faster than off a floppy. In any case, for many programs, most of the loading is done during initialization, so you don't get too much net activity later. Furthermore, with adequate memory, you can copy applications over the network, so you get your very own local copy on the RAMdisk. John E. Doner doner@henri.ucsb.edu (805)893-3941 Dept. Mathematics, UCSB, Santa Barbara, CA 93106
boris@world.std.com (Boris Levitin) (12/14/90)
doner@henri.ucsb.edu (John Doner) writes: >A better thing [than theoretical operation from a server copy of the System] >to do is to copy the system, finder, etc., to a >local RAMdisk. I've been using a MacPlus in much this way for some >time now. It works pretty well; I keep exactly one floppy by the >machine to boot up with, install the RAMdisk, and supply a copy of the >system for the RAMdisk. All the applications I use with that machine >are out on the server. If the ROM of the MacPlus had the system, >finder, etc. plus the code to create the RAMdisk, I wouldn't need the >floppy at all. >Sure, programs are slower to load than off a hard >disk, but probably faster than off a floppy. No by a wide margin. In my experience, this is not true even when the network is composed of very few machines, much less on your *typical* AppleTalk net with some 30 workstations, a couple of printers and mail. >In any case, for many >programs, most of the loading is done during initialization, so you >don't get too much net activity later. Many or most of the most popular general-productivity applications do not belong to this category. >Furthermore, with adequate >memory, you can copy applications over the network, so you get your >very own local copy on the RAMdisk. Which raises the question: why is all this hassle necessary? A hard-disk- equipped workstation, access-managed by FileGuard (from ASD Software) or similar program if you're concerned about security, makes a lot more sense and is a lot easier on the user than any currently-imaginable AppleTalk-based diskless workstation configuration. Remember that the Unix machines which are commonly used diskless use Ethernet, which is a lot faster, and their users still complain a lot about server access speed. Boris Levitin ---------------------------------------------------------------------------- WGBH Public Broadcasting, Boston boris@world.std.com Audience & Marketing Research wgbx!boris_levitin@athena.mit.edu ---------------------------------------------------------------------------- (The opinions expressed herein are my own and do not necessarily coincide with those of my employer or anyone else. The WGBH tag is for ID only.)