((lambda (x) (x x)) (lambda (x) (x x)))

I couldn't find any truly Slackware/KDE way of naturally configuring ssh-agent(1) to work easily with my login process. Most of the existing methods use a combination of .xsession files or some other scripting, but all of that sort of takes away from the KDE side of things. Not that this is a bad thing necessarily, but if you are like me, and don't have an xsession file at all, adding one just for the sake of doing ssh-agent doesn't seem so nice.

Instead, I chose to seek out the general features provided by KDE for this type of thing. As it turns out, there are three special directories that KDE uses to handle starting and stopping of programs and the handling of the environment when logging in.

Enabling ssh-agent and populating the environment

ssh-agent must sbe running, and the appropriate environment variables defined in order to use it. KDE provides the directory .kde/env for just such a purpose. In there, executable scripts are run and let you define new environments. I put the following into ssh-agent.sh and made that file executable.

#!/bin/sh
eval `/usr/bin/ssh-agent`

Adding your private keys

You use ssh-add(1) in order to add your keys into the ssh-agent program. To do this, I have another script similiar to the ssh-agent.sh called ssh-add.sh (also executable), that is placed in the .kde/Autostart directory.

#!/bin/sh
SSH_ASKPASS=/usr/bin/x11-ssh-askpass
/usr/bin/ssh-add

You will note that the program x11-ssh-askpass is not installed by default in Slackware. I used the SlackBuild provided by SlackBuilds.org for this purpose. I modified the script a bit so that it suited me, and then went ahead with the normal build and install process.

Stopping ssh-agent on logout

At first, I thought I was done once the above steps were completed. However, I soon learned that the ssh agent will stay running even after I logout. To fix this, I use another script in the .kde/shutdown directory.

#!/bin/sh
/usr/bin/ssh-agent -k

which will kill the appropriate daemon on exit.

Voila!

Descot is making headway. Most of the basic API and server is written, and the system is partly usable. However, at the moment, submissions to Descot servers really lacks. I am spending most of my Descot alotted time blocks trying to get the right infrastructure going for this so that the system is usable for people.

Hopefully, soon, the system will be released in an useful manner. I can then package up a Version 1.0 release, and start getting many comments, which I suspect most of Schemeland will have.

On the plus side, the Descot paper has been approved for the Scheme workshop, so I'll be giving a small mini-presentation on Descot there.

Why do people do such things? Why take a perfectly disastrous 'define-macro' incantation and turn it into a longer, worse 'syntax-case' incantation? The idea of moving to a sane macro system like syntax-case is to take advantage of a higher-level of macrology; in this case, the automatic hygiene. No, just take the whole blimey code snippet and wrap it in a 'datum->syntax' why don't you? Good way to make bad code worse!

Instead, the solution is to search for that place where the hygience 'needs' to be broken, and leave everything in the land of hygiene: nice, neat, and clean.