>>> Well, can someone comment on the useability of gdbm? I know, it has
>>> dbm and ndbm compatibility "mode" and a less restrictive license.
>>> Should we switch over to it?
>> This isn't necessary. The *current* FreeBSD libc Berkeley DB sources
>> are completely safe -- they're under a UC Regents copyright notice.
> Well, but there are programming bugs in it, as was pointed out in this
> thread. Unless FreeBSD wants to maintain its own db, we need to select
> someone else's. DB3 -- despite its technical merits -- does not fit
> because of restrictive licensing. gdbm's license is not ideal, but
> acceptable -- so I'm inquiring about its technical merits...
Technically gdbm is fine. I doubt you'll be able to displace
Berkeley DB, though; gdbm is less buggy, but doesn't offer many
of the features, nor does it offer equivalent performance.
> I'd welcome your comments in particular, since you are an expert in the
> field and there is not going to be a conflict of interest.
Actually, I'm pretty biased. :-) I'd like to see Berkeley DB
1.85 go away for a lot of reasons -- I don't much care what
it's replaced with.
>> This discussion is only regarding the possibility of making the
>> Berkeley DB 3.X functionality available to the FreeBSD community and
>> its customers.
> Well, it started out discussing the next release of nvi and promptly
> concluded, that it would require upgrading dbm. So, now the issue is --
> which db to pick: the currently used (buggy), the DB3 (too restrictive a
> license, IMO), gdbm, or something else (Net or OpenBSD's?).
Nvi won't require upgrading the library's dbm support. Berkeley
DB 3.X supports inclusion of multiple DB versions in a single
application. Nvi's simple solution is to include a copy of DB in
the nvi distribution.
Sleepycat Software Inc. [EMAIL PROTECTED]
118 Tower Rd. +1-781-259-3139
Lincoln, MA 01773 http://www.sleepycat.com
To Unsubscribe: send mail to [EMAIL PROTECTED]
with "unsubscribe freebsd-current" in the body of the message