There are certain mistakes that you can make when writing DTrace scriptsthat are worth pointing out, partly because I've made them myself andpartly because I've seen them in other people's scripts on the net. Toserve as an example of this, suppose that you want to track ZFS read andwrite volume, so you write the following:

fbt::zfs_read:entry{ @zreads = sum(args[1]->uio_resid); }fbt::zfs

Suppose that you want to keep a running count of something in a DTracescript, for example the number of outstanding disk IO requests. Theobvious and most flexible way to do this is to use an ordinary DTraceglobal variable or array; you can even find examples of this invarious DTrace scripts. Unfortunately, this only works in restrictedsituations. If you use this generally, in a number of situationsyou'll sooner or later experience lost counter events. My guess is thatDTrace deliberately doesn't attempt to

In extremely idealized theory, the job of an SSL CA is to verify theidentity of the entities that they issue certificates to. People areforever clamouring for real SSL CAs to live up to this idealized image;they want SSL certificates to 'mean something' instead of being givenout to anyone who can scare up a domain name and a credit card that willpass basic billing verification. I've recently been struck by thesomewhat depressing realization that this is an impossible job.

By this I do not mean that

Suppose that you are dealing with some piece of code that uses TCPsockets and does not set an explicit send buffer size. You vaguelyremember that the default send buffer size can be tuned, but nothingimmediately obvious turns up. This is the situation I found myself inrecently.

It turns out there are two answers. The first one is /proc/sys/net/ipv4/tcp_wmem , which is mostly written up in Documentation/networking/ip-sysctl.txt inthe kernel source.

After recent experiences , I've become convincedthat my current methods of testing and monitoring disk performance arewhat I'd call inadequate. Most of my testing and monitoring focuses ondisk bandwidth, often streaming IO bandwidth because it's easy to beconsistent with that. One problem with this is that random IO matterstoo, but the bigger problem is that I've come to believe that latencyis what really affects your perceived performance .

Yes, you need good disk bandwidth in order to deliver decentperformance.

Here is another problem that I see for new search engines, ones thatpeople are unfamiliar with (to go with yesterday's other set of them ).

Not everything is on the web, or at least not everything is findable insearch engines with a sensible amount of effort. This means that whenyou get what is essentially a negative result in a search engine, you'reconfronted with a question. Did you phrase your query badly (for thissearch engine), or is there really no sensibly findable

A while back I gave DuckDuckGo a try (forvarious reasons that I'm not going to try to summarize here). One of thethings the experience brought home to me is how hard it is for anyone tocompete with Google in search, at least general Internet search. Thecrawling is hard enough on its own, not just because of the scope butalso because you have to tacitly persuade a critical mass of webmastersto not block your robot, either out of hand or when it misbehaves (andapparently

One of my long-running little bits of unhappiness is that Python strongly encourages modularprogramming but makes it awkward to write little programs in a modularway. Modules have to be separate files and once you have multiple filesyou have two problems; the main program has to be able to find thosemodules to load them, and you have to distribute multiple files andinstall them somehow instead of just giving people a self-contained fileand telling them 'run this'. I recently found that there is a (hacky

To follow up on my illustrated example of this , Iwanted to talk about how averages mislead people. They do it in at leasttwo different ways.

The first way that averages mislead is that they smooth out exceptions.The longer the amount of time you average across and the more activityyou see, the more that an average will hide exceptional activity (well,burry it under a mass of normal activity). You generally can't do verymuch about the amount of activity, so if you want to