[4] in Layered Athena
Re: Layered Athena Requirements
daemon@ATHENA.MIT.EDU (Mark Curby)
Fri Oct 23 14:35:00 1992
Date: Fri, 23 Oct 92 14:34:04 EST
From: mlc@MIT.EDU (Mark Curby)
To: layered-athena@MIT.EDU
Cc: macdev@MIT.EDU, dosdev@MIT.EDU
Mark et al -
Nice job on the layered Athena requirements.
While clearly the priority of this effort is (and should be) on UNIX
based platforms I think it will prove useful, both in terms of your
short term goals and I/S's longer term goals, to also keep in mind
low-end systems during this process. A private UNIX workstation running
a proprietary operating system in some ways has more in common with a
typical Macintosh on campus than a typical (traditional) public Athena
workstation. Reviewing the problems and successes I/S has had
supporting Mac and DOS machines on campus may provide some useful
information.
In some areas -- with a little work -- we maybe able to find solutions
which support all Athena platforms (Mac, DOS, and UNIX). Where we have
been able to do this it has been a big win, e.g. Kerberos, Moira, email.
If we could also do it for version checking/notification, software
updating/distribution, usage monitoring, etc. it would be nice.
> Date: Fri, 23 Oct 92 12:03:59 -0400
> From: Mark Rosenstein <mar@MIT.EDU>
> 3.Updates: the workstation owner should have the option of:
> (a) His workstation is updated automatically whenever a newer
> version of a subset is available.
There have been some attempts at commercial products for the Mac to do
this. Looking at them might give some ideas, and reviewing the problems
with them might help us avoid some problems.
> (b) He is notified that new software is available, but must take
> manual action.
This is what VersionServer attempts to provide today for our Mac & DOS
products. It would be great if we could concentrate our development
resources (and later our maintenance and operations resources) on a
single system for UNIX, Mac, & DOS.
> 6.Tracking: DCNS needs to know what people are using so that we can
> provide better service and know when it is safe to decommission old
> versions.
> (a) The above requirement for stable storage of the configuration
> might allow for whatever tracking we need.
> (b) Real time monitoring such as SNMP should be able to tell us
> what subsets are loaded.
> (c) Are there privacy concerns here?
This is a big part of what TestTracker is all about. Again a single
system could be a win.
- Mark
------------
Mark Curby
MIT Network Services MIT Room E40-342G
(617) 253-7725 77 Massachusetts Ave.
mlc@mit.edu Cambridge, MA 02139