Crusty Blaa

Federico: the combination of a "*priv" field and GObject private data is the best way to go:

struct _PangoFcFont
{
   ...
   gpointer priv;
   ...
};

#define PANGO_FC_FONT_GET_PRIVATE(obj) ((PangoFcFontPrivate *) ((PangoFcFont *) obj)->priv)

static void
pango_fc_font_class_init (PangoFcFontClass *class)
{
  ...
  g_type_class_add_private (object_class, sizeof (PangoFcFontPrivate));
}

static void
pango_fc_font_init (PangoFcFont *fcfont)
{
  fcfont->priv = G_TYPE_INSTANCE_GET_PRIVATE (fcfont, PANGO_TYPE_FC_FONT, PangoFcFontPrivate)
}

Indeed, that's why g_type_get_private() was added. You get the best of both worlds - the convenience of a priv pointer with the fact that the private data is allocated in the same chunk as the object itself, without the inefficiency of calling get_private() a lot or the extra static variable in Owen's original proposal.

Figuring out what the story is with LDAP notifications isn't terribly easy. There are a number of different protocol extensions out there:

• Netscape's Persistent Search or PSEARCH. Fedora Directory Server supports this. Extends the standard searchRequest such that it doesn't complete immediately, and returns any changes to the matched by the search.
• Triggered Search Control or TSEARCH. Not sure what implements this. Similar to psearch.
• Microsoft LDAP Control for Directory Synchronization or DIRSYNC. Implemented by Active Directory, but requires the client to poll for changes.
• LDAP Content Synchronization Operation or SYNC. Implemented by OpenLDAP and allows both polling and persistent modes.
• LDAP Client Update Protocol (RFC 3928) or LCUP. Similar to SYNC. Not sure who actually implements this.

The strangest thing about all this is that LCUP is the only one of these that progressed from Internet Draft to RFC, yet neither OpenLDAP nor Fedora Directory Server implement it. SYNC seems to have been proposed by the OpenLDAP crew because when they went to implement LCUP they found that it "requires server implementations to maintain complete history information in order to provide eventually convergent incremental refreshes", which presumably wasn't something that OpenLDAP already did. Yet the working group went ahead and progressed LCUP to RFC and not SYNC.

Anyway, moral of the story is that if you want notifications, then you want PSEARCH if you're using Fedora Directory Server and SYNC if you're using OpenLDAP.

If you're using OpenLDAP's client library, rather than the Mozilla LDAP C SDK, then it's a little tricky since you have to manually create the psearch control and parse the entryChange controls. Here's some example code.

This Google Map Pedometer thing is pretty damn cool. I mapped out the 17k route I ran tonight. Now I can put aside my deep suspicion of the distances reported by my own pedometer :-)

If only the satellite imagery for Dublin was a bit better ...

I finally got around to committing some changes to GConf which Lorenzo Colitti's analysis of GNOME startup time showed would make a considerable improvement to login time. More details here.

The most frustrating part of this is just how difficult it is to get decent, reproducible figures of login time to show the improvements.

I first tried using bootchart to reproduce the results as Lorenzo had done. I hacked up a script to run gdm on a test machine, automatically login as a test user and get a bootchart of the time between gdm starting and the panel finishing loading the applets. I did a number of runs for each of my test cases - unmodified GConf, unmerged tree; unmodified GConf, merged tree; patched GConf, merged tree.

Unmodified Merged Tree Merged Tree, Split Translations

You can see improvements, just as Lorenzo predicted, but annoyingly each run of bootchart varied wildly from others, so you can't really be sure exactly what difference you've made.

Next, I tried a much more low-tech approach. I wrote a scriptto record a timestamp in a text file in /tmp and ran that script from xinitrc and from the panel (once it had finished loading applets). By making the script reboot once it had recorded the second timestamp, and configuring GDM to login automatically, I could walk away from the machine and let it record a bunch of timings rather than sit there and watch it reboot.

Disappointingly, these results varied quite a bit too. But, by discarding obvious anomalies (note my ignorance of statistical methods) and taking an average, I got:

• Unmodified GConf - 14.382s
• Unmodified GConf; merged tree - 13.978s
• Patched GConf; merged tree - 11.086s

That shows a \~20% improvement in login time, which is certainly promising.

I'm always a tad shocked when Red Hat Magazine comes out every month with some genuinely interesting and useful articles. Really nice to see Integrating your applications into the desktop, Part 1 from Zana this month, for example.