The Fugue

I have been waiting for this for a long time. Finally, finally, it is here.

The gentoo people, bless their hearts, have documented gpg-agent more than anybody else. Thanks to them and Google I discovered that keychain supports gpg-agent, and keychain is exceptionally-well documented.

This excerpt from keychain(1) on my Debian box:

This snippet would work in .bash_profile (for bash) or .zlogin (for
zsh) to load two ssh keys and one gpg key:

    keychain id_rsa id_dsa 0123ABCD
        [[ -f $HOME/.keychain/$HOSTNAME-sh ]] && \
                source $HOME/.keychain/$HOSTNAME-sh
        [[ -f $HOME/.keychain/$HOSTNAME-sh-gpg ]] && \
                source  $HOME/.keychain/$HOSTNAME-sh-gpg

In addition to that, I configured my gpg-agent thusly in ~/.gnupg/gpg-agent:

pinentry-program /usr/bin/pinentry
no-grab
default-cache-ttl 28800

Now configure gpg to use the agent:

$ echo use-agent >> ~/.gnupg/gpg.conf

Tell mutt to use the agent:

$ echo set pgp_use_gpg_agent >> ~/.muttrc

mutt for some reason requires that GPG_TTY be set (thanks to dato on #mutt on freenode), so add this to your ~/.bashrc:

export GPG_TTY=`tty`

Enjoy!

I like to make cron jobs to mail me interesting information, e.g. the output of clog. Often, I want to truncate at 72 characters rather than deal with the wrapping, so I use this cute little sed script:

sed "s/^\(.\{72\}\).*$/\1/"

I get asked this ridiculous question at least once a month at work, due to the proprietary software that we use. I'm tired of googling for the answer, which I can never remember, so here it is:

#include <stdio.h>
#include <gnu/libc-version.h>
int main (void) { puts (gnu_get_libc_version ()); return 0; }

Scorched 3D is a fabulous modernization of the classic DOS game Scorched Earth, "The Mother of All Games". It features 3D graphics and gameplay, LAN/Internet play, and in most ways it is faithful to the memory of Scorched Earth.

Scorch, as we used to call it, was one of our favorite games growing up. With 7 kids all wanting to get in on the action, it was one of the few games we could play cooperatively. It was a favorite tactic of mine, when it became obvious that I might get kicked off the computer to let someone else have a turn, to suggest we play scorch. It usually worked, too.

Scorched 3D is wonderful in every way that scorch was, and then some. The only fault I can find with it is that the computers are too dumb. Surviving in a match with 5 true cyborgs bearing down on you was one of the true joys of the original scorch. Oh, and for some reason things go haywire unless I turn off the water, but I can turn it off, so that's ok.

Scorched 3D runs on linux, so I don't think I'll be playing classic scorch much anymore. I rank this game right up there with BZFlag and Liero, taking the place of its noble predecessor.

Log files are big boring tangles of spaghetti that are about as much fun to review in their raw format as it is to go to the dentist. Yet, not reviewing your logs is one sure-fire way to be negligent, especially when you're a System Administrator.

I surveyed the options. Logwatch came out on top but it is not as easy to customize as it should be. So I wrote clog.

This isn't that hard, after all. In the spirit of "release early, release often" I am "pre-announcing" it. I'm not declaring a release, and it's bound to change drastically over the next week or two, but it works and it's ready to go to work for you. If my as of yet small collection of agents isn't good enough for you, then write your own (it's easy, especially if you know ruby already; just subclass Clog::Agent) and send them to me to be included.

Browse the code online, or use darcs:

darcs get http://hans.fugal.net/src/clog

I just read Code as Design: Three Essays by Jack W. Reeves. I highly recommend reading it. It has given me a new perspective and I find that it rings true in many ways.

I often tell people that I like "designing" software more than coding it. I was drawing that imaginary line in the sand that so irritates Reeves, and finding that I preferred the top-level design side of it. In reflection, since reading his essays, I will be changing that standrad speel as I now better understand my own feelings on the matter. I enjoy the whole process. I do like top-level design most, for I am a dreamer. But top-level design doesn't give the endorphin rush that coding does when you begin laying out the code that turns the sea of ideas in your head into a real, working system. In retrospect, I do enjoy coding and always have - what I don't enjoy is converting a "design" into code. That goes for my own "designs" as much as for those written by others.

Lately I've been following his suggestion in a subconscious way, out of necessity. I am working as a system administrator which means very little software development in the day job. So I have several side projects I'm playing with, but the scarcity of time has compelled me to spend less time fiddling with "design" and more time creating design (code). I haven't neglected top-level design, and especially not the deep thought that I put into a project at the beginning. It's been more of a rebellion against extra "design".

For a fabulous concrete example, I present the work I've done so far on alex. Alex is a softphone that I am writing, because I have found all available softphones on linux to be inadequate and fundamentally flawed, for what I want to do with them. I thought through major components of alex - audio, network, UI. Then I started the skeleton. Then I started to get lost so I fired up umbrello and made some basic UML. Then I started to code and saw some fundamental flaws. So I completely reworked the UML. Then I started to refactor the code and saw some detail changes that needed to take place. Propogating those detail changes back to UML quickly became incredibly loathsome, so I stripped the UML of almost all detail, leaving it as a shell of top-level design that does what it's supposed to do: show you the top-level design, without bogging you down in details. I'm very happy with it, for now, and I'm happily coding away the details, changing the class and interface design details as I go. The whole process is very fluid, and very satisfying. I feel like I understand the design and the code very well. I've been building up to this, gradually swapping my love for OO and design out for a love for getting something done. "Release early, release often" and all that other stuff.

In summary, I think I've missed out in some ways because I was looking down my nose at coding. I've often had the unpleasant feeling of having too many dreams and not enough to show for it. I have for some time now been trying to act more on those dreams and not let them fizzle until they are dead, and these essays have given me a new perspective that I believe will be profitable in that pursuit. Thank you, Jack.