There is a certain school of thought in system documentation thatbelieves, to stereotype things, that there is no such thing as being tooexplicit or having too many examples. Much of Sun's Solaris documentationmakes a great example for this school.

Unfortunately, these people are wrong. There is such a thing as toomuch documentation, because having too much has a number of problems:

• your documentation becomes less and less readable, as the importantthings are buried under a flood of examples, cross references,and low

Here's an issue that I ran into recently: from version 1.4.20 onwards,lighttpd has stopped passing stderr to CGI processes, should onebe peculiar enough to run CGIs on lighttpd ( which can be done ). If you need error logging from your CGIs, you will haveto roll something on your own.

(Fedora 10 has lighttpd 1.4.22 and so is affected by this.)

There is a bug report for this, but I don't know

I generally like the Bourne shell, but I will easily admit that it hasa number of things that are less than ideal. One of those less thanideal things is a peculiar omission: you cannot easily redirect just standard error into a pipeline.

This sounds like a peculiar thing to want, but there are situations where you do need to process stderrseparately; for example, you might need to timestamp all stderr outputand log it. In a hypothetical shell with this feature you could have a'timestamper' program

One of the technical problems with'sender stores messages' schemes for email-like things is that itlets a malicious sender generate messages on the fly for up to themoment customized malware (and this gets much, much worse if the protocolhelpfully includes things that you can use to fingerprint specificclient software).

It is tempting to deal with this problem by making the identificationfor messages include a hash verifier or address, in the way that currentversion control systems identify files by their hashes. This would meanthat

Here's one view of the difference, put in a punchy short form:

• web 1.0: all of this user attention is going to be worth money!
• web 2.0: all of this user attention is going to be worth money,and this time around we're going to make sure that the users stickaround for it.

In classic 'Web 1.0' operations (with the apex of this being the variousportals), it turned out to be very hard to monetize all

Here is one of my periodic irritations, posed as a question:

How do you revert a modern Gnome application's settings back tocompletely stock values?

In the traditional Unix world, programs wrote their settings to dotfiles(sometimes dot-directories). If you wanted to reset a program back to itsstarting state, you removed the program's dotfile or dotdir, and you weredone. In the modern Gnome world, not so much, because dotfiles are oldfashioned now.

(Oh, some programs still

Here's a thesis:

The problem I see with making ticketing systems accessible to users isthat you periodically need to have a genuinely private conversationamong the sysadmins in response to user requests. I'm not sure how oftenthis happens in typical organizations; ours is somewhat atypical in howwe structure support, and possibly as a result it seems to happen fairlyoften here.

If your ticketing system is (internally) public, then you can't havethese conversations in the ticket; you have to find some

On the surface, the (c)Pickle module looks like a good, simple wayfor your Python program to save and load its data; much like XML , it means you don't have to write a parseror even save and load routines as such, just some file and objectmanipulation code. However, through my experience in writing DWiki I'vecome to understand that this temptation would be a mistake (one thatI've actually half-made; DWiki 's caching layer uses pickling)

To follow on from yesterday's entry , suppose thatone is using (c)Pickle to save data in your Python program, and you wantto version your data somehow. I can think of a number of approaches:

• take the 'pickle as stored JSON' approach; serialize your complexobjects to simple objects (dictionaries, lists, etc), add versionnumbers, and only pickle the simple objects. Then you can do all ofthe usual version mismatch fixups when you de-serialize the reloadedsimple objects