Quiet day. Yvonne's off to Germany tomorrow, and we spent a some
time preparing for that—apart from packing there's also the work that I will have to do
which previously Yvonne did. Spent some time working on some coding guidelines; it's a pity
that they won't interest anybody outside the project.

Yvonne off to Germany today, which shouldn't have taken much time
on my part, but somehow I didn't get started with anything else until early afternoon. More
tidy up work; tomorrow we can finally start some real testing again.

Finally took a look at the rainfall bulletin for last
month. It's shocking for at least two reasons: firstly, the rainfall was only about 5% of
the normal (the L in the Decile column indicates the lowest on record), and
secondly the report itself is in conflict both with other information on the same site, and
also with reality. For example, no rain was reported at all for Echunga: that seems to be a
common occurrence. And surely they must have averages for McLaren Vale, one of Australia's
most important wine-growing areas. I wonder how much we can trust the other values.

Yvonne's gone, leaving me with some extra work to do, though it
wasn't as bad as I feared. After my recent web page work, back to testing the video recording
application, once again telephonically with Peter Denton, and made reasonable progress. I
always like commits that remove much more than they add:

revision 1.9
date: 2006/11/03 05:52:05; author: grog; state: Exp; lines: +21 -113
Rewrite to set the state segemnt. Clean up much cruft in the process.

Weather is still an interesting topic, and I went looking for comparative graphs of
rainfall and temperatures in different parts of the country. The Bureau of Meteorology has the data, but it's in tabular form, and
I'd like a graph. Spent some time wondering how to get gnuplot to use the data,
without success. The problem is that I have rows like this, representing average monthly
rainfall in Stirling:

I want to plot the rainfall by month, but gnuplot expects the data to be in columns,
not rows. I'm sure there must be a utility to turn things on their side, but I wasn't able
to find one in a reasonable time.

In the evening, addressed an issue that has annoyed me about mplayer for some time: the on-screen time display
bears no relationship to reality when displaying MPEGs (recorded or directly) from digital
TV. It seems that the time information embedded in the stream does not get converted, so the
“elapsed time” seems to be randomly distributed in the range 0 to 30 hours. Made
a change to at least partially fix that—simply subtract the time of the first frame
from the elapsed time, and things work almost correctly. That can definitely be improved on,
though, so I won't publish yet. In passing I'm once again amazed by how simple it is to make
this kind of fix to mplayer, despite a desperate lack of comments. Given that there's
no other technical documentation, that's a particular challenge.

Into town this morning for a scheduled dentist's appointment, and then spent a surprising
amount of time shopping. BiLo is now a name of the
past; they've been taken over by Coles, not
necessarily an advantage from what I experienced today. Couldn't find any coconut cream: the
shelves were empty, and all they had were significant quantities of “Lite”
coconut cream, which is something I haven't seen before. I strongly distrust anything with
“lite” (or even “light”) in its name. Tried to find customer care,
but to get to them you have to leave the supermarket. What genius thought that out?

Finally found somebody who said that they were suffering some supply problems, so left
them and went to Woolworths, where I found the
normal stuff, along with even more “lite” cream. The house brand costs $0.82 per
400 ml, the same price as the “lite”. It's worth looking at the cans:

The normal coconut cream contains 68% coconut, and the “lite” version contains
only 23%, almost exactly a third; the rest is water. So if you need 1.2 litres of
“lite” coconut milk, you can either buy one can of normal cream and dilute it 2:1
with water, or you can pay 3 times as much to buy 3 cans of “lite”. Why would you
want to do the latter?

Down to Bonnetts, where Yvonne's saddle, sent for a quotation, had been repaired—total cost
$10. They didn't even do a bad job: it's difficult to recognize where the damage was:

Peter Jones over in the morning for a talk about installation and updating, and made good
progress. It does mean that I'll have to completely overhaul the database design, but that's
not as much work as it sounds. Spent most of the day working on that.

The dam water line is blocked again! It had occurred to me some time ago that the
water I pumped up to reverse flush it probably wasn't enough; measured the trough and found
that it contained about 475 litres. The pipe to the dam has a 50 mm internal diameter, which
corresponds to about 2 litres per metre. How long is it? It's difficult to say, since it's
underground, and it's not in a straight line from the dam. but my best guess is about 400
metres, or 800 litres. That would mean that the water in the trough would only reach half
way, obviously enough only to dislodge the blockage, but maybe not enough to get it out of
the pipe back into the dam. Decided to pump water from the fire fighting tank (which proves
to claim to be 2500 gallons, or 11,400 litres; we bought it as a 10,000 litre tank) back up
to the dam. That proved to be easier than I had expected, and made me wonder why I had
thought of the trough in the first place:

Pumped about half the tank (over 5,000 litres) of water up the pipe, during which time the
tiny petrol tank of the pump ran dry twice. What idiocy! What use is a fire pump that
requires you to pour petrol around in the middle of a fire?

On the work front, finished off the changes I had started earlier in the week, committed
them and shelved the project for the moment. Spent the afternoon cooking; I should have more
time for this sort of thing.

The extra “sprinkler” was a dripper line that had blown off the connector
because of the higher pressure. Let's hope that that's the end of the blockages.

Claire Baker had sent me some updates for the web site of the ICT Council for South Australia, which is dire need
of it, so spent some time doing that. Most of the time was just general cleanup of the HTML;
it's not worse than that of other sites, but it's really disappointing how bad most HTML
looks. Maybe that's one of the down sides of content management systems (which I still can't
see as anything except a workaround for lack of availability of a good text editor).

In the afternoon, had intended to look at freevo, which I had recently installed on
teevee, but somehow got sidetracked to looking at synergy instead. synergy is a
program that shares the keyboard and mouse across multiple systems. Unlike x2x, it
works across multiple platforms, not just for X. Also unlike
x2x, it doesn't understand X displays, and I spent quite a bit of time trying to make
sense of the (relatively voluminous) documentation before discovering that it simply doesn't
cater for more than one display per “system” (i.e. IP address). Managed to get it
working for boskoop (which until now I had been calling boskopp; the latter is
a popular spelling in Germany, but it seems that Boskoop is a town in the Netherlands, so
I've had to adjust the spelling accordingly).

Also tried to get it to work with Microsoft “Windows XP”, but the latter
didn't have any configuration file, and the GUI setup didn't seem to provide a way to create
or import one. That's not a particular problem; I didn't really want to connect it anyway.
The good news is that it works in conjunction with x2x, so once I can work out a way
to simulate the “Apple” key on my keyboard, all should be well.

Another quiet day. Spent some time writing up the discussion on eggs below, and had my
first attempt at running freevo. The
documentation is of the usual quality, or maybe a little better. It starts off giving all
sorts of details of how to install it, all done automatically for me by the FreeBSD Ports collection, and then doesn't tell you how to
start the program. It does tell you how to configure it, which is fortunate. It's relatively
straightforward if you want the defaults (NTSC, 800x600 display). Tried with my setup and
entered:

=== root@teevee (/dev/ttypb)~31 -> freevo setup --geometry=1280x720 --tv=pal --chanlist=australia
System path first=No
checking for mplayer... /usr/local/bin/mplayer
checking for mencoder... /usr/local/bin/mencoder
... many more of these
geometry must be one of: 800x600 768x576 640x480

Wow! That makes it pretty useless. I suppose I need to go back and try my luck with MythTV again. Or maybe I should learn python and fix it.
Continued anyway and was able to point it at my Maybe directory (for stuff that I may
look at if nothing else comes up), and found:

That scared me—did it maybe first delete the contents? No, they're still there:

Yvonne left me with 18 fresh eggs in the fridge, so I've been having
a boiled egg for breakfast every day. It's easy to boil an egg, right? That's why none of my
myriad cookbooks have details. Somewhere in the back of my head I had this concept of a
“3 minute egg”. The first time (not recently) that I tried this, the egg came
out almost raw: only some of the white had started to coagulate.

What went wrong? Details, as usual. There are two basic ways to boil an egg:

Put an egg in cold water in a saucepan, bring to the boil, and boil for three minutes.
This will give you an egg where (roughly) the white is solid and the yolk is still
liquid.

Bring some water to the boil in a saucepan. Add the egg and boil for six minutes.
Again, this will give you an egg where (roughly) the white is solid and the yolk is
still liquid.

I went looking on the web and found references to both
methods: eHow.com gives only the
first method,
while Delia
online gives both, the second with a twist: take the pot off the boil after one minute
and leave another 6 minutes (7 in total).

Somehow both of these are missing a number of important points:

The boiling time for an egg is dependent on its weight, and more importantly, its
diameter. The eggs I have here range in weight from 44 g to 71 g, and from 40 mm to 47
mm. The eggs in these photos both came in the same box.

No recipes I know address the diameter of an egg, and almost none address the weight.
The EU regulations divide eggs into 7 classes. Class 7 is anything less than 45g (like my
second example), class 1 is 70 g and more, and the others are in 5 g steps in between. My
old copy of the American book “The Joy of Cooking” states that the recipes
are for 2 oz (i.e. 57 g) eggs, probably rather smaller than most eggs nowadays.

The cooking time depends on the following factors:

The temperature at the surface between the water and the egg. This is easy to
specify for the second alternative: it's 100°.

The surface area itself. For a first approximation, we can assume that the heat
flow into the egg is proportional to the surface area.

The diameter of the egg. The further the heat has to go, the longer it will take.

The mass (“weight”) of the egg. The cooking time is roughly proportional
to the heat flow divided by the mass, and thus the surface area divided by the
mass. For eggs of the same shape, the mass is proportional to the cube of the
diameter, and the surface area to the square of the diameter, so this ratio is
proportional to the 1.5th power of the diameter.

The previous point would be more exact if the heating were very gradual (i.e. the
temperature differences small). That's not the case here: in the second case, we
have an egg at about 20° being plunged into water at 100°. The first case is more
complicated, but even there the temperature of the water rises much faster than the
temperature of the egg.

At a first approximation, I'd assume that the cooking time in hot water is
proportional to the radius (and thus the diameter) of the egg: in other words, the
time taken to get the heat to the middle of the egg depends on how far it has to
travel. Combined with the previous factor, this would suggest a cooking time in
proportion to the 2.5th power of the diameter.

The previous calculations make a number of implicit assumptions. in particular that
the thermal resistance of the shell is the same as the inside of the egg (also assumed
to be uniform). But it's a basis for thought.

Even if you assume that the cooking time is roughly proportional to the diameter, the
egg with 47 mm diameter would take nearly 20% longer to cook than the egg with 40 mm
diameter—that's over a minute difference for the second method. It's difficult to
guess what the difference is for the first method.

Eggs are relatively fragile. If you put a cold egg into boiling water, the pressure
inside will build up suddenly, and the egg may crack or burst. The larger the
temperature difference, the more likely this is to happen.

There's a simple solution for this, but I haven't seen it in English-speaking
countries: an egg piercer:

You put the big end of the egg onto this device and press down; the spike in the
middle makes a small hole in the shell, which allows the pressure to adjust.

The cooking time depends on the initial temperature of the egg. Many warn against taking
the egg directly out of the fridge: Delia writes:

Don't ever boil eggs that have come straight from the refrigerator, because very cold
eggs plunged straight into hot water are likely to crack.

I've already addressed that issue. But what difference does the initial temperature
make in the boiling time?

If you put the egg in cold water and bring it to the boil, you have at least two
sources of inaccuracy:

The time it takes for the water to come to the boil depends on the strength of the
flame and the amount of water. During this time about half of the cooking takes place,
as you can see by the comparison of the cooking times for the two alternatives.

The time it takes for the water to come to the boil is also dependent on the number of
eggs you put in the water: the more, the longer it takes to boil.

It's difficult to decide exactly when the water is boiling. Is it when the first
large bubbles appear? Or when it's boiling vigorously? These two events can be 30
seconds apart.

Delia's idea of taking the water off the boil after a minute also introduces a small
inaccuracy: the remaining time depends on how quickly the water cools down. The fact that
she adds a minute to the cooking time suggests that this is non-trivial (in fact, I
wouldn't expect it to make that much difference), but she doesn't explain what use this
twist is.

When removed from the water, the surface of the egg is hotter than the middle. If you
don't do anything, heat will continue to transfer to the middle, and it will continue to
cook. You can slow this down by running cold water over the egg after removing from the
saucepan. eHow mentions this, but Delia doesn't.

What does this mean in practice? I use method 2 because it's more reproducible. Ultimately
you're going to have to find your own times, but if you have a box of eggs like the ones
shown above, you'll have an idea how to proceed. I've been eating the big eggs so far; when I
get to the small ones, I'd guess that they will only need 5 minutes instead of 6.

This is no isolated incident. When looking at last month's disastrous rainfall results, I
have no confidence that the figures given represent the reality.

Researching cassoulet recipes

Spent much of the afternoon with more experimental cookery, specifically things
that Yvonne doesn't like. I'd like to make
a cassoulet again, but it's
almost impossible to get one of the key
ingredients, confit d'oie an
ingredient so foreign to the English way of cooking that I don't even know how to translate
it—neither do any of the references I can find on the web. It's goose cooked and
salted and preserved in its own fat.

One of the big problems with casoulet is finding a definitive recipe. There are two
basic kinds, the cassoulet tolosain and the cassoulet de Castelnaudary. The quantities and
the methods and times of cooking also vary wildly. And the otherwise excellent Time-Life
cookbook series that was printed in the 1970s omits the confit d'oie, presumably
because of the difficulty of finding it.

So today I tried making a cassoulet-like dish mainly with the intention of getting the
quantities right. A good thing too: they were way off. In particular, all recipes seem
to specify too few beans.

I started with three sources of recipes:

Time-Life “The Cooking of Provincial France” in two versions (English and
German, the latter for usable units of measurement). This was published in 1968 as the
first of a series of cookbooks, and in general I've found them very good.

La cuisine du marché by Paul Bocuse, published by Flammarion in 1980.

La Cuisine de Madame Saint-Ange, published by Larousse, this edition in
1982.

These recipes differ greatly in the recipes, and they all seem to have too few beans.
Here's what I used:

Traditional measure

Quantity

Ingredient

Step

500g

beans

1

300g

lamb, from leg

2

250 g

pork, from forequarter

2

150 g

duck fat

3, 8

20 g

couennes (pork skin)

4

75 g

smoked ham

2

500 g

onions

5

25 g

garlic

5

170 g

double-smoked Moscow sausage

6

245 g

double-smoked Kransky sausage

6

800 g

tinned tomatoes

6

50 g

bread crumbs

8

Preparation

Soak the beans in lukewarm water for 2 hours. The purpose is not to soften the beans, but
just the skin. Longer soaking will provoke fermentation.

The beans should be “fresh” (i.e. from the last harvest). Madame
Saint-Ange and Bocuse are both in agreement that old beans detract greatly from the
quality of the dish. They will split, and the interior will remain granular.

Brown the whole pork and lamb in a frying pan.

Bring 2 litres of water to the boil and add beans, meat and 100 g duck fat. Bring back
to the boil and salt lightly (salt tends to harden the beans). Simmer at the lowest
possible heat for two hours.

Steam the couennes for an hour, then cut into small strips.

Chop and fry onions in duck or mutton fat until glassy, and then add crushed garlic,
fry for a couple of minutes. Reserve.

After two hours, add the sausage and tomatoes, check the salt and boil on low heat for
another hour.

Drain the pot, keeping the broth for later, and separate beans and meat. Chop meat into
5 mm slices (Bocuse recommends 3 mm). At this point it became clear that I had too much
meat, so I split it into two parts, one for a later cassoulet.

What will I do differently next time? In proportion, there was far too much sausage and
onions, and far too few beans and almost no couennes. It also tasted too much on the
“smoked” side. Here are the proportions I'll use next time.

Traditional measure

Quantity

Ingredient

Step

400g

beans

1

200g

lamb, from leg

2

125 g

pork, from forequarter

2

150 g

duck fat

3, 8

50 g

couennes (pork skin)

4

200 g

onions

5

15 g

garlic

5

250 g

double-smoked sausage

6

400 g

tinned tomatoes

6

50 g

bread crumbs

8

Note that the smoked ham is gone, and that there is only one (unspecified) kind of
sausage.

A couple of people have sent me feedback about the egg boiling article. Tom Maynard
comments:

Mayhaps you are overanalyzing your egg preparation technique? AFAIK, eggs are edible in
every stage from raw to hard-boiled (and beyond). A perfect 3-minute egg exists in my
memory, in my G'ma's kitchen, without any science behind it at all—save 30-50
generations of “technique.”

Clearly you don't need all this background to boil an egg, but it helps to understand the
issues. I'm reminded of a fortune cookie in the FreeBSD fortunes files:

Ray's Rule of Precision:
Measure with a micrometer. Mark with chalk. Cut with an axe.

Quo vadis, software?

I need to accept the fact that my tools are getting out of date. I've been using mutt for years now, but its weaknesses are beginning
to show: it uses an external program, urlview, to select URLs embedded in the message.
urlview doesn't understand the format of the text, and it lists all the URLs together.
In addition, because it doesn't understand the format, you get all the URLs from a multipart
message displayed together, and if it's in quoted-printable, the result is nonsense. For
example, from a message like this one:

Where are the URLs that were shown above? No idea. One might be item 3, but it's so mutilated
that you can't tell. The problem here is that the original message is in quoted-printable,
and mutt doesn't decode that for urlview.

In addition, mutt has the problem that it displays on a terminal window, which has
a predetermined character set. I'm still using ISO 8859-1, so much stuff is just displayed as
?. Also, it doesn't handle format=flowed correctly. I suppose I could fix it,
but I get the impression that there isn't much energy behind the mutt project any
more. Everything is going into the GUIs.

OK, I thought, another attempt. Installed sylpheed-claws. Fired up and got Yet
Another Horrible Paned Window (and only one of them). The text, on my 1600x1200 display, was
miniscule. Fixed that as best I could (the text got bigger, but the menus and frames were in
the same flyspeck), moved to another screen (2048x1536) and it was suddenly gigantic! I've
already complained about similar problems with firefox. Why is it that text sizing is
such a problem for GUI software?

Apart from that, the more I see of these paned windows, the more I hate them. How can
people live with an arbitrary subdivision of the screen? The whole idea of windowed
environments was supposed to be get away from that sort of problem. Why not a window set, in
this case with, say, an index window, a folder menu and one or more message windows, each
individually resizeable, and maybe handled as a set by the window manager?

And, of course, there's this “there can only be one” mentality: it seems that
you can only start one copy of sylpheed-claws. If you try to start another one, it
gives focus to the one already running, even if it's on a different display. This is stupid,
pointless and a show-stopper for me. When I'm in the lounge room watching TV, I can start
another mutt window and view my mail from there, while the mutt in the office
stays as it is. sylpheed-claws would just transfer control to the version running in
the office. A waste of time.

Another disappointment is firefox 2.0. I upgraded to it recently and discovered
that, even though I have done my damndest to disable this stupid “tabbed
browsing” misfeature, it does it anyway under some circumstances, and I can't find a
way to disable it. Today I tried updating a WikiPedia
article, and pressed Alt-P for the preview. Nothing happened. I had to scroll down to
the bottom and press the “Preview” button. When I was finally finished, I pressed
Alt-S and was given some firefox function. So now I have lost more
functionality. Every change in firefox seems to make it worse. Maybe there's a way to
fix it—I hope so—but it wasn't obvious, and the configuration menus don't offer
any help. Backed it out and installed the latest version of 1.5 instead.

Where is software development going? Am I really behind the times because I can't put up
with things that make my life harder?

Spent a lot of today working on the MythTV port to FreeBSD, based on the work of Stacey Son 18 months ago. He did
his work based on revision 0.17 of MythTV, but in the meantime they're up to revision 0.20,
and a lot of things had changed. It took most of the day, but finally I got it to build
cleanly. Now to see if I can also get it to work, and if I don't find something that drives
me crazy about the interface.

Message from Michael Hughes referring to my report about telling me that sylpheed-claws can, indeed, separate
its panes into individual windows. Tried that and confirmed that it works—all on the
same display, of course. If this seems silly, I really do use two displays for my mutt
mail: I do the reading on wantadilla:0.1 (straight ahead in the photo) and reply via an emacsclient
window on echunga:0.0 (to the immediate right, the black monitor in that photo). And,
of course, it still doesn't address the “there can only be one” problem.

Had intended to work on the MythTV port today, but in
the middle of all that got a call and a couple of strangely formatted and formulated mail
messages from Hahndorf; looks like our project is moving again. Spent some time looking at
the web pages, writing more PHP/MySQL code. I thought I had got the knack of it, but it still
took a fair amount of work to get right.

Working on the MythTV port showed that I'm not out of
the woods yet. It builds, but doesn't install, and I'm still having difficulty conveying the
environment variables (in this case QMAKESPEC) to the underlying build. It works
fine if I set it from the shell. The same thing should work via the Makefile if I
specify it in MAKE_ENV; but it doesn't. More head-scratching. Also it tried to
install non-existent programs, and it looks as if I'm going to have to add some serious
post-installation scripts: currently it tries to install the database as the non-existent
user mythtv.

Yvonne got back from Europe today, not without a delay which made
her miss her connection in Melbourne. She seemed pretty bright, so on leaving the airport,
and after marvelling yet again how badly designed the people and traffic flow is, dropped
into
IKEA, which opened recently just outside the airport. We had just intended to take a
look, but ended up buying quite a bit: they have a number of things that we had been looking
for (though not egg piercers). One thing that I didn't buy was a corkscrew, though I was
tempted:

Chris Yeardley has just moved house (well, about 6 weeks ago, and not really
“house”), and we've been keen to see what it looks like, so this morning, despite
the fact that it had been less than 24 hours since Yvonne returned
from Europe, we set off on a 650 km road journey to
Dereel. Stopped in Nhill for food, and made the mistake of ordering some ham and cheese
sandwiches; we had forgotten how basic a $3 sandwich can be, and I'd like to do so again.

Chris is still living in a shed while they finish the house, so down to Rokewood to find a
bed and breakfast and something to eat—at the local pub, something that reminds me that
pubs are not our style. Food was OK, but took 40 minutes to arrive, by which time all our
clothing stank of tobacco. Took Chris back home, then in to the bed and breakfast,
“Whispering Gums” in Aitchison St., where the hosts (Bev and Jim; never found out
what their surname is) invited us in for a “glass of red” and a talk. Late to
bed.

Up correspondingly late this morning and in to get a breakfast from Bev, including duck
eggs (it seems that it's a legend that they have to be hard-boiled, as long as all parts are
a little cooked), and enough to feed an army. Then off to Chris' place and took a good look
around. It's a nice area, and one of the few places in Australia where you can ride around
freely (most of the area is forest), but despite the relative closeness of big cities (32 km
to Ballarat, about 110 line of sight to Melbourne CBD, and more like 50 to the outskirts), no
ADSL is available.

Chris had just received a letter from Telstra saying that, though the preliminary testing
had suggested that she could get ADSL, in-depth testing of the (newly installed) line had
shown that it was not possible. She could get satellite if she liked.

What a load of nonsense! As I see it, the terms have the following meanings:

Preliminary testing

Establishing whether the exchange has a DSLAM.

In-depth testing

Checking the cable record to calculate the theoretical
attenuation of the line in question, and whether it has a pair-gain system.

In Chris' case, the exchange is in
Corindhap, an estimated 7 km away. That's too far for Telstra's interpretation of ADSL
attenuation; they make a sharp cutoff at 4.1 km, as Internode's graph shows. Never
mind that the exchange almost certainly has an ADSL 2 DSLAM, but for political or marketing
reasons Telstra hasn't enabled it yet, and that ADSL 2 can reach significantly further than
ADSL. I wonder how many people are suffering because of this rigid policy.

Even these calculations are unnecessarily conservative, or Internode's graph is wrong. I
have seen an extract of the cable record check for my ADSL line, the summary is:

That's 566 metres longer than Telstra services. Looking at the end of the cable, it stops with
two 2 metre lengths of cable. That must be the box on the street. After that comes a 100m
length of cable to the house, a junction box and another 30 metres to my office. Assuming a
loss of 10 dB/km, that would add 0.13 dB, giving total cable losses of almost exactly 53
dB. This is surprisingly close to the 54 dB or so that my ADSL
modem typically reports. This gives a downstream margin
of 18 dB, which presumably would be enough for another 1.8 km or so (or 2.5 km with a low-loss
cable like the 64CPFUT at the top of my example). That alone would make 7 km, without
techniques such as ReADSL2. I
wonder why nobody is getting up and shouting about the situation. Maybe they are, and I just
haven't heard.

None of this means that Chris really can get ADSL, of course. But I have the
distinct feeling that Telstra has put the issue onto the “too hard” pile. As the
monopoly owner of Australia's “last mile” infrastructure, that's not good enough.
The very least they could have done would be to give a reason why their “in-depth
testing” revealed that she couldn't get ADSL.

Looked round the property and the house in the morning, then off on the long drive back
home. We must be crazy driving 1400 km for just a few hours' visit. After yesterday's
disaster with the sandwiches, bought some food at a “Subway”
outlet on the way out of Ballarat. I don't particularly like Subways, especially the way they
make them in Australia with tired, soggy bread, but the fact that they were only about the
same price as the sandwiches in Nhill yesterday makes it more understandable why they're
doing so well here.

Took a look around the countryside again, then for the fun of it left the main road
(Western Highway) at Horsham and took the road to Edenhope, Narracoorte and Padthaway. It's
amazing how little traffic there is off the main highways; between the outskirts of Horsham
and Narracoorte, about 150 km, I encountered about 20 cars, only two driving in my
direction.

Didn't do much today, mainly catching up after our trip in the last couple of weeks.

More on (moron?) thermometers

While in Germany, Yvonne bought some odds and ends that are difficult
to find here, including a meat thermometer. For years I've had a meat thermometer which you
stick into the meat, but in the course of those years it has acquired a coating that makes
it difficult to read. Similar thermometers are available in Australia, but they're made in
America, where they still use antiquated units of measure, and the adaptation to Celsius is
an afterthought, so the markings on the scale show temperatures like 54°, 65°, 71°, 77°, 83°
and 88°. The one Yvonne brought back was in Celsius, but it was obviously designed for
illiterates:

Presumably the illiterates know their farmyard animals, though. But I still can't guess
what some of the graduations on the scale mean, and the lack of display of low temperatures
makes me feel uncomfortable; how do I know that the thing isn't off by 10°?

The obvious choice would be a digital thermometer, but the only one I found had problems
with the temperature sensor: it was far too influenced by the surrounding temperature, so I
had to wrap an insulator around the exposed part. It also overheated and burnt out on one
experiment. Nevertheless, we found one at
IKEA on Thursday:

Peter Jones and some others are off to Brisbane for a demonstration tomorrow, so over to
Hahndorf to look at some last-minute details, none of which took very long, and I was out
again after little more than an hour.

In the afternoon, more work on web pages with PHP. Rasmus says it's just like C, but he's
wrong: the syntax looks very much like C, but the whole feel of the language is different,
and as a result debugging is very different. Also, the fact that it's basically a report
generator (the output is the most important thing) makes for a different interaction. Still,
by the end of the afternoon made significant progress with the most complicated of the
pages.

Finished my work on Peter Denton's laptop this morning, shut it down and tested a reboot.
I couldn't start X! Spent some time investigating, and decided that some of the ports
conflicts were the issue, so deleted and reinstalled X and KDE.

That in itself was an issue, because I didn't have both of the install CDs for FreeBSD 6.1-RELEASE. Started burning the second CD when it
occurred to me that I didn't need a CD at all; simply:

After reinstalling everything (in the case of KDE, this required the -f flag to
pkg_add, because there were different versions of MySQL), X still wouldn't
start: it turned out that I had installed the production xorg.conf file. Removing that
was enough: it seems that the real configuration file was in a different location, but that
the production one (/etc/X11/xorg.conf) was found first.

In the afternoon finally started catching up on other things. I really need to work
less.

Spent most of today looking at remote controls under FreeBSD. I have this remote
control that came with the DVICO tuner card; it's unclear what the real name is: the unit
itself bears the name “FusionREMOTE”, but the Linux dmesg output
states:

It's also not clear which letters are written in capitals and which in lower case; I've
also seen “DViCO” and possibly others.

I've already had considerable pain trying to get
lirc, the Linux Infrared Remote Control software,
to work. There's a partial port for it in the FreeBSD Ports Collection, so decided to play
around with that. Discovered that my particular remote control uses the HID (Human Interface
Device) interface, called /dev/usb/hiddev in Linux. The corresponding FreeBSD device
is /dev/uhid. Played around with uhidctl(1) and added a hex dump feature that
showed that repeated data sets the high-order bit of the (16 bit) data word:

The data is delivered in bits 1 to 7 from the left; the last 8 bits are always 0xfe.
Looking at the data in lircd.conf, this corresponds pretty well. Clearly this was the
down button:

begin codes
ok 0x5e
up 0x51
down 0x53
left 0x5B
right 0x5F
...

What about the kernel API? It's described in uhid(4) for FreeBSD. Linux doesn't
seem to have kernel man pages; instead, the interfaces are described in the directory
/usr/src/linux/Documentation, in this case in
/usr/src/linux/Documentation/usb/hiddev.txt. The interface is very different and I
spent some time looking at the LIRC code in daemon/hw_hiddev.c, where I found
obscenities like:

Round about here, I got sick of even looking. lirc has proven to be a real pain at
the best of times. Do I ignore the problem, fix it or write a different interface? Spent some
time thinking about that and came to the conclusion that I had to live with the problem, at
least in the short term, but boy, is that painful! This code also showed something that could
be a problem: Linux refers a struct hiddev_event with the members hid and
value. value is clearly the value displayed by usbhidctl, but I
don't see anything corresponding to the hid value of 0x10046. Where does
that come from?

After visiting Chris, we're wondering whether we shouldn't be considering moving house.
There's a lot of value tied up in this house, and we don't really need this big a property.
Chris paid only a fraction of the price for her land, and we could build a comfortable house
on land like that for about a quarter of what this house could bring. Had a couple of estate
agents in to evaluate it; they were so enthusiastic that I wonder why we're even considering
moving out.

lircd 0.7.2: unable to open '/dev/uhid': No such file or directory (2)

Why couldn't that be put in as well?

Presumably the “caught a signal” is lircd's own way of stopping (or
committing suicide). I didn't bother to fix that one.

In the process of testing this code, discovered another problem, not related to the
software: the DVICO remote control suffers from premature repetition. It's almost impossible
to press a button without repeating, and presumably it would blow the mind of the designer of
my brain-dead Motorola L6 mobile phone: during the time you have to hold down the
“off” button to turn on the phone, the remote control repeats 27 times. This
isn't a FreeBSD-related problem, nor an isolated case: it happens on both of the controls I
have, and on both FreeBSD and Linux. Ended up writing code to ignore the first two repeats,
which still makes it very responsive.

Next was to actually use the functionality with mplayer. That required going back to the
inaccurate, incorrect, incomplete and contradictory LIRC documentation. It seems I needed a
.lircrc file. Format? Who knows? I found multiple examples, but no documentation. One
of the examples was the DVICO/LIRC
HOWTO, which included a file which I copied as discussed. No reaction. Why? Well, an
obvious reason is that the button names mentioned in that file don't correspond to the button
names in the /etc/lircd.conf file. The format appears to be straightforward,
but who knows what gremlins lurk? Spent some time looking at that. The format of the file
appears to be (caution: once again this is an example, not the (missing) documentation):

begin
button = Right
prog = mplayer
config = pt_step 1
repeat = 0
end

Here the names on the right of the = sign are clearly strings. Right is
presumably intended to the name of the “right” button (called right in
my lircd.conf), mplayer the name of the program, pt_step 1 an entry
in the ~/.mplayer/input.conf file, and the parameter to repeat might mean
that further repeats of this button should be ignored (though in this case that seems a bad
choice).

This clearly gives me the option of controlling multiple programs from the same remote
control, a very useful function. But it also seems to imply that specific buttons relate to
specific programs, which is far less useful. The top of the control has four buttons marked
“DTV”, “MP3”, “DVD” and “CPF” (whatever that
may mean). Clearly the intention is to divert the functionality of the other buttons to one
of four programs. How do you do that? I don't know yet.

Over to Hahndorf for a project meeting this morning; our concerns of a couple of weeks ago look unfounded, and suddenly it's
“all systems go” again. Spent some time after the meeting looking at some issues
we have; our prototype machine is still running FreeBSD
5.4, and we have some ACPI issues that no longer exist under 6.1.

In the afternoon, back to the remote control stuff, and found yesterday's assumptions
confirmed, including the concerns: mplayer
reacts to the remote control even when it's iconified, so if you have multiple
mplayers running (something I do frequently), presumably all will react to the remote
controls. I need to look at doing something there. Also had permission problems with
lirc. By default, the socket is writable by root only:

It's not clear why mplayer needs to open this file with write permissions, but it
stops it from working. I also don't know wat /var/lirc/lircm is. Clearly it's been
there for a while, but I didn't mention any work on lirc on 23 August.

We're still thinking about moving house—but where to? Previously Yvonne has always wanted to be near a forest so that we could go riding
there, preferably without having to transport the horses. That was at least partially because
in those days we had trouble loading horses into floats, a problem that's long in the past.
And we find that, although part of Kuitpo forest is just down the road
from us, we prefer to transport the horses so that we don't always have to ride in the same
place.

So: where would be nice to live? It doesn't have to be as close to Adelaide as we are
here, but it would be nice not to be too far away, and of course it has to be less than 5 km
cable line from a telephone exchange. Today drove around the Fleurieu peninsula, down a back
road past Kuitpo Colony to Mount Compass, Victor Harbour and back via Yankalilla and Myponga.
Nice landscape, but nothing obviously desirable.

In the afternoon into Mount Barker to look at some display homes. Prices are quite
reasonable, but there's a lead time of over 12 months between signing a building contract and
moving in. That makes it much less attractive, and the salesman's “you can live in a
shed for the year” doesn't exactly fill me with enthusiasm.

More work on mplayer today, still trying to
get the on-screen display showing correct values. This time I was concentrating on getting
the total time correct; frequently it would show values less than half the correct value. I
had suspected some kind of overflow, but after tracing through some particularly emetic code,
found that the input stream was either supplying incorrect bit rate data, or was being
interpreted incorrectly. After that, found that it also gets reported accordingly on
mplayer startup. The values seem to have no relationship to the real information; do
they come from the stream, or is mplayer misinterpreting them? Here's what I get for
the Adelaide TV channels:

There seems to be no relationship between the bit rate and the resolution, and in addition
some “HD” streams are nothing of the sort. In many cases, the HDTV streams have a
slower specified bit rate than the normal resolution. Seven HDTV is a special case: it seems
to be very weak, and frequently enough I get nothing at all.

What does this mean for mplayer? Clearly it can't always relate on the specified or
calculated bit rate. I think the best choice would be to look at the file size and calculate
from there. That would also help where the timer wraps around in the middle.

Also did some work on our project; in this case, mplayer is reading from a pipe,
and we somehow need to find a way to get it to flush the pipe when it starts so that it's
showing current data and not the data that had collected in the pipe. That's straightforward
enough: a keyboard input would do it, but in our case it looks like we'll send the command
down another pipe:

The work we're doing on the black box prototype is more smoothing rough edges than genuine
development work; the latter is a separate branch. But it still means making changes to the
software, and we don't have any version control. I didn't realize how much that concerned me
until I woke up in the middle of the night worrying about it.

First thing in the morning I put it into CVS, the first time I've done this from scratch.
The CVS documentation doesn't make it easy: the canonical command is cvs import, but
as the name suggests, that assumes that it's an import from another tree, and it
insists on giving it a side branch. I couldn't find anything at all to tell me how to
create revision 1.1, the first revision in the trunk. Finally found a way, though I still
don't know if it's the best: import an empty directory as a new module, then add the source
files and cvs add them to the repository. I'm amazed how often even simple things
are difficult to find.

The work itself was relatively simple, apart from understanding why some problems were
occurring. That was sorted out by the evening, and tomorrow we'll test.

More work on mplayer status lines. Calculating the bit rate isn't nearly as easy as
I expected it to be.

VoIP for dummies

Avaya has recently published and distributed for free
two books
called “VoIP
Security for Dummies”
and “VoIP for
Dummies”, in that order. The idea sounds very good, and even the fact that they
have only 64 pages doesn't necessarily detract from them. I had both sent to me, and started
reading the first, not a thing that really concerns me. On Friday the second one arrived,
and today I tried to read it.

The “Dummies” book is different: it makes the others look good. It's obviously
intended as a sales vehicle, but after wading through half the book trying to find some
content which was neither uselessly fuzzy nor incorrect, I gave up, still not really
understanding what Avaya was trying to sell. A pity: the idea is good, and getting people up
to speed understanding VoIP would presumably help them sell things (though, since I don't
know what they're selling, I'm not sure). Here a couple of samples:

Page 9:

The VoIP protocols, or simply IP, as many have begun to call it for short, are
interoperable.

Page 10:

The IP telephone has a network interface card (NIC) built into it ... The NIC ... provides
the device with its physical address on the LAN.

To support IP telephony, a server with a MAC address is typically dedicated to load the
IPT software that is used to manage all the controls.

At no point in the above text does he mention IP addresses. They come later. But first:

One or more devices known as switches are installed around to form the core
infrastructure of the IP Telephone LAN.

If you plan to run IP Telephony with your computer data on the same LAN, make sure that
you use IPT compatible switches. As with any addressable device on the LAN, the switches
used must also be MAC-addressable.

This is, of course, nonsense. I am running two Sipura SPA3000s connected via a 10 Mb/s hub
(they're 10 Mb/s only devices) with no server software (because the Asterisk book wasn't good
enough to enable me to configure it properly). What the author is probably trying to say (and
my guess it's his poor understanding of what somebody else told him) is that QoS is
important, and switches should understand it. But that's just a guess. A fact is that up to
this point (bottom of page 11) there has been no mention of IP addresses. They come in the
middle of page 13:

Unlike the MAC addressing on the LAN side, VoIP traffic on the WAN side uses the IP
addressing scheme.

When the packets arrive at the destination LAN, the edge device breaks down the VoIP
packets and forwards them to the server that manages the IP Telephony services on the LAN.
From this point, the rest of the process is similar to IP Telephony services.

Huh? This is supposed to be an IP Telephony service.

So maybe the intention of the book is to sell Avaya's services, not explain IP telephony
in detail. But this level of inaccuracy leaves me wondering if anybody at Avaya knows what
they're talking about. What should have been a good advertisement for them proves to be a
complete fiasco. They should change the title to “VoIP by dummies”.

More work on the black box prototype today. I had not realized how much progress we have
made in the last few months. This machine is at the status of early July, and I ran into all
sorts of unexpected problems when making only minor changes.

How do you get mplayer to catch up with an
input stream? You can create a command pipe with input file=/pipename, but if
you send a seek beyond the end of the current input stream, it hangs for a while and then
crashes. In our prototype, that then brings down the entire application. Spent some time
trying various options, but didn't find a solution.

More work on the prototype today, and managed to fix most of the problems that we ran into
today. I still don't understand why I can't run it under the debugger: it reads from the
parallel port, and for some reason the program gets a SIGBUS on the read instruction (in
(%dx),%al). Is this a debugger bug?

Another estate agent came around today with a valuation. Not nearly as good as we had
hoped; looks like we'll be staying here after all, unless another one comes round with a
silver bullet.

Fluffy has been staying away from home for a couple of
days now. That's normal enough in this hot weather, but today she returned in a very sick
state; we first thought she had been bitten by a snake. Yvonne took
her to the vets, where Ashley found fluid in the lungs and an elevated temperature, and put
her on a drip. He's not really sure what it is, but suspects an allergy. First time I've
heard of serious allergic reactions in cats.

There's a couple of ones in the last photo that look like a pair of eyes with nothing
else. For scale: the red ribs of the filter are about 0.9 mm thick.

Spent the morning investigating the PVR250 port; there's a lot of work needed there.

Didn't finish that before I had to go the Annual General Meeting of the ICT Council for South Australia, during which we
elected a new Board of Management. Neither David Raffen, the incumbent chairman, nor Adrian
de Brenni, one of the vice-chairs, contested the election, and we had fewer candidates than
positions available. The new chairman is Dean Littlefield, who has only been on the board a
few months. Clearly changes are on the way.