morgan@Jessica.stanford.edu (RL "Bob" Morgan) (04/19/89)
[This continues to not be the right place for this, but there isn't a comp.filesystems.vendor-independent . . . ] Some people write: > > - It [TOPS] does not allow sharing of executables. I think this is a > > MacOSism: for instance, Hypercard apperently needs write permission > > (and ownership of the user for the executable). Therefore, it is > > impossible to build a central place for executables, and restrict > > write access to 'disencourage' viruses. > > You're correct. It's a MacOSism of sorts. Really, it's an > Application-ism. Most applications (including HyperCard) want > "scratch" space as they run. This prevents people from concurrently > running executables located on a central server. Hopefully, NFS will > help with this Yow! This is *completely untrue*! The file server I am using from my Mac (a 3Com 3Server running their 3+Mac) has executables for almost 20 very popular programs (including the one I'm using now) which reside on a read-only volume and are happily shared by our office staff from their dozen or so Macs (licensed, of course they're licensed, why do you ask? 8^). Other places I'm familiar with on campus do the same with AppleShare and TOPS servers. HyperCard *was* about the only application to have the above-mentioned problem, but with its recent release is no longer. Applications that require scratch space or personal config files keep them on one's System volume, which it is indeed true can't be read-only or shared, but *can* be located on a file server (as is mine right now, though I think only 3Com supports this). - RL "Bob" Morgan Networking Systems Stanford