Natalie Maynor <[log in to unmask]> writes:
>
> Listproc commands are very definitely not identical to LISTSERV commands.
> The fact that a few of them are the same makes it even more confusing since
> it causes subscribers to assume they're all the same.
>
> As listowner of two LISTSERV lists and one Unix Listproc list, I can assure
> you that we're talking about a contest between a gazelle and a crippled
> sloth.
 
I'm not about to argue that the programs are the same.  I've managed
lists with both systems, and I am currently the system administrator
at the Coalition for Networked Information.  We use a DEC 5000 and the
Unix-Listprocessor to manage about 40 mailings lists.  So, I have some
experience with both systems too, and a fair amount of experience at the
system mangement level on the Unix-Listprocessor system.
 
(Also, I'm not going to bother with a justification of why we use the
Unix-Listprocessor and why we don't use Revised LISTSERV.  Those of you
who really care, or really need to know, already do...)
 
However, I am going to say that I find Ms. Maynor's comments about the
gazelle and the sloth highly inflamatory and indicitive of the rather
uneducated banter that gets tossed about the net regarding my favorite
topic, namely 'Revised LISTSERV vs. all-other-evil-list-management-
systems-in-the-world.'  Any comparision of these two systems, in
particular, is invalid from the outset.  So spare me...
 
For one thing, nobody in either camp has any type of meaningful benchmark
from which to measure such a comparison.  Yet each side seems to enjoy
deriding the other to such a great degree that there is really little
meaningful dialogue about what such a benchmark would entail.
 
Secondly, the two systems operate in very different environments,
architecturally speaking.  Revised LISTSERV has benefitted, until
relatively recently, from operating in a largely homogenious environment.
Unix-Listprocessor, on the other hand, operates in a much more
heterogeneous environment (both hardware -- RISC, Sparc, Mips, Intel,
etc.; and software -- Ultrix, SunOS, AIX, SCO unix, etc.).  Making
comparisons of Unix-Listprocessor performance from one machine to the
next is difficult, comparing it to the largely VM/NJE/RSCS LISTSERV
is nuts.
 
Finally, the Unix-Listprocessor is heavily reliant on SMTP (primarily
unix's sendmail) for the actual delivery of mail.  With all deference
to the IETF powers-that-be, this is a protocol which is not particularly
good a point to multi-point transmission and an implementation which, at
best, was never designed with this type of application in mind.  In
short, sendmail is the weak link in system performance not the Unix-
Listprocessor code.
 
P.S. -- As long as I'm writing...
 
I welcome an opportunity to evaluate L-Soft's product in a unix-like
environment.  However, if Mr. Thomas plans on relying on sendmail for the
actual spooling and delivery of mail, as the Unix-Listprocessor system
does, he may find that his own product doesn't perform as well as it
does in its current environment.  I've been using the Unix-Listprocessor
system and watching its development long enough now that you'll have a
hard time convincing me that Mr. Thomas has better solutions to some of
the real problems confronting list-management developers in unix-like
environments than those employed in Unix-Listprocessor.  But, if he does
have the answers, I'm sure he'll make a mint and I'll be in line to buy
the product too...
 
I also understand L-Soft's business reasons for using Pascal.  But I
think they might find many people reluctant to employ the product in
unix-like environments if it is shipped in Pascal code.
 
Personally speaking, the product will have to demonstrate some significant
and *measurable* performance increase over the Unix-Listprocessor system
before I will be persuaded to purchase a Pascal compiler in order to
compile the system.  Unless L-Soft can ship pre-compiled binaries, or give
me a deal on a licensed Pascal compiler with the LISTSERV distribution, I
don't see a good reason to move away from C.  Sites my size can't afford
to employ C and Pascal programmers.
--
 
   Craig A. Summerhill, Systems Coordinator and Program Officer
   Coalition for Networked Information
   21 Dupont Circle, N.W., Washington, D.C.   20036
   Internet: [log in to unmask]   AT&Tnet (202) 296-5098