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:
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.
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
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:
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 eatabrick.org. 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
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.
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
Add a cup of fresh cilantro.
Blend it all together.
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.
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.
- Use post filename to get post time (this is
- Allow for a relative path for the data directory
- Rebuild static files older than the most recent template mtime
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
$ rsync -avz --delete htdocs eatabrick.org:/srv/http/eatabrick.org/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 eatabrick.org.git
$ cd eatabrick.org.git
$ 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 eatabrick.org:eatabrick.org.git
$ git push deploy master