Five years ago today I officially retired. Time has
flown! And of course my lifestyle has changed considerably—for the better, I'd say. It's
not so much what I'm doing as how I'm doing it: now I do what I want to do, in my own time.
If I don't want to do something, I can refuse. During my working life I didn't have that
luxury.

And, gradually, it seems that I'm living the same kind of life I did before I started
working for a living. Earlier this year I typed in the remainder of my diary for 1967. Apart from the obvious difference in experience, and
the rather painful events I documented as a result, I'm doing much the same now as then.
I'm enjoying it.

When I was younger, people talked of old age (itself a changing term) as a return to
childhood. I don't know what exactly they meant, but I was left with an impression of
declining intelligence and childlike behaviour, specifically that of children under 10.
That may come, but it's not what I'm seeing now: it's more a return to normal after having
to do somebody else's will for a third of a century. To misquoteSomerset Maugham, work is a very
dull, dreary affair, and my advice to you is to have nothing whatsoever to do with it.

Coincidentally, this month includes a number of life-changing anniversaries, this year
neatly laid out in a 5 and 15 year framework. For
once in reverse order:

5 years ago today I retired.

15 years ago, on 18 July 1997, we moved into Wantadilla, also marking the end of a 3 month move of domicile
from Germany to Australia.

45 years ago I was towards the end of a 3 month move of domicile
from Malaysia to Germany.

50 years ago I took not one, but two scholarship exams for King's College Taunton: one for academic
performance, the other for music. I didn't get either scholarship, but I did get what
they call an “exhibition”, something like a second rate scholarship, for both. I think
I was the only person to manage that, and it seems that it's indicative of me: jack of
all trades, master of none.

In this month 55 years ago I returned to Australia after spending the previous 3 years
in Malaya and
subsequently a trip round the world.

More playing around with yesterday's photos today. I still can't work out why those two
panoramas didn't automatically align correctly, but found that a couple could do with
significant improvement. Here before and after, with mouseover
alternation:

In this image, flare is clearly visible round the door of the shed at the right. Flare in
the images is still an issue, made considerably more difficult by the fact that it's almost
invisible in the viewfinder.

It's clear that my lazy load code still leaves a lot to be desired. While looking at the
issues, discovered that the pages I am now generating severely upset the W3 validator, in particular the data-original attribute.

I'm not sure how to handle this. On the one hand, HTML prescribes specific attributes for
each tag, and others aren't allowed. On the other hand, JavaScript not only allows them: it
appears to make sense. To find out how to resolve the issue, I at least need to learn more
about JavaScript
and jQuery. Tried that and decided that
my own PHP functions were too untidy, and spent some time trying to make them easier to
understand. The untidiness didn't help, and I didn't get finished.

One of my continual rants about the “Microsoft space” is that the file system hierarchy has
been chopped apart and pasted onto windows. How do I find the window? Simple, it's on the
screen in front of you. Oh, it isn't? Well, we have nifty search tools for you that will
find all files matching specific broad attributes within a matter of minutes.

Today I had the issue: I wanted to scan something, for which I currently still need to
use pain, my Microsoft laptop. After installation it came with a popup asking me
where to store the image. A while back, that got on my nerves, so I disabled it. Now I
can't find the scanned files! And I can't find a way to reenable the popup either.

Still, there are those nifty search tools. I had just scanned in the image, so I wanted to
tell it to search only for things updated in the past 5 minutes (-mmin 5
in find terminology). But no, windows don't work that way. You get the choice the
programmer thought of: last week, last month, last year, or any. OK, off I went looking for
documents. After only a few minutes, it found it:

But "C:\Documents and Settings\groggy\img009.tif" didn't exist. Of course not!
That's only part of the pathname. Why should I get it all, even though there's space for
it? That would be too simple. Yes, there's a specialist option View → Details, but
not only is it not default, it has to be set every time.

OK, this is only partly Microsoft's fault. It should show in the scanner application. But
somehow it's all symptomatic of an attitude that, like a stone in a shoe, irritates more
every time I encounter it.

So what was the problem? Restarted postfix. No change. Reloaded named. No
change. Only when I stopped and restarted named did things work again. What a bind!

Looking at the logs, this happened some time between 17:44:19 and 19:26:26. What happened
in that time (apart from this problem, of course)? Nothing. This is hardly a heavily
loaded server, and we were eating and watching TV. I'm baffled.

Why localhost in the first place? Like most ISPs, Internode blocks outgoing port 25 (SMTP). So I have set up a tunnel, and I send mail
to its port on localhost.

Into the office this morning to discover my backup disk LED flashing. After further
investigation discovered that the monthly level 0 dump was still running after 11 hours.
And still further investigation showed:

Normally it takes about 4 hours to do the level 0 dump. Now it was less than half way
through. Clearly it made sense to restart the backup. But why does it occasionally show up
as a 1 MB/s device? I don't know, but on detaching the disk and reattaching it, it was
still 1 MB/s. After power cycling the drive, it was recognized correctly. But that could
be a coincidence, like so many things I find with USB.

Is this USB, is this my motherboard, or is it FreeBSD? Possibly a little of everything. But FreeBSD has the great advantage of
telling you what's going on. With commercial desktop operating systems, you don't know.

I back up my photo disk separately from other data. There's lots of it, it's
incompressible, and it makes sense to have a mountable file system. I keep two copies, one
of which is always at Chris Yeardley's house in case of larger catastrophe. One of the
disks has a USB enclosure; the other had one until it died (under warranty) last year, and
MSY still haven't managed to replace it. Today
I mounted the disk with the enclosure on lagoon, Yvonne's computer, using USB. Bad idea—see previous article. Something went wrong:

This write error is understandable: it's trying to write to offset 712 TB from the beginning
of the disk, and the disk is “only” 2 TB in size. That indicates some kind of file system
corruption, so umounted it and tried fsck, which confirmed my fears:

At the end, the file system was “clean”, but the damage was so massive that I went at it
again—and found more errors. lost+found was 11 GB in size.

Normally I keep the file systems in sync with rsync, which could handle this kind of structural damage, but not holes in the
files themselves: normally, if they have the same size and the same modification
timestamps, rsync considers them identical without checking. There is an option to
check, but that doesn't make sense: it requires more I/O than just rewriting the file
system, especially since I have two almost complete copies of the data. So that's what I
did: new file system, and start all over again. This time I did the logical thing and
connected the disk to defake
via eSATA, which I should have been doing
all the time. But there's something like 1.3 TB of data, and I only have a 100 Mb/s
Ethernet connection between dereel and defake, so by evening I only had a
small fraction copied.

That etymology is supposed to be in a Greek font, but only the π in the second word is
correct. The rest looks nothing like Greek.

I've seen this before, and I assumed that it's incorrect fonts that are the problem. But
how do you investigate this kind of problem? This happens on teevee (my TV projector
machine) and defake. On dereel it's almost right:

What's causing the difference? Callum Gibson suggested that it was firefox's settings, a can of worms in
themselves. “Allow pages to choose their own fonts, instead of my selections above”? That
doesn't really make sense, since my selections don't include any of what are obviously two
different font sets. But nowadays things don't need to make sense, so I tried it anyway.
It turned out that defake had allowed it, and dereel had not. What happens
when you change it? On defake, it fixedworked around the problem:

But on dereel, enabling font selection made no difference whatsoever. OK, that's an
older version of firefox, but the difference in behaviour is remarkable.

So I'm left with two issues: what fonts is the page selecting, and why is the Greek version
selecting two different font sets? The latter's easy to determine, and would have been even
easier if “view page source” would work for this page. For some reason it doesn't, and I
had to save the page to disk. Then I discovered:

So the quotes are enclosed in a polytonic class span, whatever that may be. And
clearly that chooses different fonts. I don't think I want to know.

But what were the fonts that were chosen? I guessed
at Syriac, but that needed clarification.
It seems that there are very few tools to help with this sort of thing. With Callum
Gibson's help, went looking at parts of X that I
haven't looked at in over 20 years. They haven't improved. The obvious way to find the
fonts I had referenced was with find to look at font files that had been accessed in the previous 10 minutes:

Not very friendly? -fa makes up for that in modern fashion by not complaining and
just displaying a completely unrelated default font (Bitstream Vera Sans-12). The thing is
that you first need to find out what the internal font name is. It's not just the file
name, not even after you've stripped off extensions and things. The only way I found, and
it's a real pain, is to get fc-list to list the fonts and then look for likely
looking things:

But that looks like a perfectly normal ISO
8859-1 character set! It took a while and some nudging from Callum to discover that
there are more pages (indicated at least by the active Next button), and page 4
showed:

Bingo! These fonts cover the range 0x300 to 0x3ff. In UTF-8, those are the code
pages for combining
characters (0x300 to 0x37f and Greek (0x380 to 0x3ff). Syriac is in the
range 0x700 to 0x73f. This font does include glyphs in that range, but
it's spamming the Greek alphabet range too. Now to find out where it comes from.

This evening Jashank Jeremy pointed me to a HTML5 working draft titled “Embedding custom non-visible data with the data-*
attributes”. That looks surprisingly like what I'm already doing with the lazy loading code I'm working on at the moment. As I thought, it seems to be a
good idea. And it seems that it works already, so there's no reason not to accept something
like that, even if the naming restrictions seem a little bizarre.

I've seen that before, and I've
blamed NFS. But looking more
carefully, this is tar x (extraction, as the leading x shows). And
of course there were no permission problems. What's causing this? In any case, it required
me to continue with rsync. And then I
discovered:

The disks are the same sizes, and until recreating the file system on /photobackup,
so were the file systems. I got the parameters for creating the file system from dumpfs
-m /dev/ada0p1, which should have given me the newfs command line to recreate
the file system. But it just gave me defaults. Damn! Now I have to start all over again.
But it doesn't have to be immediately; the backup disk won't fill up for another 6 or 12
months. In the meantime, I can do some more thorough integrity checks on the other disk.

The whole thing makes it clear, though, that I finally need to complete my migration
to 64 bit. It shouldn't be that difficult, but I don't want to run into trouble down the
road where I can't get back to run some software I need. So I need to run both for a while,
something I've frequently done in the past. Does x2x still work? Yes, sort of. They've
removed the -south and -north attributes, but I didqn't use them anyway,
and the rest is OK. So I'll migrate to a two-machine system again at least until everything
I want works under 64 bits.

Somehow I'm spending all my time with my computers again. It wasn't supposed to be like
that, but it's warmer in my office than out in the garden. Today was a little better; it
seems that sunshine is more of an incentive than temperature. Managed to get most of the
old cannas cut down before my
motivation subsided.

Over to the Yeardleys' for dinner tonight. David, Tuyết and Minh Chau are off again
tomorrow morning, and we probably won't see them until the New Year again. Sweet and sour
fish, some of the fish David brought with him from the Queensland coast, where he's
currently working.

Peter Jeremy posted a link to a survey about political opinions on Facebook today. I've done it before, once in the current
form and once in something very similar that I did in a management training course in late
1986. In each case I came out consistently as economically left and libertarian, somewhere
near Mohandas Gandhi. To my
surprise, though, most of the people on IRC who divulged their results ended up very close.
Is that why we tend to agree on a lot of things?

The other thing that surprised me was the grouping of modern politicians:

Asked them to talk to us before entering the property, to which they agreed. But they
didn't come today: they spent all day cutting down a few trees and branches on the 500 m
stretch of Kleins Road. 3 of them. I would have expected that to take an hour or so.

Today marks 14 months since I started planning to
upgrade dereel, my main system, to a 64 bit version of FreeBSD. During that time I've always found reasons to
procrastinate: the pain of migration is just too much, and it would be difficult to move
back if something goes catastrophically wrong. But I've gradually come round to the idea of
running a 32 bit machine and a 64 bit machine in parallel until it's done. And today I
finally took the plunge, in the process taking both machines out into the garage and
dislodging prodigious quantities of dust with a jet of compressed air. I had two
machines: dereel, 4 processors, 6 GB of memory (of which I could only use 3), with
two dual graphics cards to drive four monitors:

The other is defake, a much older single processor machine that I used to drive my TV
projector until a PowerCor voltage surge
killed the USB bus (despite the “protection” of a UPS). Interestingly, it has the same
processor frequency:

The first step was to set up X running on defake, still on the old machine. I
couldn't load the display card driver. It claimed an invalid object file format, which made
no sense. The messages in the system log were clearer:

So the driver was out of date. Why? It proved to date from January, and I had updated all
ports several times since then. It looks as if some dependency information is missing.

After that I didn't have much trouble except for difficulties getting the second graphics
card to work, the one I was given some months back. After a fair amount of experimentation
came to the conclusion that it's dead.

Next step was to swap the system disks in the machines, thus effectively changing their
identities. In the process, I also renamed defake to eureka, a name I had
reserved for this possibility 5 years ago. It wasn't as bad as I thought, right? Maybe
not. If anything, it was worse. It didn't help, of course, that I shut the machines down
before adjusting the /etc/fstab files. But I couldn't boot the new dereel at
all: the loader couldn't find the kernel.

The problem lies at least in the way FreeBSD boots. The first step (in this case, anyway)
is that the BIOS locates the bootable partition in
the MBR and loads a bootstrap
from that. In the case of BSD, this partition will be a BSD slice with potentially a number
of BSD partitions inside. The bootstrap then locates the loader, which reads a number of
configuration files, notably /boot/loader.conf, and decides where to find things.

But at every step the naming is different. After reading the man page boot(8), I'm not
convinced of anything except that the page needs revision. BIOSes talk of C:
and D:, loader talks of disk1s1a, and the kernel has a plethora of names and
numbering schemes depending on interface and disk driver. Finally I discovered
that disk1s1a was the second disk (I had some recollection that the numbering started
with 1, not 0), and I couldn't reset the loader to try disk0 once it was booted. To add to
the confusion, once I got it booted, it didn't run the siis driver, which would
have called the system disk something like ada0, though it was loaded; instead it
came up as /dev/ad4. Modified the fstab accordingly; I'll check later what
went wrong.

Once I got the systems up and running, there was a plethora of strangenesses. Some, like
changes in configuration, were clear; others were very puzzling:

The keyboard map ended up for my Sun Type 7 keyboard being different from what it was
on dereel. In particular, I still have to run xmodmap twice, but the
resultant behaviour is different. And on defake I could switch to vtys
with Ctrl-Alt-F1 to Ctrl-Alt-F8, but only the
ones marked like that above the main keyboard, though they're bound to F21
to F28. Now the keyboard map seems to have noticed that. This is part of a
general issue with xmodmap.

I thought that Emacs didn't work, but I discovered that the window manager opened
it off the screen. Specifically, the command was:

That should create a window at the top of the display with the right-hand side 53 pixels
from the edge. Instead, it was positioned way off the right of the screen. Changing
the font allowed a small part of the window to appear on the screen.

Where's the problem? A bit of searching showed that it was the Emacs executable.
Other versions of Emacs worked fine. Rebuilding from the latest port didn't
help. Built Emacs version 21 for comparison. That worked fine and also used the
fonts I wanted, which I had set somewhere (.Xdefaults?) years ago, but
which now are no longer respected. Tried version 22, but that doesn't build. What a
mess!

xtset, a program I picked up literally decades ago, displays different texts. I
put it in the Ports Collection over 10 years ago, and it hasn't been updated since. So
what has changed? My configuration?

I've had a binary of kklondike, a solitaire game that used to be in the standard
X distribution, for years, and I've hacked it a bit. It no longer builds, and there are
lots of missing libraries. A similar situation exists for my version of xearth,
which I hacked 16 years ago and for which I have lost the sources. Yes, I can install
all the old 32 bit libraries, and maybe I should, but there's also the option of linking
them statically so the problems won't happen again.

That's just the tip of the iceberg, of course. My weather station software isn't running, I
don't have backups set up, there are lots of programs, such as wine and VirtualBox, that need to be configured. It'll keep me busy for some time to
come. But at least my photo software appears to work.

On with my migration to FreeBSDamd64
today. A couple of mount problems on other machines because I had moved the file
systems /src and /Photos from dereel to eureka, but nothing
serious. The real problem was the weather software: it needed recompilation, after which it
ran for a while. And then, after some other tweaks, it failed with a missing MySQL library. I had to compile it again. Where did the
library go?

But that wasn't the end of it. The weather station connects via USB, and the USB bus
on dereel is dead. So I had to move the database to eureka. And then the web
database functionality on dereel no longer worked. Yes, I could have changed the
access parameters, but I'm planning to move the web server anyway, so it seems
counterproductive. Until I do, neither my local database stuff nor the weather station
display will work.

Apart from that, tried something that I have been meaning to do for a long time: coalescing
monitors into a single display. The old way to do that was
with Xinerama, which I never used
because my monitors all had different resolutions. Then it seems
that xrandr was the way to go. But now
there's TwinView for
nVidia cards, which I have, so on the
recommendation of Callum Gibson tried that.

The instructions say to run nvidia-xconfig --twinview, which takes the current X
configuration file and converts it to a TwinView-compatible file. But it does it in a way
that completely obfuscates the changes:

199 lines of diffs! And where did those comments come from? They're mine, alright,
but they weren't there in the original. Spent some time with ktrace to find out what
it had done, but finally discovered it had collected all my carefully placed comments in the
file and moved them to the top. Is this another variation on the sin of reverse chronologism?

Finally found what real changes had been made. Only the ones described in the instructions.
Add the lines:

I have two cards with 4 monitors, but I only wanted one pair to have the double display (a
7680×1080 display would really look rather silly). Did it work? Yes. And it does exactly
what you'd expect. The question is only whether it really makes sense. It's going to be
good for running Hugin, where I
often need to have both the preview window and the mask window visible at the same time.
They both need to be on the same display, so this will give me the horizontal space I need.
But for the rest of the time it doesn't seem to be very useful. Many programs position
windows in the centre of the screen; when I started, xearth was split across the two
monitors roughly along the San
Andreas Fault, and others bring up menus in exactly the same place. So I think I'll
revert to separate displays and start a second X server with fewer displays—once I work out
how to reenable display switching again.

Also tried out Hugin with my new memory limits. Not a success. My verandah panorama
from last weekend was detected with a maximum error of 373.0 and an average error of 6.0, up
from 5.4 and 1.8 respectively when I did it on dereel last week. When I loaded the
project file and tried to stitch, nona kept crashing with
SIGBUS, something I almost never saw on i386. Is this a difference
between i386 (SIGSEGV) and amd64? In any case, I'm far from
having things running normally. It certainly vindicates not only my two-machine approach,
but also my reluctance to migrate.

The tree cutters have been active in Kleins Road for the last 3 days. Today I took another
look and discovered that they had cut down two more trees, a wattle and a eucalyptus that I
had been rather fond of:

But it seems they had been slated for removal too, and the people here today were just
tidying up, converting the things into mulch. They really could have discussed the thing
with me first. On the positive side, we got the mulch, probably about $200 worth. But
then, they were our trees.

On with the migration to FreeBSDamd64 (64 bit version) today. It wasn't easy. I had expected the transition
not to be smooth, but I had never expected it to be this bad.

Much of it was related to photo processing, the reason that I started the migration in the
first place. I had noticed that the 64 bit version of Hugin had problems that didn't occur on the
32 bit version, and sent mail to the mailing list. One of the
replies suggested that this is a known issue that also occurs on Mac OS X, so maybe
something will come of that.

But there were other issues. I took my weekly panoramas today, because the weather was
suitable, and even reading the images into the computer was a problem:

How could that ever have worked? But it seems it has done for a year and a half. And under
the present circumstances, it's not the first thing I would look for. That was simple
enough, but when running another script, which calls PHP
functions, I got a message

Fatal error: Directive 'register_long_arrays' is no longer available in PHP in Unknown on line 0

Deprecated: Function ereg() is deprecated in /home/grog/public_html/php/includes/onephoto.php on line 456

Now what's so dangerous about using POSIX regular expressions? But clearly I needed to heed
the prayers of those who know better and convert to Perl regular expressions. The
documentation of ereg and preg_match was sufficiently different in style that I got the impression
that return value in the third parameter was different, but it seems that was a
misunderstanding. In the end, discovered that this Emacs command (using different regular
expressions again) would do the conversion, at least for my relatively simple regular
expressions:

I chose ~ as a delimiter simply because I then didn't need to worry about
conflicts.

Finally I got as far as trying to stitch today's panoramas. Again the verandah centre had
very poor results with panomatic, so I tried the new cpfind program. It
crashed and conveniently shut the log window before I could get a chance to read it. How I
wish Hugin would store the log file somewhere where it can be examined. I'll look at
that later. Finally, however, I had a fast panorama preview window with something that
didn't look too bad—and discovered that the move controls didn't work.

Back to running on dereel. Got to the fast panorama preview and... the move controls
didn't work. It looks as if this is a problem with the X server. OK, I wanted to get the X
server working on dereel as well, so attended to that. It now had only the
display chip on the motherboard, but that's an nVidia chip as well. But when I configured X, it came up with the free nv
driver, which is amazingly restrictive: it couldn't even find a mode line for 1920x1080, the
resolution of the display. When I tried to use the proprietary nvidia driver, the
one I've been using for years, I once again got the message:

I know I didn't link the module statically into the kernel, so this suggests to me that the
module didn't tidy up behind it on the last reload. When I have time to reboot the system,
I'll try again. And maybe the error message from the driver is really trying to tell me
that it doesn't support this particular chipset. Another thing to investigate.

OK, so back to the nv module. How do I get a mode line for that? Decades ago I
wrote a detailed description of how to do this, which later found its way into The Complete FreeBSD, but nowadays it should be easier. There's xvidtune for
that. Or is there? Looking on eureka, I couldn't find it, and it seems that the
port has been removed. Why? No time to look now; I had a copy on dereel. But it
says:

=== root@dereel (/dev/pts/1)/boot/kernel32 -> xvidtunePlease install the program before using

What does that mean? No idea. Tried a few alternatives and finally gave up. Still, at a
pinch I can make do with this ugly 1280x1024 screen that it gave me. Well, no:

So I'm stuck. I can't run Hugin on eureka because of bugs. I can't
run Hugin on dereel and display on eureka because I can't move the
images in the fast panorama preview. And I can't run Hugin natively on dereel
because I can't get X to run properly. What a pain! I had expected problems, but nothing
like this many.

Out of desperation, tried running on dereel and displaying on lagoon,
Yvonne's computer. That worked. But it's complicated and
slow, and Yvonne would have a word or two to say about tying up her computer for hours at a
time.

In the evening, while waiting for Yvonne in the lounge room, tried running things
on teevee, the projector driver. And again I couldn't move the image in the move
tab. It wasn't until later that I realized that this is another amd64 machine.
What is it about that that triggers the problem?

Other strangenesses

As if that wasn't enough, there were various other things that happened that don't appear to
be directly related to the upgrade. Every time I saved my diary notes in Emacs, it
got displayed on the neighbouring firefox. There's no obvious connection between the
two, and the key bindings haven't changed. Closing the file and reopening it stopped the
problem.

Woke up this morning to find a mild frost. The weather station showed a minimum of -0.2°,
and some areas of the garden had frost on them. But most of the water areas didn't, only a
little on the small bird bath in the Japanese Garden:

It certainly looks interesting, especially since we normally fry the eggs in rings to keep
them together. But it's difficult to cut the slices accurately enough to stop the white
getting out underneath, and the taste wasn't convincing: the capsicum is too sweet. We
considered trying again with green capsicum, but I don't see that being much better a match.
Nice idea, but no cigar.

So I more or less have FreeBSDamd64 running, but there are significant problems with Hugin, compounded by compatibility problems
running the nvidia driver
on dereel. After doing a couple of panoramas on Yvonne's machine lagoon, realized that I had a laptop with functional X on the desk to
the right in my office. It is usually called pain when it runs Microsoft, but it
also has a FreeBSD system, eucla, on the disk, so booted that, and sure enough, it
worked.

Problems: tiny 1024×768 display, and also the confusing names. I now have
systems eureka (main machine) and eucla (laptop), not to mention the
old echunga. At least I never had an echuca. But the similarity of the names
is confusing, and I managed to update the wrong /etc/fstab. I didn't notice it at
first, until I tried to do another panorama and got:

Yup, both on /Photos. It took me a while to look at the first column: one was
mounted directly, one via NFS. I wish the system wouldn't allow that.

And then I got a reply to my
message to the Hugin mailing list, referring to a bug report on the subject of
inability to move in the move tab. It seems that by holding down the middle button, it will
work. And currently the bug report is marked “will not fix”, blaming the window manager
(fluxbox in the bug report, and my case
fvwm2) for the problem. That seems
unlikely, but I do have an issue with moving windows. I have this bound
to Shift-Meta-Button 3. Under i386, you hold down the key and
drag the window. But this no longer works. Instead I have to click and release the button,
and then I can move the window, and again click a button when I'm done. I had thought it
was a configuration issue that I had intended to look at later, but potentially it's
related.

So once again I tried running Hugin on dereel and displaying on eureka.
And panomatic got stuck in a loop, and the control point windows didn't display any
text! While wondering about that, managed to provoke a debilitating bug that I had hoped I
had left behind me: the mouse cursor got stuck between two screens, jumping back and
forward. I haven't found a way to get out of that one: I had to stop X and restart it. But
I couldn't restart X. In the end, gave it up as a bad job and rebooted. And then I could
start X, but I didn't have a mouse. It produced some error messages that I didn't write
down, something to do with the device being open by some other process. But on a second
attempt, it worked. That's pretty much what I saw on Wednesday, but didn't write down. Is this a general problem? I don't have the
strength to try it again. I just want things to work again.

While I was rebooting eureka, also rebooted dereel to put in an nVidia PCI
card that I had found lying around. Bad idea. Once again I couldn't boot; somehow my boot
configuration got messed up since I last booted. Somehow nothing at all is going smoothly,
though I suspect some of it is my own fault.

As if that wasn't bad enough, I discovered that cvr2, the MythTV box, had somehow lost its default route and not
updated the programme info. I can't see that that can be related to the other problems,
since neither dereel nor eureka are involved in network routing. It must be
the phase of the moon.

After the double reboot, at least I can now display the Hugin screens
on eureka, and I confirmed that the trick with the two mouse buttons works. Spent
some time investigating the strange behaviour of panomatic, which seems
non-deterministic. In one case I found that it had put control points nowhere near each
other (for example, one at the top of the image, the other at the bottom):

Not only that: it claimed that the control points were very close to each other. For
control point 0 (in the middle in the first image, at the bottom in the second) it claims a
distance of only 0.66 pixels. What has gone wrong there? When I tried again, I didn't get
the same results. Still, this is an out-of-date version of Hugin. First I need to
try with the latest version.

Spent nearly all day trying to get Hugin to work, with only moderate progress. The first issue was to install
the latest version of Hugin, so checked that out and once again ran into this problem
with tclap, compounded by the
problem that I didn't understand where cmake was looking for the files. In the end
gave up and unpacked them into /usr/include/tclap, a suboptimal place. But at least
it should keep the builds quiet until I get it right. There is also a new dependency on
SWIG, which was relatively trivial to fix.

After that, tried again. No change. The first problem was just finding out
why cpfind crashed: it logged to a window that disappeared as soon as it crashed, so
there was no way to know what went wrong. ktrace had showed me some of what was
going on, including that the messages were written to stdout, so took a look at the
code, and found the main function
in hugin-2011.4.0/src/hugin_cpfind/cpfind/main.cpp. I've lost all liking
for C++, but fortunately you can write C code
and get it to work, so wrote this kludge:

It took me quite some time to realize that these parameters are incorrect. They're right
for panomatic, but not for cpfind. I couldn't find what the right parameters
are for cpfind, and I couldn't find where to set them in the preferences, though I
was sure they were there before. I got them implicitly by resetting the control point
detectors to defaults. After that, it ran, found a very good match (better than the 32 bit
panomatic), and I found:

Later Terry Duell on the mailing list pointed me to the Edit button in the
preferences, where you can set the parameters to be handed to the control point detector.
Inspection shows that the correct parameters for cpfind are:

-o %o --multirow %s

While for panomatic it's:

-o %o %i

But clearly the values weren't correct in the first place. There are a number of issues
here:

It's very difficult to get these programs to log their information. Yes, they show it
in a window on-screen, and in many cases if they crash—but only then—offer to save it
somewhere. Wouldn't it be so much easier to do it the other way round?

Knowing the correct parameters for the programs isn't easy. There should be a better
way to set them. Currently it seems that they're read from the file ~/.hugin, so
if that's corrupted there's nothing you can do except follow the recommendations given
at startup:

The results of cpfind with yesterdays “house looking south” panorama were very good,
better than I had had with panomatic in 32 bit mode, nona didn't crash, and I
got a good result. So I tried again with the “verandah centre” panorama. Not good:

Once again I got lots of spurious control points between different parts of the same image,
and they were by far the worst matches, up to 693 pixels apart. It had turned a number of
images on their side, like this one:

It wasn't the multirow attribute, which seems to be set whether or not you ask for
multirow. I tried removing all the control points attached to only one image, and I got a
better result, but still unacceptable.

Another issue is still moving in the fast panorama preview window. The bug report refers to a debug build,
so tried that:

One of the alternate possibilities I had while trying to solve the Hugin problem was to run the 32 bit binaries
on eureka. For that, of course, you need the libraries, and they need to be located
with ldconfig. Tried that, and for some reason it refused to accept the
library /dereel/usr/local/lib/hugin:

There's not much difference, but it's significant. At first I thought the hexagonal nut was
a disadvantage compared to the D ring on the old one, but this proved not to be the case: it
requires a spanner, but it makes it easier to tighten the nut. By contrast, the D ring is
difficult to grasp, and it has already bent because of the tightening needed. And somehow
the arrangement of the padding on the other side means that it slips less. It's the same
kind of padding, so maybe the fact that the pads are smaller enables them to grip better.
In any case, it looks as if I won't need to glue it, so I've ordered another.

On with my various experiments with the FreeBSDamd64 migration today. The biggest discovery was how to find 32 bit shared
libraries. I had already discovered that ldconfig ignores files with specific names,
but that appears to be a bug in ldconfig. In any case, using the old (probably
“deprecated”) environment
variable LD_32_LIBRARY_PATH works, so now I can run all my old 32 bit programs
like kklondike and my version of xearth.

More
importantly, though, I can run the 32 bit versions of the Hugin programs. Did a lot of
experimentation, including running hugin-i386. That worked, but it wasn't able to
load the fonts:

Still, detecting the control points with panomatic-i386 was successful, and the
panorama looked OK. Saved the project, started 64 bit Hugin with the same
parameters, and it still looked OK. Ran Align again, using 64 bit panomatic,
and it broke it again. Somehow I'm not getting much further. Saved the project files for
32 bit and 64 bit detection for further reference. They're very
different, but nothing reaches out and grabs me.

On the positive side, took some time to get the web server and mail running. And once again
I had lots of changes to make in my PHP code
because they don't want POSIX regular expressions any more. By comparison, getting mail up
and running was easy.

We've been here 5 years already! How time flies. I was
thinking of taking some photos to show how things have changed in that time, but I've
already done that to death with the photos, notably the ones I took earlier in the year. Still, it's been quite a time,
and we're feeling comfortable now.

Continued trying to get Hugin working on FreeBSDamd64 today, and
with the help of the mailing lists finally made the breakthrough. The original problems
(mainly crashing) have gone away. The single row panoramas that I had tried had worked, and
the only problem I had was with the “verandah centre” panorama.

While looking around, discovered that there is, indeed, good documentation for the control
point detectors, where you'd expect it: Help. It fires up a web browser (how does it
know which one?) with relatively complete documentation of the parameters, including the information
for cpfind that should use the --multirow option unless you're doing big
panoramas. It seems to have nothing to do with multirow panoramas.

The other information was about the really bad control points on the same image. They're
not a bug: they're a feature, something called vertical line control points, as the control
point view of the south view panoram show.
That also explains why the error was so small. But clearly something went wrong with the
verandah centre panorama. You can switch off the line detection
in Preferences/Assistant, so tried that and got good results.

Why did the vertical line detection fail so badly? Probably because none of the images were
taken pointing horizontally. The lower row was pointing at the floorboards, and it seems
that linefind took them to be vertical, giving rise to this kind of misdetection:

Another issue I had with Hugin was the inability to drag the image in the fast preview Move tab. I had heard that
it was a window manager bug, but that seemed
unlikely. Still, it was worth checking, especially since there's an outstanding bug report against fluxbox reporting output from xev. I was able to reproduce it here with the 64 bit
version of fvwm2. Without a window
manager, or with the 32 bit version of fvwm2, a mouse click and release give the
following events:

This is very close to the bug report, and it correlates directly both with the inability to
move in the fast panorama Move tab and the strange methods I need to move windows
with the window manager. So for the time being I'm staying with the 32 bit version.

One of the reasons I wanted to move to FreeBSDamd64 was to have enough memory to run VirtualBox machines big enough for programs like DxO Optics “Pro”. Up to
now the biggest memory I could get for smart, a Microsoft XP image, was about 800 MB.
Today I tried again, once again running into problems with out of date drivers—why
doesn't portupgrade upgrade them? But apart from that, everything went smoothly, and
I was able to get up to 3.5 GB of memory. Installed the latest version of DxO and ran it.
How much faster? The old machine has a 2.8 GHz Pentium D with 2 GB of memory. smart
now has 3 Phenom 9550 CPUs with 3.5 GB of RAM. According to cpubenchmark.net, the Pentium D has a PassMark performance of 1,300, while the
Phenom has a PassMark of 2,536, pretty much exactly twice the speed. So how did the
conversions go? First thing to note is that DxO, at any rate, only used one CPU. I don't
know if Microsoft XP can use more, but there was no evidence of it. And it took twice as
long! It seems that these PassMark numbers relate to all available CPUs, so this seems
reasonable, but it's a bit disappointing to see an already glacially slow program get twice
as slow again.

The good news about my migration to FreeBSDamd64 is that it's almost over. Things are running more or less smoothly, and
now I can address the things that I needed amd64 for in the first place. Yesterday
I established that smart, a virtual Microsoft XP machine on eureka, was
actually significantly slower than braindeath. Discussing it on IRC today,
established that yes, Microsoft XP is multiprocessor-capable if it's installed that way, and
that's the way it's installed on braindeath, which appears to
have hyperthreading. That also
confirmed that DxO
Optics “Pro” uses both “CPUs”, so it was worthwhile investigating the situation
on smart. It proved not to be running the other processors I had given it, and I
didn't really feel like doing a full install. Instead I need to find the cheapest way to
buy a new 64 bit Microsoft operating system and install that.

Still, Callum Gibson—as always—came up with a number of interesting links which promised to
help. The first looked like just
what I needed, but stressed the importance of having “Service Patch 2” installed. My
version is Service Pack 3, so that seemed OK. But it wasn't: things look very different
under the covers, and the instructions just didn't work. There's another page on the subject, but I felt I had spent enough time on the matter
already.

Instead took a look at a couple of other VMs. I have just received a DVD of Ubuntu 12.04, so installed the 64 bit version of
that. On Peter Jeremy's suggestion, called
it echuca. That was uneventful,
but when it came up I couldn't find anything to do with it. No shell! It seems that
Canonical have achieved their aim of making their operating system as Microsoft-like as
possible. It seems that it is possible to get a shell by clicking on top right and
typing in terminal, but the “out of box experience” was very negative. I'll leave it as
it is until I need to use it for something.

Apart from that, migrated the web server to eureka, updating the DNS configuration to
match, and ran into yet more problems with PHP.
Why, WHY do they have to deprecate things as standard
as POSIX regular expressions? One of the
results is that my phpMyEdit pages no longer
work, not even after frobbing. Tomorrow I'll have to install the new version to get it to
work again.

My opinion of the authorities was already at rock bottom, so this couldn't worsen it. But
it makes very clear just how incompetent they are. I suspect “there are sufficient grounds
to vary the costs” is what we've been getting at all along. But they don't say anything
more about it, just as they don't give any reasoning for the rejection. Instead they offer
to issue a warrant to claim $0.00 from me. I didn't think that sort of thing still really
happened.

How do I react? We'll have to go to court to get the fees back. But should I react to the
letter? On IRC, Edwin Groothuis suggested I should call up and refuse to pay, Peter Jeremy
thought a cheque for the value demanded would be a good idea, and Callum Gibson suggested I
ask for extra time to pay. Personally I thought of calling up and saying
that bPay refused to process the
transaction. But all these approaches have the disadvantage that whoever I contact, though
he or she may fail the Turing test,
might understand that I'm making fun of the system and have absolutely no sense of humour.
But what a system! We still feel persecuted, and Yvonne even
talked of returning to South Australia.

Three weeks ago I planted a number of tomato,
chili and lily seeds. The tomatoes should have germinated in 10 to 14 days, so clearly
something was wrong. I had left them in the bathroom by the window, one of the brightest
places in the house, but not the warmest: most of the time the temperature is under 20°. So
a couple of days ago I put them in the kitchen, where it's very dark but significantly
warmer. And that did the trick: now a number of seeds have germinated, and hopefully the
rest will follow suit.

That's only part of the issue, though: they need both warmth and light. I suppose I'll have
to put them back in the bathroom with some heating.

Yvonne came back from shopping with 4 kg of chicken
wings—only $8! We have not one, but
two recipes for them, but today I did more
experiments. In the past I have either steamed or boiled them to cook them, and then
barbecued or deep-fried them. But the first step still didn't convince me, so today I took
the wings out of the marinade and cooked them in the microwave oven. While deep-frying, I
reduced the marinade and added honey, something that I hadn't really got to work properly
before.

The result? Good, but it could be better. The meat should be falling from the bone, and it
wasn't quite. That's a matter of the microwave oven, of course. I cooked for 10 minutes at
440 W. How much did they weigh? I don't know, but there were 5 wings, probably 600 g.
That particular load should probably have been cooked for about 30% more, say 13 minutes.
So the important rates are: 570 kJ per kg, 730 W per kg. We'll try again in a couple of
days.

Everywhere I go I find more fallout from decisions made in the latest version of PHP. As planned yesterday, got hold of the latest version of
phpMyEdit and installed it. Ran the
script phpMyEditSetup.php and got:

Notice: Undefined index: db in /usr/local/www/data/phpMyEdit-5.7.1/phpMyEditSetup.php on line 65

Notice: Undefined index: tb in /usr/local/www/data/phpMyEdit-5.7.1/phpMyEditSetup.php on line 66

And that was all. For whatever reason, the generated page ended there. Tried again
on dereel, still running the old version of PHP, and that worked. So I moved the
generated file (freezer.php) to eureka and tried it there. And the web server
gave a 404! I've never seen that before for a file that was present, no matter what the
contents.

As if that wasn't enough, discovered a new “feature” in bash: I have a number
of environment variables that refer to path names. In this case it was W, which is
the base directory of the web server. And I use it in conjunction with file name
completion, like this:

Is that intentional? It doesn't seem to have anything going for it, and I can't find a way
to turn it off.

In any case, did some comparison of the newly generated file. About the only difference was
a comment saying which version of phpMyEdit had generated it. Further investigation
showed that the newest version is dated 16 September 2007, so it's clearly another dead
project. Did some investigation of alternatives before I realized that this is God's way of
telling me to finally write my own, custom built pages. But clearly not today. For the
time being we'll just run it on dereel.

But what a pain! It really seems that PHP, in particular, is being deliberately
backwards-incompatible.

My photo processing isn't exactly typical. I don't use any of the big online photo sites
like Flickr or Picasa. Instead, I process things almost entirely my own
way and display them on my web site. That allows me much more flexibility in the
presentation, including including them in other pages, multiple sizes, comparison images,
popup EXIF data, lazy loading and more.

And inevitably it's a work in progress. There's a lot of mess under the covers. But
yesterday Peter Jeremy asked me for a copy of the software. That's fine, but there's no
documentation (does this sound familiar?). So today I spent some time writing a web page on
my photo processing. Hopefully it'll be
useful.

Not a very good imitation of a pink grapefruit. I forgot to notice which tree this is, but
possibly it's the old one, which has already played this kind of trick on us. As
grapefruits go, it was acceptable, but too sour and bitter for our taste. Hopefully the
ones still on the trees will be better.

Enchiladas rojas for dinner tonight, and
went out looking for recipes. They're surprisingly similar, and also pretty much the same
as enchiladas verdes except for the sauce, so I've combined the recipes and just
written a new recipe for the sauce.

One issue is the cheese. I used feta and
discovered that it doesn't melt. About the only other thing of interest is that the
tortillas stuck to the comal,
which I think is because they were too moist. I've also decided to use 30 g
of masa per tortilla instead of the previous
25 g, which seems to be a better size.

Finally bit the bullet today and started work on a replacement for the phpMyEdit deep freeze list. It's been a while since
I've done this, and I spent sometime looking in vain for an example. Finally I took the
most likely candidate and went off to the PHP manual web site,
which told me that—of course—the MySQL interface
I was using is deprecated. I should
choose mysqli or
PDO_MySQL. Did
some reading about that and came to the conclusion that there wasn't much in it. So what
interfaces did I have compiled in? That's in /var/db/ports/php5-extensions/options.
And none of the interfaces were installed. How could anything work?

But then, of course, nothing did work. Rebuilt the PHP extensions and installed
them, restarted httpd, and suddenly everything worked again. What's wrong with this
picture?

Clearly it's at least nominally my fault. I tried to run scripts on a web server that
didn't support them. But there are several mitigating circumstances:

I built these ports based on the options file on dereel, which does have
MySQL support. Why did it get changed?

This port hadn't been updated for months—it was dated 12 January, and it was based on an
old version of the port. I had run portupgrade several times since then. Why
didn't it update things?

And most important of all, PHP whinges vociferously when I use functions it doesn't
like, but is completely silent about the fact that I called a function that wasn't
available at all. What's more important?

So: in the end I just needed to replace some obsolete variables, and everything works
again. But why were there no error messages?

The other bug that I found yesterday was the completion issue with bash. Callum Gibson
went off into the web and came back with a number of references indicating that it was
introduced about 18 months ago, people agree that it is a bug, and nobody is doing anything
obvious about it. This message probably sums it up. It's a sad day when such a central piece of software can have a bug of
this magnitude for this long. But then, who uses shells any more? The web browser is the
way to go, and they're all riddled with bugs.

Photo day again today, and managed to take my panoramas with no particular problems.
Yes, smart (the virtual Microsoft machine on eureka) is even slower
than braindeath, but of course I was able to spread the processing across both
machines, with the result that my first processing step was done somewhat faster. And then
I ran into trouble stitching the equirectangular panoramas:

That was despite allocating 3.5 GB of memory for the process, something it didn't come close
to using. Is this the result of an internal limitation? This was the 32 bit version, since
I had had trouble building the 64 bit version of enblend version 4. Took another look at
that:

This was followed by many more of the same. Why did that happen? Compared with my
successful build of the 32 bit version 3 months
ago. It failed too! Further investigation on Google found a number of hits, some saying that they had
solved the problem—but not how. It seems, though, that this is a documented compatibility
issue between enblend and libpng. On that page I read:

Portability Note

The libpng 1.5.x series continues the evolution of the libpng API,
finally hiding the contents of the venerable and
hoary png_struct and png_info data structures
inside private (i.e., non-installed) header files. Instead of direct
struct-access, applications should be using the various png_get_xxx()
and png_set_xxx() accessor functions, which have existed for almost
as long as libpng itself. (Apps that compiled against libpng 1.4 without
warnings about deprecated features should happily compile against 1.5, too.)

Wonderful! I can't recall any reference to deprecation in prior builds, and I
really, really don't care about code purity right now. I just want the bloody thing
to work. People have suggested dropping back to older versions of libpng, but
clearly that's not the best way to go. It looks as if I'm going to have to do yet more
work.

My experiments with Hugin's linefind program haven't been very positive so far, so
today I tried one panorama both ways, with and without linefind. The results weren't
encouraging: without linefind, I had an average error of 0.9 pixels and a maximum of
2.8. With linefind those values increased to 1.6 and 18.8.

And the results? Conveniently it lost the cropping, so these two images (first without,
then with linefind) don't quite match. Run the mouse over
either image to replace with the other:

One thing's clear, though: the first image (without linefind) has better verticals.
And that's exactly what linefind is supposed to buy you. Maybe it assumes perfectly
level orientation, something that I seldom do. So for the time being, at any rate, I won't
use it.

Today's exactly the middle of winter, and also my garden flower photo day. Took advantage of
the meeting of autumn and spring with a couple of vases of flowers seldom seen together,
like Narcissus and roses or
gingers:

Sent mail to the Hugin group today about the enblend build problems. Quickly got a reply pointing
me at the Arch Linux repository with patches that look right. But why are they there and not
in the enblend repository? It seems that they have been added to the repository, but
only in the development version, and there's nothing at all on the site to point at the
problem.

This morning our daughter Yana arrived by overland bus in the
middle of the night to visit us for a couple of days. She's nearly finished university
(thought she was, but discovered she still had a couple of electives to do), and she's
thinking of going into gastronomy. Apart from some long discussions—she has also decided
that she wants to learn more languages—this meant that we had to eat lots of food, including
nasi lemak for breakfast and a recipe
for Coquilles Saint-Jacques with
courgettes and thyme:

The last couple of weeks have been pretty much tied up with my computer migration, and
though the end is not yet in sight, at least I'm getting time to do other things. It's high
time we planted some of the Hebes in
the east and south of the garden, so did a bit of investigating there, also some weeding.
Somehow I can't get motivated.

My remaining problems with the enblend version 4 port related to the outdated version of texinfo that we have in the base
FreeBSD source distribution. Investigating
the subversion logs showed that
it had been updated regularly up to about 7 years ago, and then nothing. On the other hand,
we have a newer version in the Ports
Collection. Why? Sent a message to the project mailing list and got a clear answer:
about 7 years ago texinfo changed its license to the GPL Version 3, which is incompatible with
the BSD license, so we could no
longer include it in the base system.

My timing is clearly inaccurate. As Harald Arnesen points out, GPL V3 was published on
29 June 2007

On the other hand, found out how to work around it and use a specific version
of makeinfo:

CONFIGURE_ARGS= MAKEINFO="${LOCALBASE}/bin/makeinfo"

Tested that and sent it off to Vasil Dimov, the maintainer. What a time it has taken!

The “divisible by 5” anniversaries continue. Fifteen years ago
today we moved in to Wantadilla, which I mark as
our real return to Australia after decades living overseas, mainly in Germany. By some
strange coincidence, it's also roughly 55 years ago since
I first returned to Australia with my parents after spending 3 years
in Malaya.

To Geelong in the afternoon to see Leela
Movva, the periodontist, dropping Yana at the station on the
way. Leela had been planning some deeper gum treatment, which I had expected to be like I
had five years ago, but this time it was serious work,
including cutting through the gums, folding them back and cleaning underneath. It'll take a
couple of weeks to heal. Hopefully this won't have to happen too often.

It's been over two weeks since I migrated to
FreeBSDamd64, and I still have a
long list of things that need fixing. Today managed to wedge the X server again—how
I wish that would go away—and again had difficulty starting it. Then I discovered that
my Emacs geometry problem, which I thought had gone away, is still with me. It seems
that I didn't test it very well before. And somehow startx without parameters now
wants to start server 1 instead of server 0. Why should that be? It's OK if I explicitly
specify server 0, but why should it change the default?

A couple of days ago I noticed a strange thing about last week's letter from Victoria Police: although it stated that
the application had been refused, and that Yvonne should pay
$0.00 or face the prospect of them issuing a warrant, the heading (conveniently separated
from the message by a number of case references) read VARIATION OF COSTS ALLOWED.
What does that mean? What did the letter mean at all? I had been meaning to call them once
I got my resolve together, but today another letter arrived. On the face of it, it had
nothing to do with Victoria:

But why this extreme stupidity? I discussed last week's letter with a number of people,
many of whom came up with some fanciful ideas about what to do next, but none of whom
thought that the application had been rejected. On the contrary, the only reference to the
application (incorrectly qualified with “to revoke this Court Order”) stated that it had
been refused. “Sufficient grounds to vary the costs” is such a nebulous term that it's
almost meaningless, though it did suggest to me that something had been accepted. On the
other hand, there's a demand to pay $0.00 or face the prospect of having a warrant issued.
At least that indicated that the variation was not to increase the costs. The whole form of
the letter is tantamount to illiteracy.

In many ways, though, it's also related to the inability to communicate of people in the
Microsoft space. Consider this hypothetical mail message and reply:

> I am prepared to pay the original infringement penalty of $244. I ask you to waive the remaining
> fees.

Your application to revoke the Court Order has been refused by the Infringements Registrar.

Once again I get the impression that they don't read carefully enough, or they don't have
the intelligence to understand the content. But the demand for payment of $0.00 suggests
that their computer people are no better.

One of the problems about my migration to FreeBSDamd64 that I knew about in advance is that wine doesn't work. And that's annoying, because I use it to run Ashampoo photo optimizer in my photo processing. The
idea was to use a virtual machine instead.

But one problem that I hadn't expected with virtual machines is that startup and shutdown
isn't instantaneous. It can take up to a minute in a manner reminiscent of this cartoon:

By contrast, wine does fire up essentially instantaneously, like any other program.
But I can't even run it across the network because the performance goes to hell. So it was
good to discover that the version of wine that I built on dereel,
the i386 box, also runs on amd64. I suppose in the long term I should
maintain an i386 box for port builds.

It's taken me over 2 weeks to get my Hugin installation to work correctly with 64 bit executables. That's a good
thing too: the 32 bit version of enblend maxes out with a process size of 3 GB, and that's not enough for some
of my panoramas. Today I experienced some of the largest memory footprints I've ever seen:

The most interesting thing, though, was the processing time. At the beginning of last month I had an extreme case
where enblend took 4 hours, 40 minutes to do its thing. Admittedly that was with a
higher resolution panorama, but in general enblend's processing time has been a
serious factor. Not so today: the garden centre panorama took all of 4 minutes, 29
seconds—a 60-fold speed increase!

One of the reasons the migration has taken so long is the new linefind program, which
is designed to find verticals. The man page doesn't say, but it appears to assume a
horizontal lens axis, and it fails badly on my multirow panoramas. So for the moment at any
rate I'm not using it.

I've already commented on
a bugfeature of DxO Optics “Pro”: if
the EXIF data of the input image is changed
in any way—even in valid ways—it may ignore it completely. In my case, I had put my name in
the Author tag. There's a clear workaround there, one that makes sense anyway:
don't put the Author tag in the raw file, just in the
output JPEG. DxO will even do this for you,
though I haven't found a way to get it to store the values, so I have to reenter them every
time I start it; it's easier to use my script afterwards.

So I did it like that today. Not a success. Hugin complained about every image:

I've been struggling with weeds for as long as I've been here, but comparing today's photos
made it very clear how I'm losing the battle. Two years ago I was concerned about the state
in the first image, but today it looks like in the second picture:

Yesterday I noted what appeared to be a 60-fold increase in the speed of enblend, but I wasn't quite comparing the
same thing. In fact, not only did the panorama I took at the beginning of last month have more images: it was also much
larger, in fact about 170 megapixels (26046×13023). So today I tried restitching it.

That gave quite a different picture: enblend took nearly 58 minutes, still only about
20% of the time it took in 32 bits last month. The reason was clear: it had more memory to
play with, and it used as much as it could get. The maximum resident set went up to
4,420,796 kB, and the address space grew to at least 12,344,496 kB, the largest I have ever
seen. It also managed to swell the size of swap to over 3 GB. I still have difficulty
coming to terms with these sizes, over 1000 times as much as was considered big only a few
years ago.

That wasn't just an experience: it also has its positive side. This image was the one that
I had found to have a number of stripes near the joins between the rows:

They're gone now. It's not clear whether that's because of a newer build of enblend,
or whether it's a bug that went into hiding with more memory. The base sources remained the
same, but there were other libraries. Still, the swap usage suggests that I should put more
memory into the box. Somehow 32 GB no longer seems excessive.

The comparison of the garden photos with two years ago make it clear that I should be doing
more weeding, so spent nearly an hour today doing the best part of a square metre. I can
see more use of chemicals and weed mat in the near future.

I suppose it's a sign of my general laziness that I don't even read the magazines to which
I'm subscribed. In particular, I find that I don't get through c't until the next one comes two weeks later. But in the
last couple of weeks it dawned on me that I had read issue 12 (dated 19 May 2012) and not seen anything since. Then, last
week, issue 15 (dated 30 June 2012) arrived. I was about to
write a message to Heise, an action fraught with difficulty, when two days later issue 14
arrived. And then today issue 13 arrived, along with a copy of the their quarterly photo
magazine, also very late. I now have everything, but they've all been knocked around a bit,
and even issue 15 was about 10 days late. I wonder if I'll be able to get them to do
something about it without too much effort on my part.

I back up my machines religiously every night using a cron job. And I at least skim
the output every morning to ensure that nothing went wrong. Or so I thought. Today, with
the help of my X loop bug, I managed to blow apart a
virtual machine disk. A clear case for restoring the disk from backups.

And then I discovered my backups hadn't run for about 2 weeks. No messages
in /var/log/cron. Entry in /etc/crontab OK. And you don't need to
run crontab for /etc/crontab; cron checks the timestamp and re-reads
automatically. So what went wrong?

The timestamp! I had copied the file from dereel to eureka, using
the -p (preserve permissions and timestamps) option, so it was still dated October
last year. Restarting cron seems to have done the job.

The exercise also shows how annoying this X bug is. I've been investigating it on the web
for some time, and I've come up with a couple of things that suggest it's not as directly
related to multi-screen as I thought. This report shows something
similar happening with a single display (“the mouse is flickering on some edge of the
screen”). This one is with FreeBSD, but I
found other reports of it happening with Linux.

Enables the use of system events in some cases when the X driver is waiting for the
hardware. The X driver can briefly spin through a tight loop when waiting for the
hardware. With this option the X driver instead sets an event handler and waits for the
hardware through the poll() system call.

It's not clear that that is related, but it's quite possible. In any case, it's related to
heavy load, so there's a chance. I've put the option in my config file, and we'll see if it
does any good.

My mother Audrey Lehey, née Herbert, has had an interesting life, mixing with people in high
places—she once even received a visit from the Queen of England. But for some reason search
engines have overlooked her completely. To prove the point to Yvonne, I searched for her again this evening. This time I found a new hit:

The marriage of Audrey Eileen, eldest daughter of Mr and Mrs R. Herbert, Raith Court, East
St Kilda, to Telegraphist Norman George Lehey, RAN, eldest son of Mr and Mrs G, Lehey,
Montrose st, Auburn, was celebrated on Saturday at All Saints Church of England, East St
Kilda. Archdeacon Schofield officiated. The bride, who was given away by her father, wore a
trained gown of white satin. Miss Audrey Lehey was bridesmaid, and Mr Robert Herbert was
best man.

Clearly that was my parents' wedding, and there are details there I didn't know, such as the
address of my mother's parents. But, ironically, the reference to Audrey Lehey wasn't for
my mother, but my aunt Audrey, now Audrey Schaedel.

More generally, though, the NLA trove web
site looks very interesting. It is apparently an attempt to digitize all old
Australian newspapers. I wonder what else I'll find in there.

Last time I made pizza dough, I reduced
quantities significantly. It's not completely clear that it's better, and I had intended to
use only 4 g yeast and 100 g flour per pizza. We made pizzas again today, and to be on the
safe side, I put in 5 g yeast per pizza. That's certainly enough. I pre-baked the bases
for 4 minutes, by which time they looked like this:

The bases swelled up to a point where they hit the upper heating element. But we're
gradually getting there. I can't make up my mind whether to use less yeast next time, or to
prick the base halfway through the pre-baking to stop it swelling up so much.

Last night, just before going to bed, our network connection dropped. This happens from
time to time, but this time it was different. The (wireless) link was reestablished, at
least part of the authentication succeeded, but then... nothing. I couldn't be bothered
last night, and hoped that it would clear up by the morning. It didn't. But when I
restarted the ppp process, it came up immediately. So some error that ppp
didn't think worth retrying.

Reading ppp.log is a real pain. It's verbose and repetitive, and the meaning of some
of the messages is really difficult to interpret. But now I have a log of the failure and a
log of a successful connection, so I can compare them. In a normal connection, I go through
a whole sequence of:

So my best bet is that something at the other end is flaky at best, and in this case didn't
work at all.

By coincidence, received a message from Internode support this afternoon, referring to a ticket I had raised. Two problems: firstly, I hadn't
raised a ticket, and secondly they claimed that my phone number was out of service. So I
called them up and discovered that they still had my old phone number from Wantadilla in the system. That's over 5 years out of date, and I
have only had this service for about 18 months. And the ticket was a response to an
automatic reply I send from the toy webmail account that they insist I have, the one whose
name I have never revealed. They know it, of course, but shouldn't be sending anything
there. And when they got the reply, they were confused.

In any case, discussed the network dropout with Bill, who saw from his end that I had had
several short sessions, all less than a minute long. So somewhere in between there
was some issue with connection setup. Bill thinks it's with Optus, but it seems that before
they can lodge a fault, I need to deinstall and reinstall my software. I wonder if they do
that too.

And of course, there's very little help interpreting what this means, not even in the
documentation. I have a link to a Dial Plan Parser, but it didn't help very much. Finally I got it:
<#0,:>xxx.<:@gw0> means “Enter #0, wait for the
(external) dial tone, then dial the number”.

More playing around with FreeBSD inside
VirtualBox today. Upgraded the
virtual defake to the latest 9.1-BETA kernel and... it wouldn't boot.
They've recently done a dirty trick and changed the name of the disk driver, so the boot
disk became /dev/ada0 instead of /dev/ad0. The loader had no difficulty
loading the kernel, but then the entries in /etc/fstab were wrong, and the root mount
failed.

That's OK: the loader enables you to tell it where the root file system is:

Error 19 is ENODEV, operation not supported by device, not necessarily the most
obvious error indication. Looking at the output of the list command, it seems that the
kernel doesn't recognize the disk:

mountroot> ?cd0 ada0

I should have seen ada0s1a there, but there's just the base disk. This isn't the
first time I've had problems here, and I'm not sure what's causing them. Time to download
an ISO and try from there.

The continued with my weeding in the area. One weed, in particular, grows via underground
runners and can spread very quickly. Spent the best part of an hour removing it from under
a single Grevillea. Strangely I can't
find any reference to what this weed is:

It's interesting because of the lobes at the bottom of the leaves. Apart from that, it
could be some kind of Rumex, but the photos
on some web sites, such as the Australian Government Weeds in Australia site, are so tiny that I can't recognize anything. Not only is
the image only 199×144
pixels, the web page reduces it to 80×57:

We bought a Camellia japonicanearly 2 years ago, and it spent the last 2
summers in a pot on the verandah. It didn't flower much. Then I moved it to the front of
the house, still in the pot, next to the white camellia that has been here since we moved
in. It seems to be doing a lot better there, and is already flowering, before the
established white camellia:

In the last week I have received no fewer than 4 issues of c't, including the quarterly photo edition. Clearly
that's not enough: today the fifth arrived, last week's issue 16. Hopefully that's the end
of the blockage.

Peter Jeremy pointed me at a newpaper
article today: it seems I wasn't the only person hit by the network outage. They
don't go into great detail, but the fact that it affected mainly postpaid customers suggests
that it's something to do with authentication, which fits my problem description. The
negotiation died just at the point where I should have received an IP address. Looking at
what I got for the previous connection, I see:

syd6 is almost certainly Sydney.
So it appears that I was connected
via New South Wales, which fits
the problem description. That's good news: things of that magnitude are visible enough that
they'll ensure that it doesn't happen again. A more localized problem wouldn't get the same
amount of attention. Why did it take so long to fix? Maybe they were deinstalling and
reinstalling their software.

While discussing the matter, Peter also pointed out a couple of other things that I hadn't
looked at carefully:

It's clear enough what PRIDNS and SECDNS are: they're the name server addresses. But what
are PRINBNS and SECNBNS? The MS gives the clue: NetBIOS Name service. What on
earth is that there for? This is supposed to be an Internet service, not
a NetBIOS service. And it seems that the
large number of retries is part of Optus' insistence on trying to negotiate NetBIOS names.
Years ago Edwin
Groothuis got bitten by the same thing. Peter commented:

If I recall the investigations I did and read the logs correctly (mine is basically
identical to yours), Optus are sending ConfigNak (the RecvConfigNak
entries) because our SendConfigReq doesn't include a NBNS entry.

He also recommended to increase the retry count with this line in ppp.conf:

It's becoming ever clearer that my work in the garden is strongly influenced by the weather,
and today was cooler. Managed some work anyway, including cutting down the grass bushes
that we had planted in the east garden and then decided against. That involved dragging out
our old but powerful mains-powered hedge trimmer and laying cables all over the place, so
also trimmed the Buddlejas while I was
at it. It's amazing how much they can grow in only a single season.

It's about time I committed some changes to FreeBSD, and as a prerequisite for that I need a separate build box. In the good old
days I used old computers, but now we have virtual machines, and some time ago I created a
few of them. I use them happily enough for Microsoft, but for some reason all three of my
FreeBSD boxen wouldn't boot.

The problems were only marginally related. swamp came up, but I couldn't log in.
When I tried, I got the message:

What's that? Yes, I had had trouble with pam years ago, but I thought I had disabled
it. And this came after a relatively minor change to the system, including a crash and
subsequent fsck, so it seemed reasonable to assume that some of the pam files
had been lost. But which? And how do you disable pam?

Discussed it on IRC, and Michael Ralston came up with a reference saying that /etc/pam.d/login needed changing:

But this discussion was dated 27 September 2007 and referred to
FreeBSD 7.0-CURRENT. swamp was running 10.0-CURRENT, and it had
worked up until recently, and I had been upgrading things regularly. Surely it couldn't be
related? But my login really did have the old auth in it, so I tried the
change anyway, and... it worked!

What's wrong with this picture? The problem didn't occur after an update, but after a crash
with subsequent fsck, which completely misled me. And clearly my login file
was out of date—in fact, it had the ID line:

# $FreeBSD: src/etc/pam.d/login,v 1.16 2003/06/14 12:35:05 des Exp $

And no, des has nothing to do
with DES: it's the login
of the committer, Dag-Erling Smørgrav. Checking the logs, it seems that there has been only
a single update since then, on 11 June 2007, and that was the one
that caused the pain. But why didn't my upgrades update it? Callum Gibson told me I should
have been reading the handbook. That's a
problem: I've written my own handbook, and though
it's out of date, the question is how often you should check. Every time? That doesn't
work.

The current version of the handbook mentions /usr/src/UPDATING, a file I hadn't even
heard of until I read of it in the mail message that Michael referred to. But it shouldn't
be necessary, and in any case it seems that it now no longer contains any reference
to pam. One of the great things we used to say about FreeBSD decades ago was that
all you needed to upgrade your system was “make world”. Somehow the project
appears to have given up on such simplicity.

I had less luck with another machine, defake. After building a recent kernel, it
just can't find the devices. Although the disk hasn't changed, and it's able to load the
kernel from /dev/ada0s1a, the probes only discover the base device /dev/ada0.
So I'm dead in the water. I can boot the old kernel, so the disk structures are OK, but I
can't upgrade it. What's wrong here?

In any case, it's clear that continual upgrades aren't as smooth as they were 10 or 15 years
ago, so downloaded an ISO image for 9.1-BETA and installed that, making
acquaintance for the first time with the new installation procedures. I suppose they might
be OK for newcomers, but they don't seem to offer as much choice as before, and at least
under VirtualBox they're just plain
ugly. But VirtualBox offers one advantage for this sort of thing: throwaway virtual
machines. Now I have a completely virgin 9.1-BETA machine, and I can clone a
second one as a snapshot of the first, and do my work there. When I'm done, I just throw it
away and make another clone. Now to decide where to clone.

VirtualBox has another strangeness: it tries to second-guess the keyboard layout,
failing miserably in my case. In particular, the function keys F1 to F12 or
so seem to have got lost, and the Esc key is still in its old location, but manages
to create extra characters. That's normally not a problem, because I interact with the VMs
via xterm, but when trying to boot the machine, it complicates things enormously. In
particular, I should be able to boot defake from one of three partitions, selected
by F1, F2 and F3, but that doesn't work.

Yesterday I pruned all the Buddlejas,
but then it occurred to me that there were a few more to do. They proved to be more than
the original quantity, and I also managed to remove a lot of old growth on
the Salvia microphylla. My
energy didn't last to the point of carting off the branches, which will have to wait until
tomorrow.

Yvonne and Chris Yeardley headed off
to Adelaide and Olivaylle today to pick up some horses, for Chris to
beat up some young men, and for Yvonne to go shopping in the Central Market, leaving me alone with
the cats. Somehow I didn't do much all day long. Cleared away yesterday's prunings, but
the weather wasn't really conducive to doing much more work in the garden.

The make buildworld I started last night on swamp, one of my virtual
machines, still hadn't finished this morning. It proved that the machine had hung. On
further investigation, it wasn't the virtual machine itself but the host environment. I had
to shoot down the entire VirtualBox system
and restart. And then it happened again some hours later! What's wrong here? And how do I
debug it?

That wasn't the only strangeness I had today. Last night's backup failed because the backup
disk was already mounted. But why? Tried umounting it, but something had it open:

Ignoring the evidence that Yet Another port fell through the last portupgrade session,
what's gam_serve? Nothing. It's gam_server, but lsof truncates.
pkg_info tells me that it's part of gamin-0.1.10_4, conveniently avoiding
telling me the path name of the port. There's no good reason for that:

=== root@eureka (/dev/pts/13)~175 -> cat /usr/ports/devel/gamin/pkg-descrGamin is a file and directory monitoring system defined to be a subset of the
FAM (File Alteration Monitor) system...

The process conveniently had init as a parent, so I killed it. A new one popped up
and took hold of the file system again. Why? Found another gam_server process, so I
shot both of them down. Both came back again. In the end I had to force umount the
file system to get rid of them. Another head-scratching moment.

You can never prove the absence of a bug, right, just the presence? I had been wondering
how to decide whether the recent changes to my
X configuration fixed the hangs that I have been
having. Now I have proof, unfortunately: it happened again today, not once, but twice. How
do I debug this kind of problem?

So the London Olympic Games are now well under
way, and both TV entertainment and news have dwindled to a trickle. I've heard more
criticism of the event this time round than in previous years, such as this cost comparison. And of course the big
news networks have coverage on their web sites, such as this one from NBC:

But then, understanding other countries has never been a US forte, as presidential hopeful
(“Obama has messed up overseas
policy”) Mitt Romney has
recently demonstrated. At least he's honest: other presidents don't let you know
they're inappropriate for the job until after they're elected.

That should have given me a backtrace of the process that paniced. What went wrong
there? It's beginning to look as if I should take another look at kgdb, but I'm not
sure if I have the energy. In any case, it seems that this is a genuine bug
in -CURRENT, one that mainly hits VirtualBox users. It's not 100% clear why that should be, except that the bug
is specific to the network interface that VirtualBox provides.

Yvonne and Chris back
from Adelaide and Olivaylle in mid-afternoon. Yvonne was not happy
with Adelaide and the Adelaide Hills. Her shopping spree in the Central Market was disappointing: many
of the stands she had wanted to visit are no longer there, and others, such as Standom, have greatly reduced their offerings. And
Mount Barker has become a trendy, glittery place with high prices and superficial offerings.
There's a Japanese place there where they bought some takeaway food which was so bad that
they would have left it behind if they hadn't been so tired. To add insult to injury, the
person serving them suddenly decided that she couldn't speak English when they complained.
How things change in only 5 years!

Despite expectations, our Kaffir lime
tree is bearing lots of fruit. It's not really intended for that: its main purpose is for
the leaves. But before just throwing the fruit away, we've tried various things with them.
They're too small for using the flesh, but today I pressed quite a bit of juice before
thinking to try it. It's not very sour, but it's overwhelmingly bitter. Out with it after
all.

Winter has another month to go, but there's plenty to do in that time, and the first
suggestions of spring are coming. Tomorrow I'll take some photos of what has happened so
far.

A couple of weeks ago, Yvonne Curbach, the leader of the Growing Friends, asked me for
some birch saplings. I've been
dragging my feet, mainly because I couldn't find any, but time's getting on for that, too,
so today dug out what I could find—a measly two saplings, along with one I had planted in a
pot earlier, and also another which looks just the same (twig with buds), but which I
suspect is a Japanese ornamental cherry. And while I was looking at that, noted that the
two Hibbertia scandens
cuttings that I had made last October are now developing
leaves. Just the thing to plant in the shady area at the north-west corner of the house.
Planted them there, in the process removing some really unhappy
looking petunias, which I planted in pots
for the greenhouse. There's a good chance they'll survive for another season.

We don't watch sports, and as I mentioned,
for us it's mainly a dry spell in the TV programme. But we heard good things about the
opening ceremony, so we decided to take a look at that.

I've just finished a rant about Mitt
Romney's lack of diplomacy. After what I wrote yesterday, he went on to Israel and
claimed that Jerusalem is the capital
of Israel. That's an excellent way to
annoy the Palestinians and confirm Arab prejudice against the USA. Bravo! I wonder
what he would have said if he were asked whether the Palestinians should get
Al-Quds as their capital.

The ceremony continued with an interesting view of British history, complete
with token negro—playing cricket with a
group of English gentlemen in what appears to be the mid-17th century. That's so wrong:
firstly, there wouldn't have been any coloured people in that society at that time, and if
there had been, they wouldn't have allowed them to play cricket with them. The same actor
(I think) appears inmost other scenes. Nothing against coloured people, of course, but this
is rewriting history. The English were very different until relatively recently, and the
first coloured player in English international cricket was Roland Butcher, who played his first
game for England in 1980. That doesn't say when coloured people were allowed into other
teams, of course, and for some reason the web is silent on the topic, but I don't think it
could have been much before 1950.

And then James Bond. It's interesting
that the Queen participated, but the whole thing looked so completely inappropriate, and I
at any rate wouldn't have known it was supposed to be James Bond if I hadn't been told. He
looked like a prototypical British officer.

Round about this point we couldn't be bothered watching any more. It's possible that things
got better after that, but they would have had to change a lot to make up for the
disappointing start. I skipped through the rest of the first half without finding any
evidence, though I did find evidence that I wasn't the only one who was less than happy with
the affair:

Yvonne got a phone call from Jenny Judson today. Her old
German Shepherd bitch died a
couple of weeks ago, and she's been looking for a replacement. She has now found one:
Nemo's mother, a mere 650 km away from where she
lives. Sometimes I wonder how many pure-bred German Shepherd Dogs there are in Victoria.

After deciding to throw away the kaffir limes, I did a bit of research, and in the process discovered the names in
Malay and Indonesian. For once they're not the
same. In Indonesian the preferred name is jeruk perut, though they also know the
Malay name limau perut, So do I: it's an important ingredient, and the Indonesian
page states that they use the juice too. So I went off looking through my Malaysian and
Indonesian cookbooks. It seems that they use them in addition to things
like tamarind, presumably because of the
bitterness. Still, worth keeping in mind.

Yvonne was in town today, and while she was there she dropped
in at the Botanical Gardens to give
the birches to Yvonne Curbach.
Yvonne was a no-show (probably just a bit late), but Bruce Holland was there and identified
some of the plants she brought along: the unidentified plant that we bought
in Napoleonssix weeks ago is
an Erodium:

He also identified the weeds I was looking at last
week. As I suspected, it's Rumex,
though he didn't tell Yvonne what kind. He also identified some cuttings that she had
brought—from elsewhere in Napoleons: they're a variegated sort
of Pittosporum
tenuifolium, and we should be able to propagate the cuttings. So that's what I did in
the afternoon:

I left most of the leaves on this one for comparison's sake; conventional wisdom has it that
it's better to cut most off and to trim the rest of the leaves, but it's interesting to see
how much difference it will make.