Path: utzoo!utgpu!news-server.csri.toronto.edu!cs.utexas.edu!tut.cis.ohio-state.edu!ucbvax!DSL.PITT.EDU!sean
From: sean@DSL.PITT.EDU (Sean McLinden)
Newsgroups: comp.protocols.iso.dev-environ
Subject: Re:  How Serious are we about running quipu?
Message-ID: <9004111149.AA04579@cadre.dsl.pitt.edu>
Date: 11 Apr 90 11:49:45 GMT
Sender: daemon@ucbvax.BERKELEY.EDU
Distribution: inet
Organization: The Internet
Lines: 66

> How serious are you about running quipu?
>
> Is it just something that you got for free compiled - it worked
> so you put a bit of data in and connected up - or are
> you a bit more serious about maintaining a proper directory. I.e.
> keeping all the information up to date and complete.

I am, perhaps, not the best person to be answer this since our reasons
for running the pilot software had more to do with exploring applications
of X.500 services, but...

We (University of Pittsburgh), have roughly 2000 entries in our DSA.
This represents less than 10% of the total number of accounts supported
on our various systems. The difficulties with doing as you suggest are:

1. The lack of any real applications software which would provide an
incentive for mainitaining an uptodate database. For example, if WP could
be used to maintain the University's campus telephone directory. The PP
and MH mail systems might provide just the incentive just as the Andrew
White Pages is used by the Andrew Message Delivery System.

2. The lack of integration into Unix accounts management software. We
have users with many accounts over many systems, some of which have different
names, many of which contain inaccuracies. Since there is no real central
accounts management for many of the research systems, detecting aliases,
duplicates and things can be quite difficult. Given the number of variations
on Unix password files, it is non-trivial to even parse these into meaningful
DSA entries.

3. Occasional quirks of the code. The organization of the pilot is such
that the master DSAs actually edit (copy) data into the local EDBs. This
isn't much of a problem as long as the system continues to run but a
quirky memory error on the DECStation 3100 causes our DSA to crash once
every 18 hours or so. When it goes to reload, it cannot restart the DSA
because of errors in the EDB files. We workaround this by keeping copies
of our startup EDB files, and restoring those prior to restarting QUIPU,
but this is suboptimal.

To be fair, it has been a mammoth effort for the ISODE and QUIPU
developers to have gotten the code even to this state; a remarkable
accomplishment. But the software is still too experimental for many
institutions to consider running as a reali world appliction.

> My personal thoughts are that if we are going to do this then me may
> as well do it properly, and each organization make some sort of 
> commitment in money/manpower to maintaining an uptodate complete
> directory.

Agreed. But the problem is justifying the money and manpower. I don't
know how things work in your institution, but I know that in mine, some
of the most useful packages (GNU emacs and gcc, X, ISODE, TeX), were
installed, developed, and maintained by people who did it, not because
they were paid to do it, but because they were interested. It was
popularity of use that convinced administration to spend money on support.
Even then, it was a long time in coming and the funds were never what we
would like them to be.

In the real world, it is *very* difficult to find money to support
experimental software. Personally, I think that those types of activities
are why Universities exist, but the distinction between Academia and
Industry is becoming smaller and smaller with each year. We don't have
the luxuries that we did, even 5 years ago.

Sean McLinden
Decision Systems Laboratory
University of Pittsburgh