One of the popular advantages attributed to using domain-specificlanguages is that they're 'human-readable'. This label is highlymisleading because there is no such thing as a human readablecomputer language of any sort, DSL or otherwise.

Despite decades of AI research, we cannot instruct computers in naturallanguage; it is too slippery and imprecise. As a result, all languagesused to specify things to computers have specific semantics and arenot simply 'plain English'. Even if you try hard to use

A while back I wrote about how I monkey-patch modules for testing , but I didn't really write about why I preferto do my testing this way instead of, say, using dependency injection in the code I'mgoing to test.

My ultimate reason for doing it this way is that I would rather haveclean code and ugly tests than dirty code and cleaner tests. 'Testable'code that has everything it talks to injected into it as a parameteris generally ugly; specifically, it is

One of the things that turns plain applications into social applicationsis the ability to get feedback from other people ,the ability to know that other people are appreciating your stuff. Ithink it follows as a corollary that if you want to build a popularsocial application, getting the feedback right matters a lot; the morefeedback people get, the more likely they are to continue using yoursocial application.

To be specific for a bit, let's talk about Flickr (partly because I haveexperience with it as a

I have recently run into an interesting collision between typicalweb analytics practices (and applying this to random URLs) and goodsecurity and robustness. The straightforward manifestation is that linksto WanderingThoughts entries from the Planet Sysadmin Twitter feed don't work; trying to follow one getsyou remarkably terse error messages from DWiki (the software behind WanderingThoughts ).

DWiki is very cautious. One of the ways that this manifests is that itdoesn't accept random query parameters on requests; it knows what queryparameters each URL accepts,

Lately, one of the popular ways to configure programs is not to comeup with a custom configuration language or format (and the associatedparsers and so on) but to use a general purpose language for thispurpose, generally augmented with as much of a DSL as you can wedge in.One example of this is Rake , but thereare others; I have the impression that it's most popular when there maybe actual logic that you need to express in the program configuration,as is the case for makefiles

Due to security and complexity issues ,Unix systems vary somewhat in exactly how they handle the server side of doing NFS mounts . I've recently been digging inthis area, and this is what I've learned about how it works in Solaris10.

The server side of mounting things from a Solaris 10 fileserver goesmore or less like this:

• a client does the usual SUNRPC dance with portmapper and then sendsan RPC mount request to mountd
• if the filesystem is not exported at all or if the options

Like many sysadmins using Unix workstations, I spend a lot of timerunning xterm s. Given that most of the time the remote X program Istart with my rxexec script is an xterm , it'sno surprise that I wrote another script to automate all of the magicinvolved, called rxterm .

Rxterm's basic job is to start an xterm on a remote system with all ofthe right options set for it; for instance, so that the xterm titleand icon title have the name of the system that

Earlier, I mentioned that modern NFSservers don't have a comprehensive list of NFS filesystem accesspermissions stored in the kernel; instead they have a cache andsome sort of upcall mechanism where the kernel will ask mountd if a given client has access to a given filesystem if necessary.I've recently been investigating how Solaris 10 handles this, sohere's what I know of the kernel authorization cache:

First, the Solaris kernel does cache negative entries (this IP addressis not allowed to access this

Linux's little love notes about software RAID consistency errors makes a perfect example of something thatsystem administrators run into all the time: pointless error reports.

It's worth noting that a pointless error report is something differentfrom a useless error report. A useless error report tells you thatsomething has gone wrong but doesn't identify what it is, what exactlyhas gone wrong, and so on; you have to hunt that down on your own. Apointless error report shouldn't even have been generated