Re: XP / freeze-drying sessions in OS X
Re: XP / freeze-drying sessions in OS X
- Subject: Re: XP / freeze-drying sessions in OS X
- From: Ken Tabb <email@hidden>
- Date: Fri, 6 Jul 2001 19:16:03 +0100
First, I think it's a great idea to freeze-dry the user's session so that
they don't have to load up Classic each time. I also think it would be
great to get Solaris/AIX-type "keep running my processes while I'm logged
out" prefs, possibly controlled in NetInfo, so that the sysadmin gets to
keep an eye on who is using their resources.
I think education market (where I work) could really benefit from
'paused' sessions (and especially 'background' sessions, if it were
implemented), although I can foresee several implementation 'challenges'.
I don't really see the point in the hot swap feature, but that could be
because I don't fall into any of the categories for which people have
given useful examples of it in action. The rest of my message assumes a
network of OS X macs, with a MacOS X Server for user authentication.
Sorry to all the 'little guys (and girls)' but these problems would not
be a problem for them as they are not, by their definition, nomadic.
If I could be the Devil's Avocado for just a moment, if the user's
session's RAM (or whatever) were freeze dried on the computer last used
by the session (eg. LabMac1) and you then move to LabMac2 and log in,
there will have to be some process for (a) knowing which machine you were
last on (presumably if you're using NetInfo authentication it would be
able to tell you this info) and (b) getting the stuff off it (eg. what if
LabMac1 is now switched off?)
The easy answer to this would be: store the freeze-dried sessions on the
NetInfo server (which you're also using as the user authentication). But
if you have (for argument's sake) 500 users, all of whom use approx
(again for argument's sake) 192Mb of RAM in their average session (I
think a realistic amount for OS X w/Classic and a few apps), then you
have 96,000Mb (i.e. over 90Gb) of server disk needed just to store their
*RAM* (that's not their apps / documents / the server software or system
itself). Yikes that's expensive.
Even if you were to say "ah but hard disks are sufficiently cheap that
this would be OK, so we'll store all freeze-dried user sessions on the
server(s)", if you then want to go the extra mile and have your processes
continue after you've logged out, which machine is doing the processing?
The server (a la Sun X terms / X-Rays (the CPU-less clients))? Double
yikes it would cripple it (besides needing all the user software loaded
on it). Would this raise 'different technologies controlling the same
process' problems, for instance using an AltiVec G4 to do some sciencey
stuff, then logging out only to find that your processes are now being
done by a G3 - and the software is AltiVec only, for instance? It could
corrupt what you had done during your session, making you slightly
annoyed upon discovering this the next day.
Even if processing were controlled by the very same mac you logged out
of, what if the sysadmin decides it's time to roll out a new NetBoot
image for all the macs? With newer versions of the software, or even
removing some of the apps you were using? Arguably NetBoot doesn't
officially support OS X images yet so it's not yet a problem, but you get
my point. They might ssh/telnet in and make changes, in which case it is
a problem even without NetBoot.
And so it was that email@hidden said on 5/7/01 8:33 pm:
>
Virtual PC does that: you can stop your whole environment, it writes all
>
the memory used on a file on disk when you quit. If you open it later, it
>
just reads back the files, and voila! you are still in the middle of you
>
apps (means: games, since it is PC stuff ;-).
Granted this is a great feature of VirtualPC. Virtual PC doesn't launch
in OS X (even in Classic) yet, but your example (in OS 9) works because
you are using the same machine each time. What if you are in a lab and
use a different computer from one day to the next?
In summary, I think there are loads of issues when you move this scenario
to a network. And it is a network environment which would benefit most
from this (i.e. where computers are left on all day/night and so where
distributed and background processing are most available).
Just my 1.6 pence Sterling,
the boy Ken
---------
Ken Tabb.
Mac & UNIX C/C++/Java developer (Health & Human Sciences),
Machine Vision researcher/programmer (Computer Science),
University of Hertfordshire, England
http://www.health.herts.ac.uk/ken/
Certified non-Microsoft Solution Provider