Older blog entries for jimw (starting at number 19)

i want to write a simple application using mozilla's xul and javascript that talks to a remote server using xml-rpc. there's xml-rpc support distributed with mozilla, but i can't get it to talk to anything. it sure would be nice if developing an application with xul weren't such a pain.

ishamael, there's a lot more downsides to being overweight than the years you'll lose at the end of your life.

and dieting doesn't have to mean living without good tasting foods (especially if you can do better than cake and steak!) or with a strict schedule of exercise and limited food consumption. (in fact, i would say those are all warning signs that someone's dieting efforts are doomed to fail.)

oh, yeah. open source. more releases of colobus happened, and ask set up nntp.perl.org with it. doug maceachern has patches to turn it into an apache 2.0 protocol handler. that crazy doug.

i finally packaged up colobus for release to the world. (that's the name for the nntp server for ezmlm mailing list archives.)

as an excuse to do a little programming, i wrote a simple clock program for x. it is just a simple text display (with a drop shadow) in a shaped window (so it is transparent) that raises itself whenever its visibility changes (which probably isn't very friendly, but whatever). you can grab it here.

the nntp server that runs off ezmlm mail archives is almost done. i just need to fix up the overview database updating, and test it with some more clients.

so, i went down the route of writing a news server that uses ezmlm archives for the spool. i have a basically functional news server working (including posting).

the big chunks remaining are dealing with message-ids properly (the current code basically punts -- i need to build a two-way database of message-ids to message paths), and adding xover support (which will be easy -- making it efficient will be slightly harder).

dealing with getting php.net's news server set up on a new machine, i think i've come to the conclusion that i should write a new storage driver similar to tradspool, but with hashing of the individual articles at the newsgroup level.

since we're not expiring anything from the server, tradspool doesn't really cut it (over a hundred thousand files in one directory just isn't cool, even if your filesystem is), and timehash doesn't cut it either, because i'd like to keep the newsgroups seperated (without having to set up a seperate timehash spool for each group).

what would be really sexy, though, would be to have inn just slave off the ezmlm archives, and avoid the duplication altogether. hmm.

you know, i get the feeling that Zaitcev doesn't read the rolling log of diary entries.

repeat after me: the article title length does not matter. putting long, unbreakable strings of text (like, say a url) into the article lead is, however, a different matter.

as mike750 pointed out, the latest pam packages in debian's unstable are hosed. luckily, i noticed it before logging out of the two machines i had upgraded, and was able to copy a fixed pam_unix.so into place. (basically, "apt-get source libpam0g; cd pam-0.72; ./debian/rules setup; perl -pi -e "s/sgaddset/sigaddset/" build-tree/Linux-PAM-0.72/modules/pam_unix/support.c; ./debian/rules build; sudo cp build-tree/Linux-PAM-0.72/modules/pam_unix/pam_unix.so /lib/security".)

this is the second time i've gotten screwed by pam breaking on an upgrade. the last time i had to fix it by abusing nfs. apparently the maintainer doesn't do a lot of pre-release testing, which is rather unfortunate for a part of the system that can make it very difficult to get into your system when it falls over.

other than that, debian is the bee's knees, of course.

i just have to wonder if it hurts to be involved in a heated database. it actually sounds rather refreshing, although perhaps not this time of year. maybe a couple of months ago, when it was a little colder.