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?)
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: 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
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
