The current state of the art in comment spam

Write, geek! gets a fair amount of spam replies. This sur­prised me at first, when it be­gan hap­pen­ing al­most im­me­di­ate­ly af­ter the blog was set up and con­tent was post­ed. I should have known bet­ter; there’s al­most no cost to spam­mers in spam­ming even un­pop­u­lar blogs, so why would they make an ex­cep­tion for mine?

I’m us­ing the Akismet plug­in for WordPress, so it’s not like any of the­se com­ments ac­tu­al­ly make it to my blog. In fact, I’d nev­er even have to see them, if not for the fact that I reg­u­lar­ly clean the­se com­ments out of my spam fold­er by hand. I do this part­ly to en­sure that noth­ing le­git­i­mate gets fil­tered in­cor­rect­ly (which hap­pens some­times) and part­ly be­cause I like to sort of keep tabs on the cur­rent ‘state of the art’ in spam­ming.

The cur­rent state of the art in spam­ming is this: the com­ments are get­ting bet­ter. No longer are com­ments jam-packed with dozens of links com­mon­place (one par­tic­u­lar de­fault WordPress set­ting prob­a­bly made those al­most 100% in­ef­fec­tive), but they’ve been large­ly re­placed with com­ments that mas­quer­ade as… ac­tu­al com­ments!

The idea of noise dis­guised as sig­nal is noth­ing new if you’ve used e-mail in the last 15 years, but that the noise is get­ting bet­ter (read: more dif­fi­cult for hu­mans to de­tect) is some­what sur­pris­ing. Of course, the­se com­ments are no match for a large, dis­trib­ut­ed sys­tem like Akismet, which all-knowingly sees what’s be­ing post­ed to prob­a­bly mil­lions of blogs, but the well-disguised, large­ly pseudo-flattering com­ments are prob­a­bly now de­signed to get hu­man blog au­thors to click the “Not Spam” but­ton, free­ing them the com­ments the spam box so that they can do their SEO-based dirty work.

Of course, gen­tle read­ers, I’m far too smart to fall for that, but not so blind­ed by my ha­tred for spam to be un­able to ap­pre­ci­ate a well-crafted work of au­thor­ship, like this one I just found:

Spam that reads "Excellent read, I just passed this onto a colleague who was doing a little research on that. And he actually bought me lunch because I found it for him smile So let me rephrase that: Thanks for lunch!"

Sure, it’s not per­fect, but some­one out there put some mod­icum of thought in­to it, which is the least you could ask of the au­thor of a work that’s go­ing to be dis­trib­ut­ed on a mas­sive scale.

Plus, it’s a lot bet­ter than this anti-gem I al­so just found:

Spam that reads "Why jesus allows this sort of thing to continue is a mystery"

Can you get more un­in­ten­tion­al­ly self-referential than that? (No, you can­not… and yes, that was a chal­lenge.)

How to transfer photos from a Game Boy Camera to a computer (in Linux)

A few days ago, I found a Flickr group thread that was prac­ti­cal­ly beg­ging for my in­put. It read some­thing like “Hey Everett, you’re sur­pris­ing­ly enough not the on­ly per­son out there with the­se two in­ter­ests (one ob­scure and the oth­er semi-so). Would you be will­ing to help out quite pos­si­bly the on­ly oth­er per­son in the world who cares about the­se things?”

Not on­ly was I like, “Heck  yeah!,” but I de­cid­ed that this was wor­thy of blog­ging, in case a third in­di­vid­u­al hap­pens to de­vel­op the­se in­ter­ests. (If this is you, wel­come!)

So, in case you find your­self want­i­ng to get crap­py pho­tos—a term I use most af­fec­tion­ate­ly — like the­se:

off of one of the­se:

red Game Boy Camera

and you use Linux:

(I kid!)

…like I do, read on.

The hard­ware I’m us­ing to down­load pho­tos over USB is SmartBoy USB car­tridge read­er (which is made by the­se peo­ple). And there just so hap­pens to be a great open-source pro­gram for fa­cil­i­tat­ing this task us­ing this de­vice (or a sim­i­lar car­tridge read­er): gbcflsh.

So what’s the prob­lem? gbcflsh is on­ly dis­trib­ut­ed as source, and the source fails to com­pile un­der re­cent re­leas­es of Ubuntu. I con­tact­ed the de­vel­op­ers of gbcflsh, and one gave me some sug­ges­tions for fix­ing the source code. They have yet to pub­lish the fixed source, so I’ll doc­u­ment how I got it to com­pile.

(If you don’t care about this, just grab the bi­na­ry I made: gbcflsh 32-bit, md5sum: 85b185706c3d5fe45b7787787f8510bd; gbcflsh 64-bit, md5sum: 4326e08fcfb5be39004c290df2a71988)

  1. Download and ex­tract the source code.
  2. Install the fol­low­ing pack­ages:
    gcc 4.3.3, qt4-dev-tools, libftdi-dev 
  3. Focus on the fol­low­ing files:
  4. Add the fol­low­ing to the bot­tom of the #in­clude sec­tion of each file:
    #in­clude <cst­dio>
  5. That’s it! Compile it like you al­ready know how to do (which I won’t get in­to here).

gbcflshWhen you run gbcflsh (you’ll need to do so as root, by the way), it’ll look a lit­tle bit like what you see to the right. Select the vis­i­ble op­tions (USB, Auto, Ram: 128 KB) and click “Read RAM.”

If all goes well, you’ll end up with the con­tents of your camera’s RAM in the form of a .sav file. Great! The hard part is be­hind us, but we’re not quite done yet.

Next, you’ll need a pro­gram that will ex­tract pho­tos from the save file. I be­lieve there are a few, but they all seem to be for Windows. Fortunately, the one I use works per­fect­ly un­der Wine. gbcameradumpIt’s called GBCameraDump.exe, and it can cur­rent­ly be found here. Download it, run it via Wine and se­lect the .sav file you got from gbcflsh. You’ll have some­thing that looks like this screen­shot (ex­cept hope­ful­ly with bet­ter pho­tos).

I would al­so ad­vise you to — if this sort of thing mat­ters to you — check the or­der of the saved im­ages. They’re like­ly to be out of or­der due to, it seems, the way Nintendo de­cid­ed to han­dle the sav­ing of im­ages to the car­tridge. (Also, you’re like­ly to find some pho­tos you thought were delet­ed, which may come as a sur­prise.)

So there you have it: how to get pho­tos off of this cam­era of the past, us­ing the op­er­at­ing sys­tem of the (sigh) fu­ture.