Thursday, 1 May 2003	Echunga	Images for 1 May 2003
		Top of page
		next day
		last day

Got a message from Andy Oram this morning. My book is in print! Hopefully it will do well.

More work on Vinum this morning, and committed a large number of changes, some of which came back to bite me in the evening. There should be a better way to handle checkins. Spent a bit of time checking the drive discovery code, which seems to be just plain broken. In the process found problems with the debugging tools, which I think I probably need to fix before I continue with Vinum.

Friday, 2 May 2003	Echunga
		Top of page
		previous day
		next day
		last day

Another quiet day. Spent some time thinking about how to rewrite the Vinum startup code: currently it gets started one way at boot time, and a different way if you start it later. Didn't get very far with that. I need to think more first.

Saturday, 3 May 2003	Echunga
		Top of page
		previous day
		next day
		last day

Finally got round to writing the code I was thinking about yesterday. It was probably worth holding off; things looked a lot clearer today, and if it weren't for the incredible slowness of zaphod, I'd have been able to test it. As it is, the combination of debug code in the kernel, slow processors (466 MHz Celeron) and continual hangs in SMP mode meant that it took all day. In the meantime played around with debugging tools, which are also in need of work.

Sunday, 4 May 2003	Echunga
		Top of page
		previous day
		next day
		last day

More work on Vinum today. Discovered that newfs support for Vinum volumes is broken yet again. I wish people would test their changes before committing them. Finally got the rewrite of the configuration finished and committed, and turned my attention to the question of read policies: when you have a volume with more than one copy of the data, it's usually better for performance if you read from each copy in turn, so called round-robin access. VERITAS has a thing called read policies, where you read from the same plex every time, and for some reason I tried to implement it when I wrote Vinum. Unfortunately, it was broken, and for some reason some people want to have it. I had a patch which did half the job, but the other half needed to be written, which took most of the day. In the process, gradually refined my kernel debugging macros.

Monday, 5 May 2003	Echunga
		Top of page
		previous day
		next day
		last day

Still more work on Vinum today, and finished the read policy stuff. Managed to commit everything before the code freeze--I thought. It turned out that something went wrong with a commit and broke world yet again. Somehow this commit method is just too fragile.

Tuesday, 6 May 2003	Echunga
		Top of page
		previous day
		next day
		last day

Code freeze for FreeBSD 5.1 started today, not without some reports of breakage in Vinum. Spent the rest of the day catching up with things I had left lying while doing the coding.

Wednesday, 7 May 2003	Echunga	Images for 7 May 2003
		Top of page
		previous day
		next day
		last day

Sigh Despite the feeling that everything was going well with the Vinum changes, came into the office this morning and discovered a number of people reporting hangs in Vinum. Spent some time looking at that, somewhat hampered by other events. Fiona from Tudor Park came over looking for somewhere to put some horses while they sprayed their paddocks. Sorted that out, then off riding with Yvonne.

Back home and found that I had managed to put not one but two deadlocks in the Vinum configuration process. How did I ever manage that?

Thursday, 8 May 2003	Echunga
		Top of page
		previous day
		next day
		last day

Finally managed to check in the fixes to Vinum today, and confirmed that they fixed the problems. About time too. After that looked at an issue with growfs, another casualty of the GEOM migration, and came to the conclusion that the patch I have been given did in fact work, but it looks as if growfs needs rewriting, or, better, merging with newfs.

Yana back in the evening with a CD-ROM which FreeBSD didn't understand. Microsoft had no problems. I thought it might have something to do with the Joliet format, but it seems that Joliet's not a problem. Another thing to look at. Also started work on an idea for a new, very short book. I have a theory that the time it takes to write a book is an exponential function of its size, so this one should be finished pretty quickly.

Friday, 9 May 2003	Echunga
		Top of page
		previous day
		next day
		last day

Mail is piling up, but I can't be bothered. I'm getting through the important messages, but the daily grind of 1000 odd routine messages takes less time if I batch the messages to two or three times a week. I think.

Playing around with short books again today. It's interesting how quickly I can get these things put together. I'm aiming for a single-topic book of somewhat less than 100 pages, and managed to get 35 pages together in the day, mainly derived from Daemon News. Certainly it's a lot easier to write a short book, which by definition must contain a lot of undefined references, than it is to write a long book and put all the material in the right place.

Saturday, 10 May 2003	Echunga
		Top of page
		previous day
		next day
		last day

Today I still didn't feel like doing the things I should be doing, so instead played around with audio recording. That took a surprising amount of time: the programs I found all had minimal documentation at best, and there is very little documentation about the subject. It seems that most people use sound hardware to play back existing files rather than to create new ones, and even then it's usually just importing from CD. None of the documentation I found gave a clear answer about which file to read the data from, though it appeared to be /dev/dsp. Unfortunately, all programs I tried got a “device busy” error from the driver, although I'm pretty sure that nothing had the device open. Looks like yet another case for kernel debugging, maybe only to make up for deficient documentation.

Sunday, 11 May 2003	Echunga
		Top of page
		previous day
		next day
		last day

More work on the sound driver today, and after delving deep into the kernel, came to the strange discovery that there were no input channels on the Codec. Pondered that for a while, but didn't do much.

Message from Ted Unangst, from the OpenBSD project, who found himself at a loose end and decided to port Vinum to OpenBSD. Gave him the sources for the NetBSD version, and to my surprise had a reply within a few hours saying that he had managed to build it. That's quite impressive.

Helping Yana with OpenOffice spreadsheets in the evening. My aversion to OpenOffice is growing, as is my conviction that spreadsheets are a Bad Idea. There should be a more reliable way to do these things.

Monday, 12 May 2003	Echunga
		Top of page
		previous day
		next day
		last day

The day got off to a bad start. I had to access web pages on the AUUG web server, and they took forever, over a minute to arrive. Spent some time investigating and discovered that requests were taking exactly 75 seconds to complete. Another thing about the tcpdump output was more important, though: it didn't resolve the IP 192.109.197.81, battunga.lemis.com. A little further investigation showed that, although my own reverse domain was working fine, the parent domain (109.192.in-addr.arpa.) was not. That's run by DENIC, and their name server setup leaves much to be desired. whois finds:

OrgName:    Universitaet Karlsruhe
OrgID:      DENC
Address:    Am Fasanengarten 5
Address:     Inst.  fuer Betr.- und Dialogsysteme
Address:     D-7500 Karlsruhe
City:
StateProv:
PostalCode:
Country:    DE

NetRange:   192.109.0.0 - 192.109.255.255
CIDR:       192.109.0.0/16
NetName:    NETBLK-UNIDOBLOCK
NameServer: NS.NIC.DE
NameServer: XLINK1.XLINK.NET
NameServer: NS.RIPE.NET
Comment:
RegDate:    1991-05-01
Updated:    1998-09-30

Look at that last update date. In the meantime, xlink1.xlink.net is no longer authoritative, and ns.ripe.net doesn't answer any queries. ns.nic.de was down, something I can't do much about. Grrr. It would seem that it wouldn't have been so bad if their registration information were correct: the SOA record refers to three other name servers:

$ nslookup -q=soa 109.192.in-addr.arpa.  ns.nic.de.
Server:  dns4.denic.de
Address:  194.246.96.59

109.192.in-addr.arpa
        origin = ns.nic.de
        mail addr = ops.denic.de
        serial = 2003051201
        refresh = 10800 (3H)
        retry   = 1800 (30M)
        expire  = 3024000 (5W)
        minimum ttl = 86400 (1D)
109.192.in-addr.arpa    nameserver = ns.nic.de
109.192.in-addr.arpa    nameserver = dns9.denic.de
109.192.in-addr.arpa    nameserver = dns11.de.net
109.192.in-addr.arpa    nameserver = dns14.de.net

That doesn't make much difference, though. They're not authoritative either.

Got hold of Cameron Grant on IRC, who told me that my sound chip problems were due to the driver, which doesn't support input. The Linux driver does. Looks like I'm in for some coding.

Spent most of the afternoon helping organize the AUUG elections. The ballot papers were supposed to go to the printers today, and we had the usual last minute changes. Apart from that, investigating running Vinum on md devices, which currently doesn't work. It's difficult to find things because the kernel debugger keeps creating "fatal" trap messages which completely obscure the console output, so put in a patch to stop that. Kernel building takes such a long time nowadays that I didn't get round to anything else.

Tuesday, 13 May 2003	Echunga
		Top of page
		previous day
		next day
		last day

Carried on with testing today, in particular getting Vinum to work with md devices. The surprising thing was: it does. It took a long time to discover that, however: I had been using swap-backed md devices, which have the nice property of only requiring backing for those pages which are actually used. As a result I was able to create md devices many terabytes in "size", and even newfs and mount them:

Filesystem 1048576-blocks Used   Avail Capacity  Mounted on
/dev/md0          2063175    0 1898121     0%    /mnt

Unfortunately, they have a "sector" size equal to the VM page size, which I suppose is understandable, and though the block IO layer seems to be happy with that, Vinum isn't (yet). Tried file-based backing and it worked fine, but I first had to create backing files in the full length of the device, which is a bit of a nuisance.

Wednesday, 14 May 2003	Echunga
		Top of page
		previous day
		next day
		last day

On with the testing this morning, and after a reboot zaphod consistently didn't make it to multi-user mode: it panicked with a message that freed memory had been modified (“last use was devbuf”). Spent some time investigating that, including enhancing the debug support, and found that yes, indeed, it was in Vinum, a bug which must have been there more or less since day one, and yet had never been discovered. Fixing it's another problem, but I was pleased that the debug tools were so useful.

In the early afternoon, Yvonne returned with a new monitor to replace the ageing iiyama which I was unable to get repaired in March. In view of the fact that we'll soon see cheap high resolution LCD displays, and that this particular one only needed to do 1600x1200, decided on a 19" monitor rather than a 20" monitor; the difference in price is something like 3 to 1. Ended up with an LG Studioworks 900B. You can certainly tell that it's cheap: it came without any real instructions. The instructions on the CD-ROM referred to most of LG's monitors, but not to this one. I had to google to find the specs. Apart from that, it seems to be OK, though it exudes a surprisingly strong smell of warm circuit board. Hopefully it won't catch fire.

While moving monitors around, managed to dislodge the output cable of my USP, taking down three of my machines with the longest uptime. From the day before:

echunga       up  77+07:37,     0 users,  load 0.14, 0.34, 0.25
flame         up 143+10:27,     0 users,  load 0.16, 0.12, 0.16
wantadilla    up  77+07:36,     0 users,  load 0.01, 0.06, 0.05

Growling, decided that this was the time to install in echunga the new CD burner which Yvonne had also brought back. That worked fine, but the two existing CD drives (SCSI) didn't. Spent a couple of hours investigating that before coming to the conclusion that both of the drives had died, presumably during the power failure. That in itself wouldn't be do bad, since one of them was failing anyway, but it meant I only had one CD-ROM drive on the system, and thus wouldn't be able to play audio CDs without interruption. I couldn't put another IDE CD-ROM on the system, because it already has 3 disks and a (new) CD drive. I'll have to scavenge an old SCSI drive.

In the evening to the AUUG SA Chapter meeting, which was also the committee election. David Bullock stood down as chairman, since he's planning to move to New South Wales. We ended up deciding on a smaller committee, with Luke Schapel as chairman, Ben Close as secretary (again) and Andrew Rutherford as other member.

Thursday, 15 May 2003	Echunga
		Top of page
		previous day
		next day
		last day

Up this morning and spent some time putting echunga back together. Found an old Tohsiba SCSI CD-ROM drive and confirmed yesterday's assumptions that both the other CD-ROM drives had died. Spent some time messing around with cables, host adaptors and CD-ROM drives and finally came to the conclusion that the best solution would be my old Nakamichi CD-ROM changer (built in November 1994, as it said on the back of the drive). I was able to mount that externally, thus getting rid of the mess of cables round echunga, and also moving it further back under the desk. This whole issue has been an incredible waste of time, but at least things are now marginally tidier.

Working on Vinum, discovered that my assumptions about the cause of the errors were incorrect. It's rather amusing how the error was discovered. On freeing memory, a diagnostic kernel build option fills each work in the block of memory with the value 3735929054, which in hexadecimal reads 0xdeadc0de. When allocating, it checks if the values were still there. In this case, they weren't all. The memory block in question was 2048 bytes long and started at offset 0xc1b4e800:

0xdeafc0de? Well, it's an amusing twist. But where was it located? From where it was allocated, I knew that this block once contained 8 entries of struct drive, and that on expanding the table they had been copied to a new area of memory. Narrowing it down, I found

(gdb) p ((struct drive *)0xc1b4e800)[5]
$15 = {
  devicename = "ÞÀ­ÃžÃžÃ€­ÃžÃžÃ€­ÃžÃžÃ€­ÃžÃžÃ€­ÃžÃžÃ€­ÃžÃžÃ€­ÃžÃžÃ€­Ãž",
  label = {
    sysname = "ÞÀ­ÃžÃžÃ€­ÃžÃžÃ€­ÃžÃžÃ€­ÃžÃžÃ€­ÃžÃžÃ€­ÃžÃžÃ€­ÃžÃžÃ€­Ãž",
    name = "ÞÀ­ÃžÃžÃ€­ÃžÃžÃ€­ÃžÃžÃ€­ÃžÃžÃ€­ÃžÃžÃ€­ÃžÃžÃ€­ÃžÃžÃ€­Ãž",
    date_of_birth = {
      tv_sec = 0xdeadc0de,
      tv_usec = 0xdeadc0de
    },
    last_update = {
      tv_sec = 0xdeadc0de,
      tv_usec = 0xdeadc0de
    },
    drive_size = 0xdeadc0dedeadc0de
  },
  state = 3735929054,
  flags = 0xdeafc0de,
  subdisks_allocated = 0xdeadc0de,
  subdisks_used = 0xdeadc0de,
  blocksize = 0xdeadc0de,
  pid = 0xdeadc0de,
  sectors_available = 0xdeadc0dedeadc0de,
  secsperblock = 0xdeadc0de,
  lasterror = 0xdeadc0de,
  driveno = 0xdeadc0de,
  opencount = 0xdeadc0de,
  reads = 0xdeadc0dedeadc0de,
  writes = 0xdeadc0dedeadc0de,
  bytes_read = 0xdeadc0dedeadc0de,
  bytes_written = 0xdeadc0dedeadc0de,
  active = 0xdeadc0de,
  maxactive = 0xdeadc0de,
  freelist_size = 0xdeadc0de,
  freelist_entries = 0xdeadc0de,
  freelist = 0xdeadc0de,
  sectorsize = 0xdeadc0de,
  mediasize = 0xdeadc0dedeadc0de,
  dev = 0xdeadc0de,
  lockfilename = "ÞÀ­ÃžÃžÃ€­ÃžÃžÃ€­ÃžÃžÃ€­Ãž",
  lockline = 0xdeadc0de
}

At this point I should have pasted it in to an editor, but I didn't, since I thought it was in one of the fields not represented in hex. Instead I did some successive approximation:

So there it was. Something had tried to set a flag in the old copy of the drive data after expanding the table. The value it set was evidently 0x20000 (0xdeafc0de - 0xdeadc0de), which is the constand VF_CONFIGURED. That is only ever set in vinum_scandisk:

    drive->flags |= VF_CONFIGURED;              /* this drive's configuration read  */

The code caters for the possibility that the drives will move and reinitializes the pointer, but still it happened. I'm still puzzled.

Friday, 16 May 2003	Echunga
		Top of page
		previous day
		next day
		last day

I can't believe it. After filing a suit against IBM back in March, SCO has now sent out a letter to their customers telling them that Linux contains UNIX source code. I'm completely dumbfounded. Spent some time writing up my own version of things. In particular, it's interesting to note how SCO's stock has increased in value since the initial suit against IBM.

More work on the bug in Vinum, which is still eluding me. Rather than attack it head on, spent some time getting my debugging tools up to scratch, since I'll need them anyway for a couple of tutorials in September. At least the ps command works now.

John Westlake around in the evening with the results of some soil tests we did a few weeks back. Greg Edmonds had wanted to put some superphospate on the paddocks to fertilize them. The soil test showed that the soil was far too acid and almost completely lacking in calcium and magnesium (pretty much what John had said when he looked at the vegetation), but had 2.5 times as much phosphorus as it should have. Good thing we did the test; now we'll have to spread the appropriate bases and fertilizer.

Saturday, 17 May 2003	Echunga
		Top of page
		previous day
		next day
		last day

How I love these days when I come into the office and something has gone seriously wrong! Today I had almost mail, and a bit of investigation showed that mail was not coming in from FreeBSD.org. A bit of investigation showed that some of the changes I had made to the DNS configuration recently were wrong: I used to have the (hidden) master local name server on echunga, which also has the PPP link, so all local queries went out the slow link and came back that way, which was also more expensive. I had changed the master name server to battunga and made echunga a slave, but I hadn't changed the configuration for the three visible name servers on the net, and they had apparently not been able to update the configuration from a slave name server. Did some messing around and found for some reason that the name server on battunga wasn't responding, perhaps because sat-gw, my Linux satellite receiver, had hung itself up yet again. Even after rebooting sat-gw, things didn't work too well. Finally gave up and started a "master" name server on echunga for the express purpose of serving the remote name servers. But mail from FreeBSD.org still didn't come in. After some investigation, discovered a couple of problems on mx2.FreeBSD.org which coincided with my problems. After Peter fixed that, mail started arriving far faster than spamassassin could process it, and it was hours before it was actually delivered.

After that, didn't feel much like doing real work, and spent a bit of time typing in the of rather strange story of how I first moved from England to Germany. It's amazing how much detail I lost in the diary.

Sunday, 18 May 2003	Echunga
		Top of page
		previous day
		next day
		last day

Keeping up with mail is becoming more and more of a problem, especially when, as today, I had most of yesterday's mail to handle as well. That kept me busy for quite some time.

Apart from that, back to finding the Vinum bug that I've been looking at all week. Most of the delay was due to my hopes of using it as an example for the debug tutorial. Finally it turned out to be pretty much what I had thought:

vinum_scandisk is called with a list of drive names. It goes through each of these drives looking for Vinum partitions and allocates drive entries for anything that looks like a Vinum drive, and in the process it may expand the drive table, which thus changes its address. As a result, I'm careful not to use pointers in this code.

Next it sorts the drive list by last modification date and goes through it reading in the configuration. In this loop I had a pointer to the current drive, since we already had the list of drives. What I had forgotten was that there may be references to non-existent drives. In this case, parse_config will allocate a reference to a drive. In this particular case, there was a referenced but not present drive, and adding it to the list caused the size of the list to increase. That was easy enough to find, but how do you teach it?

Monday, 19 May 2003	Echunga
		Top of page
		previous day
		next day
		last day

Adelaide Cup today, and a public holiday. Somehow I didn't feel like doing computer work, so took a look at the 10 or so packing cases left in the library. It's been nearly four years since we moved into the extension to the house which contains the library, and over 6 years since we packed the cases before leaving Germany. They were mainly old files and things, some dating back to the early 70s. Found a printout of a PDP-8 disassembler that I had written in early 1971 and since completely forgotten about, along with a lot of other things.

The weather was terrible today. We had some of the worst rain we've seen in some time, along with some hail which clogged up the gutters and caused them to overflow into the roof. Spent some time on the roof cleaning them out again. The water tank, which had been full already, was overflowing faster than I've ever seen it.

Tuesday, 20 May 2003	Echunga
		Top of page
		previous day
		next day
		last day

After all of yesterday's rain, the Bureau of Meteorology's daily daily rainfall bulletin showed no rainfall for Echunga. I wonder if these are the same data that go into their statistics. I often notice that they're missing entries. Meadows, the same distance in the other direction, reported 15 mm. I'm sure we got more than that.

Suddenly realized that I have a number of documents to write: the AUUG President's report for this weekend's board meeting, a column for AUUGN, and both a tutorial (kernel debugging) and a paper ("Why I hate OpenOffice") for AUUG 2003. Did the first and half finished the second, which will address the legal issues surrounding UNIX, with specific reference to this SCO nonsense.

Another panic in Vinum, pretty much like the first one. Spent some time looking at that, but didn't come to any useful results.

Wednesday, 21 May 2003	Echunga
		Top of page
		previous day
		next day
		last day

Carried on all day working on the latest Vinum bug. I deliberately took it slower than I have been doing so far so that I could have a good example for my debug tutorial. It turned out to be one: this time I ended up modifying data in a freed plex table. It wasn't me, it was something else changing a mutex. Since I had just copied the table to a new location, the mutex list linkage remained unchanged pointing to the old area. Ugly. In view of the fact that the mutex was only required at all to give finer grained locking for the stripe lock table than the splhigh() which older versions had, it seemed reasonable to map the plexes onto a statically allocated group of 32 mutexes, so ended up doing that. I'm astounded how many bugs I've found in Vinum in the last couple of weeks. Hopefully there aren't too many more lurking.

Thursday, 22 May 2003	Echunga
		Top of page
		previous day
		next day
		last day

Quieter day today. Spent all day building the latest FreeBSD version on zaphod prior to committing yesterday's fixes, and in the meantime attended to various less urgent matters which have been piling up, and even managed to get my office looking not quite as untidy.

Friday, 23 May 2003	Echunga
		Top of page
		previous day
		next day
		last day

I never fail to wonder at how many broken mail servers there are out there. Lately we've been having a lot of spam (or possibly breakin attempts; I never look at it) with a spoofed address support@microsoft.org. This stuff gets rejected by postfix, unfortunately often with an error message to the purported sender. Today I got this:

Date: Fri, 23 May 2003 05:03:13 +0930 (CST)
From: MAILER-DAEMON@lemis.com (Mail Delivery System)
To: postmaster@lemis.com (Postmaster)
Subject: Postfix SMTP client: errors from mailb.microsoft.com[131.107.3.122]

Unexpected response from mailb.microsoft.com[131.107.3.122].

Transcript of session follows.

 In:  220 inet-imc-04.redmond.corp.microsoft.com Microsoft.com ESMTP Server
     Thu, 22 May 2003 12:33:45 -0700
 Out: EHLO wantadilla.lemis.com
 In:  250-inet-imc-04.redmond.corp.microsoft.com Hello [192.109.197.80]
 In:  250-TURN
 In:  250-ATRN
 In:  250-SIZE 5242880
 In:  250-ETRN
 In:  250-PIPELINING
 In:  250-DSN
 In:  250-ENHANCEDSTATUSCODES
 In:  250-BINARYMIME
 In:  250-CHUNKING
 In:  250-VRFY
 In:  250-XEXCH50
 In:  250-X-LINK2STATE
 In:  250 OK
 Out: MAIL FROM:<> SIZE=51589
 Out: RCPT TO:<support@microsoft.com>
 Out: DATA
 In:  250 2.1.0 <>....Sender OK
 In:  501 5.5.4 Invalid Address
 In:  503 5.5.2 Need Rcpt command.
 Out: RSET
 Out: QUIT
 In:  250 2.0.0 Resetting

This is a genuine response from Microsoft's mail servers. They can't make up their mind whether the message I'm trying to send is valid or not (it is), and send contradictory messages.

Spent the morning tidying up a little, then into town to meet Liz Carroll and Gordon Hubbard for a pre-board meeting briefing. Normally we have these meetings at my place, but today Gordon had a brief meeting in town, and we were intending to pick Pia Smith up from the airport at 5:40, so we planned to stay in town. Pia was delayed, however, and Liz had broken off a heel from one of her shoes, so off to Mount Barker to get that repaired. By the time we got back, it was 6 pm, so we hardly had any time to talk.

Pia arrived at 8:30 pm, and spent the evening talking about the differences and similarities between AUUG and Linux Australia.

Saturday, 24 May 2003	Echunga
		Top of page
		previous day
		next day
		last day

Into town early for todays AUUG board meeting, in the beginning of which Pia participated. Decided we didn't really know who our members were, and that it was time to do another survey. We probably should get SAGE-AU involved as well.

Nothing else of great importance happened during the meeting, after which off to the Oostende pub yet again, and met Pia there. On the way home, got a phone call from the Henley Beach police station; somebody with a car with my registration and similar appearance had filled up at a petrol station and not paid about 30 minutes before. That would have to happen at a time when theoretically I could have been there; fortunately I had been with witnesses all the time, and Pia was able to confirm that my tank was only ¼ full. The police bloke seemed happy enough with what I had said too, so we may hear no more.

In fact, we did hear more, though I forgot to report it at the time: they really did have my registration plate. A couple of days later I found that the front plate was missing, and I had to get new plates.

Sunday, 25 May 2003	Echunga
		Top of page
		previous day
		next day
		last day

Up earlier than normal today for the "early barbecue". We were supposed to start at 10 am, but the first people didn't arrive until nearly an hour later, and they carried on arriving almost until Pia had to leave for the airport (taken there by Geoffrey "Microsoft Refund Day" Bennett, much to Yana's relief). The Linux.conf.au committee spent some time talking with Pia; to my surprise, some of them had never met her, and one nearly mistook Yana for Pia. Took a number of photos.

Had a good lunch, then Pia left and we spent the rest of the afternoon installing OpenBSD on a SPARCstation 2 that David Lloyd had brought with him. Quiet evening.

Monday, 26 May 2003	Echunga	Images for 26 May 2003
		Top of page
		previous day
		next day
		last day

Spent most of the day today in catch-up mode. I've been chasing my mail for some time, and today things were made worse by more information about the SCO affair. At the weekend AUUG board meeting, we realized that we would have to make a statement about our stand on the matter. To make matters worse, the NSW chapter have invited Kieran O'Shaughnessy of SCO Australia to come and talk about the Linux lawsuit. That should be interesting, but Gordon's concerned that the talk will be seen as AUUG supporting SCO's stance, so we're working on getting the statement out before the meeting. That kept me particularly busy; did more researching into the mess than I really wanted to.

Tuesday, 27 May 2003	Echunga
		Top of page
		previous day
		next day
		last day

What a day! Spent most of the day continuing with the SCO statement. Finally got something together and called up Kieran O'Shaughnessy to discuss the matter with him. That proved to be useful: he told me some stuff that hasn't made it through to the press, or at least not to those that I have read. In particular,

• The reason why SCO stopped shipping Linux earlier this month appeared not to be directly related to their complaint against IBM. In the course of researching the IBM case (which I'm still trying to understand), SCO got three independent (and unnamed) companies to investigate the Linux kernel code. All of them came back and stated that they had found significant quantities of UnixWare 7 source code in Linux. I asked him if he really meant UnixWare 7 and not System V.4, and he said that it was UnixWare 7.

  Viewed from 20 years later, this seems to be a solitary claim. Did they really claim or believe that, or was Kieran mistaken?

• I had thought that SCO had implied that they could even potentially sue their own customers. This appears not to be the case: SCO have stated that they hold users of SCO Linux and Caldera Open Linux harmless from SCO legal action relating to breaches of SCO IP within Linux.

He still didn't give me a useful explanation for why they don't just point to the offending code so that people could remove it. I'm left with the feeling that they don't want it removed: this way, they can demand a license from every single Linux user. Not exactly what I would call playing fair. In any case, we were able to talk for half an hour without getting angry, so I suppose that's something (especially for me).

After that, conference call for the AUUG 2003 programme committee, and more or less agreed on the programme. That took 1½ hours. The whole day spent on AUUG stuff.

Wednesday, 28 May 2003	Echunga
		Top of page
		previous day
		next day
		last day

I had hoped to get rid of the SCO statement yesterday, but it kept me going all morning. Finally round midday Gordon and I were happy with it.

Into town in the afternoon with a horse float for mysterious activities which I can't report on now. Look back here in a couple of days.

Added on 1 June 2003: the mystery can be explained.

Yana's 18th birthday is coming up on Saturday, and we didn't know what to give her. She had been talking of buying a grand piano, not exactly a cheap option, especially since she has never learnt to play the instrument. That was clearly out of the question. Looked in the ads and found one for $12,000, rather more than we wanted to spend on a whim, but we also found an upright piano in need of an overhaul which was been given away for free. That sounded like the right price, and we thought that we could have it overhauled when it was clear that Yana would use it, so into town in the afternoon with the horse float to pick it up. I wonder how much these things weigh. Multiple phone calls on the way, including one from Andrew Rutherford as we had just got it up the ramp. For some reason, the AUUG committee was quite amused by the idea of interrupting me loading a piano into a horse float. I think we've done funnier things.

Thursday, 29 May 2003	Echunga	Images for 29 May 2003
		Top of page
		previous day
		next day
		last day

Yvonne had to go riding today, and the piano was still in the horse float. Fortunately Lady isn't easily spooked, so we were able to get a rather amusing photo:

Image title: Lady and piano          Dimensions:          2048 x 1536, 608 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 Thursday, 29 May 2003, thumbnails          All images taken on Thursday, 29 May 2003, small Diary entry for Thursday, 29 May 2003 Complete exposure details

 

Spent the morning looking for how the press reported the SCO business. The Age (and thus also the Sydney Morning Herald) did quite a good job of it, but The Australian didn't mention it. There were also postings on ZDnet Australia, copied more or less to ZDNet UK and ZDNet USA, mainly highlighting the fact that the press weren't allowed into the NSW Chapter meeting this evening. Given the change in focus that they created, I think they have vindicated Kieran's decision.

Of course, Novell stole our thunder: they revealed that SCO doesn't own UNIX. They also showed a very pro-Linux stance. For a while, I thought "that's the end of it, then", but of course SCO's accusation still stands.

Friday, 30 May 2003	Echunga
		Top of page
		previous day
		next day
		last day

More cleaning up after the work on the SCO statement. One more short article in Linuxworld, but most of the stuff seems to have blown over. Spent most of the day catching up on neglected documentation, but also found some time to install some audio ripping software. I must learn more about MP3.

Saturday, 31 May 2003	Echunga
		Top of page
		previous day

Today was Yana's 18th birthday, which kept us busier than expected. I still hadn't finished working out how to run the MP3 player that we bought her for her birthday, and spent most of the day looking through the ports collection for appropriate software. That was surprisingly difficult. I have already been using grip for some time for playing CDs on echunga, but I haven't done any serious copying for some time, and not only had I forgotten what I had used, I had also lost the configuration files. To add to the confusion, the grip configuration documentation doesn't agree with the installation: the former talks about a stripped-down version of cdparanoia, but the latter only gives the choice of cdda2wav. But cdparanoia only works on SCSI CD-ROMs, which are becoming pretty rare nowadays. I suppose most of them are used by Linux people pretending that their IDE drives are really SCSI.

Finally came to choice of dagrab to rip and lame to encode. That wasn't enough, though: the file hierarchy choice is a little bizarre. Discovered that with a CD of Haydn's Schöpfung I got files names like /var/spool/music/rundfunkchor_u_orchester_berlin__hkoch/jhaydn_die_schpfung_cd1/01-introduction_part_1.mp3, which don't fit very well into the 8.3 file naming scheme that the MP3 player uses. There's obviously more work to do on the configuration before it's finished.

Had a bit of fun giving her her presents. We hadn't known what to get her: what do you give the girl who has everything? We had an idea, and Yvonne went to the chemists and got a prescription bottle with the text PENICILLIN: Take one three times a day until finished. Yana Lehey, 31/05/2003. That went down fairly well.

Yana brought along some of her friends (Blake, Clemmy and Guy), and I got Guy to help me move the piano into the music room just before she opened her presents. Clemmy then asked to see her musical instruments, and Yana walked in there without even noticing the piano. The surprise was pretty good when she finally saw it. Looks like a relatively successful choice of presents.

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.