Pig at the wedding question/diatribe
<scraping sound of soapbox being pulled up>
I really, /really/ appreciate applications that build into a single binary or a very few files, that can be built on a (different) build and test host, then copied over to the production when everything is thrashed out and ripe...you know, like Pine and UoW IMAP. I like it because: = it keeps the production host clean, = updates are MUCH more manageable, = you don't have a compiler on the production host to give hackers a way to build nasty things on your production machines, = You know when you remove/replace the single/very few files, you've got everything cleaned out/replaced. = there's prolly other things that don't come to mind right now.
I have just gotten to page three of INSTALL and it seems like This Will Not Be The Case With Mailman. Tell me it isn't so.
I guess I'm just hopelessly behind-the-times in not wanting the installation fairy sprinkling files here and there and generally making heavy local dependencies. I never wanted to be a Hero-Wizard (who maintains the smooth running balance of the Code Forges of Magrathea by mighty, arcane & stupendous acts of magic...and ends up wasted), I didn't want to own, feed and take care of five elephants and a steam engine, I Just Wanted A Mailing List Manager...
Augustine's Law #405: Anything that isn't in a design won't break http://wallofjokes.shacknet.nu/Misc/AugustiL.html
Or tell me how wonderful it is............
<grumble, grumble>
send hate mail to the address below
--
Stewart Dean, Unix System Admin, Henderson Computer Resources Center of Bard College, Annandale-on-Hudson, New York 12504 sdean@bard.edu voice: 845-758-7475, fax: 845-758-7035
On Fri, 2004-10-29 at 17:09, Stewart Dean wrote:
[ installation difficulty rant snipped for brevity ]
If your OS vendor (or distribution) provides packages you typically only need to do something as simple as "install mailman" and do a few basic post-install configuration steps. The installation complexity burden is borne by the pre-supplied package and your life is much simpler.
John Dennis <jdennis@redhat.com>
"Stewart" == Stewart Dean <sdean@bard.edu> writes:
Stewart> <scraping sound of soapbox being pulled up>
Stewart> I really, /really/ appreciate applications that build
Stewart> into a single binary or a very few files, that can be
Stewart> built on a (different) build and test host, then copied
Stewart> over to the production when everything is thrashed out
Stewart> and ripe...you know, like Pine and UoW IMAP.Mailman solves a different kind of problem from Pine and IMAP. IMAP has no user interface; Pine doesn't need to worry about screwing up anything but the user's own data if it screws up. The MLM problem is much less straightforward; it requires careful attention to security issues, both against hostile entities like crackers and spammers, and against benign but still dangerous activity (aka "fool-proofing"). In order to deal with the inherent complexity, AFAIK most MLMs are written in scripting languages like Python or Perl, and the rest (eg, smartlist, which is distributed with procmail) are very inflexible, require list manager == system administrator, and require separate CGIs, invariably written in a scripting language, to provide the web interface.
Stewart> = there's prolly other things that don't come to mind
Stewart> right now.Microsoft Exchange sounds like it's just what you need. It's only your money and your freedom that are at stake. ;-)
Stewart> I guess I'm just hopelessly behind-the-times in not
Stewart> wanting the installation fairy sprinkling files here and
Stewart> there and generally making heavy local dependencies.Not at all. In fact, that's been a design goal and within the constraints imposed by dealing with an MTA and multiple user interfaces, it's been successful IMO. Compared to earlier versions of majordomo (I haven't dealt with anything but Mailman for about 4 years), Mailman has a well-defined structure which makes it easy to find the things I need, and has very few local dependencies except for Python and the MTA. On the other hand, compared to smartlist it allows me to delegate list configuration to the owners with little worry, and makes user-specific configuration possible.
All the files are under one directory, except for the MTA configuration and possibly the archives. If your production system is binary-compatible with your test system, you just tar up the whole thing on the test side and untar on the production system. You may have to make any MTA changes by hand, although it's not hard to configure some MTAs (sendmail comes to mind) to use multiple alias files.
Stewart> I Just Wanted A Mailing List Manager...Actually, I suspect you define Mailing List Manager in a way that doesn't apply to Mailman. What "mailing list manager" means in this context is "a set of user interfaces that allow list owners and users to configure their lists and subscriptions without requiring effort on the part of system administrators." It's about allowing delegation of responsibility without complicating your life, rather than about simplifying your life per se.
If you're mostly setting up one-way announcement lists and the like, you might be more interested in CRM (customer relations management) software. If you are looking for something that just manages distribution lists and don't care about flexibility for list owners and users, smartlist might be more up your alley.
Stewart> Augustine's Law #405:
Stewart> Anything that isn't in a design won't breakMurphy's Corollary to Augustine's Law #405: The users will nevertheless complain that the feature is broken by its very absence.
So design the system that gives you exactly what you need, no more, and no less, and put it out for bid. Be it ever so humble, it won't be cheap.<wink>
Stewart> Or tell me how wonderful it is............It would help if you described what your needs are rather than complaining about aspects of Mailman that are designed-in in order to meet the needs perceived by the designers. It's quite possible that you would be better served by a different package.
-- Institute of Policy and Planning Sciences http://turnbull.sk.tsukuba.ac.jp University of Tsukuba Tennodai 1-1-1 Tsukuba 305-8573 JAPAN Ask not how you can "do" free software business; ask what your business can "do for" free software.
participants (3)
-
John Dennis -
Stephen J. Turnbull -
Stewart Dean