Oy.
So, to start with, I discovered yesterday morning that whitestar, my laptop, had shat itself badly sometime between 0330 Wednesday and about 0900 yesterday, irreparably corrupting its JFS filesystem. I tried several times to fsck the filesystem before concluding that it was dead with a stake through its heart and I'd have to reformat and restore from bare metal. I thought at first that the disk itself, an 80GB/5400rpm ATA Seagate Momentus, had failed, and spent most of the day running tests on it before satisfying myself that it was physically fine, something had just shot the filesystem in the head.
So after reformatting, the next problem was to restore. I started out by restoring just whitestar's Bacula client onto babylon5, my desktop, then copying it across to whitestar (booted from a rescue CD). This is when I discovered that the Gentoo bacula-5.0.1 package does not actually build a static Bacula client even with the static USE flag. So I spent a while trying to build a static client manually, which was where I discovered that with current glibc versions, you cannot build a fully static Bacula client on Linux; certain functions (dlopen, initgroups, getgrdir, getgrnam, endgrent, getpwnam, getpwuid, endpwent, getaddrinfo, gethostbyname2, and getservbyname at least; possibly others) still require the shared libraries for the glibc it was built against to be present at runtime, even in a static executable, and if that "static" client is then run in an environment with a different glibc version than the system it was built on, it'll SEGV the first time any of these functions is called.
In the end, I resorted to restoring whitestar's entire filesystem into a scratch directory on babylon5, then copying them over with rsync. Make a few mounts, chroot, setup grub, and whitestar was good to go, though I had to redo some cleanup of old files I'd done over the weekend. This whole saga led me into doing some investigation of the configuration options in Bacula-5, which ... honestly leave a lot to be desired. They are complex, confusing, and counter-intuitive, do not consistently yield the expected results, and contain several hidden gotchas. The upshot is I'll be proposing a significant change to the structure of the primary Bacula configuration options.
While I was waiting for restore jobs, disk tests, file transfers etc, I amused myself playing Portal. It's currently a free download from Steam until May 24 in honor of Portal being ported to the Mac. So if you were always curious but didn't want to spend the money, go grab a copy for free. (Don't be surprised if it takes you two or three, or five, or eight tries to get a download connection; Steam's download servers are getting hammered.) Some of those maps are a lot of fun (although vorlon, my gamebox, only barely has a fast enough video card for it; Portal is distinctly sluggish on a 256MB nVidia 6800XT card, even with the resolution dialed down from 1600x1200 to 1280x960).
no subject
no subject
And Portal was a lot of fun.
no subject
no subject
I would encourage you highly to stick with the game through the whole "puzzle test" thing. And I'll leave it at that.
no subject
(Oh, and solved all the test puzzles without assistance, though there were a couple spots on the post-19 phase where I utterly could not figure out where the fuck I was supposed to go next and had to look up a walkthrough to get a hint.)
no subject
While I thought it was awfully nifty, I was baffled that the public in general had taken to what amounted to a physics puzzle game with only a vague dadaist plot.
Booted it up again some months later, and actually played it through. My gosh, I'm glad I did. That was a much different game than I thought it was.