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 began hap­pen­ing almost imme­di­ate­ly after the blog was set up and con­tent was post­ed. I should have known bet­ter; there’s almost no cost to spam­mers in spam­ming even unpop­u­lar blogs, so why would they make an excep­tion for mine?

I’m using the Akismet plu­g­in for Word­Press, so it’s not like any of these com­ments actu­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 these com­ments out of my spam fold­er by hand. I do this part­ly to ensure that noth­ing legit­i­mate gets fil­tered incor­rect­ly (which hap­pens some­times) and part­ly because I like to sort of keep tabs on the cur­rent ‘state of the art’ in spamming.

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 default Word­Press set­ting prob­a­bly made those almost 100% inef­fec­tive), but they’ve been large­ly replaced with com­ments that mas­quer­ade as… actu­al comments!

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 humans to detect) is some­what sur­pris­ing. Of course, these com­ments are no match for a large, dis­trib­uted sys­tem like Akismet, which all-knowingly sees what’s being 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 designed to get human blog authors 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 hatred for spam to be unable to appre­ci­ate a well-crafted work of author­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 into it, which is the least you could ask of the author of a work that’s going to be dis­trib­uted on a mas­sive scale.

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

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

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

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 input. It read some­thing like “Hey Everett, you’re sur­pris­ing­ly enough not the only per­son out there with these two inter­ests (one obscure and the oth­er semi-so). Would you be will­ing to help out quite pos­si­bly the only oth­er per­son in the world who cares about these things?”

Not only was I like, “Heck  yeah!,” but I decid­ed that this was wor­thy of blog­ging, in case a third indi­vid­ual hap­pens to devel­op these inter­ests. (If this is you, welcome!)

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

off of one of these:

red Game Boy Camera

and you use Linux:

(I kid!)

…like I do, read on.

The hard­ware I’m using to down­load pho­tos over USB is Smart­Boy USB car­tridge read­er (which is made by these peo­ple). And there just so hap­pens to be a great open-source pro­gram for facil­i­tat­ing this task using this device (or a sim­i­lar car­tridge read­er): gbcflsh.

So what’s the prob­lem? gbcflsh is only dis­trib­uted as source, and the source fails to com­pile under recent releas­es of Ubun­tu. I con­tact­ed the devel­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 compile.

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

  1. Down­load and extract the source code.
  2. Install the fol­low­ing packages:
    gcc 4.3.3, qt4-dev-tools, libftdi-dev 
  3. Focus on the fol­low­ing files:
    src/Logic.cpp
    src/ReadFlashThread.cpp
    src/ReadRamThread.cpp
    src/WriteFlashThread.cpp
    src/WriteRamThread.cpp
  4. Add the fol­low­ing to the bot­tom of the #include sec­tion of each file:
    #include <cst­dio>
  5. That’s it! Com­pile it like you already know how to do (which I won’t get into 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 options (USB, Auto, Ram: 128 KB) and click “Read RAM.”

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

Next, you’ll need a pro­gram that will extract pho­tos from the save file. I believe there are a few, but they all seem to be for Win­dows. For­tu­nate­ly, the one I use works per­fect­ly under Wine. gbcameradumpIt’s called GBCameraDump.exe, and it can cur­rent­ly be found here. Down­load it, run it via Wine and select the .sav file you got from gbcflsh. You’ll have some­thing that looks like this screen­shot (except hope­ful­ly with bet­ter photos).

I would also advise you to — if this sort of thing mat­ters to you — check the order of the saved images. They’re like­ly to be out of order due to, it seems, the way Nin­ten­do decid­ed to han­dle the sav­ing of images to the car­tridge. (Also, you’re like­ly to find some pho­tos you thought were delet­ed, which may come as a surprise.)

So there you have it: how to get pho­tos off of this cam­era of the past, using the oper­at­ing sys­tem of the (sigh) future.