I got bored and decided to play with greasemonkey. The results are somewhat crude but it works and I think I like it better than my current solution to interface with del.icio.us.

delicious.user.js

Requires: Firefox, the greasemonkey extension, and a del.icio.us account (free)

For those out of the Know: Greasemonkey is a sexy extension for Firefox that lets you execute "user" scripts whenever a page loads. This lets you add functionality, remove banner adds, clean up pages, change themes, etc of pages you are viewing. This prospect is extremely exciting.

Since the Mozilla family support xpath and other neat things in its javascript engine, you can do huge set of actions on the pages you view. This includes using xpath to find advertisements and deleting those elements, for instance. The possibilities are potentially limitless. I highly recommend people having a gander.

Go to GreaseMonkey

People are fundamentally bad at using 'reply-all' - or perhaps it is that 'reply-all' itself is bad. Either way, reply-all to lists will reply to the list AND to the poster, who most likely is a member of the list anyway. So, s/he gets two copies. This irritates me because I have to end up removing duplicates myself, manually.

Worry not, here comes procmail and formail to save the day. The following 2 rules will put duplicates in a 'duplicates' folder.

# Keep track of message IDs.
:0Whc
| formail -D 8192 messageid.cache

# I don't want to see duplicate messages
:0a
duplicates

A special note on duplicate detection. Every email (hopefully) will have a Message-ID. Replies will hopefully have an In-Reply-To or a References header that specified the Message-ID that it is in response to. This is how MUA's (mail user agents) know how to sort mail by "thread."

At any rate, formail -D tells formail to look in the cache (messageid.cache) for an existing message id. If it's not found, it is stored and formail exits with failure status. If it is found, formail exits with a success

Read the procmailrc manpage if you want to know what the W, h, c, or a flags mean on rules.

For the past several years I've more or less ignored the existance of HTML 4, CSS, and JavaScript. My web design has centered around a fluent knowledge of html tables and little else. My new website design is much more in tune with today's web technology. Hopefully, assuming I can get off my butt and do it, I'll be writing a few articles in the coming weeks about things I've learned and whatnot.

I started a new project today to try and do a kiosk interface completely via a web browser. I'll post a link to it when I've actually finished up work on it. It uses XML, JavaScript, DOM, and fun with CSS. I've already found a "feature" of Opera that's making me want to switch to back to using firefox for the devices this interface will run on, but I haven't decided yet.

I may just end up writing something that uses the mozilla rendering engine and nothing else, but that's probably more work put into this than I want to spend. More on things as they develop...

I got bored and wanted to see how my new site compares against other things. These statistics are by no means thorough. The benchmarker I used is a very simple program called webbench. It simply sends request after request at whatever you point it at. The statistics were done using 5 concurrent clients over 30 seconds (-c 5 -t 30).

I think the results are pretty interesting.

http://www.google.com/	7126 pages/min
http://www.amazon.com/	8340 pages/min
http://www.csh.rit.edu/	3690 pages/min
http://www.csh.rit.edu/~psionic/new	7066 pages/min
http://www.csh.rit.edu/~psionic/new?nocache	710 pages/min

A factor of 10 difference with caching than without. Sheesh. How easy is it to cache things in mason? Let me show you.

<%init>
return if (!exists($m->request_args()->{'nocache'}) && 
		$m->cache_self(key => $m->comp("/lib/cachename"), expires_in => '30 minutes'));
</%init>

Put that in the %init section of any component and poof, mason caches the output of that component for 30 minutes (as specified). According to this site, you can cache the return values of components too, which makes it a bit like Memoize in a way.
The /lib/cachename componenet is a little dohicky I wrote up to automatically generate a key name to cache by:

<%perl>
	my ($k,$v);
	my $args = scalar($m->caller_args(1));
	my $key = scalar($m->callers(1))->{"path"};
	$key .= ".$k=$v" while (($k,$v) = each(%$args));
	$key =~ s!s!_!g;
	return $key;
</%perl>

This component generates a key in the form of "compname.foo=bar.baz=fizz" or whatever. It takes the arguments passed to the component and makes a unique key out of it. This is so I can cache specific calls to each component (like Memoize!) with specific arguments rather than simply caching only one output and using that. This is slick.

So for this new part-time job I've got, I'm working on a Soekris net4501. FreeBSD has some surprisingly cool support for these things thanks mostly to phk@freebsd's work. Now that I've managed to get a slimmed down version of freebsd built and running (7.3meg world, 2.2 meg kernel) of a pxe boot, I've had a chance to actually play with the darned thing.

The first thing I noticed was /dev/led/error. You can do

echo 1 > /dev/led/error

and viola! The error led on the board is on. This device supports quite the array of syntax you can throw at it. For instance, I can do

echo "f1" > /dev/led/error

and the error led will start blinking. Read led(4) if you care to know more about the rest of the syntax it supports (it'll even handle morse code from running /usr/games/morse -l).

I also discovered there was support for the GPIO pins on the board, too. This is done through the same /dev/led interfaces. To enable one of the pins as a device, you fudge around with the machdep.elan_gpio_config sysctl and you'll end up with devices such as /dev/led/gpio5. Neato! More about the GPIO-specific stuff here:
http://lists.freebsd.org/pipermail/freebsd-current/2003-November/014700.html

So far so good, I've got a usable shell with most tools I use (short of gcc and gdb) in 8.7 megs.

# df -h
Filesystem    Size    Used   Avail Capacity  Mounted on
/dev/md0       19M    8.7M    8.8M    50%    /

Since it's less than 10 megs, I have it mounted in memory instead of nfs. Doesn't hurt too much, seeing as how the board has 64 megs of ram, and with everything booted and me logged in I have 26 megs free.

Speaking of disk size, /usr/bin/host is a whopping 1.1 megs. That's quite large for dynamically linked binary. However, I think it was statically linked against libbind or something silly. Either way in the final product it'll go away, shaving more disk usage off.

This project has been a grand adventure into freebsd's world build system. My whole time working on this has been me writing one makefile. The way it works is fairly slick, I think. First, it generates a 20 meg vnode-backed filesystem, then builds a bunch of things from /usr/src and installs them to that new filesystem. Once this is done, I clean out some unnecessary files like library archives (.a files), worthless things in /usr/share, etc. The kernel is handled much in the same way, doing make buildkernel in /usr/src and then plopping a new kernel.gz in /tftpboot.

The cool part is how libraries are built. The makefile builds all the necessary binaries, installs them, and then uses ldd(1) to look for library dependencies. With this list of required libraries, it builds each required library from /usr/src and installs those. To make things easier to work with, I have two other make targets that let me test the system in both a jail(8) and chroot(8). This soekris board is so cool :)