RE: BDB recovery after power outage

["Howard Chu" <hyc@highlandsun.com>]

> -----Original Message-----
> From: Frank Swasey [mailto:Frank.Swasey@uvm.edu]

> Let's be clear here.  Are you saying "post it to the ITS, do it
> yourself, or shut up" (that's probably blunter than you intended, but I
> want to make sure I understand what you are saying) ???

Not exactly. Very simply - unless something is entered into ITS, its chances
of being acted on by any OpenLDAP project members are next to nil. This list
is for discussing how to use the software, requests for changes to the
software belong in the ITS.

re: "do it yourself or shut up" - you're missing the point, which is to use
the proper channels.

> Howard, I have no true knowledge of what you or your company does.  I
> have seen you post about versions of OpenLDAP and friends for Solaris
> before.

OK, let me give you some information on who I am and where I'm coming from. I
am a member of the OpenLDAP core team, my company Symas pays for my time
spent working on OpenLDAP. Over the past couple years, Symas' sponsorship has
made possible a vast quantity of bug fixes and enhancements to the OpenLDAP
code base. The fact that OpenLDAP 2.0 is 3 times faster than OpenLDAP 1.2 is
due to my work on profiling the system and rewriting much of liblber and the
slapd front-end. The majority of back-bdb was written by me, picking up where
Kurt left off. back-ldap was written by me, extended by a few other folks,
but is essentially mine. The reason that Cyrus SASL 2.1 works with OpenLDAP
is because of my work, debugging and extending what was there before. All of
the SSL/TLS certificate support was written by me, including the mechanism to
use SASL/EXTERNAL with TLS certificate DNs. Much of the early profiling work
on OpenLDAP 2.1 was done by me, and the majority of optimizations derived
from that. OpenLDAP 2.1 is a couple times faster than 2.0, mainly due to the
many hours I spent running profiles and rewriting slow code. The significant
optimizations in OpenLDAP 2.2 including new memory management scheme, new
internal API, new back-bdb caching mechanism, are being churned out by ...
guess. The code I'm working on now, in CVS, is already ~30% faster than
OpenLDAP 2.1. Shall I continue, or do you have the general idea now?

An aside - the people complaining on this list saying "OpenLDAP isn't meant
to perform" really piss me off. I and the other active developers have spent
countless hours working on the performance and stability of this thing, and
our efforts have paid off in substantial gains.

> I can't pay for anything.

Well then you should be glad to have what you have already. You think the
world owes it to you to give you powerful software for free?

> I'm not the one that controls the purse
> strings.  Now, when I find that money tree, then this all
> becomes play

This is not play for me; this is my livelihood. It takes a lot of time and
energy to move this code base forward. No one on the project has time to deal
with every issue that comes along. It's already costing me too much time just
to write this one piece of email.

  -- Howard Chu
  Chief Architect, Symas Corp.       Director, Highland Sun
  http://www.symas.com               http://highlandsun.com/hyc
  Symas: Premier OpenSource Development and Support