For to be to make you smarter. For to be to get you dead.

Keyboard 2014-11-05

I have recently been investigating building or purchasing a 60% keyboard. Before committing to this investment, I wanted to get an idea of how much I actually use the keys outside of the 60% layout. There may have been some kind of tool to show me this but I decided to whip up a very rudimentary keylogger and let it run for a few hours while I used my computer.

I did say it was rudimentary. Better data might be attained with a better method of logging keystrokes, as xinput seems to regard holding a key down as a long series of press and release events rather than a single one. After collecting the data for a few hours I created a script to put the data into a useful format for me to digest.

This script reads the keylog and creates a "heat map" of which keys I actually pressed. Here is the generated image:

keyboard heat map

Update: I have regenerated the map with a few days of data to give a better view of my usage.

Some notes before interpreting the data:

I have my caps lock mapped to super (windows key) because it is the modifier I use for my window manager functions. I do not actually turn caps lock on and off that frequently.

I have my escape and tilde (left of number 1) keys swapped. I'm not sure I like this just yet as I type ~ more often than I had realized.

I only had the keylogger running while I was doing work-type things. I boot into Windows if I am going to play games and I did not log any data during those times although I'm not sure the differences would be significant.

All in all I think this really shows how little keys are used outside of the 60% layout area (at least by me during the time of this experiment). In any case, this has strengthened my resolve to acquire a 60% keyboard.

heartbleed 2014-04-09

In light of the recent heartbleed bug, I have taken an opportunity to review my server configuration and ensure that everything is up to snuff. To facilitate this, I used the wonderful Qualys SSL Labs tool. Their best practices seemed extremely reasonable to me so I set out to ensure I was following all of them

First of all, I had to make new server keys and certs because of the potential that they were compromised. Personally, I can never remember how to work the openssl command line tool so I have set up a makefile to do all that nonsense for me:

This makes my life much easier since I can just make clean all when it's time for new certs. The dhparam.pem rule is because nginx by default uses openssl's default DH parameters which are only 1024 bit and that will weaken the security of clients using ephemeral keys which kind of defeats the purpose.

With the certs in place, I have the following nginx configuration:

This configuration has netted me a coveted A+ from Qualys:

SSL Labs Overall Rating: A+

However, I did have to make some compromises to do this.

First, I have disabled use of SSLv3 (because it is broken). This precludes IE6 from accessing I cannot think of anything less controversial than this. If for some reason you need to support people using IE6 you should review your life choices. According to Qualys, this also precludes YandexBot 3.0, which is apparently a bot from a Russian search engine. This is more unfortunate than not supporting IE6 but not so much that I am going to use a broken protocol.

Second, as mentioned earlier, I am using 4096 bit DH parameters to match my 4096 bit key. This apparently precludes Java 6u45 from connecting. As far as I am aware Java 6 is no longer supported so it's probably time for any clients using this to upgrade to something less broken.

Lastly, I have excluded 3DES from the list of ciphers my server is willing to use. This was probably not entirely necessary since 3DES is not really broken but it does use 112 (or 108) bit keys which are a tad too small for my taste so it got the axe. This precludes IE8 on Windows XP from connecting. As with the other sacrifices, this product is no longer supported by its makers so I see no reason for it to be supported by me.

Salsa Verde 2013-11-07

We had a taco bar and salsa contest at work today so I made some salsa verde.


First, husk and rinse a bunch of tomatillos. I used a pound and a half.


Cut up a bunch of peppers. You can take the seeds out if you are a wuss.


Add an onion and some garlic and salt to taste. Put it all in a baking dish with a bit of oil.


Roast everything at 375°F until the tomatillos are squishy (about 45 minutes).


Add a cup of fresh cilantro.


Blend it all together.



gfk 2013-09-07

I made a new thing. It is called gfk. You can read about it at

In case you hate clicking links, it's basically a system for storing secret files on a USB drive so that your private keys have two factor authentication.

My goal now is to put something on here before another year passes.

blosxom and git 2012-06-04

When I moved all of my servers away from apache2, I started using blosxom in static mode. There's no dynamic content on this blog anyway, so there wasn't much sense in trying to get the CGI to cooperate with nginx. As such, I made a Makefile to build and deploy the site for me, which was pretty rad.

The site is also maintained in a git repository, though, and so I had the idea that pushing to the git repo should just automatically update the website. Here, I will share how I achieved this awesome magic.

First of all, I had to make a few changes to blosxom to get it to play nice with a git repository.

Here is my modified blosxom (based on 2.0):

Next is the Makefile I use to generate the static pages for blosxom. It also renders a minified stylesheet from my lesscss source file.

Now with these in hand, I am set up with my original plan. After writing my posts I could deploy as such

$ make
$ rsync -avz --delete  htdocs

But since I would need to push the changes back to git anyway, there's no reason to take that step. In order to do this, there are only a few easy steps. First, create a bare repo on the machine that hosts your blog and add a post-receive hook to it:

$ mkdir
$ cd
$ git init --bare
$ touch hooks/post-receive
$ chmod +x hooks/post-receive

The post receive hook I use is extraordinarily simple, since I already had the Makefile to do most of the work:

Now, back on your local machine, just add this new repo as a remote and you will be able to push to it to update your blog:

$ git remote add deploy
$ git push deploy master

Happy blogging.