Shedding Bikes

I have this hypothetical question I’ve been using periodically to talk about the relevance of ad hominem in evaluating software:

What if Hitler gave you a cheese sandwich?

It’s a pretty simple question. Imagine you’re sitting there and, yeah, Hitler is eating across the table from you. He’s got a cheese sandwich and he hands it to you. “Hey, want my grilled cheese?”

Most normal folks would turn him down, politely most likely but they’d definitely not eat a sandwich from a guy who used to slowly increase his doses of arsenic. But also, you’re probably thinking, “No way, this guy’s an insane mass murderer, I’m not eating that damn sandwich.”

Ok, change this up some more, what if you were walking by and there was a box labeled “Cheese Sandwich” and right under that is a Nazi Swastika. You gonna eat it? No Hitler involved, just a box with a cheese sandwich on it sitting there looking like you can eat it if you want?

Sure, you might open it, look at it, maybe sniff it, but most normal people won’t eat it. Why? Because that Swastika has suddenly got you thinking about the history of this sandwich. Why is that on there? Where did this thing come from? Is it poisoned?

Let’s go one step further, and say you just find a random sandwich in a clear plastic bag on a table. Nobody’s around, and you’re kind of hungry. You going to eat it? Again, most normal people who can buy a sandwich won’t eat it. It’s just laying there. Who knows how long it’s been there or what the hell’s been done to it.

Instinctively, humans have this sense of avoiding things that will poison them, and that involves using their memories, sense of history, and ability to think ahead to predict what could happen. This is how we’re able to figure out how to eat a huge range of stuff no other species has figured out. We use this finely honed sense of “that food will poison you” to avoid getting sick and to find food that will keep us fed.

Programmers and other “logical” types seem to lose this ability when it comes to information. They’ll frequently get information poisoned with stupid ideas because they think the motivations and history of the person telling them something doesn’t matter. They remove the context of the words and evaluate only what’s said and nothing else, and then believe the most absurd stuff ever.

This belief that any look at a speaker’s motivations is “ad hominem” leads many smart people to believe the incredibly stupid things.

Everything Has Already Been Said
The reason evaluating a person’s motivations matters these days is because there’s been a massive increase in the amount of information created and stored over the last 500 or so years. Basically, a whole hell of a lot has already been said by someone else at some point. In fact, most ideas are so horribly unoriginal that the only thing you really have to go on when evaluating them is why someone could be telling you this.

Let’s say I tell you that my software is “language agnostic”. Well, that’s been done before in other ways, so you have to look at why I might be telling you that. The idea itself isn’t original or that useful, but if I then tell you, “because I want people to be able to use the best tool and not get caught up in language wars,” then you can evaluate the statement better.

However, if I tell you don’t look at my motivations, or where I’m coming from, or what I used to do, and claiming “ad hominem!” then I’m most likely trying to trick. An honest person has no problem with you looking past the words to the motivation. Dishonest people will try to bluff so you don’t look too closely.

If more technologists did this kind of critical thinking, then it’d be harder to get them to use potentially dangerous or crap technology. If they accepted that most everything has been said or tried already, then they can use motivations and historical context to figure out why things might be different. They can also use it to call bullshit or question why things are the way they are.

The Sordid Past And Present Of Tor
Tor by itself, without knowing its history, seems like a great idea. You point your browser at it and suddenly you can view web pages without people knowing that it’s actually you. Great right?

Please Read: To help us keep this site running please visit our generous benefactor Top Tier Cakes website. There you will find a selection of birthday cakes and other celebration cakes for special occasion. You can visit their site here.

The problem is that Tor’s pedigree is less than stellar. First, it was originally a US Navy project then released to various “hackers” (a word which in a lot of ways is just synonymous with “NSA collaborator” or at least a wannabe). Whether the source code started there or just the idea, you have to ask why the hell the Navy would work on this and then release it.

The Navy of course gave some hand-wavy answer of wanting to use it, but the Navy just doesn’t do something like this without another reason. Who knows what it is, but I this makes my spidey sense go off.

That’s the first strike against Tor, but let’s look at more reasons to not use Tor. How about the research that showed how easy it is to break in various ways. Those might be fixable, so how about that there can be super nodes that with just a small sample of traffic can figure out a lot of content?

Alright, maybe that can be fixed, but then you read about a semi-secret volunteer group collecting data from 12 ISPs and handing it to the government. This Project Vigilant apparently has 600-1500 volunteers who are all hackers collecting and analyzing data and handing it straight to the government without user consent. Project Vigilant also claims it:

tracks more than 250 million IP addresses a day and can “develop portfolios on any name, screen name or IP address.”

Holy crap, that’s a lot of traffic analysis. Given how small the “hacker” community is, that’s also a gigantic percentage of hackers and security experts on the volunteer payroll of a group who’s job is to illegally wiretap people and circumvent the law on behalf of the government.

I don’t have to remind you abou the panic over the OpenBSD and NETSEC accusations. What about the various entries to the Underhanded C. The truth is, if a large group of determined and patriotic hackers want to infiltrate and inject seemingly innocent maliciousness into code they definitely can. With 600+ potential recruits, they definitely are.

Conflict Of Interest
But all of this is just unsubstantiated and could be hypothetical, what actually worries me is Jacob Appelbaum works on Tor and works for Wikileaks. This to me is the Hitler Grilled Cheese of the argument, the historical context that drives me away from Tor. Wikileak’s job is to take people’s secrets and show them and who’s hiding them to the world. Tor’s job is to do the inverse. The two project’s goals don’t align, and having one dude do both gives me the willies.

You see, if it is fairly probable that there are multiple attacks against Tor, that there is a group actively trying to collect enough data to make Tor pointless, a group with enough people to infiltrate the Tor project, and then Jacob is working for Wikileaks and Tor, then there’s too much going on for me to trust jack and/or squat. Jacob’s affiliation with Wikileaks has made Tor a target big time, in addition to the obvious conflict of interest.

For me–and this is not an accusation against Jacob–the chance that someone on the Tor project is in cahoots with someone else is too high. It’s either the government, this Project Vigilant, or Wikileaks, and who knows what. When claims surfaced that Wikileaks got its initial set of magically appearing documents from Tor, I wasn’t surprised. Having Jacob claim otherwise doesn’t help at all, and I still won’t believe this didn’t happen until possibly decades later when whatever really happens is declassified.

Finally, I will go on record right now saying Wikileaks rocks. I think there needs to be more of this, and actually I think the world will benefit more from more international coverage and more corporate leaks. But, if anyone from Wikileaks tries to work with me or on any project I’m on you bet your ass I’m not trusting them one bit.

Never trust a traitor, no matter how noble their intentions.

P.S. I have a long bet that SELinux is an NSA backdoor. Any takers?

I just uploaded the latest Tir 0.6 for everyone. This version has everything refactored into multiple modules, extensive unit testing, and built-in very easy to use background tasks. If you want to install it then follow the Tir Install guide to get it running.

Built-in Background Tasks
Over on Hype.la people can upload their pictures, which is great, except they usually want to upload monster photos that need to be scaled. There’s also things like search indexing, updating their static ads lists, and tons of stuff that really can just be don in a background task rather than hold up the browser.

Tir uses ZeroMQ so I figured, shouldn’t be too hard to make a nice little “background task” API. For those not familiar with the concept, a background task is basically a process you start that receives some kind of RPC to do work. You use these to offload long running processes like some of the stuff I mention above.

In Tir it’s dead simple, with a task process looking like this:

require ‘tir/engine’

function test(args)
Tir.dump(args)
end

Tir.Task.start { main = test, spec = ‘ipc://run/photos’ }
If you put this file in your app/ directory, then tir start will run it like it’s a normal handler. The difference is, instead of taking requests from Mongrel2 it accepts simpler messages on the 0MQ socket you have in spec.

Here’s an example handler that does receive messages from Mongrel2, but sends the headers off to the above background task and then fires off an OK reply right away:

require ‘tir/engine’

local conn = Tir.Task.connect { spec = ‘ipc://run/photos’ }

function main(web, req)
conn:send(‘photo’, req.headers)
web:ok()
end

Tir.stateless {route=’/Task’, main=main}
If you were to hit curl http://localhost:6767/Task then this would return OK, but you’d see the background task actually receive the headers and print them out.

Changing The 0MQ Socket
This is very simple right now, but already you can configure the socket that’s used to match your needs. It normally defaults to a raw PUB/SUB socket with out subscriptions or idents, but you can change that with a different config:

Tir.Task.start {
main = test, spec = ‘tcp://0.0.0.0:4545’,
recv_ident=’PHOTO_PROCESSOR’, socket_type=zmq.PULL
}
This would bind a listener socket to whatever port 4545 and use it like a PULL socket (round robbin) rather than SUB. You could then connect with:

local conn = Tir.Task.connect {
spec = ‘tcp://background-cluster.myco.com:4545’,
send_ident=’client-34343′, socket_type=zmq.PUSH
}
That could be a client connection to the above using the domain name background-cluster.myco.com on port 4545 and doing a PUSH socket.

You can also pass in a subscribe option to Tir.Task.start so that, when it uses the SUB socket, it will be subscribed to only messages with a certain target.

Significance Of This
It’s early, but this means that Tir will let you convert slow long running handlers into fast tight async clusters by just moving the code into a background task and having the handler shoot data at it. Since it’s so easy to start these tasks up and make them, and since you get 0MQ goodies, this means you shouldn’t need to use many of the current background systems.

Of course you’d probably need a bit more on top of this depending on the use case. You’d need to store state, establish some kind of “protocol” for what the task accepts, and probably need to find a way for tasks to report back. But, this base lets you create all that.

Already this kind of simple background task is helping me rework some parts of Hype.la that were starting to suck. I’ll have more information on patterns for using this as I actually apply it.

tl;dr ZedShaw.com will change to audio only, so move your RSS feed to here or oppugn’s feed for my rants.

I like to change up my blog about once every year or so, just to keep with the spirit of the internet and to explore new ideas. Last year I decided that I want to branch my ZedShaw.com blog out into a set of other blogs that covered topics I was interested in. This worked great and now people know they can get technical essays from here, and rants from oppugn.us.

Well, I’m feeling the itch again, so I’m going to change up ZedShaw.com to match a new music related idea, while leaving sheddingbikes.com and oppugn.us alone. I’m going to basically adopt the challenge of turning ZedShaw.com into a “No Writing Zone”. The only thing I’ll post there is audio files, maybe pictures. All the writing will be done on my other sites.

What this means for all of you is, if you are following the RSS feed on ZedShaw.com then it’s time to move!.

Move your RSS feed to here or oppugn’s feed for rants. Keep ZedShaw.com in your RSS feed if you’re into what I’m going to do next.

The Plan
This may change a bit, but the plan for zedshaw.com in 2011 will be audio. I’ve wanted to do an audio only kind of thing for a while so I’m just going to do it. What I’ll be posting is pretty much everything I do related to music, and I’ll be working on posting some essays I do as audio posts instead. Pretty much just exploring sound and audio instead of writing for my project in 2011.

Thanks for your time.

This is a quick post announcing that I finally setup the Tir Web Framework Site.

There you will find:

• Install instructions
• Getting Started guide
• Contributor Instructions
• Downloads for source, luarocks, example code.

I spent the last month crafting Tir at the same time that I worked on my latest side project Hype.la. During the development I came up with a way to have all your cakes and eat it too. You can have coroutine based handlers, stateless, and evented, and mix and match them in the same application.

I found that this “State Agnostic” approach meant that I could use whatever worked best for each interface. I’ll go more into it later when I talk about Hype.la more and show how I used the different state styles to make the application.

About Hype.la
I really needed to have something real I could use Mongrel2 and Tir on, and a friend gave me a pretty neat idea for a “social advert trading thing”. I wrote Hype.la to implement the idea and also to work out all the various features Tir needed. I also ended up learning a lot about CSS and design at the same time, so yes, I did all of the UI for better or worse.

You can read more about it on, well, the about page.

Feel free to try Hype.la out but keep in mind it’s only been live for like 2 days. It’s stayed up, but there’s a bunch of bugs and stuff I need to fix before people can really start using it.

I will eventually release the code to Hype.la as a large real demo of Mongrel2 and Tir, so stay tuned for that. I first have to work out things like unit testing with Tir and the deployment scenario. Right now it’s very much “works for me” code.