leif's blog

g++ and member initialization

Recently I've been working on porting a very large (and obsolete) system to a modern Linux platform. This has been rather painful, particularly since the code has a million and one compiler warnings (when compiled with g++ -Wall). In particular, one class of warnings was annoying the hell out of me:

foo.cc: In constructor ‘Foo::Foo()’:
foo.cc:34: warning: ‘Foo::loki’ will be initialized after
foo.cc:33: warning:   ‘int Foo::leif’
foo.cc:41: warning:   when initialized here

This might not seem like a big deal, but when we're talking about 30 or more members that needs to be initialized, and they are completely out of order, it quickly becomes annoying to figure out the correct order. So, I hacked up gcc a bit, to introduce a more helpful warning. With this patch, I now get something like this instead:

foo.cc: In constructor ‘Foo::Foo()’:
foo.cc:34: warning: ‘Foo::loki’ will be initialized after
foo.cc:33: warning:   ‘int Foo::leif’
foo.cc:41: warning:   when initialized here
foo.cc:41: warning: Correct initialization order is:
foo.cc:44: warning:   Foo::leif
foo.cc:44: warning:   Foo::loki
foo.cc:44: warning:   Foo::odin

I've tested this with gcc v3.4.4 and gcc v4.0.2, and it seems to work fine on both. Since I'm not a gcc hacker, my implementation might not be the optimal one, but it works for me. Isn't open source great sometimes?

More on UnionFS and AutoFS

I did some quick hacking around the autofs mount point, and came up with this quick (and very dirty) "fix" for my problems:

#!/bin/sh

key="$1"

opts="-fstype=unionfs,ro,dirs="
ls /share/unix > /dev/null

egrep "^$key" /etc/auto.misc | sort | awk -v key="$key" -v opts="$opts" -- '
        BEGIN           { ORS=""; OFS=""; first=1 }
        first == 0      { print "\\:/misc/" $1 }
        first == 1      { print opts "/misc/" $1; first=0 }
                        { system("ls /misc/" $1 ">/dev/null") }
        END             { if (!first) print " :none\n"; else exit 1 }
        '

It's still not perfect, but certainly a lot better. Notice I moved the Unionized mount points to it's own automount map (/union). I just put the script above in /etc/auto.union, make it executable, and add the map into /etc/auto.master, e.g.

/union          /etc/auto.union         --timeout=600

Update 1


On my FC3/4 system, I kept getting warnings from the diskcheck utility. This was easily avoided by modifying /etc/diskcheck.conf, and add something like:
ignore = "-x nfs -x unionfs"

Unionfs, autofs and ISOs

I use many different Linux distributions, and versions of those, and like to keep them available on my various boxes. I setup a very simple autofs map for this, which I mount as /misc:

FC3-1   -fstype=iso9660,ro,loop :/share/unix/Fedora/FC3-i386-disc1.iso
FC3-2   -fstype=iso9660,ro,loop :/share/unix/Fedora/FC3-i386-disc2.iso
FC3-3   -fstype=iso9660,ro,loop :/share/unix/Fedora/FC3-i386-disc3.iso
FC3-4   -fstype=iso9660,ro,loop :/share/unix/Fedora/FC3-i386-disc4.iso

This is incredibly useful, but somewhat annoying when I'm looking for a particular RPM for instance. I have to manually look at up to four different directories to find it. So, I decided to give UnionFS a spin. I downloaded the latest tar-ball, and built it following the easy instructions (basically just make and ''make install').

I decided to just add another entry in my automounter map

FC3 -fstype=unionfs,ro,dirs=/misc/FC3-1\:/misc/FC3-2\:/misc/FC3-3\:/misc/FC3-4 :none

Notice how the ':' separators in the dirs option are escaped with a backslash, without it I could not get it to work it all. To make things worse, the automounter is not able to handle all this automatically, so unless /misc/FC3-* are all already mounted, I can't see /misc/FC3 at all. This is rather annoying, but I haven't found a way around it.

However, besides those problems with the autofs interaction, UnionFS is pretty damn cool. Now I can see all the FC3 RPMs in one directory, /misc/FC3/Fedora/RPMS.

RHEL4 and Sound Blaster Live! 24-bit

My workstation at work (yeah, I do work ...) crapped out big time on my old sound card (an old Vortex2 card) after I upgraded to RHEL4. So, I went to the local Fry's store, and picked up the cheapest Sound Blaster card I could find, the SB Live! 24-bit for a mere $29.99. Well, as it turns out, this card is not supported by the ALSA drivers provided with RHEL4...

Fortunately, it was pretty damn straight forward to upgrade the ALSA drivers on this box, these are the steps I had to take:

{CODE()}

RedHat released DS!

Finally we have an alternative to OpenLDAP: Fedora Directory Server! This is great news for everyone who's used the old Netscape or iPlaner Directory server. Not only do we get the software "for free", the source is also available!

I've just started playing with this release, and so far it's looking pretty good. I expect to have more news once I've moved more data from my old OpenLDAP directories over to FDS (Fedora Directory Server, I have no idea if that's an appropriate acronym). Head over to the Fedora Directory Server Wiki site for more information, and Downloads.

Also, I decided to "revive" an old site of mine, slapi.com, which I hope will be a dedicated resource for writing new extensions for the Directory Server. There's not much there yet, but I've re-posted an old article of mine I wrote 5-6 years ago.

Serial ATA and ABIT IS7 (ICH5-R)

Last week I built a new file server based on the ABIT IS7 mobo. I bought 2 large SATA drives, and planned to use simple mirroring of the two disks (RAID-5 just sucks too much :-). I installed Fedora Core 3 on this system, and that worked seemingly without problems. But, upon further examination, I started getting an error like this in my syslog:

Mar 31 20:33:34 server kernel: Losing too many ticks!
Mar 31 20:33:34 server kernel: TSC cannot be used as a timesource.
Mar 31 20:33:34 server kernel: Possible reasons for this are:
Mar 31 20:33:34 server kernel:   You're running with Speedstep,
Mar 31 20:33:34 server kernel:   You don't have DMA enabled for your hard disk (see hdparm),
Mar 31 20:33:34 server kernel:   Incorrect TSC synchronization on an SMP system (see dmesg).
Mar 31 20:33:34 server kernel: Falling back to a sane timesource now.

This obviously couldn't be good... Running "hdparm-t" on the disks showed me abysmal read performance from the SATA disks (like, in the 2-3MB/sec range, when I'd expect at least 60MB/sec). I spent quite a while trying to figure this, trying newer kernels (2.6.11), trying without RAID mirroring etc. I also checked the obvious BIOS settings, but the either all seemed right, or didn't make any difference. Until I tried the setting for the actual IDE controller, where the default "mode" obviously didn't do the right thing. Changing this to "Enhanced mode" did the trick, and the system performs well now.

Yahoo Search Web Services

Well, it's finally official, Yahoo released the search APIs to the public. The Developer Network has all sort of documentation, and downloads of example code and APIs. Obviously, you should use Python. Swaroop has already begun hacking, writing a QT Image search tool thingie. The Python APIs are hosted on SourceForge, at http://pysearch.sf.net/ .

I'm about 50% done with my next search project, a Gimp plugin that lets me search for Images, preview the thumbnail, and then import the selected image(s) as layers into the Gimp. I'll post with screenshots once it's looking less gimpy.

Fedora Core "devel" packages and yum

I try to keep my system up to date using the Fedora "devel" packages, using the yum updater. Sometimes I would get errors like

unsigned package //var/cache/yum/development/packages/glibc-2.3.4-3.i686.rpm
unsigned package //var/cache/yum/development/packages/eog-2.8.1-1.i386.rpm
unsigned package //var/cache/yum/development/packages/pango-1.8.0-1.i386.rpm

The problem here is that not all development packages are signed, for whatever reason. Assuming you still trust Fedora, simply modify your yum configuration file (/etc/yum.repos.d/fedora-devel.repo in my case) to add a line like
gpgcheck=0

More on snapshots

I've been using rsnapshot for quite a while now, and I'm really happy with it. It's been saving my ass on several occasions already. To make access to certain snapshots easier, I've created a small "system" of NFS mounting and symlinks.

The general idea here is to setup a number of symlinks in the directories that I've performed snapshots of. For example, in my home directory I end up having these symlinks:

.daily.3 -> /misc/.snapshots/daily.3/server3/home/leif/
.daily.2 -> /misc/.snapshots/daily.2/server3/home/leif/
.daily.1 -> /misc/.snapshots/daily.1/server3/home/leif/
.daily.0 -> /misc/.snapshots/daily.0/server3/home/leif/
.weekly.1 -> /misc/.snapshots/weekly.1/server3/home/leif/
.weekly.0 -> /misc/.snapshots/weekly.0/server3/home/leif/
.monthly.0 -> /misc/.snapshots/monthly.0/server3/home/leif/

Setting up the NFS mount point


First of all, we need to have a read-only mount point where the actual mountpoints are stored. In my case, I use an automount map for /misc, like
.snapshots      -ro                     server3:/export/.snapshots


Creating symlinks


This is all good and well, but we also need to maintain symlinks into the NFS mount point. I wrote a very simple Python script to recursively create symlinks. It's fairly configurable, using the PythonConfig style configuration file. Here's an example configuration:
[snaplinks]
base: /misc/.snapshots
exclude: daily\.[45] weekly\.2 monthly\.[1-9] quarterly\.[0-9] yearly\.[0-9]
max_depth: 1
#destination_subdir: .snapshot
 
[leif]
source: server3
directory: home/leif
destination: /home/leif
max_depth: 5
The snaplinks section provides global configurations and defaults, which you can override in individual sections. Beware, use this tool at your own risk, I've tested it quite a lot, but I'm sure there are still bugs.

Firefox and Emacs key bindings

As a die-hard Emacs users, I can't survive using my browser without Emacs bindings. After I upgraded to Firefox PR1, almost all of those bindings where MIA. The pain! Fortunately, after consulting with the good peeps at irc.mozilla.org, I was told that Firefox now honors the Gnome/GTK settings for key "themes".

Depending on your version of Gnome, you can change the setting by going to the control center and use the Keyboard Shortcuts panel. This does not seem to work in the latest Gnome version, at least my v2.8 installation of Gnome doesn't have the appropriate settings in this configuration panel.

So, in my case, I had to fire up gconf-editor manually, and edit the Key named /desktop/gnome/interface/gtk_key_theme. I changed the value from default to Emacs, and after restarting Firefox, everything was cool again.