Saw Frequency with Drew last night... pretty decent movie as it turns out... hit the Gypsy Diner (the shiny diner) afterwards and found out just how bad one side dish can be.. something called butterfly chips or something like that... totally nasty.
Got a response from Pat B. @ Corel giving a mini-patch to mc-4.5.40/vfs/util-alone.c to add a little function so podfuk will compile (it's a hackaround method, but it works). I still wonder why linker's aren't smart enough to pick out needed functions from objects (worst case, noop the other functions), although it'll be nice when (soon hopefully) the kernel has that capability, although it'll come at the cost of an ELF section for every single function.
Trish Hogan (TPC-C DB person) reports that Clarinet has never used 64-bit data. ServeRAID guys report (sigh) that the bottleneck is a SCSI layer one in the Linux kernel (amazing how I get faster with other controllers, though, eh?). Oh, well... at least s/w raid will let me distribute among PCI busses which is good since that's where the real bottleneck will be (esp. on the 64-bit and only 33MHz PCI bus 3 in the Netfinity 7000M10)
As I'm writing this, I'm waiting on a cable modem guy to come out and check my line and run it to an outlet. He will probably get here late, and I'm going to try and get this free since it's Time-Warner and all (and in the middle of their ABC dispute too :) and supposedly late means free for their service... we'll see.
mini-update: on the phone with Time-Warner and the first response was "we don't have a scheduled appointment with you today" What?!?!?!?! So I tell her to look around, that there's a strong likelihood that since I cancelled TW service before, a new and different account got created. Sure enough, she finds a second account but then reports "Well, the RR service entry was made, but it was never saved" then changes that to "It was made and saved, but no actual work order to install service was made" ARGH So now I'm waiting on the phone ... on hold having wasted my entire morning off of work, waiting for someone at TWC/RR to figure out whether or not I was supposed to get RR service today. (her name is Pam, BTW). Well, she reported back that it was scheduled, that my install would be free since they were late, and they're trying to track down where the tech is right now.
Calling in to Chase to update him about all this, he swears that it'll never happen today and I need to drop it and come into work to do some tracing. I don't wanna lose the cable modem possibility, so I'm not likely to do that :) Hopefully I can (worst-case, I hope) reschedule the install for a little later this week or something.
Ugh... finally got this settled (for the day). They rescheduled for next Monday (05/08) in the afternoon... I can't believe I wasted a morning on this crap.. bleah
AVFS indeed works standalone. coda loaded, /overlay dir made, and everything rocks. I don't really care about the redir.o kernel module hack to get the same functionality through the "native" trees, it just doesn't buy me that much.
The perl script to scan all files in a given tree and export the avfs-exported source dirs from them is written. Seems to work well, but it doesn't list the kernel numerically. I'm not sure I care since most ftp servers are going to go lexicographically too, but it'll be a quick and possibly useful hack. I might have a "last 5 of each tree" mode written in for those that don't want their rsyncd exporting a hundred diff dirs (although I don't see that it would matter, except in wasted cache space, but the coda cache manager should handle that anyway.
With rsyncd re-reading the conf file on each connection, I can get away w/o locking or doing other pseudo-atomic operations when maintaining the conf file... worst case one connection gets a broken conf (highly unlikely, but a minute race condition), but the retry will work fine. We're talking about a 10ms window once every few hours... Not likely :)