I don’t use a lot of X applications. The one that I use most often is xterm.

I like small fonts, and I find that I have no problem reading a small font on an LCD monitor. Recently someone mentioned the Terminus font. I tried it and it quickly became my favored xterm font… it’s so tiny and clean! Here are the important bits of my .Xdefaults file…

    XTerm*renderFont:        false
    XTerm*font:              -xos4-terminus-medium-r-normal-*-12-*-*-*-*-*-*-*

I also grabbed a few tiny fonts from Proggy Fonts and my new wmii font is ProggyTiny. Here is the bit from my .wmii-3/wmiirc-config.rb file…

    font        '-windows-proggytiny-medium-r-normal--10-80-96-96-c-60-iso8859-1'

The above font site also taught me how to import fonts into X font server w/o a restart and how to keep fonts in my home directory. Check out this short HOWTO.

I saw this blog post by Debian’s Florian Ragwitz, and ran my own list of most commonly used shell commands. Here they are…

    history |awk '{print $2}'|awk 'BEGIN {FS="|"} {print $1}' | sort | uniq -c | sort -r | head -15
        627 git
        266 vim
         98 cd
         76 grep
         69 ls
         63 gitk
         60 ssh
         51 sudo
         47 vv
         47 apt-cache
         40 cat
         34 make
         33 patch
         30 rm
         25 man

I started playing go. I tried cgoban and gtkgo. Both crashed a lot. Then I tried glGo… it’s much better.

I recently added an outgoing mail filter to capture the email addresses of people I write email to. This saves me time on adding them to my address book manually.

I ran into Mark’s Mutt Fan and Tip page and was pleased by the description of lbdb. I then found a way to write an outgoing filter to capture email addresses as I send mail… I wasn’t really interested in lbdb holding the forged SPAM addresses.

Welcome to the 90’s! 256 colours are here!

It’s pretty sad. I got really excited today when I read the Tip #1312: 256 colors in vim.

I quickly installed the few colour schemes listed in the tip and was really impressed with the inkpot scheme… it’s pretty.

I just had a thought while reading over the KLIPS code and creating beautiful inkscape diagrams from it ([see previous post]{20060824145428})…

Wouldn’t it be great if we had IPcomp that worked for all connections? Your cpu is always faster then the internet connection – or at least it has been my case for the last decade and a bit.

So my idea was… why not have IPcomp on all the time. Assume the other host you want to talk to has IPcomp enabled for TCP and UDP. On the first packet we send, if they don’t understand it, they will hopefully send back an ICMP error and then we retransmit the packet uncompressed. For TCP that would be pretty trival, because TCP already retransmits. For UDP we would have to remember the IPs that we tried and have a way to hold the packets before the verdict is known.

I am doing a lot of network testing and require multiple virtual networks created for my UML’s. Debian’s uml-utilities package does not currently support bringing up multiple network segments, although the uml_switch daemon can be ran multiple times. In such a setup each uml_switch is associated with it’s own tapX device and maintains one network segment.

I modified two files:

• /etc/init.d/uml-utilities
• /etc/default/uml-utilities

And filed bug 378166.

Ok, so in [last eppisode]{ldap-upgrade-to-2.3.23-brakage} we looked at how my Debian/testing upgrade of slapd killed my slapd install because I was using two incompatible schemas.

Now, I will show you how to limit what accounts are accessible to pam_ldap module on each host.

For some very stupid reason I decided to upgrade my fileserver, which happens to run my ldap database as well.

Setting up slapd (2.3.23-1) ...
  Backing up /etc/ldap/slapd.conf in /var/backups/slapd-2.2.26-5... done.
  Moving old database directories to /var/backups:

  Backup path /var/backups/dc=jukie-2.2.26-5.ldapdb exists. Giving up...
dpkg: error processing slapd (--configure):
 subprocess post-installation script returned error exit status 1
Errors were encountered while processing:
 slapd
E: Sub-process /usr/bin/dpkg returned an error code (1)

Frig!

Joey Hess blogs about bug 119185 in the Red Hat bugzilla.

Wow! Talk about screwing your users. I am not sure if Jeff Johnson speaks for Red Hat. If he does, why would anyone want to use a Red Hat (or Red Hat based) distro.

The rpm bug is one thing, but treating your client this poorly is awful. I am surprised how patient Tethys, the poster, was about the whole process. It is clear that he feels more strongly about the quality of the product then the vendor does.