I love it when people describe software as having been designed with high performance in mind. It sort of makes you wonder if you're supposed to believe that somewhere, out there, someone's designing software with low performance in mind.

This week, the mail folder into which I stuff all of the unsolicited commercial email I receive reached the 2 gigabyte mark (after only just over 73 months).

Emeril, the trust is gone. Your "Molasses" barbecue sauce features corn syrup as its main ingredient. No, don't try to explain it. I can't even stand to look at you now.

Like most everyone else at the office, I find the new MacBook Pro notebooks really compelling — you get quite a bit of power for the price now, and gosh they're pretty.

My current notebook, a behemoth that's large enough to be used as a weapon if need be, is starting to show signs that it may finally give out this year, and I find myself torn between the idea of one of those shiny baubles and the idea of getting a more versatile (but less pretty) development machine built on an Athlon64 or Turion64 base.

Steve got the CITI libgssapi package into Raw Hide this week, and I've been playing around with trying to rebuild parts of the distribution using this generic library instead of the version bundled with MIT Kerberos.

Why bother? Because the CITI library attempts to support multiple GSSAPI mechanisms. It's actually a wrapper library which, under the covers, uses dlopen() to demand-load a library which really implements a given GSSAPI mechanism. This makes it almost trivial for the library to provide multiple mechanisms for applications to choose from. This is useful because Kerberos is but one of many GSSAPI mechanisms being used out in the wild — it's the only one with good support in Fedora, to be sure, but that's a severe limitation for certain users. Making the whole thing pluggable makes it much easier to add support for new mechanisms and to have it work, right away, system-wide.

Switching to a generic library also provides an opportunity to glue together some SPNEGO code from mod_auth_kerb with some NTLMSSP work from the Samba team, and solving the whole we-don't-really-support-SPNEGO problem — without making Kerberos explicitly depend on Samba, which would be problematic given that Samba depends on Kerberos. Maybe that's total crackrock, but who knows.

The only wrinkle so far is that we would lose all of the Kerberos-specific functionality that linking directly with libgssapi_krb5 would provide. For Cyrus SASL's GSSAPI plug-in, that means we'd lose the ability to specify the location of the keytab, so I guess we won't be going there, at least not just yet.

But then, I don't think it'd be a problem for any of the client software out there. Maybe I should see how Firefox likes it....