Code Is (Not) Literature

Peter Seibel writes:

It was sometime after that presentation that I finally realized the obvious: code is not literature. We don’t read code, we decode it. We examine it. A piece of code is not literature; it is a specimen.

His essay seems to stand counter to Jeremy Ashkenas’ presentation I posted three years ago.

I disagree. Seibel misses the symmetry of reading and writing.

The act of writing English often flows and causes a reading to flow. The act of programming rarely flows and is highly analytical, so it follows that a reading will similarly lack flow and require analysis.

Code is simply an unconventional type of literature.

Furniture Music

I produced a vinyl collage radio show at KDVS over the summer of 2012. Collected below are those shows:

Pandora, Spotify, and the Internet “radio” rates

Damon Krukowski (of Galaxie 500 fame) tweeted information about his royalty rates from Pandora back in October and has followed up today with an article on Pitchfork going into detail:

… by my calculation it would take songwriting royalties for roughly 312,000 plays on Pandora to earn us the profit of one– one– LP sale. (On Spotify, one LP is equivalent to 47,680 plays.)

Curiously, he neglects to mention his terrestrial FM royalty rates in what is essentially a lament on Internet radio.

What Krukowski misses is the real danger of these services being on-demand and therefore supplanting most purchasing desire. Traditional radio also has very low royalty rates, but given its scheduled nature (off-demand) serves artists big and small as an advertising platform without cannibalizing sales.

What’s most worrisome about Krukowski’s logic are the positions drawn about the upcoming royalty rate debates in Congress:

Pandora in fact considers this additional musicians’ royalty an extraordinary financial burden, and they are aggressively lobbying for a new law– it’s now a bill before the U.S. Congress– designed to relieve them of it.

Sadly, Krukowski’s financial self-interest has him on the wrong side of this debate; if you’ve ever wondered why we’re bereft of amazing Internet radio stations — why we don’t find the same satisfying application of niche and micro-focus in Internet radio as we do on many websites — look no further than the current royalty rates.

Spotify and Pandora are not traditional radio and should not be rated as such. They’re new age rental services which should reward musicians and labels by charging rental rates. It’s not clear whether that’s a viable business model, but at least it’s honest.

Using cron, ssh, and rsync to automate backups on OS X

I’ve long appreciated this page by Troy Johnson, detailing the process of using cron, ssh, and rsync to create free, encrypted, and automated backups of remote systems. I use it to make personal backups of remote servers, just in case every line of backup defense at my hosting group fails.

But I could never get it to work on OS X. If you’ve ever set up more than a modestly simple cron job, you’ll know the difference in environment variables between your normal session and cron is enough to frustrate any UNIX denizen.

Troy’s method, specifically, seemed not to work with my SSH private keys. The command I set up ran beautifully as my user, but would always fail under cron.

I haven’t researched the particulars as to why, but private key access is apparently handled through a separate daemon under which a cron+ssh would not normally have access to. Simply add the following (tested under OS X Lion) at the start of your script to fix your environment variables and resolve this issue:

declare -x SSH_AUTH_SOCK=$( find /tmp/launch-*/Listeners -user your_user -type s | head -1 )

Replacing your_user with your username.

Here’s the entirety of my setup:

@daily /Users/your_user/

declare -x SSH_AUTH_SOCK=$( find /tmp/launch-*/Listeners -user your_user -type s | head -1 )

echo "Backing up /the/directory"
$RSYNC -az -e "$SSH -i $KEY" $RUSER@$RHOST:/the/directory /Users/your_user/Backups/remotehost-server/the/directory