BSDDB copyright and licensing restrictions while in use viaPython
jcw at equi4.com
Thu Feb 24 01:13:05 CET 2000
Oleg Broytmann wrote:
> On Mon, 14 Feb 2000, Fredrik Lundh wrote:
> > > > if you prefer to use free and IMHO better data-
> > > > base engines, check out metakit (www.equi4.com)
> > > > or gadfly (www.chordate.com).
> > >
> > > Any information on what ways these are "better" than Berkeley
> > > DB? Any pointers, at least?
> > humbly speaking:
> > metakit: fast, efficient, small, highly portable,
> > great python interface, and free.
> Hm, portable? Well, exerpt from README:
> * Solaris 2.6 / gcc 2.8.1
> The Solaris builds are nasty for several reasons:
> Despite this, I'm doing my best to resolve these issues. Having a
> solid build of the core *and* of Tcl / Python extensions is quite
> * Other Unix systems
> No notes yet, more details expected when the new release is tried
> on other Unix systems.
> I cannot consider it "portable". Oh, yes, I have exactly 2.8.1,
> even worse, on Solaris 2.5.1. No other program reveals bugs in 2.8.1.
Well, you sure are going out of your way to make your point. It would
be nice if you also mentioned that MetaKit runs on Unix, Windows, Mac,
VMS, BeOS ... quite a wide range of systems from small-model MS-DOS to
64-bit Alpha (Unix, NT, VMS, take your pick), and quite a wide range of
compilers (including Sun's, AIX's, and half a dozen on Windows).
MetaKit has been "closed source" until last December, and hence has not
benefited from the wide platform tweaking OSS usually gets over time.
Perhaps it would be best to reserve judgement until MetaKit has been
around as open source for a year or so?
I agree 100% with you that the MK build mechanism needs improvement, and
will add that all such improvements will be integrated and acknowledged
with gratitude. Hey, I see a VxWorks port has just been completed :)
As to the pros and cons of MK versus other systems: there is no single
answer. MK can run circles around BDB for some things, while being way
slower in some other cases. This is not related to the quality of any
implementation, but to the fact that MK uses column-wise storage. This
leads to a very different set of trade-offs, and a very different way of
thinking needed to make it work well. On other words: YMMV.
Oleg, I welcome your input on MK, positive and negative. Yes, in a way
MK is a "poor boy", because it is a new kid in the (OSS) neighbourhood.
But it's a lively newcomer, and you're welcome to help make it grow up.
More information about the Python-list