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.

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.

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.