unsigned long geek = random();

Yesterday I finally got around to adding a second head and setting up Xinerama on my dual Creator3D Sun Ultra 60 running NetBSD/sparc64 -current (4.99.4). Setup was fairly straighforward – I started with a fresh XF86Config generated by X -configure and added the necessary stanzas for the second video card and monitor.

The only slight problem I had was a missing fb1 node in /dev, with the result that XFree86 didn’t even find the second card. After much hair-pulling, I realised what the problem was and ran MAKEDEV std_sparc64 in /dev to fix it. The reason for the missing device node was that my machine had been upgraded from 3.1 to -current and I had neglected to update /dev during the upgrade. Oh well, all’s well that ends well

Dual Creator3Ds are only supported by 4.0 and later – if you try and boot 3.1 and earlier on a machine with a pair of them, you may find your console “disappearing” when the second card is initalised. To get around that, remove the second card, upgrade and then reinstall the card.

Some useful resources:

• My working XF86Config
• The Sun Frame Buffer FAQ
• A guide to setting Sun frame buffer resolution

Update: fixed the broken link to my XF86Config

A few weeks ago I contacted Internet Solutions and they are now kindly hosting a local pkgsrc distfiles mirror. To use it, simply add the following to your /etc/mk.conf:
MASTER_SITE_OVERRIDE=ftp://ftp.is.co.za/NetBSD/packages/distfiles/

If a file isn’t found at the local mirror, the pkgsrc fetch Makefile target will fetch it from another (non-local) mirror.

A few weeks ago I collected some more Sun hardware from a friend of mine who seems to know the location of the best dumpsters in town. It was quite a collection: a pair of Ultra 60s, a Ultra 2, a pair of Ultra 1s, a Sun 8mm tape drive and a StorEdge L280 DLT changer.

One of the Ultra 60s had a single 360Mhz CPU, 1GiB RAM, a 9GiB disk, gigabit Ethernet and a pair of Creator3Ds. The other had a single 360Mhz CPU, 512MiB RAM, a pair of 18GiB drives and a single Creator3D. The Ultra 2 only had a single 200Mhz CPU, but had 512MiB RAM. The Ultra 1s were pretty low end – both had 143Mhz CPUs, 64MiB RAM and a quad fast ethernet and one had a 2GiB disk, the other being diskless.

I’ve given the one Ultra 60 and the Ultra 2 to Jonathan Groll and the Ultra 1s will probably be given to some deserving homes amongst CLUG members. My Ultra 60 is already running NetBSD-current (currently 4.99.4 kernel and userland) and working well, but more on that in a later post.

It’s incredible, but a few years ago it was impossible to get any moderately decent Sun hardware locally, but these days it seems to be falling from the sky. At rough count I currently have 13 unused Sun machines (6×32-bit, 7×64-bit). Now I just need to get myself a nice Blade 1000, 2000 or 2500 and I’ll be a very happy camper. Of course NetBSD still needs to get working sparc64 SMP and UltraSPARC-III CPU support, but that’s minor stuff

On Saturday I got two Sun UltraSPARC systems from a friend, in exchange for my unused SGI O2. Although the O2 was a great little machine, I hadn’t used it for about a year and SGI’s poor support for IRIX (ie no easy way for me to get patches) meant it would probably have languished in my pile of unused systems for a while longer.

The two systems I got were an Ultra 10, 333Mhz, 256MiB, 9GiB IDE, Creator3D and an Ultra 2, 300Mhz, 256MiB, Creator3D and no disks. I’ve already stripped my Ultra 5 and put its RAM, SCSI controller, disk and USB 2.0 card into the Ultra 10 and it seems noticeably faster – probably a combination of the Creator3D and the extra cache on the 333Mhz CPU (2MiB vs the 256KiB on the Ultra 5′s 360Mhz).

The Ultra 10 is running NetBSD-current (4.99.1) and once Solaris 10 Update 3 has been released, I’ll be installing it on the Ultra 2.

Yep, it’s true – it takes longer to build Firefox 2.0 than it does to build 1.5. Timings on a 500Mhz EV56 AlphaServer 800 running NetBSD:
real 612m43.097s
user 534m11.005s
sys 80m52.159s

Contrast those with my previous results and you’ll see that it takes about 4 minutes longer to build 2.0. It’s bloat I tell you

I upgraded my notebook to Linux kernel 2.6.18 about a month ago, shortly it was released. One thing that is greatly improved is the stability of suspending to disk. I use Suspend 2 and with various patchlevels of 2.6.17 it would sometimes not suspend properly, necessitating a reboot. Things seem a lot better after the upgrade – I haven’t yet had a suspend fail, touch wood.

Sadly, my laptop still generates spurious ACPI overheating events, which cause an unwanted shutdown. That’s something I’ll probably have to fix with a new DSDT or by patching the kernel myself to ignore nonsensical temperatutes (783 degrees!).

Today I upgraded to VMware Workstation 5.5.2 on my notebook, which runs Debian testing. When I started VMware, I got the following in a terminal window, but the VMware window didn’t appear:

/usr/local/lib/vmware/bin/vmware: /usr/local/lib/vmware/lib/libpng12.so.0/libpng12.so.0: no version information available (required by /usr/lib/libcairo.so.2)
/usr/local/lib/vmware/bin/vmware: /usr/local/lib/vmware/lib/libpng12.so.0/libpng12.so.0: no version information available (required by /usr/lib/libcairo.so.2)


After a bit of judicious Googling, it seems that the above libpng errors are red herrings and that the problem is caused by an incorrect libdbus being loaded by VMware. The solution is to preload the correct version of libdbus. For more information, including a solution, see this thread on the VMware forums. Apparently newer versions of Ubuntu exhibit the same problem.

As Rafiq says, our local LUG is in need of sponsorship for its stand at this year’s Futurex exhibition. About half the money needed (R10,000 – about US$ 1,250) has been collected so far, but we still need every donation we can get. For more info on donating, see the sponsorship page on the CLUG site.

I’ve made my donation (guess who I am on the list – have you?