I currently have a ZFS on Linux performance mystery with sequential NFSwrites. One of the things that I want to do to diagnose it is to get atrace of NFS client activity so that I can see exactly what is slow andwhen. In theory I could reconstruct this from sufficient analysis ofthe TCP stream; in practice I couldn't make Wireshark do this with somebrief poking and this seemed like a good time to learn Systemtap (afterall, DTrace can definitely do this sort of stuff with effort)

Some packages ship with systems of split configuration files, wherethere is a standard configuration file (or several) and then a filethat is specifically designed to be customized by the local systemadministrator. The intention is that the sysadmin can make changes tothe local-use config file without having to worry about the package'supdates to the standard configuration (and thus without having to mergetheir changes and the package's changes). Unfortunately packages oftenmake a tragic mistake in the contents of these local files.

As I got wrong once before , thecorrect way to secure your SQL against SQL injection attacks is not to try to quoteall your arguments (even if you do it in a library) but to use SQLplaceholders instead. This raises the obvious question of what are SQLplaceholders and how do they differ from correctly quoting your SQLarguments.

The simple answer is that SQL placeholders are transmittedto the SQL server separately from your SQL statements . Tomake a terrible analogy, SQL placeholders are much like using exec*(

While I wrote up the general state of affairs with ZFS and 'advancedformat' disks I've never described how this affectsus in specific. The short version is that we are not in as much troubleas we might otherwise be because we're running ancient and somewhatunder-functional software.You are in the maximal amount of trouble if your version of ZFS willrefuse to add 4K sector disks to old pools and you have no way to lieto ZFS (or the kernel in general) about

I still run a mailer on my office workstation, handling email toaddresses that I've had for a very long time and which I used to usea lot in public (back in the days when the Internet was a much nicerplace). To a very good approximation the only email that gets sentto it any more is spam.

(I have systematically transfered all legitimate email to otheraddresses elsewhere and I no longer subscribe to mailing listsand so on from it.)

Which leads to the punchline:

CVE-2013-1979 is a more or less just-released locally exploitable'gives root' Linux kernel vulnerability. Usually when I read CVE bugdescriptions I can get at least a vague sense of how something would beexploitable, but this one puzzled me; I could see how the bug was notgood but I couldn't see how it would be exploitable. Even the proof ofconcept code didn't particularly clear this up.

As described in the Red Hat bugzilla the

Lately, 'infinite scrolling' web pages have become a popular designtechnique. These are pages that add additional content as you scrolldown; keep scrolling and they'll keep adding, basically forever.While I can see the attraction of infinite scrolling, for me one ofits big features is also my biggest issue with it.

One big appeal of infinite scrolling is that the user never has tointerrupt their actions to go on. There is no scrolling to the bottomof one page, following a 'next page

I've written before on my view that web robots of all sorts shouldnever send a Referer header. In those entries I mostly said 'don't dothat' without giving a solid philosophical argument about why, so todayI feel like changing that.

(Not that a philosophical argument actually matters. Proper behavioron the web is defined by social convention, ie by what lots of otherpeople do and expect, not by arguing with people over what makessense. Whether or not you agree with a social

Today a web spider called 'Diffbot' (run by diffbot.com) made a wholebunch of requests here, all of which failed. They failed because, justas it has repeatedly done in the past, it made them all with a Referer header of ' https://news.google.com/ ' and this behavior long ago led meto ban it entirely from here .

There are a number of things wrong with this header. The first is that,to steal from the old Trix commercials