Older blog entries for jimw (starting at number 15)

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.

i find it very disappointing that the gnu file utilities can't handle urls (speaking webdav under the hood, perhaps), and that gnu tar doesn't just automatically detect the compression type instead of making people remember whether bzip2 is 'y' or 'I' or 'j' or whatever this week.

sure, you can fill in the gaps with things like curl and wget and cadaver and remembering the magic bzip2 flag, but it just seems like someone isn't pushing the command-line interface forward when cp still doesn't understand urls.

bratsche, it could just be that people that are fanatical to a type of music (or a specific band) are fun to tweak. (and in my experience, exposure to music breeds appreciation, and exposure to fanatics breeds contempt.)

there's also a lot to be said about the effect of peer groups on musical tastes, of course. (in both directions. there's a herd of people who are fanatical about britney spears music, and the corresponding anti-britney herd. it's barely about the music in both herds, and they're both annoying.)

(what's this got to do with open-source? s/music(al)?/software/; s/band/vendor or license/; s/britney( spears)?/microsoft/.)

dwiner seems surprised that apache hasn't matched frontier feature-for-feature. looks to me like more people want apache's features than frontier's.

i wonder how many more people would use frontier if there were a mod_frontier for apache.

deekayen, you can get oracle for linux for free from oracle for personal/development use. (or something to that effect. i've misplaced my technet login.)

6 older entries...

New Advogato Features

New HTML Parser: The long-awaited libxml2 based HTML parser code is live. It needs further work but already handles most markup better than the original parser.

Keep up with the latest Advogato features by reading the Advogato status blog.

If you're a C programmer with some spare time, take a look at the mod_virgule project page and help us with one of the tasks on the ToDo list!