🚀 go-pugleaf

RetroBBS NetNews Server

Inspired by RockSolid Light RIP Retro Guy

Article View: comp.protocols.appletalk
Article #4227

Re: AppleShare client availablity

#4227
From: Ravinder.Chandhok
Date: Fri, 18 Sep 1987 16:01
57 lines
3627 bytes
>Here is the official Apple C. position on using AppleShare client
>software with Aufs:
> 
>	When using AUFS you must purchase AppleShare in
>	order to use the AppleShare client software. The
>	client software may be duplicated for up to 50
>	clients per AUFS server.  If you are using more
>	than one AUFS server or the number of clients per
>	server exceeds 50 you must purchase additional
>	copies of AppleShare.
>
>This applies to both educational and non-educational sites.  I am in
>the process of verifying whether "Aufs server" means a single machine
>or each "Aufs server" process.

Ok, here it is.

Name: Ravinder Chandhok
Title: Project Manager
AppleLink address: A14
Organization: Computer Science Department, Carnegie Mellon University
Problems/Comments:

My main problem with this agreement is that Apple is now reducing the state
of AppleShare to that of a seperate add-on, not system software.  If
anything, it seems to me that the AppleShare client code should be part of
the system by default.  That would encourage a standard for all Mac users
and developers, and also ensure that the Finder would deal appropriately
with all file servers, from Apple or third parties.

I certainly do not understand that decision in the context of making
"HyperCard" be advertised as system software.  For institutions with a
desire to support campus-wide file service there is no easy metric to
count the number of client code copies you need.  For example, the CS
department is responsible for teaching a course to most freshman.  About 700
a semester.  We have a lab with 50 Macs, a dedicated facility.  The students
BRING THEIR OWN BOOT DISKS.  It doesn't make sense for me to buy enough
copies of AppleShare for 700 students, when only 50 of those copies would be
in use at any given time.  The current policy seems to be that I can give
them all MultiFinder, but not AppleShare client code.

Up until now, I have assumed that I would recommend to CMU (and have been
doing so) that the RIGHT WAY to hook the Macs to our campus file system is
to use AppleShare client code and CAP.  If this means we have to buy enough
copies of AppleShare for 6000 students (which is 120 copies of AppleShare
which will cost at least $24,000), then I would have to recommend switching
to a solution from a vendor that understands the meaning of a site license.
The only other alternative is for universities to try and build an
appleshare client themselves.  It can be done, but it certainly will be a
TOTAL WASTE OF EFFORT REINVENTING IT!  Apple and the universities would be
better off thinking of new and interesting ways to use AppleShare (Our
group, for example, is writing new software in Macapp to facilitate
electronic submission of assignments and exams).

I would like to hear a statement from Apple as to which part of the code is
part of the system, and what is not.  Is the XPP driver system code ?  Or
AppleShare ?
Technical Details
Message-ID: <1987.9.18.15.39.36.Ravinder.Chandhok@gnome.cs.cmu.edu>
Path: arc1-ca.pugleaf.net!utzoo!mnetor!uunet!husc6!hao!boulder!sunybcs!rutgers!ucla-cs!zen!ucbvax!CS.CMU.EDU!Ravinder.Chandhok
References: <8709181321.AA27274@columbia.edu>

Show Full Headers
Complete Article Headers
Relay-Version: version B 2.10 5/3/83; site utzoo.UUCP
Path: arc1-ca.pugleaf.net!utzoo!mnetor!uunet!husc6!hao!boulder!sunybcs!rutgers!ucla-cs!zen!ucbvax!CS.CMU.EDU!Ravinder.Chandhok
From: Ravinder.Chandhok@CS.CMU.EDU
Newsgroups: comp.protocols.appletalk
Subject: Re: AppleShare client availablity
Message-ID: <1987.9.18.15.39.36.Ravinder.Chandhok@gnome.cs.cmu.edu>
Date: Fri, 18-Sep-87 12:01:56 EDT
Article-I.D.: gnome.1987.9.18.15.39.36.Ravinder.Chandhok
Posted: Fri Sep 18 12:01:56 1987
Date-Received: Sun, 20-Sep-87 03:05:38 EDT
References: <8709181321.AA27274@columbia.edu>
Sender: daemon@ucbvax.BERKELEY.EDU
Organization: The ARPA Internet
Lines: 57