The Answer Gang
The Answer Gang
By Jim Dennis, Ben Okopnik, Dan Wilder, Breen, Chris, and... (meet the Gang) ... the Editors of Linux Gazette... and You!
We have guidelines for asking and answering questions. Linux questions only, please.
We make no guarantees about answers, but you can be anonymous on request.
See also: The Answer Gang's
Knowledge Base
and the LG
Search Engine
Contents:
shell and pipe question
Font rendering with GTK-2.0
Radeon 7500 PCI Card Monitor Autodetect - My Solution
Updating Libc and Gcc Support on Older Distros?
What are the top five webmail applications of the Open Source world
suppress terminal messages of other processes
building MP3 playlists
Greetings from Heather Stern
Greetings, folks, and welcome to the world of The Answer Gang. It's been a fine time getting up to speed in our new digs, but now I'm indulging in some spring cleaning.
Taking a look at my hard disk I'm way overdue, too. Let me see... multiple chroot environments being used as development areas, some of which distros aren't even supported by their own vendors anymore. Rescue a few bits of actual code trees, then tarball these things off to a CD, Poof! Hey, that's not too bad. What else can I toast here? (BTW, has the state of the art in DVD burning gotten anywhere close to "just buy one at the computer store and Linux will deal with it" quite yet? I've been too lazy to check.) Some stray PDFs while I was planning my kitchen remodel... from years ago. I haven't even started thinking about cycling off backup tarballs yet.
Then there's mail cleanup. I've got quite an email humor collection. There ought to be lots of dupes in that, but it'll be amusing reading all through the summer to clear my way past it all, deleting attached pics that aren't funny, and making a little gallery of ones that are. (There are oodles of gallery software available on Freshmeat, but I probably won't make it public; my bandwidth isn't up to that.) While not a direct relation to how much disk space I'm eating, some serious antispam principles could at least do spring cleaning on my available time. Jim's been thinking of instituting greylisting on our mail server.
Now I have to note the term is a mite overloaded. I mean, we've been talking about whitelists (our good friends) and blacklists (mail never to be seen again, whether you use the RBL/MAPS servers and their kindred or not) but grey, what's that? The fact is that just seeing your friend's raw address isn't nearly enough; viruses steal names out of address books freely to spoof headers. Clued people like me can add header checks to spot they are really coming from their expected route or mail agent ... but those can change and when they do, your friends will be out of contact. Ouch. Also, mailing lists that are very open (hmm, do I know any of those? *wink*) are often targeted by spammers who hope their mail will hit many at once, while their traces are hidden by standard list-header mangling. The fact is that even the good guys need a little checking, and anyone who needs to receive mail from completely unknown people has to do something serious. Separating off how much checking to really do reduces CPU load for some cases, but that is where it gets a bit greyer. There's ASK and TMDA for making new folk at least reply before you'll talk to them. This greylisting practice is pleasantly sneaky, doing something similar but at the transport layer. Systems run by real people sending real messages really have to have mechanisms for trying again if a server's too busy, a little overloaded, maybe drop back and visit the secondary MX. But spammers don't have time to waste on all that - they've umpty squadzillions other suckers to mail. So greylisting responds with a temporary error condition, but logs who came by; at some vaguely random later point but within popular and reasonable human timeouts it will accept the mail from that server knowing it's a repeat call... and the chances that it's someone utterly normal increase drastically. And even the spammers who follow normal protocol will be stuck hosting their own stupid mail during the delay, costing them resources instead of legitimate ISPs. The downside is not really getting instantaneous notes from your correspondents, but I'm sure this can be tuned a bit.
Of course, you could always just take the classic techie's option - get
a bigger hard disk. With all that I'm up to in my development and
experimenting, it looks like I'll have to do that. Hah. Watch me
complain, twist my arm
Now I should really figure out about backing up this stuff in a way that
would be easy to restore if I have a problem... um, on something that
doesn't take more space than the original does. Otherwise trying to
clean up the house in general will have us wondering where to put all
this. Gosh, laptop drives are getting better capacities these days.
Much easier than dealing with tapes and discs, a mere 4G per disc
disappears pretty quickly nowadays, worse if you're sticking with CDs.
I'm about to attend a music convention; my crew's running an Internet Lounge at Consonance. So all the older systems in miscellaneous condition are being brought up to speed and truly dead parts are finally being tossed. Wow. I'm starting to have shelf space in my hardware cabinet again. That's more like it.
And of course, I've improved the preprocessing scripts I use to match the new stuff we have going on here. So I'm pleased to reintroduce the TAG in threaded form. Thomas did nearly all the work marking it up (for which we can thank his Ruby scripting talents) but the layout tricks are still mine. Let us know if you find any dust that still needs cleaning out of 'em. Have a great month, folks.
Readers with good Linux answers of their own, in local mailing lists or published to netnews groups are encouraged to copy The Answer Gang their good bits if they're inclined to see their good thoughts preserved in the Linux Documentation Project, by way of the Linux Gazette. Ideally the answers explain why things work in a friendly manner and with some enthusiasm, thus Making Linux Just A Little More Fun! If they're short and sweet they'll be in Tips, longer ones may be pubbed here in TAG. But we don't promise that we can publish everything, just like we don't promise that we can answer everyone. And last but not least - you can be anonymous if you'd prefer, just tell us when you write in.
HTML script maintained by Heather Stern of Starshine Technical Services, http://www.starshine.org/
