--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
|