wompom.org

In evaporation, the more energetic (i.e. warmer) a water molecule on the surface of an object is, the higher its chance of it turning to vapour.

The higher the wind speed across this surface, the faster these warm molecules will be blown away.

This is the concept of evaporative cooling.

The same applies when a company starts to fail, though there is an additional feedback cycle which compounds the problem. First, the most energetic molecules staff depart. These are the ones who can see a future for themselves outside of their current employment — and there is a high correlation between these people and those who are most valuable for an organisation. So the company becomes slightly worse due to the better people leaving. But it’s an exponential effect: it will rapidly get worse unless steps are taken to improve things. Eventually, the company stagnates as all of the interesting and innovative people have found alternative employment and only the boring ones are left.

So, the moral of the story: the more a company blows, the faster its employees leave.

This is a rant I have made many times in person: far too many to count. Since I can't possibly warn everybody who might be affected by this, face to face, I'm hoping you will all spread the word.

The problem

To begin with, I should say that ls --color is useful. It can show you which items in your directory listing are directories, symlinks, broken symlinks, device nodes, named pipes, whatever. I am glad that it exists.

However, let’s consider the basic action of ls. It is, of course, to display which files and directories exist in a directory. This is really quick and easy in Unix. Simply use the libc function opendir() then just readdir() till it returns NULL and errno is 0. In terms of syscalls, this is an open(), one or two read()s and a close().

When you turn on the color option, every directory item incurs the weight of an extra stat() call to see what it is.

Worse still, if it’s a symlink, ls will obligingly bound across to the thing linked to, to check it exists. If this causes your automounter to wake up and mount something remote, that’s quite an overhead. If your mount hangs because the remote filesystem is unavailable, you can say goodbye to that process; it'll be stuck blocking on a syscall that will never return.

A partial solution

To fix the symlink problem, here’s what you do. ls was written to avoid chasing symlinks if configured not to. Check your environment variables for the LS_COLORS variable with:

$ env | grep ^LS_COLORS

If it exists, you have a config file for colour ls: you should edit /etc/DIR_COLORS* or copy it to $HOME/.dircolors and edit it there. Otherwise, type:

$ dircolors --print-database > $HOME/.dircolors

The edit you need to do is to remove or comment out the ORPHAN line from the file.

Unless you were able to edit the file in /etc, you now need to make sure that this new $HOME/.dircolors file is used. In your shell login script (.bash_login for bash and .login for (t)csh, put the line:

eval `dircolors $HOME/.dircolors`

(Note that these are backticks, not apostrophes.)

Next time you log in, you'll be able to use colourful ls without fear of a remote filesystem freezing your directory listings.

In conclusion

Use ls --color when you need it, but as with all powerful tools, use it with care.

Corrections: James pointed out that to dump the default config it is –print-database not –print-directory.

I recently found a forgotten half-bottle of Tobermory 10 year old, in the back of a cupboard. Here are a few tasting notes about this long-forgotten friend.

This whisky is a light straw colour, quite thin in consistency. However, its insipid appearance belies a splendid if subtle flavour. With overtones of honeyed vanilla, it’s a sweet and faintly floral whisky. There is little aftertaste but I can forgive this in a delicate whisky of this nature.

I wrote a few months ago about how Ryanair had started charging for web check-in despite it being a cost saving for them — and how this was not the Ryanair that I understood. Well, I was proved right last week when they switched surcharges. Now you have to pay if you want to check in at the desk, and you get priority boarding and online check-in for free.

If only they would start putting some effort into maintaining the uptime of the web check-in site, I would be happy. That said, it beats Aer Lingus which refuses to let you print out a replacement boarding pass if (for example), Firefox crashes on getting the PDF the first time around.

Got back to the appartment last night to find police on High School Way, interviewing somebody innocuous-looking. When I went to the door to the appartment complex, it turned out that there were upwards of a dozen police, with six patrol cars, on Castro St. Most were standing around doing nothing but one of them appeared to have stopped a car and was interviewing the driver. I approached a chap at the edge of a crowd of onlookers and asked what was going on, and he declined to comment. At about that moment, the helicopter flew past for the second time.

Just as Pete and I were about to go, somebody cycled along the and stopped to cross Casto, halting in the middle of a gathering of police officers. One told him, "It’s illegal to cycle on the sidewalk, sir." His reply was a work of genius: "Oh, really?"

It was all very bizarre, though not at all menacing or confrontational. No guns were drawn and nobody was incapacitated by tazer or baton. Just another data point.

Then we went up to the appartment proper and watched Hot Fuzz. Excellent film, especially given that the room was still being illuminated by the occasional strobe of blue lights.

Over the past few months I have been asymptotically approaching being able to make a good cappuccino or latte. (I'm way better than the glassy-eyed morons who are usually behind an espresso machine but nowhere near "good barista".) However, over the last few weeks I have noticed that sometimes I was not able to steam the milk properly. I get very little foam then when I bang out the biggest of the bubbles, it’s virtually flat.

I had thought that I was just having a bad run, but then a colleague mentioned it too. It turns out that only some of the bottles have this characteristic, and we haven't determined, from analysis of the codes on the bottle tops, what determines this. Each was full-fat milk from the same dairy.

If anyone who reads this knows the answer, please mention it in a comment.

I asked an interviewee how long it takes for a disk seek, and he replied that he thought it was between 4 and 8 milliseconds. Speaking with colleagues, the conventional wisdom was that it was around 10 ms. I was unsatisfied so I thought I would try it for myself.


time sudo perl -we '$disk="/dev/sda"; $n=1500; $blocks=`blockdev --getsz $disk`; if (!$blocks) {print "Enter capacity in manufacturer GB\n: "; $blocks=1953125*(<>)}; use Time::HiRes "time"; open DISK, $disk; $start=time; for (0..$n) {seek DISK, int(rand($blocks))*512, 0; sysread DISK, $x, 512 || die; $now=time; $times[int(($now-$start)*1000)]++; $x=$now-$start; $s2+=$x**2; $s+=$x; $start=$now}; for (0..$#times) {if ($t=$times[$_]) { $tot+=$t; $median||=$_ if $tot>=$n/2; printf "%3d %s\n", $_, "x" x ($t/2) . ($t%2?":":"")}}; printf "\nTook %3.4gs for %d seeks of %s (%d GB)\n", $s, $n, $disk, $blocks/2097152; printf "Mean: %2.03gms; Median: %d-%dms; Std dev: %2.03gms\n", 1000*$s/$n, $median-1, $median, 1000*sqrt($s2/$n - ($s/$n)**2);'


It should be obvious that before you run this, you should check for yourself that it doesn't do anything dangerous. Or at least check that $disk is set appropriately for your hardware and operating system. If you don't have blockdev, estimate the number of 512-byte blocks and set $blocks to that value. (There are 1953125 blocks in a hard disk manufacturer’s "Gigabyte".)

The graph it produces prints an 'x' for two seeks of a given number of milliseconds and a trailing ':' if there was one left over. For me, on my one year old Linux 2.6.18 workstation with a 160 "GB" Western Digital (WDC WD1600JS — quoted seek time 8.9 ms) the typical output is:

  0 :
  3 :
  4 :
  5 x:
  6 xxxx:
  7 xxxxxxx
  8 xxxxxxxxxxx:
  9 xxxxxxxxxxxxxxxxx
 10 xxxxxxxxxxxxxxxxxxxxxxx
 11 xxxxxxxxxxxxxxxxxxxxxxxxxxxx:
 12 xxxxxxxxxxxxxxxxxxxxxxxxx
 13 xxxxxxxxxxxxxxxxxxxxxxxxxxxxxxx:
 14 xxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxx
 15 xxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxx:
 16 xxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxx
 17 xxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxx:
 18 xxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxx:
 19 xxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxx
 20 xxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxx
 21 xxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxx
 22 xxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxx:
 23 xxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxx:
 24 xxxxxxxxxxxxxxxxxxxxxxxxxxxxxx:
 25 xxxxxxxxxxxxxxxxxxxxxxxxxxxxx:
 26 xxxxxxxxxxxxxxxxxx
 27 xxxxxxxxxxxxxxx
 28 xxxxxx:
 29 xxxxx:
 30 xxxx
 31 :
 32 :
 34 x
 35 :
 57 :

Took 27.69s for 1500 seeks of /dev/sda (149 GB)
Mean: 18.5ms; Median: 17-18ms; Std dev: 5.24ms

real    0m27.859s
user    0m0.116s
sys     0m0.044s

Why might I care? 18 milliseconds is almost a lifetime compared with anything else a modern PC does. It’s slower than my monitors' refresh period! I can read around 1 MB from disk, 10 MB over a GigE link or 20 MB from RAM in this time. I can ping from Ireland to England, crossing 40 routers there and back, in the time it takes for my disk head to seek.

Every time you read something from a previously unread file, it costs on average EIGHTEEN MILLISECONDS even before it starts reading. That’s just 55 in a second. This has obvious implications for I/O program performance, i.e. that of most servers.

If anyone has a concern about my method, I'd be interested to hear it.

I'd also like to see the timings for different disks. Either post the whole histogram or just the stats, plus the make and model of the disk. On Linux you can get this from dmesg or hdparm -I device.

Update: I've made the script more robust under non-existence of blockdev.

I am no longer even nearly homeless, having just started renting an appartment. Because I'd be lonely on my own, I'm sharing with another Googler, Carlo Contavalli.

Here’s the weird thing. We were chatting over lunch and it turns out that, unbeknown to either of us, we are both Debian Developers. Only in Google could this happen.

I have long felt that many airport security measures are just for show — "security theatre", as Bruce Schneier puts it — but I now have some anecdotal evidence to back it up.

I fly frequently: from Dublin to my family in Durham, and I make the occasional transatlantic flight too. Before I realised it last week, I had taken a travel sewing kit in my hand luggage on seven flights, both short-haul and long. In Chicago, I even had my luggage hand-checked; they still didn't notice it.

Maybe they'd have been more thorough if I'd been wearing a turban.

Okay, perhaps it’s a little exaggeration to say that I'm nearly homeless, since I have a perfectly nice house in Durham. However, since I'm working in Dublin this is not especially helpful for my weekday accommodation.

If any reader has a room they could rent me near Grand Canal Dock, for around €400-450, please get in touch, perhaps by email. I don't keep cigarettes or pets.