I just changed DWiki to generate absolute URLs for the '(N comments)'links at the bottom of entries in my Atom syndication feeds, instead ofthe absolute path URLs it used to generate (URLs without the https://host/portion) . This scrubs out the last non-absolute URLs in my syndicationfeed; URLs in the text of entries in the feed have always been absolute,because I'm cautious and cynical.

In theory absolute URLs are unnecessary in Atom entries, because Atomhas

Tim Bray provides Apple some instructions onhow to update files containing important data (like iCal calendars). Hisdirections are fine at a high level, but they're actually not quitedetailed enough to implement from.

So here's how you safely update Unix files:

1. create a new scratch file in the same directory as the target file(ideally mode 0600).
2. write the data to it; optionally fsync() ; optionally verify thedata.
3. copy the current version's permissions to the

I've been thinking about ways around the practical cost of forking inPython . There's two common alternatives: preforkingservers and threads in general. However, both of them have issues thatmake me unhappy with them.

The best setup for a preforking SCGI server is a central dispatcher thatparcels new connections out to a pool of worker processes; this requiresthe ability to pass file descriptors to other processes. While Unix cando this (with SCM_RIGHTS messages over Unix domain sockets), Pythondoesn'

Part of today was arranging to flash a new BIOS on my new machine here(in the hopes that the most recent BIOS version would fix a mysteriousmemory corruption problem). This was a bunch of annoyance, because Ihad to come up with a bootable MS-DOS floppy to run Tyan's BIOS flasherprogram from. So that I don't have to go through all the work next timearound, I'm going to put what I found here.

In the old days, it was simple

I spent part of the other day working to speed up an SCGI based program, and wound up hitting avivid illustration of the practical cost of forking in Python. I'llstart with the numbers:

• 5.3 milliseconds per request when the program forked a childto handle each request.
• 1.1 milliseconds per request when the forking was stubbedout so each request ran in the main process.

Benchmarking was done with Apache's ab , running on the same machine(and with only one request at a

I have to take back what I said just the otherday about having seen the worst stealth spider I'd ever seen. The dayafter I wrote that entry, I saw a worse case.

Like the first one , they made two valid requeststo start with and then followed them up with 65 bad ones, all in thespan of 11 seconds. Also like the first one, all their requests were badbecause they couldn't deal with absolute paths in Continue reading...