"If you read Boing Boing's RSS feed, you've probably noticed that we are now running occasional text ads in selected entries."

Yes, and it pisses me off big time: the web version is so ad-infested that it's unreadable (40% of the screen realestate blinks and warbles and tries to entice me), so I read it via RSS (spidered by this abomination in full screen beauty. Form follows function and Content rules.

I hate ads. I run jesred (and maintain it for debian, too), a squid redirector and crap filter. I add this to jesred.rules

regexi ^http://feeds.feedburner.com/    http://localhost/jesred/dot.gif

I see no more BB ads. I am happier.

The redirection was too general: boingboing's main RSS file would be n/a with the above. But all the ads live under /~a/... Better:

regexi ^http://feeds.feedburner.com/~  http://localhost/jesred/dot.gif

I'm a stupid stubborn bastard and spent a good two days to get three orinocos reflashed and the silver to gold hack (ie. 104bit WEP and 14 channels) working. Now, after lots of swearing and gazillions of reboots it works on all three cards, one original lucent silver orinoco and two enterasys/cabletron roamabouts.
click here for the rest of the story...

as documented in bug 242378, the spambutt has a problem with expiring the bayes database. somehow a lot of atime entries get set far into the future, and the butt doesn't recognize this properl - and sits on its butt, chugging along and retrying the wrong things over and over again.

great.

after finding a tool called db-to-text2.pl which can fix the entries and playing around with it i've decided to use the big hammer on bayesstore.pm: wherever atime is written to the db, we do a sanity check.

this patch addes these crude measures, and will hopefully keep my bayes dbs in fair shape. YMMV.

Firewalls are fun, but just dropping all the bad packets is fairly boooring.
click here for the rest of the story...

I like the layout of the rssreader mozilla extension, but nothing else about it: it requires using the bookmarks (hatehate), it is in javascript (hatehatehate) and it is superslow, no caching whatsoever etc.

Why not use any of the available tickers and RSS readers?

I liked rssreader's layout and integration with mozilla. I don't like tickers, I need full articles or at least overview data to judge whether an article is worth my time and headlines Just Don't Work for me. And, the killer argument: all my bookmark info is kept in a topicmap file so any RSS reading tool must get its info from there, too. None but my personal one would do that.

So I decided to make a slurping tool that slurps feed data onto the local box and massages things into the rssreader look. Easypeasy thought I, perl to the rescue etc. etc.

Well, RSS sucks: gadzillions of slightly different versions, all incomplete and fugly. Atom sucks, too, just differently.

The one parser module present in Debian, libxml-rss-perl, doesn't understand newer RSS (ie. 2.0) at all, and no Atom, so playing with that wasn't too successful. The other potential parser, XML::RSS::Parser, is not available as a Debian package, but it sucks less: with a bit of tweakery I got it to read all the RSS flavours and also Atom. Hmm, maybe I'll package it.

Net result of a few hours of mucking around, skirting incomplete unicode support in my perl (no I don't want to update to 5.8 yet) etc. is this script called rsslurp. The link retrieval part won't be useful to anybody who's not into topicmaps (ie. most of you out there), but the part for massaging things into rssreader-compliant CSSified HTML may be. The tool also caches the source XML and produces an overview HTML page with update times and feed names.

I've found a few nice things for Mozilla Firebird, the IMHO least sucky browser right now (apart from being a memory hog).

The Permit Cookies extension does not do what its name implies, but gives you a popup for blocking/allowing/removing cookies for the current site on pressing Alt-c.

Why not allow cookies with all the other features enabled, especially "ask before accepting"? I had that, but I ran into major slowdown issues with a really big cookie permissions file which denied cookies for 99.8% of the sites anyway, and the question popup was very annoying, too.

So now I have cookies disabled in the global preferences as a good default, and for the few sites where I accept the requirement for cookies as sensible, I just enable cookies specifically for the site, once and comfortably.

Disabling cookies doesn't actually disable them: the explicit exceptions still work. The one thing I lose is the "cookies for this session only" functionality; that is taken care of by my mozilla wrapper which simply removes the cookie file on startup.

userContent.css in your profile dir/chrome/ is also quite useful for some things: the Firebird Doc Site mentions how to disable marquee tags, and here I found a tip on how to change the cursor for javascriptshite links:

a[href^="javascript:"] { cursor: crosshair; }

Flashblock is another saviour: flash crap is not displayed at all but a placeholder shows up. You can click on it and only then the flash thingie loads. Very nice, very useful.

The Tabextensionsextension is so common now that it has been properly Debianised - a welcome change from the lousy XPI installation mess mozilla tries to force on us otherwise.

Related to debianising mozilla and hand-installing extensions without messing everything up is this bit of info:

Mozilla on Debian gets its extension info from per-package files in /var/lib/mozilla-nameoftheday/chrome.d/. The good old run-parts-like approach works perfectly well here, too: you (or any package) can plop a file like 99azfixthisfuckingmess into said dir without affecting any other aspect of moz, and run update-mozilla-firebird-chrome to combine those files into what moz wants to see.

Looking at the XPI thingies (which are simply zipfiles) I usually find stupid javascript "installer" snort scripts which wouldn't do anything useful unless I run them as root (yeah, right, I'm as stupid as that). But it's not really hard to extrapolate from what you see in the install.js things, the bla.jar files (which are again simply zipfiles) and the examples set by mozilla-tabextensions to find a working install procedure.

So what I nowadays do to install extensions by hand but cleanly is rip the XPI apart and copy the bla.jar into /usr/lib/mozilla-nameoftheday/chrome/. Then I look at the install.js to see the register-something calls and populate my 99... fragment with the appropriate entries. Run the update program, restart moz, done.

Here's the entry dealing with the editcss extension as an example (they all look very similar):

content,install,url,jar:resource:/chrome/editcss.jar!/content/editcss/
locale,install,url,jar:resource:/chrome/editcss.jar!/locale/en-US/editcss/
skin,install,url,jar:resource:/chrome/editcss.jar!/skin/classic/editcss/

After seeing a nice traffic graph on a friend's site, I decided to install mrtg. Being a perfectionist with slow boxes, the defaults (ie. use mainly snmp) didn't make me happy.

I ended up writing about 10 small perlies that either query /proc or sift through logfiles. It worked, but not very nicely: lotsa perl processes starting every 5 minutes and quite some code duplication. Rethink. Improve.

So here's the new, combined, all-in-one solution: a single script that does the data gathering all in one go. It's called bigstat.

bigstat reads a couple of simple things from /proc (memory usage, interface traffic counters, cpu stats and load average), but all that is hardly new and not worth talking about. It also gets at the firewall packet drop counters and plots df -k vs. df -i.

What is notable IMHO is that bigstat also deals with sources that are decidedly not nice enough to provide convenient counters or gauges: my apache access log for example, the mail logs and my inn logs (the "common" way of getting apache info for example involves parsing the html output of mod_status...bleh, for mail people have parsed mailstats output and for inn there's nothing ready-made except for CNFS storage.)

My approach there is to use some builtin logtail functionality together with persistent counter and offset files: go over the unread/new parts of the log, look for some useful pattern and increase the counters. Then save the last counter states in the persistent counter file and also remember where in the file we were (plus inode). This guarantees counter continuity regardless of log rotation. bigstat then writes all the fourliner data mrtg expects into separate files, and mrtg just reads them via a 2-liner shell wrapper around cat. This works great and is very efficient.

If you need some inspiration to set up something similar: help yourself to my examples here. The script and mrtg config file are gpl'd. The proc stuff and iptables-usage are linux-specific, and the regexp matches will definitely need adjustment for your environment.

• cleansed mrtg config
• bigstat script
• read-bigstat script

I'm talking about the "Speedtouch Home/Pro" which I got cheap from a friend.
click here for the rest of the story...

The CA.pl example script coming with OpenSSL has a couple of nice features (among lots of exceedingly ugly ones), namely -signcert: that one, slightly adjusted to eat real input files instead of this silly newcert.pem foolishness, can convert an existing cert into a req and does sign that afterwards.
click here for the rest of the story...

i haven't set up clamav to run as a milter on my servers - yet. yes, i know about mailscanner, amavis and friends...they're all too fat for what i want, and clamav's mail parsing facilities (at least in the versions i could get onto my Debian/stable servers) are nonexistant. so i've got dual queues, between which some kind of filter is moving stuff after scanning.

my small script is a simple wrapper around MIME::Parser (see libmime-perl in debian) that reads sendmail queue files, extracts the content into a tempdir, runs clamscan on that and depending on the result, moves the stuff into the quarantine or the real mail queue. Feel free to (ab|re|per)use.

My exmh environment is full of small tweaks for my needs, acquired over the years. exmh is written in tcl, which is likely the weirdest almost-mainstream scripting language, but not bad at all - however lousy I am at it.

So here's my helpers to make training your Bayes filter (spamassassin or other) a bit more convenient.
click here for the rest of the story...

I'm collecting/snarfing/stealing sigquotes whenever I happen to spot something pun-riddled, nasty, cool or just plain stupid.

The current selection is here, ready for strfile and fortune.

Some of them are bound to exceed McQ when not used alone, but that could not be helped.

Please drop me an email if you find bad or missing attributions.

This is how a genuine metallica bootleg sounds. Amazing. (kilroy^Wköhntopp was here...) I positively hate the recent Sue-O-Mania regarding copyright issues.

...and so is some stuff you may find at the locations below. therefore,

do proceed with caution, make sure that nothing edible or drinkable is in your vicinity and enjoy life (and death) as weird and rich as they come.

• rotten.com
• Death and Dementia
• Can you handle life?
• StinkyMeat
• goatse.cx
• tubgirl.com

"Everything we have is yours."
Link

Please help yourself to anything in there. Or not, as things may be. You don't trust me?! Good. That concludes the lesson.