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.