On Mon, Jul 09, 2001 at 05:55:56PM -0400, [EMAIL PROTECTED] wrote:
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
On Tue, Jul 10, 2001 at 11:16:32PM +0200, Tomasz Paszkowski wrote:
On Mon, Jul 09, 2001 at 05:55:56PM -0400, [EMAIL PROTECTED] wrote:
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
Jason Evans [EMAIL PROTECTED] writes:
The dxstore license has the same problem as the Sleepycat DB license. In
addition, it has the pesky advertising clause of the original BSD license.
It's effectively equivalent to the GPL + the advertising clause...
but their web site has a (short) list of
On 10 Jul 2001 17:49:54 +0300, Giorgos Keramidas wrote:
Is DB 3.x the only workaround for these bugs?
Even if it's not, it's a bit much to expect SleepyCat to do the extra
work of providing the alternative fix.
I think this has probably gone as far as it can for now.
The next step is for
On 10 Jul 2001 17:49:54 +0300, Giorgos Keramidas wrote:
Is DB 3.x the only workaround for these bugs?
Even if it's not, it's a bit much to expect SleepyCat to do the extra
work of providing the alternative fix.
I think this has probably gone as far as it can for now.
The next
On Tue, 10 Jul 2001 17:24:37 +0200, Sheldon Hearn [EMAIL PROTECTED] said:
The next step is for someone to see how hard it is to provide libc hooks
for the DB 3.x functionality that nvi requires, without removing the
existing DB 1.x functionality that other subsystems require.
It's actually
On Tue, 10 Jul 2001 19:20:23 +0300, Maxim Sobolev wrote:
At the first glance it is not a big problem - nvi could build its own
private static DB3 library and link against it, leaving DB 1.x for libc.
This is the approach that Keith's suggesting, and it makes a lot of
sense. The only
Well, can you recommend some other alternative? You mentioned db-tests
you created, etc. Did you evaluate any other dbm libraries useable for
us from the licensing perspective?
No -- there aren't a lot of choices here, and nothing that is a
good enough choice that it's worth rewriting
Keith Bostic [EMAIL PROTECTED] writes:
Nvi needs some of the features of Berkeley DB 3.X (transactional
logging) in order to fix long-standing bugs in the application.
Regards,
--keith
Is DB 3.x the only workaround for these bugs?
-giorgos
To Unsubscribe: send mail to [EMAIL PROTECTED]
Nvi needs some of the features of Berkeley DB 3.X (transactional
logging) in order to fix long-standing bugs in the application.
Is DB 3.x the only workaround for these bugs?
Pretty much. To make a long story short, all known versions of vi
(including the original) will lose changes if they
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
On 9 Jul, Keith Bostic wrote:
My guess is that your answer remains the same -- and, that's cool,
I'm used to losing this argument, I do so about twice a year. :-)
Just wanted to be clear.
Well, can someone comment on the useability of gdbm? I know, it has
dbm and ndbm
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
13 matches
Mail list logo
