|
| Greg's diary |
| February 2005 |
|
|
||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||
|
|
|
|||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||
| Tuesday, 1 February 2005 | Echunga | Images for 1 February 2005 |
| Top of page | ||
| next day | ||
| last day |
For some time my Brother HL-2700CN colour laser printer has been jamming intermittently on large jobs. It's more irritating than anything, but since the guarantee will soon run out, it's time to do something about it. I called last week and discovered that the guarantee was on-site, so today Darren turned up to fix it:
He did that in a very professional manner. One of my concerns about buying a cheap laser printer was that I might have service difficulties, but that turned out not to be the case at all. About the only problem was that when he left, the printer didn't work at all any more: I had run out of black toner. Getting new toner doesn't seem to be instantaneous, either, and I'll have to wait until Friday. In the meantime, reinstalled the old faithful HP LaserJet 6MP. Based on the usage statistics, it should be another year before I need coloured toners, but I should make sure I get some in plenty of time.
Apart from that, more catchup work, notably the Makefile work I did last week. Some of our design choices require interesting dependencies, and I didn't get a reliable Makefile for the library finished before evening. Also lots of mail to catch up on.
Spent some time updating my Apple machine to the latest version of MacOS X. Documentation here could be better, too: I have 4 CDs, the fourth of which is marked “MacOS X Xcode Tools”. Nowhere is it obvious what an Xcode tool is, and the documentation makes the typical mistake of assuming that you know and just telling you about new features. It appears to be a software development package, but you have to guess that.
| Wednesday, 2 February 2005 | Echunga | |
| Top of page | ||
| previous day | ||
| next day | ||
| last day |
Still had a little work left over with my Makefile work from yesterday. It kept me busy all day! And at the end of it people were reporting strange problems that I couldn't reproduce at home. What a day!
| Thursday, 3 February 2005 | Echunga | |
| Top of page | ||
| previous day | ||
| next day | ||
| last day |
The Makefile is still giving me headaches. Spent most of the day testing it, but finally got it to work on all platforms I could think of. There's still one philosophical question: if the source code for the library is updated, should the application code rebuild the library? That's the way we have been doing it, but I consider it to be a layering violation. Doubtless we'll have some interesting discussions on that one.
It's been raining heavily lately, strange for this time of year. The water tank is nearly full, a far cry from the situation last year.
| Friday, 4 February 2005 | Echunga | |
| Top of page | ||
| previous day | ||
| next day | ||
| last day |
As expected, still some discussion about Makefile dependencies today, in particular the distinction between a library and an application which uses that library. Old habits die hard, I suppose.
Into town in the late morning for a total of three meetings, pretty much back to back. On the way picked up brewing stuff (I'm trying two new yeasts, Wyeast 1187 Ringwood Ale and 1968 London ESB Ale; both seem to be rather extreme) and new toner for the Brother printer.
The meetings themselves dragged on, and as a result I missed the inaugural beer bust. We need to get our priorities clear: first the beer, then the meeting.
| Saturday, 5 February 2005 | Echunga | Images for 5 February 2005 |
| Top of page | ||
| previous day | ||
| next day | ||
| last day |
Into the office this morning and had a report about a problem with my Makefile changes on Apple. Since I now have this new Apple machine, decided to try it out.
That wasn't as simple as it seemed. First I needed to mount the /src file system on which I keep all my sources. Root login failed. My best guess is that the update I did on Tuesday reset the root password to God knows what. After far too much searching through the online documentation, found a way to boot single user (hold down this funny “Apple” key and S during boot) and then ran passwd root. There was a bit of a delay, then the program finished. Reading the man pages revealed that:
Did some googling and found some instructions, but unfortunately they weren't up to date: they recommended booting single user and then running /etc/rc to start services. On my system, at any rate, that doesn't work: /etc/rc requires a parameter. Looked through the script and decided (rather rashly) on multiuser, which brought up the starting screen and then hung at 90% complete.
Gave up on that and tried a different approach: it seems that the system has sudo, so after rebooting tried sudo bash and then passwd root—success!
Things weren't over then, though. Next I discovered that I couldn't start more than one shell window (“Terminal”) at a time; any attempt just brought back the first terminal. Spent some time messing around in the singularly confusing menu system and discovered a way to start additional shells. But what a pain!
I still can't remap the CapsLock and Ctrl keys. I tried a couple of days ago using uControl, but it doesn't seem to make any difference, though uControl seems to the think that the remapping has worked. As a result, just using the keyboard is a pain. It seems that Benjamin Herrenschmidt is correct when he tells me that the keyboard on this model is hard-wired, so you're lumbered with the broken layout. Spent some time working my way through the installation CDs and found a package of X clients that allowed me to run an xterm on my normal display. That made things a lot easier, but Emacs still doesn't understand X. At least I was able to use my standard shell defaults and Emacs preferences, so it's not too bad.
Then back to the make problem. Things weren't over yet. First, there's no gmake (GNU make); found a gnumake instead. It wasn't until a lot later that I realized that make is a symlink to gnumake:
=== grog@tomato (/dev/ttyp0) ~ 24 -> ls -l /usr/bin/*make
-rwxr-xr-x 2 root wheel 237007 13 Sep 2003 /usr/bin/automake
-r-xr-xr-x 1 root wheel 119676 1 Feb 18:38 /usr/bin/bsdmake
-rwxr-xr-x 1 root wheel 148248 1 Feb 18:38 /usr/bin/gnumake
lrwxr-xr-x 1 root wheel 7 1 Feb 18:17 /usr/bin/make -> gnumake
I suppose that makes sense; presumably if you like you can relink it to bsdmake. But why a symlink in the same directory?
Next I had problems getting FunnelWeb. Sure, Ross has an Apple version, but it's just a tar archive. So the whiz-bang GUI downloader downloaded it and put an image of it in a window. What then? Gave up on the GUI and created a directory /usr/local/bin. /usr/local existed, but not bin; I'm not sure whether that's what's intended, but there's nothing in the PATH variable to suggest an alternative directory.
Next, running ls -l across NFS appeared to hang; couldn't work out why, so copied the data across to the local machine. Finally ran make and confirmed the bug report—and that it wasn't Apple specific. Sigh.
Since I was there, carried on trying to do things with the Apple machine. I think that one of the problems I have is to understand what it's trying to achieve. I've never been a fan of eye candy, but the rest of the interface seems so limited. Tried to get something like rdesktop to work so that I can access it from a usable keyboard and with adequate screen space: 1024x768 is so restrictive. Unfortunately, I wasn't successful. The only references I found to something like that all seem to cost money. For me, that puts Apple at a definite disadvantage to Microsoft: as I found out last year, I can use rdesktop to put the entire Microsoft desktop in an X window. Some people on IRC pointed me to cotvnc, but that's a client, and it doesn't seem to be compatible with Microsoft either.
Also tried IRC clients. Found a reference to Ircle, which is shareware. It started up, but I couldn't make head or tail of what it was trying to do. An excellent example of the kind of junk that makes me wonder where the industry is going. Then Wes Peters pointed me at X-Chat Aqua, which seems to work, though it doesn't seem to be even as usable as ircII. Maybe I'm expecting too many specifics, but it would certainly help if I could get some documentation that makes sense.
In summary, I found the whole thing very frustrating. It occurs to me that part of the problem is that I started using “desktop” computers before the current spate of GUIs aimed at computer illiterate people. I seem to be an exception here: the current distribution of the dates of birth of FreeBSD committers peaks slightly after when I first got my first computer “desktop”:
|
|
||||||||
In that time I've come up with my own, efficient ways of doing things, and the GUI environment doesn't give me that flexibility. The command-line interface does, modulo a few silly decisions such as file names with spaces in them, but I don't need to spend money on an Apple if I just want that interface.
I also have difficulties with the GUI itself, things that look more than suboptimal. For example, sometimes (I think) you need to click once on an object, and sometimes twice. Unlike Microsoft (which doesn't do a very consistent job either, admittedly) there's no immediate feedback when you press a button, so I end up clicking too many times, typically resulting in accidentally starting Acroread (and not acroread), which happens to be the first entry in the Applications directory.
The other thing that seems so strange in all current GUIs is their insistence on breaking up the directory hierarchy. Not only with Apple I'm often left wondering where the directories are located. Even UNIX-based web browsers such as firefox create their own directories (or even, in some cases, try to store in the directory in which the executable is located). There seems to be a deliberate attempt to separate directories and their contents. I can't understand why, but I find it incredibly frustrating.
Where does that leave me with the Apple? I haven't given up. But the first impression is just as negative as with Microsoft. Gone are the days where Apple can advertise that the Macintosh is so simple that you can learn to use it in a day. I wasted one and still don't know how to use it.
| Sunday, 6 February 2005 | Echunga | |
| Top of page | ||
| previous day | ||
| next day | ||
| last day |
Another work day today. Discovered the reason for the make problems yesterday: I had forgotten to add a dependency line. Will it never end?
More work trying to understand the Apple box, and didn't succeed very well. It's nice to have the BSD/UNIX interface to the machine, but what is put on top completely baffles me. There's this program called Finder, a name that rivals Microsoft in its re-use of a normal English word. As I discovered (and describe below), it loses mount points for NFS file systems.
If there's one thing about UNIX that has really stood out over the years, it's the file system hierarchy. One single address space to locate just about everything. For reasons that completely blow my mind, it seems that Apple wants to break this hierarchy apart and hide the details. Probably the best example of this is NFS-mounted file systems. After a bit of trial and error, I had persuaded Finder to show the root directory of the system, including all the mount points for my NFS file systems. I mounted an NFS file system, and... Finder removed the mount point from its directory listing. I can't imagine what good that could do. Obviously, though, it's misnamed: it should be called Loser.
More discussion on IRC suggested an alternative. It's obviously too difficult to type this:
# mount zaphod:/src /src
Instead, the user-friendly alternative is:
Start Finder. There's probably a simple way to do this, but all I can find is:
Move the cursor to the bottom of the screen.
Wait for the “Dock” to pop up
Select the left-hand (at least on my machine) image, which displays the text Finder when you position the cursor over it.
At the very top of the screen, the menu changes to the “Finder” menu. Select Go.
echunga:/ /echunga nfs rw 0 0 echunga:/home /echunga/home nfs rw 0 0 wantadilla:/ /wantadilla nfs rw 0 0 wantadilla:/home /wantadilla/home nfs rw 0 0 echunga:/dump /dump nfs rw 0 0 wantadilla:/dumpa /dumpa nfs rw 0 0 wantadilla:/dumpb /dumpb nfs rw 0
Of course, you have to go through the whole rigmarole for each file system. With /echunga/home something interesting happened: a new entry home (and not Volumes/echunga/home) appeared on the Finder window. Selecting it gave an empty directory (I think). Continuing further, mounting /wantadilla and /wantadilla/home gave another entry in the Finder window, again (and very confusingly) called home. I can't find any way within the GUI to determine which /home it is. Looking at it with df, I found (showing NFS file systems only):
=== root@tomato (/dev/ttyp2) /Users/grog 2 -> df
Filesystem 1048576-blocks Used Avail Capacity Mounted on
zaphod:/src 150214 79244 58952 57% /src
echunga:/ 5814 5301 47 99% /Volumes/echunga
wantadilla:/ 9912 4566 4553 50% /Volumes/wantadilla
wantadilla:/home 51895 39296 8447 82% /Volumes/wantadilla-1
For some reason my /echunga/home got umounted. echunga's log file confirms:
Feb 7 15:20:08 echunga mountd[827]: mount request succeeded from 192.109.197.153 for / Feb 7 15:20:26 echunga mountd[827]: mount request succeeded from 192.109.197.153 for /home Feb 7 15:20:30 echunga mountd[827]: umount request succeeded from 192.109.197.153 for /home
I'm pretty sure I didn't do that. In any case, at this point I still didn't have zaphod:/src showing either, so I tried mounting them both again. This time it worked, and I had two home entries in the Finder window, without any way to determine which is which. df now tells me:
=== root@tomato (/dev/ttyp2) /Users/grog 2 -> df
Filesystem 1048576-blocks Used Avail Capacity Mounted on
zaphod:/src 150214 79244 58952 57% /src
echunga:/ 5814 5301 47 99% /Volumes/echunga
wantadilla:/ 9912 4566 4553 50% /Volumes/wantadilla
wantadilla:/home 51895 39296 8447 82% /Volumes/wantadilla-1
echunga:/home 6329 4543 1279 78% /Volumes/echunga-1
zaphod:/src 150214 79244 58952 57% /Volumes/zaphod
So now I understand what's going on. The question is: Why? It seems as if Apple has deliberately broken one of the most important things about the UNIX file system, but only in one view.
I didn't approach Apple with an intention to criticize it. I was really hoping for something good. What I find seems to be a deliberate obfuscation and complication. So far, I'm very disappointed.
| Monday, 7 February 2005 | Echunga | |
| Top of page | ||
| previous day | ||
| next day | ||
| last day |
Into town for Yet Another Meeting today. At any rate, managed to convince Peter that we don't really need to come into town on two different days for meetings with the same people, so this may be the last Monday meeting: the beer bust on Friday is a compelling argument to do the meetings then.
On the way home finally picked up some shelving to install in the Mike Smith Memorial Room, in which I can hardly move any more. Then on to the Alliance Française, about whom I had not known, although they've been in Adelaide for 90 years. They have a number of French video tapes, so there's a good chance we'll decide to become a member.
Catching up with things in the afternoon. These meetings in town really cut into the day.
| Tuesday, 8 February 2005 | Echunga | Images for 8 February 2005 |
| Top of page | ||
| previous day | ||
| next day | ||
| last day |
I've had this program in gdb since Sunday, and I need to get back to looking at what's wrong with it, but so many things got in between that I didn't get round to it. It's not made any easier by the fact that I need a lot of time without interruption to think about it.
Today wasn't the day: first I had nearly 3000 mail messages accumulated since Friday, and secondly the Makefile saga was still giving problems. A quick hack that takes a week to fix. I should know better by now.
Apart from that, finally started doing something about the Mike Smith Memorial Room. The area in the middle was almost impassable:
|
|||||||||||||||||||||||
Moved that out into the library and started putting the shelves together. How ugly they are!
| Wednesday, 9 February 2005 | Echunga | Images for 9 February 2005 |
| Top of page | ||
| previous day | ||
| next day | ||
| last day |
Lots of different things to do today. As planned for yesterday, I finally got round to brewing my two batches of beer, which kept me interrupted for a lot of the day. Also found Yet Another bug in the build process, and spent some time building and running a test suite for it. By the evening there were still some issues with Apple, but since we're not testing on that platform, I thought it better to commit.
Also finished putting the shelving together the Mike Smith Memorial Room:
|
|||||||||||||||||||||||
Now to decide how to utilize the storage space.
| Thursday, 10 February 2005 | Echunga | |
| Top of page | ||
| previous day | ||
| next day | ||
| last day |
Finally time to work on my Monkey bug, the day after the end of the (second) Year of the Monkey. Decided that it would be a good idea to write up the debugging session as an example of how to use gdb, and then set off with the old conditional breakpoint technique to wait for the problem to happen. I never cease to marvel at how much CPU time that takes; apart from slowing down the tested program, gdb itself uses about 50% more CPU time than the program.
That stopped after a while, though: the gdb process hung in a WAIT state. Repeatedly. Finally ran it under ktrace and generated hundreds of megabytes of trace output. I was able to confirm that I could reset the length of the trace file to 0 without problems. Finally it hung again, and I looked at the end of the 172 MB remaining trace file and found that it stopped with:
12325 gdb CALL ptrace(12,0x3026,0xbfbfd5e0,0) 12325 gdb RET ptrace 0 12325 gdb CALL ptrace(PT_STEP,0x3026,0x1,0) 12325 gdb RET ptrace 0 12325 gdb CALL wait4(0xffffffff,0xbfbfd808,0,0)
This is the same sequence that repeats itself thousands of times in the trace: it should continue with
12325 gdb CALL wait4(0xffffffff,0xbfbfd808,0,0) 12325 gdb RET wait4 12326/0x3026 12325 gdb CALL kill(0x3026,0) 12325 gdb RET kill 0 12325 gdb CALL ptrace(PT_GETREGS,0x3026,0xbfbfd5c0,0)
But it didn't: it hung. Looks like a kernel bug, presumably some kind of race condition. This is FreeBSD 6-CURRENT of 14 December 2005, so decided to upgrade to the latest version before complaining. On this old machine that would take several hours, so spent some time tidying up the Mike Smith Memorial Room. It takes quite a bit of thought to decide how to arrange things.
Then into town for a board meeting of the ICT council of South Australia. John Sanders, our new executive director (see my diary entry) is leaving us already, and there was a lot of tidy-up work to do.
| Friday, 11 February 2005 | Echunga | |
| Top of page | ||
| previous day | ||
| next day | ||
| last day |
Finally got my kernel upgrade on quartet finished, rebooted and started to run the debugger. While I was typing, the system froze. Went to look at it and discovered that it had panicked with some ufs panic I had never seen before. sigh.
Off to town after that for another set of Friday meetings. I suppose they're necessary, but they really tear the day apart.
Back home, we had lots of guests. It's a good thing that Yana has left: we needed all three rooms for Sue Macintyre, Pam Hay and Daniel Demuth, all of whom are coming to Olivaylle with us tomorrow.
| Saturday, 12 February 2005 | Echunga –> Olivaylle | Images for 12 February 2005 |
| Top of page | ||
| previous day | ||
| next day | ||
| last day |
Off early this morning in two cars to Olivaylle. We ended up with typical Australian gender segregation: Daniel came with me in the Magna, and the women drove with Yvonne in the Commodore.
In the afternoon a meeting to allow for the formation of a Paso Horse Registry in Australia, not for the first time. Four years ago we did the same thing—and, amusingly, Daniel Demuth was present at the last one too. That didn't take off, and so we're back to a new beginning. Last time round David Yeardley took the chair; since then he got divorced from Chris, so he wasn't here, and this time round Chris asked me to take the chair. A number of other things have changed since then, notably that Jorge now wants a combined registry, something he rejected four years ago. Ended up choosing an initial committee, intended to guide the association to the point where it has enough members to be able to elect a committee. They are: Chairperson Pam Hay, Vice-Chair Diane Saunders, Secretary Chris Yeardley, Treasurer Fiona Mitchell and ordinary committee member Sue Macintyre.
Our domain name phra.org is dead and gone, of course, another victim of a domain squatter. I had opted for ozpaso.org, but Chris didn't like that, so we finally decided on pasocentral.org.
Communal dinner in the evening. Much fun had by all:
|
|||||||||||||||||||||||
| Sunday, 13 February 2005 | Olivaylle –> Echunga | Images for 13 February 2005 |
| Top of page | ||
| previous day | ||
| next day | ||
| last day |
Up relatively late this morning, and after breakfast round to look at all the horses: both Daniel and Sue had never been here before. Then Daniel and I off back home, where I started playing with setting up the Paso registry web sites, while Daniel played with my new Apple PowerBook, installing all sorts of things that I wasn't too sure about.
What I didn't mention here is that we picked up Samba, a Paso Fino filly that Jorge had promised to Yvonne:
Image title: samba 1 Dimensions: 844 x 828, 281 kB Make a single page with this image Hide this image Make this image a thumbnail Make thumbnails of all images on this page Make this image small again Display small version of all images on this page All images taken on Sunday, 13 February 2005, thumbnails All images taken on Sunday, 13 February 2005, small Diary entry for Sunday, 13 February 2005 Complete exposure details
The name “Samba” can cause misunderstandings, of course, and one of my conditions to give her the name was that both Tridge and Jeremy Allison would agree to the name. Hah, thought I, Tridge never answers his mail. But surprise, surprise: both Tridge and Jeremy answered almost immediately and were happy with the name.
| Monday, 14 February 2005 | Echunga | Images for 14 February 2005 |
| Top of page | ||
| previous day | ||
| next day | ||
| last day |
Finally bit the bullet and moved most of my computers to the new rack today. It doesn't fit as well as I had hoped, and the card table with the monitor is decidedly sub-optimal, but at least it has significantly tidied up the place:
|
|||||||||||||||||||||||
Now to decide what to do with the rest. There's an incredible amount of mess there, much of which should be thrown away.
Finished building a new kernel for quartet, and now at least it doesn't panic shortly after boot. But the hang in gdb is still there. Discovered a sysctl to turn off individual CPUs:
=== root@quartet (/dev/ttyp3) ~ 2 -> sysctl -w machdep.hlt_cpus=14
machdep.hlt_cpus: 0 -> 14
This masks off CPUs 1, 2 and 3, leaving only CPU 0 to run. It's quite convenient that you can do it on a running system.
With that, I was able to run and hit my conditional breakpoints. It's obviously an SMP So, do I fix the race condition, or do I put up with it? I entered a bug report, but based on the current state of debugging in FreeBSD, I fear that nothing will happen until I look at it myself, and I don't have time for that.
Found the bug, anyway, and continued investigating. Hopefully it will be downhill from now on.
| Tuesday, 15 February 2005 | Echunga | Images for 15 February 2005 |
| Top of page | ||
| previous day | ||
| next day | ||
| last day |
Gradually the long weekend is winding down, and I was able to continue my debugging, and finally found the bug: an off-by-one error that has been there since the initial checkin on 17 March 1994, and probably since the code was first written in 1991 or 1992. Day 1 bugs never cease to amaze my by their resilience.
After that, continued running the test—not a fast thing on this slow hardware—and by evening it had failed again: I had overflowed a link field (32 k copies of the same data). That will be easy enough to fix.
| Wednesday, 16 February 2005 | Echunga | |
| Top of page | ||
| previous day | ||
| next day | ||
| last day |
More testing today. How slow this machine is! It wasn't helped by the fact that I was reading my source files (many of them) across an NFS link, so decided to set up a local Vinum array to hold the source data. That was more easily said than done. quartet is running FreeBSD 6-CURRENT, so I had to use gvinum, which I haven't used in earnest before.
It wasn't easy: attempts to create new drives kept crashing the system, and most of the dumps I (finally) got were not readable. After a lot of messing around, connected the array to teevee, which is running 5.3-RELEASE, and used Vinum to create the objects. Clearly gvinum still has a way to go.
I heard later from Lukas Ertl, prime gvinum developer, that he hasn't tested gvinum with INVARIANTS set. It looks like a good idea to do so.
After getting the array up and running, spent the rest of the day copying 28 GB of data. I really need faster hardware.
In the meantime, spent some time trying to get my program to compile under Linux. That was more difficult than I thought: on the one hand, I had included BSD-specific code like the functions that produce the ls -l listing, and they pulled in so many non-standard functions that I spent a couple of hours unravelling them. On the other hand, Linux doesn't appear to have any standard functions to convert 64 bit values from big endian to little endian and back. It can use the standard htonl and friends for 16 and 32 bit conversion, but there's nothing like FreeBSD's htobe32 and friends, which include 64 bit variants. Looks like I'll have to bite the bullet and write them.
| Thursday, 17 February 2005 | Echunga –> Sydney | |
| Top of page | ||
| previous day | ||
| next day | ||
| last day |
On with both testing and porting today, making some progress. By late afternoon testing had run into another bug, and I didn't have time to look at it. Things now compile under Linux; I'm always left with the feeling that I'm kludging things to compile under Linux, but I'm assured that this is the right thing to do.
In the evening to Sydney for an AUUG board meeting, coincidentally my first flight with Virgin Blue. I fear they're the sign of the future: American-style no frills service. I suppose we'll survive, but it's lowering the level of service across the industry.
In Sydney, had a late dinner at the “Grace of India” near Milsons Point railway station, a lamb biriani. Not too bad, I suppose, but the meat was just a little tough.
| Friday, 18 February 2005 | Sydney –> Echunga | |
| Top of page | ||
| previous day | ||
| next day | ||
| last day |
AUUG board meeting today, at Sun in North Sydney. For the first time I can recollect, we finished long ahead of time, and I was left with a 4 hour wait for my return flight. The travel agent confirmed that I couldn't change my flight, but since we no longer go out for drinks after the meeting, went to the airport with Mikal Still, and was rewarded by having my flight changed anyway, so I was on the plane within an hour of leaving the meeting.
Back home, my el-cheapo copy of the Hänssler Edition Bachakademie, the complete works of Bach on CD, had finally arrived. The edition is the work of Helmuth Rilling, who is greatly respected, and the CD collection was offered for as little as € 119 (instead of the normal price of € 1349 or the “list price” of € 2900). At that price, I had to buy it, even though I already have the complete works.
The packaging was disappointing: 43 4-CD jewel boxes, each only a little thicker than a normal jewel box. It's nice to save space, but they're of such flimsy construction that nearly all of them had broken CD grips, presumably as the result of transport that left no external signs:
|
|||||||||||||||||||||||
It's unlikely that they would last long even if they had not been broken.
In addition to that, the documentation was of unbelievably bad quality. Apparently earlier copies this edition had come with one or two data CDs with (presumably) more information, but mine came with a booklet (claiming to be in four languages, but in fact only in German) with overviews but no details. It included a number of cross-references to the CD numbers, but they're not the same numbers printed on the CDs (though the sequence appears to be similar), nor the numbers printed on the boxes, which are different again. In itself it is of good quality, but I suspect it has been lifted from the official, expensive distribution.
The text on the boxes themselves is very difficult to follow, and the relatively thick booklets are a real disappointment: they contain nothing but the track list (which is missing on the outside of the box, thus requiring you to dig out the booklet to find anything).
The music? Not too bad. The Brilliant Classics edition is with mainly original instruments, which sounds better to my ears, but the performances here appear to be better.
In summary, it's definitely worth the price. It's just sad that they made so many mistakes in the packaging. I wonder if I can find the data CDs somewhere (not to mention a whole lot of durable jewel boxes).
| Saturday, 19 February 2005 | Echunga | Images for 19 February 2005 |
| Top of page | ||
| previous day | ||
| next day | ||
| last day |
Quiet day. We had intended to do things, but in the end I did almost nothing about from some pottering round the house. Maybe it was the unseasonally gloomy weather.
Spent some time rearranging my CDs—in the last week I have received a total of 264 new CDs, most of them requiring repackaging, and that requires both more shelf space (which I organized today) and more jewel boxes, which are surprisingly difficult to get. I know from arranging the AUUG quarterly CD-Rs that the cost of a jewel box must be less than $0.24 per CD—that's what our replicators charge for them, including putting the CD in the jewel box—but it's almost impossible to find anything for less than double that price, and they don't seem to interest the eBay vendors, who prefer to offer DVD boxes and slimline jewel boxes.
We're still having trouble with mice in the kitchen. Lilac has been good at catching them, but today she showed how selective cats are about catching mice. Yvonne found one in the cupboard, and before she could do much it hid behind some bottles of beer. I brought Lilac in, moved the bottles to one side to show the cowering mouse. Lilac wasn't interested, even when I literally pushed her nose up against the mouse. Then the mouse jumped away—fortunately in a direction that Lilac could follow—and was done for within a second. We've seen other examples of that: it must be the motion that the cats go for.
| Sunday, 20 February 2005 | Echunga | |
| Top of page | ||
| previous day | ||
| next day | ||
| last day |
Another quiet day. Spent rather more time bottling beer than I had intended, but apart from that did surprisingly little.
| Monday, 21 February 2005 | Echunga | |
| Top of page | ||
| previous day | ||
| next day | ||
| last day |
What a day! On Thursday evening I had shut down quartet to save power. Today I rebooted it, started gvinum—and it paniced on me, repeatedly. The dump showed some cryptic comment about a missing plex, but I couldn't make much more of it without digging into the code, which is very different from Vinum. Decided to reboot an older machine with FreeBSD 4.10 and Vinum—but I couldn't find a disk. Grabbed the FreeBSD 4.10 install disk and tried to install on a couple of machines, which didn't want to recognize the disk. Finally found a combination that worked, started Vinum and discovered that there were, indeed, missing plexes on the configuration, relating to the configuration that I was unable to delete on Wednesday (that caused a panic too). Deleted that and reconnected the arrays to quartet, then I could start testing, after wasting half a day.
Also looking at the profiling code that I originally wrote in April last year. I could have sworn that I had got it to compile (though not to run) in December, but I can't find any evidence, and it needed more work done, in the process showing up more problems with the build process. sigh.
It's been quite a moist summer, and one of the results has been a number of mushrooms on the lawn:
|
|||||||||||||||||||||||
Yvonne took some of them to town with her today to find out whether they were edible; nobody was able to confirm or deny. In Germany you'd go to the local chemists' and get a statement, but nobody here seems to know enough. Called up the poisons hotline and was told that, unless I knew what they were, I shouldn't eat them. They couldn't tell me who could tell me what they are. Dragged out an ancient book on mushrooms which suggest that they're Agaricus Campestris, and very edible, but it would be nice to find out for sure. Strangely, the Australian National Botanic Gardens seem to think that they're poisonous.
| Tuesday, 22 February 2005 | Echunga | |
| Top of page | ||
| previous day | ||
| next day | ||
| last day |
Spent the morning chasing another bug that looked surprisingly like the one I fixed last week. In the end it proved to be a “file name too long” error, nothing I'm likely to see in real life.
Apart from that spent some time looking at the intrusive profiling stuff. It's almost working, but I wrote this in a couple of days last April, and it's taking longer to port to Linux than it did to write in the first place.
We're finally trying to get the appearance of our garden improved. Ben Henderson of the Adelaide Hills “Secret Garden” has been doing some work for us, and today he came and told us what he thought we should do with the area to the south-east of the house, up to the pond. It's surprisingly similar to what we had been thinking. It also looks as if it will be surprisingly expensive. Certainly nothing that we'll get finished in the next 12 months, and we're left wondering if there's a cheaper way.
| Wednesday, 23 February 2005 | Echunga | |
| Top of page | ||
| previous day | ||
| next day | ||
| last day |
Came in this morning and found my program still running. It's not exactly a ball of fire, especially on this hardware (old Pentium II with 200 MHz and my old SCSI disks from the Sun disk array).
More discussion about the way we build our software today. I really have a problem with the idea of the Makefile in one directory going into another and building it. It seems that I'm the only one within Rocksoft, though, so ended up reinstating what seems to me to be broken behaviour. As a sanity check, asked on various IRC channels (FreeBSD, Linux and NetBSD). FreeBSD and NetBSD agreed with me; Linux didn't answer. Here the transcript:
FreeBSD:
* groogle poses a philosophical question.
<groogle> Assuming I have two subdirectories in the same source directory.
<groogle> One contains the "application", the other contains a library that supports the
application.
<groogle> If I 'make' in the application directory, what checks should it do about the
library?
<Darius> if it was me..
<Darius> the makefile would only try to link to it and nothing else
<groogle> $ make Darius
<Darius> ie it would expect the library to be built first
<groogle> And what if the library was not there?
<Darius> groogle: *boom*
<groogle> Fail?
<Darius> the link fails, PEBKAC problem
<groogle> OK.
<groogle> Other opinions?
<sjg> um, have the top level makefile traverse into the lib dir first, but the
makefile under the app. directory shouldn't care. or 1 makine?
<sjg> er
<sjg> makefile?
<sjg> makine?
* sjg shrug
<Darius> sjg: that's my opinion, get your own ;)
<sjg> Darius: that's your opinion++
* Darius -> home
<Darius> hehe
NetBSD. On request I've changed the nicks.
* groggy poses a philosophical question.
<groggy> Assuming I have two subdirectories in the same source directory.
<groggy> One contains the "application", the other contains a library that supports the
application.
<groggy> If I 'make' in the application directory, what checks should it do about the
library?
<foobar> heh
<tbazz> groggy: i woudl say ideally nothing. the top level should descend into the
directories below it and those Makefiles (or whatever) should make sure
whatever needs to be done is done
<groggy> Right, but this Makefile is not in the hierarchy.
<groggy> i.e. I have two directories, app/ and lib/.
<groggy> app/ depends on lib/.
<bar> yeah, apart from checking that the libs it needs have been made and installed
already, at least in an objdir
<groggy> So if I say 'make' in app/, and lib/ hasn't been built, what should happen?
<groggy> These are static libraries, so they get linked from their build directory
<bar> then make should fail with something like 'don't know how to make ../lib/foo.a'
i guess
<groggy> OK, thanks.
<bar> (a common objdir might help)
<groggy> Right.
<groggy> I'm just trying to DTRT.
<bar> if foo.a is likely to be a standalone lib as well, optionally compiled if not
already present on the platform, then you probably have configure fun
<groggy> This is all application.
<bar> but that configure lives in the parent dir
<groggy> Consider it to be a package.
<groggy> Yes, that's my view too.
<bar> yah, if it's statically linked, it's less likely to be such
<uep> bbl
<anon> oi
<anon> groggy; we do that type of things in various parts of the netbsd build
<anon> the "toplevel" makefile usually does
<anon> SUBDIR = libdir .WAIT appdir1 [...] appdirn
<anon> .WAIT is bsd.subdir.mk magick to ensure libdir is built before the rest
<groggy> anon: Yes, that's fine.
<groggy> Now what happens if somebody goes into appdir and does a 'make' there before
libdir has been built?
<anon> groggy; dunno if freebsd's bsd.subdir.mk has that syntax
<anon> it fails
<groggy> anon: This isn't FreeBSD. This is at woork.
<anon> using what make infrastructure? custom gnu make ?
<groggy> I'm just trying to DTRT.
<groggy> Yes, as it happens.
<groggy> But I don't think that makes any difference.
<groggy> Well, s/custom //
<anon> you _could_ put a rule in the appdir makefile that automagically builds the lib
if it's missing. i'm not sure it's worth doing, myself
<groggy> That's what people at work want to do.
<groggy> It seems wrong to me.
<anon> so build the lib in the same dir and use normal make dependencies
<anon> or are there multiple app dirs ?
<groggy> And I'm just looking for other opinions.
<groggy> Yes, there are multiple (2) app dirs.
<anon> add a dependency rule then
<groggy> Sure, that's easy.
<groggy> The question is, is it correct?
<anon> by what definition of "correct"? "stylistically correct?" :)
<groggy> Yes, for want of a better term.
<anon> depends on the project, really
<anon> in netbsd we don't bother
<anon> for a homegrown project using your own make infrastructure with sooky & lazy
developers, it's probably "correct"
<groggy> OK :-)
My program was still running in the evening. What a snail!
| Thursday, 24 February 2005 | Echunga | |
| Top of page | ||
| previous day | ||
| next day | ||
| last day |
Came into my office this morning, and the my program test was still running. It finished fairly soon, but 48 hours is ridiculous. Spent the rest of the day preparing for a second set of tests for comparison. That wasn't as easy at it sounded: gvinum reacts very unfriendlily to having drives go away, and I couldn't start vinum on FreeBSD 6.0 because a function that it needs has gone away, so first had to install 5.2.1. Then the copy of the files (another 20 GB) took half the day at full disk speed. I need faster hardware.
| Friday, 25 February 2005 | Echunga | |
| Top of page | ||
| previous day | ||
| next day | ||
| last day |
Spent most of the morning researching faster hardware. It looks like the AMD Opterons are getting quite reasonably priced, especially for the slower models (currently a Opteron 242, dual processor capable, costs $379; a 250 costs $1229 and is 50% faster than the 242). Unfortunately, there are motherboard issues, and more importantly, there is no stock.
Meetings in the afternoon again. 14 people for half a day makes 7 man days. There must be a faster way.
| Saturday, 26 February 2005 | Echunga | |
| Top of page | ||
| previous day | ||
| next day | ||
| last day |
Weekends seem to be quieter nowadays. Or at least I thought so. Then I realized what I had to do:
For once, I didn't have any beer to brew. I also didn't get much of the list completed.
Made quite some progress with the Mike Smith Memorial Room, but basically I just have too much stuff. I wonder how many of those big old 21" monitors actually work.
The DVDs were quite another matter. They had been recorded on my flaky Digitrex DVD recorder, and it couldn't play them back. I had already noticed that computers did a better job, and mplayer on FreeBSD plays them with no problems beyond its emetic user interface.
Today I decided to play them in the Apple—after all, that's what it's supposed to be good for. It's always difficult to guess what to do to play something, since there's no documentation, and obviously I don't have any “intution”, but after a while it became clear that there was no DVD player software installed on the machine. Finding out why that was so, and what to do about it, was a nightmare.
The pitiful excuse for documentation told me that it was installed automatically if the hardware was present, and how to detect if a DVD drive was connected to the machine. In the latter case, you'd expect the instructions to read “examine the drive and see what's written on it”, but instead I was taken through a maze of twisty little menus, all different, with the intention of finding whether the system thought it did in fact have a DVD player. The instructions didn't go as far as to say how you could tell, but everything seemed to indicate that the system did in fact agree that the hardware was installed.
OK, then, it should be simple enough to find the package and install it—I thought. In fact, another tiring search of the installation media showed nothing obvious; later somebody pointed out that it was in the directory "//Volumes/Mac OS X Install Disc 1/System/Installation/Packages/Essentials.pkg" (how I hate these stupid file names with spaces in them!). Tried to install that, but since I had in the meantime upgraded the system, it refused to install. Somebody sent me a “Stuffit” (what an appropriate name!) archive, but for some reason there was an incompatibility there, and I couldn't install it. After three hours I gave up. Apart from being incredibly frustrating, I'm always left wondering whether the problem is with the Apple machine or with me: millions of customers can't be wrong. I suspect that a generation of using menu-driven software has taken its toll, and vendors expect you to understand it, like they expect you to be able to read and write. It's a pity, though, that they've chosen such a horribly difficult and hard to use paradigm.
In connection with documentation problems it is interesting to note a couple of books I found while tidying up the Mike Smith Memorial Room: a total of rather more than 200 pages on how to use the “Microsoft Mouse”, dated 1984, and including detailed programming information. Times have changed, but not for the better.
Dinner was to be a lamb biriani, not the first time I've cooked one, but the first time I've tried to improve on it and get some alternative recipes. The results were quite good, and I ate far too much.
| Sunday, 27 February 2005 | Echunga | |
| Top of page | ||
| previous day | ||
| next day | ||
| last day |
What a day! All I wanted to do was to play a DVD on some computer. I failed.
First I continued with the Apple. Since I couldn't find a way to install the Apple DVD player program, installed VLC instead—once I had worked out how to do that. The instructions suggest that you drag part of the archive into the /Applications directory. It took me 5 attempts to get it to go there. When I did, I couldn't work out how to start it. It seems it hides some stupid image in the “task bar” at the bottom of the screen, and some undocumented mouse click brings it to the foreground. When I did, I couldn't get it to recognize the DVD (“no DVD present”; is it talking about the medium or the drive?). Inserting a pre-recorded DVD caused a delay (and no indication that anything was going on), followed by the disk being ejected. After searching in the the help, found a hidden menu to specify the action to take on DVD insertion, and set that to start VLC. No difference. Round about now I decided that there might be something wrong with the DVD drive, but it mounted data DVDs perfectly. Removed the drive and took at look at it: “Macintosh PowerBook G3 Series 2X DVD-ROM Module”. My best guess now is that the drive really doesn't support video DVDs, but there's nothing in the appalling excuse for documentation that mentions this possibility.
While working with the Apple, also upgraded to the latest version of MocOS X. In the process, it disabled my uControl keyboard remapping, not that that was so serious: it works very badly, leaving the Control key locked on after pressing. The result is that the next time I type a d at the beginning of the line, the terminal window disappears. But now it didn't do anything: it had been disabled and refused to load. It did offer to find a new version for me, and told me, yes, there is a new version. No offer, help or instructions to replace the version. I'm continually baffled by how bad this stuff is.
Gave up on Apple and tried installing VLC on eucla, my FreeBSD laptop. Once again ran into this bug:
I had seen that before. It means that you have to install from a local disk. After that, got it installed, but when I started it, I got a whole series of this kind of error message:
Reinstalled pango, after which the program started with the following message and empty menus:
libdvdnav: Language 'en' not found, using 'ÿÿ' instead libdvdnav: Menu Languages available: ÿÿ
At this point, decided that Linux might be better. Tried booting eucla under Linux: I had installed Fedora Core 2 on it last August, but now it wouldn't boot with some obscure error message. Since there had been problems with the X configuration anyway, decided to install Fedora Core 3. The first time tried an upgrade, with the result that, after nearly an hour, the reboot failed with a “Kernel Panic”—where do they get that name from? It looks more like a kernel halt to me, with no information about where it happened. Did a clean install and was rewarded by X still not being able to recognize the hardware. I have no idea why: the same software installed out of the box on FreeBSD last July.
Gave up on Linux and returned to FreeBSD. It was fairly obvious that some of my ports were out of date. Running portupgrade did nothing useful, so with the help of pkg_info -r found the dependencies (all 74 of them!) and removed them, then started reinstalling them. By the time I went to bed I had got as far as multimedia/ffmpeg:
texi2html -monolithic -number ffmpeg-doc.texi env: perl: No such file or directory gmake[1]: *** [ffmpeg-doc.html] Error 127
Just a missing dependency. But it's really getting beyond a joke just trying to build ports nowadays.
| Monday, 28 February 2005 | Echunga | |
| Top of page | ||
| previous day | ||
| next day | ||
| last day |
The Apple DVD player problem has a solution. Spoke to the bloke who sold it to me on IRC:
-> *vendor* I'm having difficulty playing DVDs on the PowerBook. Any ideas?
*vendor* I think you'll need to be running OS9 for DVD playback - at least that was the
only way I could make it work
-> *vendor* Hmm. Interesting.
*vendor* The PB has hardware accelleration for DVD decoding but Apple only elected to
support it under OS9
-> *vendor* Ah.
-> *vendor* Nice for them to document that, isn't it?
*vendor* I didn't use it much, ended up getting a "real" DVD player
* -> vendor: groggy notes that Apple doesn't seem to think much of documentation anyway.
*vendor* Yes, it's one of those documented by omission sorts of things
-> *vendor* OK, I'll give up then.
-> *vendor* In general, I find MacOS X to be impossibly badly documented.
*vendor* Sorry, I didn't think to mention that at the time
*vendor* (DVD playback, not OSX documentation :)
-> *vendor* No worry. It serves its purpose.
*vendor* Yeah, it is a bit light on for a "power" user
* -> vendor: groggy notes that some purposes are to be a bad example.
OK, this is an old machine (4 years), so this is all water under the bridge. I suppose it upset a number of people at the time, though. But, as I said on IRC: the documentation, such as it is, doesn't mention the possibility that some DVD drives are not supported under MacOS X. Another reason to dislike the machine.
Yvonne went into town and brought me back a couple of 200 GB disk drives today, finally allowing me to test my program under more typical conditions. I'm still waiting on the new dual Opteron box to run them (special order), so I had to put them into my long-suffering teevee machine, the one that was really intended to—coincidentally—play DVDs on the lounge room TV. That worked better than I expected, and it started off working at least as fast as our existing product, though as expected the performance fell off rapidly. Still, relatively encouraging results, somewhat marred by the discovery of yet another insertion bug.
Do you have a comment about something I have written? This is a diary, not a “blog”, and there is deliberately no provision for directly adding comments. It's also not a vehicle for third-party content. But I welcome feedback and try to reply to all messages I receive. See the diary overview for more details. If you do send me a message relating to something I have written, please indicate whether you'd prefer me not to mention your name. Otherwise I'll assume that it's OK to do so.
| Top of page | Previous month | Greg's home page | Today's diary entry | Next month | Greg's photos | Copyright information |