A project I'm working on at work contains piles of some of the worst-written code I've seen in a long time. Top that with three tons of commented-out source code and you've got me angry.

I use vim (NOT gvim). I don't use syntax highlighting. The bright colors available in the terminal are too contrasting to be useful for syntax highlighting, so I have it off at all times. However, with this new project, there are so many lines of code that are just commented out it becomes extremely difficult to read said code.

Enter vim's syntax highlighting. I hate coloring of most things, but having comments a particular color is acceptable. I would prefer these comments be dark-but-visible-on-a-black-background shade of grey, so I try this in vim:

hi Comments ctermfg=grey

This makes comments appear grey. However, they grey is not quite dark enough, so I'll need to fix that. The ANSI color number for grey is 7. So in my ~/.Xresources file, I need to redefine what this color really looks like, specifically making it darker. I used xcolors(1) to show me a list of colors with names that X would recognize, and I saw that 'grey' was a decent shade of, you guessed it, grey. So I put this in my .Xresources file:

XTerm*color7: grey

Now run xrdb -merge ~/.Xresources and new xterms will use this color. Openning up vim and it looks just fine.

One special mention here, is the difference between my CRT monitor and the LCD on my laptop. The default grey color (7) in X on my laptop is perfectly visible. However, on my CRT I need to darken this color to make it visible to me. Your mileage may vary - the CRT I'm currently using is a pretty crappy 19" trinitron with some contrast issues, so using another monitor may clear this up.

I got around to publishing a writeup on my ideas and progress on my latest project to reengineer the mouse framework in FreeBSD. Assuming it gets finished, it'll probably end up in FreeBSD 7.x. I've been working with one of the freebsd committers (philip@freebsd) bouncing ideas around and such. I think the plans I've got are fairly solid despite my lacking hardware/lowlevel programming experiences. The existing mouse code is fairly easy to read so I'm using that as a starting point for learning. I won't bother reiterating what's already on another page, so if you're interested in telling me I'm completely wrong (or suggesting features, or just reading for fun), then go on over to projects/newpsm

Link: projects/newpsm

ALTQ is a quality of service packet scheduler for OpenBSD pf (pf works in FreeBSD too). I'm at home right now on DSL. DSL is just fine when the only thing I'm doing is ssh and light web usage. However, once I start a download all of the bandwidth I've got ends up being used by that download. The problem is, then, that my ssh sessions become unnecessarily sluggish due to the fact that things are now having to compete for the transmission queue.

If only there were a way to give things like ACKs and ssh sessions higher priority? Oh wait, there is! PF/ALTQ to the rescue. With very minimal effort, you can effectively make your ssh sessions usable once again even though you're downloading or uploading enough to fill your pipe.

My pf.conf is as follows:

ext_if=em0

# Make a priority queue with 3 members: q_ack, q_pri, and q_def
altq on $ext_if priq bandwidth 100% queue { q_ack, q_pri, q_def }

# Give priorities
queue q_ack priority 10
queue q_pri priority 7
queue q_def priority 1 priq(default)

# ACKs get high priority
pass out on $ext_if proto tcp from $ext_if to any flags S/SA keep state queue (q_def, q_ack)
pass in  on $ext_if proto tcp from any to $ext_if flags S/SA keep state queue (q_def, q_ack)

# SSH sessions also want priority
pass out on $ext_if proto tcp from any to any port 22 keep state queue q_pri

You'll need the ALTQ and ALTQ_PRIQ options in your kernel for this to actually work. ALTQ cannot be built as a module under FreeBSD due to the way it is implemented.

If I turn pf on, and start a long file transfer (up or down), my ssh sessions won't lag anymore.