Re: picking a DB (Re: nvi maintainer?)
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 license, IMO), gdbm, or something else (Net or OpenBSD's?). Does anyone have tried dxstore (http://www.dss.bc.ca/dxstore) ? I'am using it in few very big projects and it works fine. And of course it has BSD-like license. -- _ __ __ / \ | | / / / \ / \ --- Tomasz Paszkowski -- | |\ \| | \ \ |/ \||/ \| === IPv4://3575244866 === IPNg://3ffe:8010:59::2 === /_/ \__/ /_/ \_/ \_/ ( 2B | ~ 2B ) == FF --- To Unsubscribe: send mail to [EMAIL PROTECTED] with unsubscribe freebsd-current in the body of the message
Re: picking a DB (Re: nvi maintainer?)
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 to pick: the currently used (buggy), the DB3 (too restrictive a license, IMO), gdbm, or something else (Net or OpenBSD's?). Does anyone have tried dxstore (http://www.dss.bc.ca/dxstore) ? I'am using it in few very big projects and it works fine. And of course it has BSD-like license. 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. Jason To Unsubscribe: send mail to [EMAIL PROTECTED] with unsubscribe freebsd-current in the body of the message
Re: picking a DB (Re: nvi maintainer?)
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 other open source database systems, one of which (tdbm) apparently has transaction support and is under a BSD-like license (with a stricter advertising clause, though). It's old (last updated 1994?) but comes with a rather detailed TODO- list which should help kick-start development if we choose to import tdbm. DES -- Dag-Erling Smorgrav - [EMAIL PROTECTED] To Unsubscribe: send mail to [EMAIL PROTECTED] with unsubscribe freebsd-current in the body of the message
Re: picking a DB (Re: nvi maintainer?)
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 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. If we don't get that, the decision becomes much simpler. :-) Ciao, Sheldon. To Unsubscribe: send mail to [EMAIL PROTECTED] with unsubscribe freebsd-current in the body of the message
Re: picking a DB (Re: nvi maintainer?)
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 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. 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. -Maxim To Unsubscribe: send mail to [EMAIL PROTECTED] with unsubscribe freebsd-current in the body of the message
Re: picking a DB (Re: nvi maintainer?)
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 fairly simple to do what is needed; it's just a rather tedious and unpleasant task. What needs to be done is that the DB 1.85 API that's in libc be moved out to a separate library (call it `libdb185' or something similar). The actual code stays in libc for the use of internal libc functions (getpw* in particular) and for the NDBM emulation which SUS requires. -GAWollman To Unsubscribe: send mail to [EMAIL PROTECTED] with unsubscribe freebsd-current in the body of the message
Re: picking a DB (Re: nvi maintainer?)
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 reasonable argument against it is the size of the vi binary in embedded systems, but that one's taken at least one direct hit on this thread. So then we're done until there's a new release of nvi. Great. :-) Ciao, Sheldon. To Unsubscribe: send mail to [EMAIL PROTECTED] with unsubscribe freebsd-current in the body of the message
Re: picking a DB (Re: nvi maintainer?)
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 everyone's data to switch. 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. Well, may be that's how the nvi application will be distributed, but I doubt, that's how the nvi part of the FreeBSD will be built... In all probability, the new nvi will just get hacked to work with dbm-1.85 or gdbm. 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 =-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-= Keith Bostic 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
Re: picking a DB (Re: nvi maintainer?)
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] with unsubscribe freebsd-current in the body of the message
Re: picking a DB (Re: nvi maintainer?)
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 crash at the wrong time due to corrupted recover files. The obvious solution is to use standard transactional techniques like write-ahead logging and recovery to ensure that the vi recover file isn't ever corrupt. Berkeley DB 3.X has that infrastructure, but it's complex stuff. Regards, --keith =-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-= Keith Bostic 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
Re: picking a DB (Re: nvi maintainer?)
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. 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? 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. Well, may be that's how the nvi application will be distributed, but I doubt, that's how the nvi part of the FreeBSD will be built... In all probability, the new nvi will just get hacked to work with dbm-1.85 or gdbm. Although it is possible, that the relevant parts of DB3 will be linked staticly into it (kind of like DB3 Lite), it would be rather ugly :( Thanks, -mi To Unsubscribe: send mail to [EMAIL PROTECTED] with unsubscribe freebsd-current in the body of the message
Re: nvi maintainer?
[moved to -current] On 9 Jul, Keith Bostic wrote: From: [EMAIL PROTECTED] Mmm, so there will be a library in /usr/lib, which a commercial application will not be able to link against? No thanks, I'd rather take gdbm and their LGPL... Just to be clear -- they could link against it using the same, standard functionality that FreeBSD uses. They couldn't link against it and use all the additional features/functionality. So we'll have to document, which functions it is Ok to call and which arguments/flags can and can not be passed to them. Brrrgh... 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 compatibility mode and a less restrictive license. Should we switch over to it? -mi To Unsubscribe: send mail to [EMAIL PROTECTED] with unsubscribe freebsd-current in the body of the message
Re: nvi maintainer?
Just to be clear -- they could link against it using the same, standard functionality that FreeBSD uses. They couldn't link against it and use all the additional features/functionality. So we'll have to document, which functions it is Ok to call and which arguments/flags can and can not be passed to them. Brrrgh... As a system distributor in a previous life, Brrrgh indeed. :-) The way we've done this for previous systems is not try and document how it can be called, but only permit use *through* the system's library, that is, use it via getpwent(), the libc network functions and so on. 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 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. This discussion is only regarding the possibility of making the Berkeley DB 3.X functionality available to the FreeBSD community and its customers. Regards, --keith =-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-= Keith Bostic 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
picking a DB (Re: nvi maintainer?)
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 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... 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. 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?). -mi To Unsubscribe: send mail to [EMAIL PROTECTED] with unsubscribe freebsd-current in the body of the message
Re: picking a DB (Re: nvi maintainer?)
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. Regards, --keith =-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-= Keith Bostic 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
