Re: Squeeze can't fit on 512MiB
* Samuel Thibault:
> - Base+Standard grew from 397MiB to 491MiB
> (we install libdb4.{5,6,7,8} !?,
I suspect that this is caused primarily by API and ABI
incompatibility, and in part by the lack of response to bug reports
from upstream. Everybody who uses Berkeley DB extensively has once
been bitten by a regression. Often, people outside Sleepycat and
Oracle couldn't fix those bugs in a timely fashion, so the affected
people stay on the version which works for them. Even upon request,
Oracle does not provide individual patches for bug fixes which have
been applied to subsequent major version. Their source repository is
totally private, too (if they use version control at all).
On top of that, while there is an environment migration strategy, it
requires a lot of boilerplate code that is hard to get completely
right. Few applications provide it, so you end up with risky manual
migration procedures and user-visible disk format incompatible. The
actual data format is extremely stable, except for the DB_HASH format,
which was inferior to DB_BTREE in pre-4.5 (I think) release. However,
for reasons I don't completely understand, almost all scripting
language bindings for Berkeley DB defaulted to DB_HASH, so we end up
with plenty of pointless disk-format incompatibility, in potentially
large files containing user data where it really, really hurts.
I guess that for most users of Berkeley DB, SQLite would be a better
fit: thread-safe and NFS-safe by default, automatic crash recovery, a
simple API with a stable API and ABI, a commitment to disk format
compatibility, no predetermined limits on transaction size, and the
ability to browse the database using third-party tools. In the
multiple writers case, SQLite cannot compete with Berkeley DB running
in the Transactional Data Store mode, and it lacks built-in
replication, but how many libdb4.x reverse dependencies set *that* up
correctly?
Reply to: