> A 486, with maybe 16 meg of memory and a slow hard drive, ought to be more > than ample, assuming (a fair assumption), that it's going to run some sort of > standard mailing list software, like, say, mailman under Linux. We're > talking about a mailing list, after all, that, on a busy day, has fewer than > several dozen emails. the current list server is a PPro 200 with 128MB RAM. it has a 9GB SCSI disk, and another 18GB SCSI disk. what beats it up, is that mailman stores its data in huge mbox files; which have to be locked for each read & write. the server doesn't just get mailling list traffic; there's also a great many requests for the LKML archives (lots of web spider traffic, among the real people looking). when a webspider reads list data; the mbox file for that list has to be read, once for each message on the list. when we want to add a message to that list; the mbox file has to be locked, and so other processes block when trying to read it (or write to it themselves). so here are some of the options (note that these are not necessarily exlcusive, we could do several of these): 1. rewrite mailman to use an SQL backend. this way we can do lots of concurrent reads & writes, without blocking lots of processes. 2. make a separate physical disk for LKML; or TCLUG. this will alleviate the disk head chatter to a degree, and make somewhat more concurrency possible. won't alleviate all the process blocking, tho. 3. get more memory, so more of the mbox files can be held in RAM. the machine physically won't take more memory tho; so this isn't an option. 4. get a completely separate box for TCLUG mail. a 486 may suffice; but note that 486s usually have really awful disk controllers by today's standards. a few-hundred MHz machine with as much memory as we can cram into it, would be worlds better. IMHE; my posts seem to take about a half-day to show up. but I've never lost one. Carl Soderstrom -- Network Engineer Real-Time Enterprises (952) 943-8700