Technological Wanderings Travels in code, databases and networks

I've been trying to get my intranet password working again since I changed it a week or so ago. It worked in Safari 2, and after upgrading my G4 laptop to Leopard it still worked fine. It was only when I needed to change it that I found I couldn't change it and save it.

Long story short, it's broken in Safari to at least 3.0.4. See: http://discussions.apple.com/thread.jspa?messageID=6283882

Even if you open Keychain Access and set it manually, it won't work. A big shame. It's odd how it only stopped working when I had to change the password.

The MacBook arrived on Wednesday, 9th January. Delivery took three working days, five days including the weekend - longer than I was expecting, but an inspection of the delivery notes on the box reveal that it was sent to me in the UK, by Apple, from Shanghai. Not bad really for such a distance to travel, especially with free shipping. The courier turned out to be TNT - but I'd tried the Apple courier tracking number with TNT and they found nothing.

The packaging is up to usual Apple standards. The box is a fraction of the size of that in which my Powerbook G4 12" came, which is a good thing.

First impressions of the machine (13", 2GHz, white MacBook with 1GB RAM and 80GB disk - the cheapest currently available):

It is fast. It is close enough to my Athlon 5600X2 running Linux as to make little difference. My simple test case is a huge OpenOffice spreadsheet - a manual recalculation takes something like 5 seconds on the Athlon, perhaps 7 or 8 seconds on the MacBook. Impressive enough for me.

It is very plastic. My aluminium Powerbook makes it look very cheap. There is constant attraction of dust as the outer plastic is prone to generating static charges. The outer plastic is also shiny and smooth and as such attracts greasy finger prints and constantly looks dirty - Apple know this, as the machine comes with a cleaning cloth. Good grief. The front edge of the machine (where your wrists rest) is very sharp. The magnetic latching of the screen when closing the case seems like a good idea a first, but feels cheap in action. All this basically means that if you can afford a MacBook Pro, go for it - I really want a small laptop, and a MacBook Pro 12" or 13" would seriously tempt me.

The glossy screen is actually very good. I was terrified that it would reflect badly, but I've never seen one reflection from it yet while powered on. When off it's like a mirror, but this changes completely when in use. I also got a VGA adaptor so I can plug into my large monitor next to the DVI Linux box; I've just been watching a documentary on the large monitor while 'working' on the laptop itself and had no complaints at all (except for Quicktime not wanting to play full screen while I'm working on the other screen). VGA is a little blurry at 1680x1050 but that's expected. I do wish more monitors came with two DVI inputs.

It's a fair bit wider than my 12" Powerbook - probably an inch so despite the screen being in a widescreen aspect. There seems to be a fair bit of border around the screen and keyboard compared with the G4. On the other hand, it's significantly thinner which makes up for that when packing my laptop carry case.

The keyboard - firstly, the layout. Some keys have moved around and it has a tall, rather than wide enter key. Option has disappeared, I think this is now labelled 'alt'. My Mac inexperience is probably showing there. Worst, the function keys have useless play, pause, rewind where the keys for the expose functions should be. I can't show the desktop with one key press any more (Fn-F11 is now the shortcut)! This is a major problem and I'll have to find a workaround.

Secondly, the feel: at first, it looks depressingly like something off an 8bit computer. Thankfully the keys are quite light, direct and well spaced. Time is really the method of test here - this review is the first large text I've written on it. It's going well so far.

The start up bong can't be muted. On the Powerbook, holding mute when switching on would silence it. Otherwise, you'd hear it - which can be very useful if you're somewhere noisy already as it tells you that the blank screen is the machine booting, not a call to press power again. Well, I've had to install "Psst" and kill it off completely.

Migration - I don't understand why the migration tool requires a firewire cable. I don't have one. One doesn't appear to be provided in the box. I do happen to have a large, fast and expensive ethernet network. Never mind though; it turns out that migrating is actually quite easy on a Mac. Mount the remote drive using AppleTalk / File Sharing, and simply drag over whatever you want. Beautifully simple. My home directory and all the applications I wanted just came straight off the PPC based machine onto the x86 and worked well first time. Some clean up of the home directory was required (such as login startup items) but otherwise I'm happy with it.

The trackpad is great - the two finger scrolling is simply wonderful. It works naturally and is immediately understood and made full use of.
PowerPC applications run on the 2GHz Core 2 Duo at about the same speed as on the 867MHz G4, which is absolutely fine. There is little now that isn't universal.

Leopard I will gloss over as I want to concentrate on the hardware - let's just say that I don't buy a Mac to run anything other than Mac OS.

That will do for part 1. I'll give it a week of good use and think of something to write for part 2.

This, by the way, is the model I've bought:

On the 1st of January, 2008, I ordered a new MacBook! Woo!

I've held off for months because:

• It's a lot of money.
• Which should I get?
• Need to upgrade my servers first.
• Want to replace the family PC with a Mac Mini.
• Aren't there new ones due out soon?

Well, on the last point there are always going to be new models due "soon". I'm sure they'll be out now I've paid the money and the current MacBook range is getting on for nearly two years old, but to be honest, I've realised that I don't care... I want a new Mac.

After a lot of deliberation, I've gone for the basic MacBook 13.1", white, 2GHz, no extras but for a VGA adaptor (yes, my monitor is DVI, but my Linux workstation uses the DVI - the monitor has a free VGA port and VGA works everywhere in stuff like projectors).

The fact is that even the basic model is going to be a huge step up from my current Powerbook G4 12". I have the model that just scraped through for running Leopard - 867MHz. In terms of memory and HD, I am happy to keep it at 1GB and 60GB for now and anyway, I work at a computer company that also retails this stuff. I can do the upgrades myself in the future for a fraction of the cost that Apple charges.

I can't wait :-)

The ordering process:
Buying direct from Apple is fairly painless, so far. I placed the order late in the day on the 1st. It was despatched on the 4th, a Friday - Apple's estimated despatch/delivery dates seem very pessimistic and quoted more than a week for just despatch. I'm now waiting for delivery (it's Sunday), with Apple quoting 'before this coming Friday'. I'm hoping for Monday or Tuesday.

The quality of the account/tracking/order history pages of the Apple site does leave something to be desired. I can't track the order with the courier - I have a code, but no information on who that code is for! I've tried all major courier's websites with no luck. Surprisingly the Apple site in the order/account side feels quite cheap, after the fantastic experience it gave up to actually placing the order. Silly things like inconsistent fonts, lack of a logout button, stuff like that. I suspect the UK version has been custom written on the cheap and is significantly different to the USA version, but I have no evidence.

Recently my car PC display started playing up. I couldn't get it to display the native 800x480, although more usual resolutions like 800x600 were working okay (just unreadably small or blurry on a 7" screen in a car!).

To cut three weeks short, it appears that Mandriva (2008.0) started listening to the TFT's DDC information - the codes that tell the PC what resolutions the monitor supports. Now it turns out that the CTF700 I have never reports the correct resolution. It reports either 800x600 or 640x480, so Xorg thought it was doing the correct thing.

The answer is to turn off DDC in Xorg and set the resolutions manually (or, in my case restore the previously working backup and change that so DDC is ignored).

To do this, add:

Option "NoDDCValue"

to the Device section of /etc/X11/xorg.conf.

I actually stumbled on this by looking at the old Via Unichrome driver notes. It does seem quite obvious now I think about the symptoms... I suppose some update I did in December changed something, although Mandriva 2008.0 is still not yet running 100% correctly - the last to work well was 2006.0, but that had poor wireless support for anything but WEP.

The last issue I'm trying to sort now is a kernel bug - on each suspend/resume, the event drivers aren't being released properly and continue to count up in /dev/input/eventNN / inputNN. This eventually causes evdev (for the touchscreen) to fail (all slots taken, leaving the machine unusable. The heavy-handed fix I've got for this is to check for my custom udev generated symlink /etc/input/touchscreen every five minutes, and if it's missing to reboot the machine. Hardly the best thing to do.

The evdev problem looks like this, notice the high input number, which was normally less than ten:


Jan 1 17:08:51 localhost kernel: evdev: no more free evdev devices
Jan 1 17:08:51 localhost kernel: input: failed to attach handler evdev to device input72, error: -23


Dec 30 13:08:21 hostname vmware-authd[13919]: The "/opt/vmware/server/lib/bin/vmware-vmx" process did not start properly. Exit 0xed00

I was getting the above on one of my old soon-to-be-replaced servers after it had crashed and been rebooted. I put VMWare server on it recently to run an SBS2003 image, as it runs perfectly on that machine's Duron and horribly on the Pentium3 of my normal VMWare box. VMWare + Pentium3 does not mix, as I have been slow to recognise.

Any, to cut the story short:
VMWare must see your ~/.vmware directory. Even if you are using the remote console, the machine running the VM needs to see the .vmware dir in the home directory of the user you are running the VM as.

I have a single /home shared over my network, and this machine - for reasons of very basic security - has never auto-mounted /home. When I set up VMWare, /home was there. After the reboot, /home wasn't.

If the error message had said that to start with, I might have got back to work an hour ago.

Long ago, if you had a crash[1] and restarted Mozilla, you'd get an error that your profile is in use even when it blatantly isn't.

What you'd do, is look in /home/me/.mozilla/randomstring/ and delete the "lock" file. Not so in new versions.

Now you need to delete lock, but also a hidden file called ".parentlock". That took a long time to find and makes me glad I use Opera for my day to day browsing, which has never taken a long time to get running again after a rare failure.

Thunderbird is a reasonably good email client, but really it is the best of a bad bunch. Anyone who once lived for Fido using Amiga software will realise just how bad an experience email is today. I think perhaps it is the Outlook experience many suffer in the workplace which has lowered expectations so much.

[1] Upgraded Kspread. It took ownership of ODF spreadsheets from OpenOffice in KDE. I tried to open a spreadsheet, Kspread opened and my machine was reduced to a gibbering wreck as it consumed all resources (swap usage). That is only software I know that can cause an effective lockup from unprivileged user mode in Linux.

I've got my hands on some old SC gigabit fibre kit:
2x Netgear GA620 64bit PCI
1x Allied Telesyn 9006SX/SC
1x Brocade Silkworm 2400

The Brocade is technically a fibre channel switch for disk arrays, SANs.
It's all about 7 years old now, but worth playing with. I've now got a machine to machine fibre link between two of my servers, and will be looking on eBay for another fibre card to extend that network with the 9006 switch.

The cards use the acenic driver in the Linux kernel. This has apparently been removed in 2.6.23, so I may be stuck at .22... I have found one flaw: with flow control enabled in the cards, they will eventually lock up and stop transmitting data. I don't know if this is the bug which led to driver removal, or a hardware issue.

The fix is to switch off flow control, module options:
options acenic link=0x0140

If compiled as a module and using Gentoo, create a file /etc/modprobe.d/acenic containing that line and run 'update-modules force'. rmmod then 'modprobe -v acenic' to confirm that it's read the line correctly (it'll show the "link" bit on the screen).

The cards support jumbo frames, so it your switch does as well you should turn that on. In Gentoo, /etc/conf.d/net:
mtu_eth4="9000"

So far, performance isn't great - 120Mbit/s is the record so far. This may be due to the vastly overloaded machines I use and one of them running in 32bit PCI mode. Flow control on/off hasn't made a difference. I have some tweaking left to do.

Of course, having put these cards in has disturbed the machines and the recent perfect uptime has disappeared... multiple hangs over the last few days, very frustrating when the machines should be perfect. Most traced so far to bad disk power connections causing disk dropouts, except for one happening while dumping data to SCSI tape which ruined a backup, which has happened a number of times in the distant past. sigh.

In a market full of choice and variety, it's funny that there are so few good SIP/VoIP phones around.
There are cheap toy phones being sold at premium prices .
There are expensive professional phones which just don't work properly.

Then there's this: Cisco bought Linksys who bought Sipura. This unholy combination looks something like: quality hardware + cheap prices + quality software.

The Linksys SPA942 really is a Cisco phone with Sipura software at Linksys prices (about £60 exVAT currently). It works with Asterisk, first time and every time. No reboots, no crashes, no voodoo required to get it to talk to the server over IP-NAT. Good weighted handset, clear sound, easy to use interface (and big, bright screen to view the interface on). Even the number buttons have that perfect weighting and clicky feel. No rubber buttons here. The web interface is a beauty to behold; it can be as simple to use as putting in the extension number and password, but there are options to change everything if you need to - and it's fairly logical and easy on the eyes.

I have a Linux (Gentoo) server which has been somewhat unreliable, and suffers from frequent lockups[1]. Today, it started to hang at boot on "Mounting Root Filesystem".

I booted a recovery CD and took a look at the RAID filesystems, all using Linux's MD software RAID1. They all assembled fine, and mounted the ext3 and reiser3 filesystems without trouble. So I started to look in more detail:

On doing a query of one of the components of the root RAID, I found:

# mdadm -Q /dev/hda2
/dev/hda2: is not an md array
/dev/hda2: device 0 in 2 device mismatch raid1 /dev/md3. Use mdadm --examine for more detail.

"Mismatch!" All the others show "active" or "inactive". I look closer and note "md3" - my root is md1, /boot is md3!
What is happening is that the RAID block device notes in its superblock which md device node it is assigned to. When booting, Linux is looking for /dev/md3 to mount the root. Knowing this to an MD RAID, it examines devices and starts those that match.

In this case, I've probably made a mistake during a previous recovery and mounted / as md3, which it has remembered. So on bootup, I have two filesystems claiming to be for the root device, which is set as /dev/md3 in the LILO boot loader.

To fix this, you need to update the super block. This is done when assembling the device, so do it from a fresh boot off your recovery disk.

This is what I did:

# mdadm --assemble /dev/md3 --update=super-minor /dev/hda2 /dev/hdd2

Once done, a query shows:
# mdadm -Q /dev/hda2
/dev/hda2: is not an md array
/dev/hda2: device 0 in 2 device active raid1 /dev/md1. Use mdadm --examine for more detail.

Rebooting, the root is mounted instantly and everything works. Huzzah!

[1] Once every couple of days, and almost certainly temperature related as the environment has been getting very hot and humid at the same time. It has a hardware based watchdog which brings it back up - I do like real server hardware.. I pulled the heatsinks off the CPUs and noticed a lot of thermal transfer compound (which would be my fault) - I've wiped these down and left just a very thin film and will see how well it works now.

========

Update:
I noticed that the machine is running the disks on mdma2, rather than udma5.
So I played with the kernel options (2.6.22-r9) to try to fix that and on rebooting got the same problem again. Going back to kernel 2.6.21-r5 solved both the mounting root and UDMA issues. So I suspect the real reason behind all this is a broken kernel revision, at least with Broadcom CSB5 (Intel SDS2 board).

Last night I was on my bulletin board reading some usenet newsgroups. Some of the groups have hundreds of thousands of messages archived in them, resulting in single data files of up to a gigabyte. The BBS was designed with 10MB in mind as an upper limit, so it's doing well - but last night the disk need defragging as it was getting quite slow.

It got me thinking along other lines though, like methods to speed it up. The BBS offers a buffering mechanism in the binary API, but not to the ARexx scripts which drive the user end of the BBS. So I decided to add it into the ARexx API. Well, I spent a lot of time fixing a bug which was present in the software for probably 15 years (the buffer breaks if you list the messages backwards! Odd how it'd never been an issue before). Also some time trying to re-learn the code: the last change I made to the system was 12 months ago exactly, and before that just a dozen changes in five years.

But it's marvellous to work in C under the Amiga. Though I was immediately struck by how difficult lack of object orientation makes C (I needed to extend a data structure, so I had to recompile everything that used the data structure. If it was saved to disk (and not in IFF) I'd need to have written a conversion tool - objects and XML (like IFF) do away with this), but at the same time everything is understandable; the complexity is only of my own making, I'm not fighting a 30 layers of abstraction to find out where the prefs are being saved.

The job took a while, probably eight hours. But I loved doing it, even though by the time I'd finished the disk had defragged and the need for the buffering was less.

The next job is make the message storage more intelligent. At the moment I have more than a million messages in what are essentially unindexed flat file databases. I think now is the time to learn how to write a proper database :-)
I could just plug in MySQL, but it'd be less efficient and of course GPL. And what fun would that be? I want to write it myself for the fun of it :-)

Thinking about it, another reason I like working on my BBS is how good the code is. The quality of coding and algorithms is a given; I'm thinking more of the visual appearance. There are three authors in the sources, the original two and myself who took over from v1.2. Neither of the two original authors wrote any comments. Seriously. One author wrote extremely neat code, which I've learned a lot from, the other wrote code of equal cleverness but in an untidy way. From this mash up comes my perfected vision of code which I've been working to for many years, as I work on refactoring the existing source and writing new. It dispares me to see the visual quality of code some people produce and I have to maintain; from simple things like not continuing to use the same bracing and commenting styles from one line to another in an existing source file to more fundamental things like using indenting.