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