unsigned long geek = random();

There’s been quite a bit of buzz over the past few months about Xgl, the X server architecture layered on OpenGL. Although still in the early stages of development, some code has been released and there are numerous guides explaining how to get Xgl running on a Linux system (the Gentoo Wiki has a good run down of what to do).

Until quite recently, Xgl was only supported on machines that could use the proprietary ATI or NVidia X drivers, which excluded me, as my laptop has an Intel 915DM display subsystem (one of those horrible shared memory systems). This has since changed and the 915DM is now supported. Rather fortuitously, today Jonathan kindly passed along a copy of the latest Gentoo-based Kororaa Xgl Live CD 0.2. When I booted it on my laptop, I was very impressed with what I saw – the performance was good (much better than, for example, the composite extension of X.org 6.9, as I’m using currently) and the eye candy certainly is purrty

After my post a few days ago about GRUB, and a boot loader discussion on the mailing lists of our local LUG, I’m reminded of Thor Lancelot Simon’s post to the NetBSD port-xen list about GRUB. He makes quite a convincing argument that GRUB is less than ideal:

The code is revolting, the user interface is opaque and highly buggy, it exhibits the “I know better than the user” interface paradigm as much as almost any system utility I’ve ever seen (note how it’s impossible to run “grub-install” on a root-on-RAID netbsd system because it *ignores* the “impossible” values in the disk map even if the correct values were hand-entered there), it is poorly documented, it doesn’t know how to pass arguments to a modern NetBSD kernel, and, even worse, the support for booting BSD kernels *at all* relies on header files copied directly from an old version of FreeBSD with their copyrights stripped off in blatant violation of the BSD license.

On Sunday I installed NetBSD 3.0 on my laptop, an HP Compaq nc6220. I didn’t have a recent copy of -current available, so my plan was to install 3.0 and then upgrade once I’d downloaded a fresh -current. As GRUB was already installed in the MBR, I decided to use it as my bootloader.

The NetBSD installation went very smoothly, and I installed into a primary partition that I’d left empty when installing Debian GNU/Linux (/dev/hda3 in Linux terminology). Once the installation was complete, I booted into Linux and edited my /boot/grub/menu.list to add NetBSD. I added the following entries:

title NetBSD 3.0
root (hd0,2,a)
rootnoverify (hd0,2,a)
chainloader +1

Once that was done, NetBSD appeared in my GRUB menu and booted like a charm. More on my NetBSD laptop experiences in a later post…

For some reason, I’ve always set the hardware clocks on my systems to local time, rather than UTC. Although I know this isn’t the recommended approach, it’s never been a problem as we don’t have daylight savings time in South Africa. Since I upgraded my laptop from Debian GNU/Linux 3.1 to testing, however, after every reboot the system time has been out of sync with the hardware time. The two differed by the difference between local time and UTC.

After much Googling, I discovered that the cause of the problem is the init script that sets the system clock. It is called before /usr is mounted, which means that /etc/localtime (which points to the correct timezone in /usr/share/zoneinfo) is a dangling symlink. To work around the problem, I copied the correct timezone file to /etc/localtime, thereby making it available before /usr is mounted. An ugly workaround, but it seems to have solved the problem.

For more information, see bug #342887.

On Tuesday I collected my new laptop from our IT department and surrendered my trusty Compaq Evo N620c. Due to a mixup I didn’t get the machine I was supposed to (a big HP desktop replacement, the model number of which escapes me), but instead got a “standard issue” machine with an additional 1GiB RAM. The machine I received is an HP Compaq nc6220 with 2GHz Pentium M CPU, 2GiB RAM, 80GiB disk, 1400×1050 display, DVD/CD writer, Bluetooth and Intel IPW2200 wireless.

I had backed up the N620c (which was running Debian GNU/Linux 3.1) and my plan was to partition and format the 6220’s disk and untar the backups onto it. Sadly, things didn’t go according to plan… I managed to stuff up /lib, which meant I couldn’t sync(1) and had to power off the machine to boot from a rescue CD. When I fixed /lib, it seemed /dev had been corrupted by the unclean shutdown. I started again and, after reformatting, extracted my backups a second time. All went well this time and the machine booted fine first time.

Once the backup had been restored, it was fairly straightforward getting everything configured for the new hardware. I built a 2.6.15 kernel and got X.Org 6.9 working on the Intel 915GM graphics at 1400×1050 (see the links below for detailed instructions). The Intel wireless is supported by the vanilla 2.6.15, which made setup trivial (I just needed to grab the firmware).

Some useful links:

• My vanilla 2.6.15 kernel .config file
• My 2.6.15 dmesg
• Gentoo on the nc6220
• Ubuntu Breezy on the nc6220
• HP information on Linux on the nc6220 (it’s even Linux certified!)

I’m pretty happy with the machine – peformance is good (even the X11 composite extension is usable) and it’s a fair amount thinner and lighter than my N620c. My only complaint is that the vesafb framebuffer console doesn’t support 1400×1050 and so I have to use a 1024×768 console (1280×1024 has the wrong aspect ratio and suffers from some strange visual artifacts). I haven’t installed Suspend 2 yet, but will do so in the next day or two.

Now that my Debian installation (since upgraded from 3.1 to “testing”) is working well, it’s time to install my operating system of choice, NetBSD…

Spotted this morning that revision 6 of the SAP GUI for Java 6.40 is available. See the release notes for info on what’s new.

You can grab it from ftp://ftp.sap.com/pub/sapgui/java/640r6/.

For some time I’ve been having issues with GConf (part of the GNOME suite) and locking. Although I don’t use a GNOME desktop, a number of applications have support for GNOME and need to interact with GConf, which is used to store application preferences.

In my environment I have a home directory that is exported via NFS from a server, running Debian GNU/Linux, to various clients, running a mixture of operating systems. GConf, being an application that needs to accept configuration updates from a number of applications running concurrently, needs to lock its data files, which are stored in a user’s home directory. Of course, having an NFS mounted home directory tends to complicate things, particularly because NetBSD doesn’t support NFS locking. The nasty thing is that when GConf cannot lock a file, it just blocks indefinitely, waiting to obtain the lock. As you can imagine, any application using GConf hangs while GConf waits for the lock to succeed. Great design…

It’s taken me quite a lot of fiddling, but I seem to have found a workable solution to this annoyance. The key is to get GConf to lock to a local filesystem, rather than to one mounted via NFS. To do this, set GCONF_LOCAL_LOCKS=1 in the appropriate shell rc file. When using local locking, GConf creates lock files in /var/tmp/gconfd-$USER instead of ~/.gconfd.

Sheesh, why can’t it do this automagically?

The Register is running a story about Google developing their own Linux distribution. The article is filled with the usual “facts” and poorly sourced rumours.

To be honest, I think the Linux market is too fragmented as it is (although the success of newcomer Ubuntu surprised a lot of people, me included). What would Google be able to bring to the party? Their last foray into pure desktop software (the Windows-only Google Pack) was met with lukewarm reviews, so perhaps they should stick to what they’re good at. If Google do release their own Linux distribution within the next year I will certainly be very surprised…