Suppose that you're writing a network server with persistent connections(these days that can even describe web servers, depending on what sortof web app you're running). Your program should really support able toreload its configuration and related things on the fly, without havingto be stopped and restarted. This should include not the configurationalone but anything you normally load once at startup. Especially itshould include anything that can time out or expire such as, oh, SSLcertificates.

The problem with only supporting

Due to recent events , we're nowrather interested in being able to measure, characterize, and track ourdisk IO performance. This, it turns out, presents some problems in themodern world.

Of course the gold standard thing to measure is your actual observedperformance in production (and thanks to some work with DTrace, Ican now actually do that). However, the problem with productionperformance is that so many things influence it that it's hard toknow what changes in it mean. In

One reaction to my problem with parsing wikitext isto ask why it matters. So what if I don't know how to properly parse WikiText ; clearly lots of people (myself included) have written code toprocess wikitext dialects and the code works, even if it may not be themost elegant code and we may not have a nice formal model for it. Ifregexp based bashing works, just use regexp based bashing.

My answer is that parsing is ultimately here to tell us how to easilywrite code that

Back in this entry , I claimed that fork() is agood API. This may strike some people as a crazy thing to say, giventhat many people consider fork() to be undesirable and something tobe papered over with higher-level APIs like posix_spawn() .

The first thing to understand about fork() is that like a number ofother Unix APIs, it is primarily a kernel API, the interface betweenthe kernel and user level code, not necessarily an interface thatordinary programmers

Suppose, not entirely hypothetically, that you are interested inmeasuring the performance of your disks. Of course you understand that averages are misleading and that latency isimportant , so you fire up a handy tracing IOperformance tester that does streaming reads and dumps timing tracesfor each IO operation.

This might sound good, but I feel that using streaming IO for this isgenerally a mistake. It isn't a fatal one, but you are potentiallythrowing away information on latency and making it harder to be sure ofany

Suppose that you have a program with a significant in-memory database,or just in-memory state of some sort. You need to save or checkpointthe database every so often, but you have a big enough database thatthe program will pause visibly while you write everything out. In themodern era, people might reach for threads and start spraying lockingover their in-memory data structures and so on. But in the old days youdidn't have threads so you couldn't do it the hard

Due to recent events , I've beenworking on a program to measure our disk IO latencies. Since itonly needs timing accuracy in the millisecond range, I've beenwriting it in Python (which is more than fast enough to not adddistortions to the IO timings). In the process of developing thiscode, I made a classic absent-minded mistake that shows a dangerof default arguments.

The code needs to know the size of the range it will be doing IO on. Inthe beginning

I saw yet another meditation on the difference (if any) betweenoperations and system administration make the Twitter rounds recently, which has finally pushed me over the edge to say somethingabout this. I want to talk about the history behind this apparentdivision, at least as I see it from my perspective.

(My disclaimer here is that I was not around at the start of thisstory, only towards the end and only in an academic environment.So my perspective may be skewed.)

A long time ago,

We have a theory about what was wrong with our problematic iSCSIswitch . To set the scene, theproblematic switch is a higher-end switch, of the sort that aregenerally intended as core switches in a network backplane; this is infact what we mostly use this model of switch for (where we've been quitehappy with them). The switch that works well is a lower-end switch fromthe same company, with all of the basic functionality but less bells andwhistles of various sorts.