Today's fire drill was caused by our printing system not printing;since it is the first day of classes, it was not a good time todiscover this. After fixing a couple of small problems, the bigstumbling block was authentication not working.

Our printing system has a central machine that handles quotamanagement and a per-lab machine that handles the actual printspooling and printing. This requires the labmasters to talk to thequota server to tell it about pages that got printed.

Because I am paranoid,

Concurrency may or may not be hard (I know people who disagree with meon that). But I am sure that it is tricky. As an illustration, I justfixed a DWiki concurrency bug that I first spotted in MyFirstCommentSpam .

For simplicity, DWiki stores each comment as a file in a directoryhierarchy that mirrors the page's DWiki path; if you comment on the DWiki page /foo/bar , the comment will be a file in a /foo/bar/ directory (under a separate top

It's always nice when people build debugging support into theirnetwork daemon. However, I have a modest suggestion:

When your daemon is designed to be run under inetd / xinetd ,writing debugging output to standard error is a bad plan.

(You win bonus points for also logging it to syslog, so that aninnocent person might be deluded into thinking that it's only going via syslog.)

Because, you see, all that nice debugging output is going to go flyingstraight off to the clients talking

In theory, WanderingThoughts has been syndicated on LiveJournal as the LJ usercks_techblog( here ) forsome time. In practice, LiveJournal has an undocumented, hard-codedlimit on how large syndication feeds can be; go over the limit and LJrefuses to process your feed. Because I dislike small limits, DWiki defaults to putting lots of entries in syndication feeds, more thanenough to exceed LiveJournal's size limit given how I write.

(LiveJournal compounds the problem by not allowing a syndication feedto be