--On September 14, 2005 12:05:31 PM +0200 Patrick von der Hagen 
<[log in to unmask]> wrote:

> Am Dienstag, den 13.09.2005, 15:13 -0600 schrieb Michael Loftis:
> [...]
>> The software is still far better than any open source list product I've
>> seen so far, but it is starting to show it's age.  All of the
>> documentation
> Could you provide some information about the advantages of listserv
> compared to open-source alternatives? I officially got the assignment to
> evaluate alternatives on Monday and might save some work if you have a
> recent comparison.

Mailman's bounce handling is a joke.  Mailmans list "database" handling is 
also a joke.  It can NOT handle large lists.  It reads the entire Python 
pickle of the list in and rewrites that every single time a change is made 
or a bounce is processed.

Mailman's UI is not templatized, very little of mailman is.  What little is 
pretty much requires server admin access to change since you must upload 
files.  ListServ allows pretty much all text and responses to be changed on 
a per list basis by the individual list owner.  HTML, mail, etc, everything 
is there.  It doesn't require/need root or server admin access to perform 
this.

Mailman, because of the above rewrite list information problem, is 
single-threaded.  It must lock each list before reading or writing.  This 
means busy lists webUI's will stop working, they'll all hang around waiting 
to obtain a file lock to do their read and rewrite or even just reads.

I agree ListServ is starting to look like it lacks polish in front of some 
others, but it's still far faster than anything I'm aware of.  It's still 
the only one with such a good template syste, even though LSoft hasn't made 
much effort at internationalization of it, it is far more capable of this 
than Mailman is with all of it's hard coded HTML and mail templates, and 
templates that are templatized but only touchable by the sysadmin.


I would also like to see 'site wide overrides' some of the older options 
cleared up or removed.  Some of it is documentation issues (like the spam 
check disable you mention) but it would be nice if the spam check mechanism 
were more transparent and could be guided on a site by site level.
>
> Basically,
> - the utter lack of internationalization
> - the very coarse configurability of several options (e.g. if
> list-request should not require ok-confirmation you can only disable all
> spam-checking, without even knowing what "all" means, because that's a
> secret)
> - hard to explain dependencies (e.g. you can have a subject-tag, but
> that conflicts with ietf-header...)
> - and some annoying behavior (if one address is subscribe to ten lists
> and active probes happen once a month for each list, you get ten probes,
> while mailman would send one monthly-reminder for all lists on the given
> server, which my users consider to be much more convenient)
> - some lack of sitewide configuration (I want to disallow my listowners
> to change some options)
> cause lots of annoyance here.
>
> --
> CU,
>    Patrick.
>



--
"Genius might be described as a supreme capacity for getting its possessors
into trouble of all kinds."
-- Samuel Butler