The current state of the art in comment spam

Write, geek! gets a fair amount of spam replies. This surprised me at first, when it began happening almost immediately after the blog was set up and content was posted. I should have known better; there’s almost no cost to spammers in spamming even unpopular blogs, so why would they make an exception for mine?

I’m using the Akismet plugin for WordPress, so it’s not like any of these comments actually make it to my blog. In fact, I’d never even have to see them, if not for the fact that I regularly clean these comments out of my spam folder by hand. I do this partly to ensure that nothing legitimate gets filtered incorrectly (which happens sometimes) and partly because I like to sort of keep tabs on the current ‘state of the art’ in spamming.

The current state of the art in spamming is this: the comments are getting better. No longer are comments jam-packed with dozens of links commonplace (one particular default WordPress setting probably made those almost 100% ineffective), but they’ve been largely replaced with comments that masquerade as… actual comments!

The idea of noise disguised as signal is nothing new if you’ve used e-mail in the last 15 years, but that the noise is getting better (read: more difficult for humans to detect) is somewhat surprising. Of course, these comments are no match for a large, distributed system like Akismet, which all-knowingly sees what’s being posted to probably millions of blogs, but the well-disguised, largely pseudo-flattering comments are probably now designed to get human blog authors to click the “Not Spam” button, freeing them the comments the spam box so that they can do their SEO-based dirty work.

Of course, gentle readers, I’m far too smart to fall for that, but not so blinded by my hatred for spam to be unable to appreciate a well-crafted work of authorship, 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 perfect, but someone out there put some modicum of thought into it, which is the least you could ask of the author of a work that’s going to be distributed on a massive scale.

Plus, it’s a lot better 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 unintentionally self-referential than that? (No, you cannot… 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 practically begging for my input. It read something like “Hey Everett, you’re surprisingly enough not the only person out there with these two interests (one obscure and the other semi-so). Would you be willing to help out quite possibly the only other person in the world who cares about these things?”

Not only was I like, “Heck  yeah!,” but I decided that this was worthy of blogging, in case a third individual happens to develop these interests. (If this is you, welcome!)

So, in case you find yourself wanting to get crappy photos—a term I use most affectionately—like these:

off of one of these:

red Game Boy Camera

and you use Linux:

(I kid!)

…like I do, read on.

The hardware I’m using to download photos over USB is SmartBoy USB cartridge reader (which is made by these people). And there just so happens to be a great open-source program for facilitating this task using this device (or a similar cartridge reader): gbcflsh.

So what’s the problem? gbcflsh is only distributed as source, and the source fails to compile under recent releases of Ubuntu. I contacted the developers of gbcflsh, and one gave me some suggestions for fixing the source code. They have yet to publish the fixed source, so I’ll document how I got it to compile.

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

  1. Download and extract the source code.
  2. Install the following packages:
    gcc 4.3.3, qt4-dev-tools, libftdi-dev
  3. Focus on the following files:
    src/Logic.cpp
    src/ReadFlashThread.cpp
    src/ReadRamThread.cpp
    src/WriteFlashThread.cpp
    src/WriteRamThread.cpp
  4. Add the following to the bottom of the #include section of each file:
    #include <cstdio>
  5. That’s it! Compile 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 little bit like what you see to the right. Select the visible options (USB, Auto, Ram: 128 KB) and click “Read RAM.”

If all goes well, you’ll end up with the contents of your camera’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 program that will extract photos from the save file. I believe there are a few, but they all seem to be for Windows. Fortunately, the one I use works perfectly under Wine. gbcameradumpIt’s called GBCameraDump.exe, and it can currently be found here. Download it, run it via Wine and select the .sav file you got from gbcflsh. You’ll have something that looks like this screenshot (except hopefully with better photos).

I would also advise you to — if this sort of thing matters to you — check the order of the saved images. They’re likely to be out of order due to, it seems, the way Nintendo decided to handle the saving of images to the cartridge. (Also, you’re likely to find some photos you thought were deleted, which may come as a surprise.)

So there you have it: how to get photos off of this camera of the past, using the operating system of the (sigh) future.