Posts

Posted on

Blogspam

I saw my first instance of blogspam on Webword at the start of October. Someone had used a “comments” form to place an ad at the bottom of one of John’s postings. At the time, I commented on how easy this would be to do in bulk. Given how simple this is, I expressed a small measure of surprise that it isn’t done more often.

Well, it is now.

Yesterday I found an article at The Laboratorium (via BoingBoing) which talked about how spammers are starting to manipulate blog comments. This in turn pointed me to Mark Pilgrim’s site, where he discusses the problem in further detail.

This “comment spam” comes in addition to “referer spam” (see also here), which I have started noticing here on Sunpig already. I had been playing around with a referer script the other week, thinking that it might be cool to show what other pages link to this site, but what seemed cool last week seems slightly worrying now.

Basically, the problem is that you are allowing other people to update the content on your site. Comments, trackbacks, and referer listings all allow other people to manipulate your web site. This is a cool feature because it makes for a more dynamic ecosystem of discussion, but it’s a risk because you might not always like what the other people make your web site say.

And it might not even just be a risk of annoyance (spam) or a security risk (autodiscovery of your mt.cgi script, followed by a dictionary attack). What happens when someone uses your web site to post libellous comments about someone else, or pornographic pictures, or even gasp the DeCSS source code? Other people may have written it, but it’s on your web site. Could you be legally liable? Is a disclaimer message enough to divert responsibility?

Fortunately, Mark’s article shows that we have some really clever people on the case already. Unfortunately, given the success (or lack thereof) that anti-spam solutions have had with email, it seems likely that blogspam is here to stay. We can try to minimize it, but it isn’t going to go away any time soon.

Posted on

Linux, cursors, and bacon

Martin's Annual Linux Experience 2002The week before last, Linux was starting to get me down. I just wanted stuff to simply work, rather than to have to do work to make it work. I got a lot of the gripes off my chest by moaning about them here on Sunpig, though.

The following evening, I nuked my SuSE install, put on Mandrake 9 for an hour or two, and went straight back to SuSE again. Seeing Mandrake made me realise just how much I had learned about SuSE since the start of October, and how much I would have to relearn to get as fluent with Mandrake. Not as much effort as moving from Windows to Linux, but it would still be infrastructural work, when my aim was to get started on the higher-level stuff.

(Reinstalling SuSE felt like a relief, which was odd, as I had just spilled my guts complaining about it. But that rant had also clarified for me the reasons I was persisting with my Annual Linux Experiment, and that was because I find it too hard to stomach Microsoft’s business practices. Moving to Linux is not easy in the same way that going vegetarian isn’t easy. After a couple of weeks, you start to get these cravings for bacon…)

After that I was fine again for a while. I was happy with my new-found conviction. Thomas C. Greene wrote an article in the Register on how to improve your fonts in Linux, and that helped a bit. (They still don’t look as good as they do in the screenshots, but they’re okay.) I got Apache installed and running–yay–and started doing some work on Movable Type.

It was while I was doing this that the next niggle jumped up: In Kedit (and every other KDE application) the cursor blink rate was very slow. And worse than this, the cursor would continue to blink while I used the cursor keys to move through a document.

This may not sound like much. So the cursor blinks slowly, so what? It doesn’t stop you from editing documents, it doesn’t mean that the cursor isn’t there–it’s just blinking slowly. Right?

Argh. Sometimes it’s the little things that make the difference between satisfyingly usable and mind-bogglingly frustrating. Because this isn’t as little a thing as it seems. If you write a lot (code, prose, whatever), you get very used to moving about a document with the arrow keys or control key combinations rather than using the mouse to reposition the cursor. It’s much faster to keep your hands on the keyboard, look up, and arrow-key the cursor to a new position that it is to move your hand to the mouse, find the mouse pointer on screen, move the pointer, click, then reposition your fingers on the keyboard. Not only is it slower because it takes more actions, I seem to remember some research that showed that different areas of the brain are active when you use the mouse and the keyboard. So your brain has to switch tasks as well. Not efficient.

Back to slow-blinking cursors: when the cursor blinks “off”, it is invisible. It is invisible for a significant fraction (more than half) of a second. During this fraction of a second, I can make several keystrokes, and move the cursor several times with an arrow key. But while the cursor was invisible, I didn’t know exactly where it was in the text.

Actually, the slow blink rate only masks the real problem. The real problem is that the cursor’s blink status really should be set back to “on” whenever you press a cursor key. This way, it is always visible when you’re arrowing through a document, regardless of the blink speed.

But could I find an option in KDE to change the blink rate, or the blink behaviour? No. Damn.

So I could guess that I’d got the cursor in the right place, and start typing again. This didn’t always work, and resulted in me having to go back and re-edit. Or I could wait whenever I reckoned that the cursor was roughly in the right place, wait for it to reappear, and then reposition if necessary. Or I could use the mouse to reposition the cursor.

All of these options are significantly slower than the way I’m used to writing. And because it was taking longer to go back and fix typos, or edit sentences, I found myself losing track of thoughts, and getting distracted. The speed at which I coded and wrote slowed down by much more than the amount of additional time it took to move the cursor.

A bit of Googling around found me a couple of newsgroup postings from people who were complaining of the same problem, but without any useful follow-ups. Non-KDE applications (XEdit, emacs) didn’t appear to have the same problem, so it looked like a KDE thing. Although I hadn’t installed it, the SuSE disks come with the Gnome desktop, so I tried firing it up. And lo, cursors in gEdit (and other Gnome apps) behave normally!

I could just use gEdit in KDE–even though it’s a Gnome app, the Gnome libraries are all installed, and KDE will quite happily fire it up. But I’d just got used to Kate, and gEdit doesn’t show a list of open files on the left hand side of the window. (There may be a plugin that provides that feature, but I couldn’t see one.)

As it turns out, some deeper searching through Google revealed that the cursor blink rate is not set by KDE, but by the underlying Qt libraries. And in fact, there is a little utility called qtconfig that allows you to set the cursor blink rate. Yay!

Setting the cursor blink rate to a low value (I’ve got it at 50ms at the moment) is almost as good as having it behave properly, i.e., resetting blink status to “on” at every keystroke.

Ah, but is there a way to make this happen? Well, it appears so. According to the changelog for Qt 3.0.5, Trolltech have fixed this version to “Reset blink timer when receiving a keypress event to keep the cursor visible during navigation.”

So…all I should have to do would be to upgrade my Qt libraries to version 3.0.5, right? Hmm. According to the YaST tool, I already have version 3.0.5 installed. Why, then, are my apps not behaving in the manner described? Dunno. But I’ve got the horrible feeling that solving this is going to involve grabbing the source for both Qt and KDE, and rebuilding both of them.

All this effort for a simple cursor blink. I’m craving bacon.

Posted on

Boom, bust

Wow, it’s over two years now since the dot-com bubble burst. Joel has a couple of tables of figures showing stock comparisons, one from last week, and one from two years ago.

The table from October 2000 shows how a selection of tech stocks were prices in that month, compared with their 52-week highs. Lots of 90%+ losses there. This years’ table shows how those same stocks are faring now, compared with their prices back then. Almost all of them are significantly down again, and by similarly large percentages. But that’s over a two year period, as opposed to a 3 month crash.

Posted on

MTRandomLine plugin

I’ve just finished doing the documentation for my first Movable Type plugin, MTRandomLine. It’s a tag that extracts and displays a random line from a text file, or a Movable Type template module. Right now, I’m using the tag on this page to display the list of random entries you see in the sidebar.

Note that it only performs the random selection when the relevant MT template is rebuilt. It doesn’t give you a new random selection each time you visit the page. There are plenty of server-side and client-side scripts around that do that already (just go to the Movable Type support forum and do a search for “random”).

The tag is probably best suited to doing random quotes, or random images. It’s a bit of a stretch (though entirely possible) to make it display random blog entries. So my next project is to make a <MTRandomEntries> container tag, which will set up a context for a selection of random entries from your blog (or from a category within the blog). You’ll then be able to use the normal <MTEntryTitle>, <MTEntryBody> and other tags within it. Watch out for it soon!

Posted on

Games Day

One room. Two LCD projectors, throwing 2 x 3 meter pictures against the walls. Two XBoxes. Eight controllers. Eight-way, split-screen, multiplayer Halo!

Holy cow, that rocked.

Oddly enough, Microsoft’s games division doesn’t automatically trigger my ethics reflex. I’ve never had a problem with Microsoft producing games software, because there is so much other entertainment content out there, that the chances of them obtaining a monopoly position are vanishingly small. The XBox itself concerns me a little, because there are fewer corporate adversaries in the console marketplace, and I can imagine that Microsoft’s ultimate goal is to have the it be the “default and only” gaming console. (Likewise with their new mobile phone platform.)

I guess I’m happy enough with MS being a competitor in a healthy, heterogenous marketplace, but not with them having a monopoly position, or with them flexing their muscle against a smaller number of players.

Or maybe I’m just trying to justify my desire for an XBox so I can play Halo? These are the questions that keep me awake at night…

Posted on

Valid RSS

I’ve made a couple of minor changes to the RSS Feed for my blog. It’s still RSS 0.91 (I haven’t had the time to get to grips with about 1.0 or 2.0 yet–but soon!), but now it’s valid RSS 0.91, as validated by Mark Pilgim and Sam Ruby’s new RSS validation service.

Valid RSS

The main change involved the lastBuildDate and pubDate elements, which have to be in RFC 822 format (e.g., Fri, 25 Oct 2002 07:04:23 +0100). Movable Type can generate a date like this quite happily: <$MTEntryDate format="%a, %d %b %Y %H:%M:%S +0100" $>. But the problem with this is that the time zone (+0100) is now hard-coded. If you change the Time Zone setting in your blog preferences, the RSS feed won’t match up any more.

Not that big a deal, really, but it’s not as elegant as having it pick up the time zone automatically. Movable Type does actually have a time zone element (<$MTBlogTimeZone$>), but it generates the time zone with a colon in the middle, i.e. as “+01:00”.

John Gruber has put together a new MT plugin which provides the time zone in RFC 822 format. You can use this to build up a proper, dynamic RFC 822 date like so: <$MTEntryDate format="%a, %d %b %Y %H:%M:%S" $> <$MTrfc822BlogTimeZone$>. Note that you do need that space between the two tags–if you cut-and-paste from the sample code in the plugin documentation, it’s not there.

Alternatively, you can use Brad Choate’s regex plugin. This doesn’t give you an extra tag, but instead allows you to apply a regular expression to the output of a standard MT tag, like so: <$MTBlogTimezone regex="s/://"$>.