In an earlier entry I gave short and long termreasons why I think that thin clients were doomed. Now it's timefor the high-level third reason (which occurred to me only afterI'd written ThinClientDoom , or it might have been in there too).

So far, people have always found productive uses for new computingcapabilities and more computing power; time and time again, sillycapabilities have turned out to have important uses, to the point wherethey've become ubiquitous. Betting on

To do simple locking in shell scripts, you need an atomic system callthat fails if the target already exists, and that is directly exposedin a utility program. Ignoring for a moment what System V did to ln , there are two good candidates on modern Unix systems: link(2) and mkdir(2) .

Mkdir is actually the better of the two (because you don't have tofiddle around with temporary files), but ln is the more common one,probably for two reasons:

1. with

In Java in The Land of Make Believe ,Ryan Tomayko unloads a righteous rant about why Java's license mattersand what effects it has in the Linux and *BSD worlds, with greatbits like:

If you want to get on the bad side of software developers and systemadmins, the fastest route is to waste their time .

Amen. What he said .

(The good news is that Sun GPL'ing Java may finally be changing all ofthis mess, which Tomayko happily acknowledges.)

(From many

Every time I see a mail from a C/R system, I get more and more temptedto teach our mail filtering infrastructure about the most common ones,so that it can automatically acknowledge the challenges, discard themessages, and not bother the users with them at all.

Will this acknowledge a lot of spam, and thus dump it on the peopleoperating those C/R systems? Sure, but that's not our problem. AndI'd clearly be doing our users a service, especially if