Random Linux tips

Playing with Arch Linux, I was forced to learn a thing or two about terminals. For example, I've often seen that silly annoyance where VI would start typing A, B etc when using arrow keys in insert mode; apparently it's due to a mismatch between what VI thinks the $TERM type should send and what actually gets there. In my case, I had to add the following option in my .vimrc: set term=builtin_xterm Also: xterms colors and options go in a .Xresources file, which must be loaded at some point with "xrdb -merge .Xresources" Meanwhile, emacs was taking ages to start up. Turns out it's doing some funky things with hostnames, you can use strace to see where it gets stuck polling for what emacs thinks is the machine name, and make sure that name can be resolved quickly (e.g. fix your /etc/hosts). Who knew grep can use colours? grep --color=auto (note: the "auto" scheme assumes a dark background for the terminal). And who knew there was such a thing as colordiff?

Social experiments with Facebook IDs

Having just watched "The Social Network", I stumbled on a post on Twitter pointing to graph.facebook.com, the free API you can use to scrape the shit out of FB (well, almost).

Turns out the API will work with IDs. Since FB started as a Harvard-only site, the first few hundred users were all Harvard alumni, obviously. So I started thinking about simple experiments like finding the most popular surnames, certain of having my class-based prejudices reinforced by loads of Winklevoss-style "aristonames". Turns out the most common names are actually Asian -- the elites of tomorrow, of course.

That's the issue, isn't it? Harvard is (supposedly) a top institution, churning out the "elites of tomorrow"; they won't all become Mark Zuckerberg, but they probably won't be homeless either.

So, as a joke, I wrote a script looking for Wikipedia pages dedicated to the first 1000 users of Facebook. Turns out there are a lot of very common names, which obviously result in false positives; unfortunately Wikipedia doesn't give you easily-parsed metadata (here's a new project for Jimbo Wales and friends), so I couldn't do things like discarding everyone born before 1970. With a bit of patience, I narrowed down the number to a rough 6%. Some of them are (or were) Facebook employees, of course, but there are also young poets, writers and comedians.

You would probably get better results by replacing Wikipedia with LinkedIn, which would include more successful businesspeople and professionals -- Harvard's bread and butter. Obviously you could also start digging across the entire FB userbase, beyond the first lucky Harvardites.

These web APIs are a great tool for smart researchers; you now have a lot of data to be correlated with a little bit of programming glue and very little time. The result might not be scientifically exact, but could still unearth surprising insights.

XKCD Fanfiction

Panel 1:
Stick Figure A: "Can you believe it? I once touched Michael Jackson's HAND!"
Stick Figure B: "So what?"

Panel 2:
SFB: "You touched the hand of a singer famous for grabbing his private parts while dancing. Did this improve your life in any way?"

SFA: "..."

Panel 3:
SFB: "I mean, did you ever SPEAK to him? Did he write you a SONG or something?"

Panel 4:
SFA: "No, but last year Donald Knuth waved at me through a cafeteria window."
SFB: "Dude, that's AWESOME!"


ALT-TEXT: "He was really looking at some Finnish creep behind me, one Snoopy Torvalds I think. Yeah, never heard of him either."

Valid keywords for KIO.Job.addMetaData

I spent three hours last night, pulling my hair out, while trying to add a custom HTTP header to a StoredTransferJob generated by KIO.storedHttpPost.

In my naivety, I thought KIO.Job.addMetaData(key,value) would accept an HTTP header name as key, and the actual header value as value. I was twice wrong: "key" is a limited list of accepted keywords (documented in the obscure DESIGN.metadata file, buried in the KDE source tree and not linked by any tutorial), and "value" is the complete header (e.g. "Content-Type: application/x-www-form-urlencoded"). It's essential to get the key right, or the metadata will be silently dropped (argh); I had to fiddle with Wireshark to find out. By the way, the two essential keys you probably want to remember are "content-type" and the life-saving "CustomHTTPHeader""customHTTPHeader" (DAMN LOWERCASE C!!! it's wrong in the design document, btw.).

(That's the terrible thing about KDE APIs: lots of barely-documented quirkiness hidden under an appearance of ease-of-use. You start developing thinking that it's all going to be easy, and find out along the way that things are not really as simple as they seem. I guess I should be thankful that at least they have good web tools to browse and grep their source, and fairly complete doxygen docs... but it still hurts more than it should.)

If anything can go wrong...

Blogger forced people to move off FTP publishing... expect breakage.