A fundamental problem with CR is that it implicitly assumes that yourcorrespondent wants you to read their email more than you do. Just lookat who's doing the work: your correspondents are doing work so that youdon't have to.

(Of course, observe that the people for whom this is the most true are the spammers.)

When this is not true, when you want to read the mail more than thesender wants you to, is exactly where CR systems break down. You mightthink

Pumas on Hoverbikes is aboutmanaging system administrators, and it's funny. Here's a somewhatout of context quote:

This is because managers are usually people who proved that they werehandy with a chaingun and were thus rewarded by having their thumbscut off and their weapons handed to some punk college hire.

From this you should be able to figure out if you want toread the rest. There's other articles too, like Suck Factor , which is where I first droppedinto the site.

(

Recently, Pete Zaitcev wrote in passing :

Now if only someone designed a UTF-8 locale which did not screwthe ordering files in ls output...

What he said. I've come to realize that what I want what I'll call the' C.UTF-8 ' locale: all of the old-fashioned Unix non-locale behavior,but with non-ASCII characters encoded in UTF-8. I don't mind UTF-8 toomuch and it's clearly the

Presented without comment, the 18 spaces of Unicode .

(From Sam Ruby .)

I started with a simple question that was vaguely orbiting in the backof my mind: are HTML numeric character entities always in Unicode,regardless of the character set of the HTML web page? The answer isyes, and that I was asking a misleading question.

Despite being called 'charset' in HTTP headers and META declarations,what you are declaring is actually the web page's character encoding,not its character set. HTML is specified as always being in the Unicodecharacter set, although the encoding of characters