To summarize an earlier entry , the classic Cquoting bug that I'm talking about here is writing ' printf(ustr) ' or' syslog(pri, ustr) ' where ' ustr ' is a string that comes from someform of external input. In that entry I mentioned that it's possiblefor languages to avoid this entire class of bugs with the right design.Well, it's time to elaborate on that parenthetical aside.

To start with, let's turn the issue around:

DEVOPS_BORAT tweeted today:

Is not about backup, is about restore.

YES . Many, many times yes.

DEVOPS_BORAT is undeniably funny, but sometimes those funny thingsare also pithily saying something very important where you shouldn'tjust laugh and move on. This is one of those times.

Until you have tested restores, you do not have backups; you have asuperstitious ritual that may or may not write some useful bits to someplace. What is important is not making those bits; what

As part of Sysadvent I recently read Jordan Sissel's Data in the Shell ,where one of his examples was a suite of tools for doing things withfield-based data (things like summing a field). I approve of this ingeneral, but there's one problem: he wrote his tools as shell functions.My immediate reaction was some approximation of a wince.

I have nothing against shell functions; I even use them in scriptssometimes, because they can be the best tool for the job.

In full blown REST , asingle resource can have multiple representations (formats). Youdecide which representation to ask for and to serve by what is inthe HTTP Accept header of the HTTP request; if you want a HTMLversion of the URL you say that you will accept text/html and ifyou want a JSON version you ask for application/json ( see eg ).

The issue I have with this in practice is that it makes the Acceptheader part of the name of the specific representation of the

Since I quietly mentioned it in passing recently , I suppose I might as well make itofficial and admit that I've gotten myself a Twitter account ( despitethe lack of names that I like ). You can find meas thatcks .

(Given my usual bad habits withnew information sources, I may go wild with following people and thenfrantically scale back as I get overwhelmed. Or I may go the other waythis time around and be really cautious about following people.)

Disclaimer: my login name is

As a followup to my first experiment with coding in public , I've put a few other Python projects up on Github.They are:

• dwiki , the code for DWiki itself (the software that runs this blog), plus the basic pagetemplates and so on that I use. I'm not entirely happy with theactual organization of the code, but I have no energy to reformit at this point (or, more likely, rewrite it from scratch).

  (At the moment the specific additional

Earlier today I tweeted :

Every time I use the Fedora 16 gpk-update-viewer I'm filled with angerfor what someone did to a nice, usable program.

Now I feel like explaining that (in the spirit of an earlier entry ). First, gpk-update-viewer is the program behindthe 'Software Update' information display on Fedora systems; it's partof PackageKit .

In Fedora 15, the (Gnome) interface for it has two relatively minorissues (which you

I've recently been tooling around in both SMF and systemd , so I'vedeveloped some strong opinions on what startup systems like this need toprovide to help working sysadmins. It will probably not surprise you toknow that neither SMF nor systemd deliver entirely useful informationtoday.

There are two sorts of service startup problems, which I'll call thesimple and the complex. The simple question is 'why did this servicefail to start'. To answer this sysadmins need to know exactly whatwas run and

I was recently reading More shell, less egg andran across this:

(I can't help wondering, though, why [Doug McIlroy] didn't use head-${1} in the last line. It seems more natural than sed . Is itpossible that head hadn't been written yet?)

While head postdates sed , this is probably not it. There is an oldUnix bias against using head to the point that a lot of old Unixpeople make a point of avoiding it