[Citadel Development] Re: Long term plans for phase-out of Berkeley DB?
Heh. Most of the database layer is still pretty much the same code you wrote 22 years ago. You did a great job on that. I've thought about switching to a SQL model. It would confer a lot of benefits. It would also open up a huge effort in getting all of the code converted over to actually make use of that kind of flexibility. Among other projects that use a "nosql" store, LMDB seems to be the favorite. But the 4 GB limit on 32-bit systems is a show stopper for now. On the x86 side of things, everyone (except me) has long since moved to AMD64, but Citadel is really popular on Raspberry Pi, which is still 32-bit for most users even though the hardware can do 64. If I want to procrastinate (which might be a good move for now) it might make sense to simply hope that we can keep Berkeley DB viable until most of the ARM world has migrated to 64-bit, and then switch to LMDB and make 64-bit a requirement for Citadel installations. Funny you mention using an alternate `--prefix` ... I just started playing around with that last night and will probably move forward with that as part of the mainline installations.
[Citadel Development] Re: Long term plans for phase-out of Berkeley DB?
> 2023-06-15 13:32 from IGnatius T Foobar >Subject: Long term plans for phase-out of Berkeley DB? > > A bit of thinking out loud with regard to long term plans for Citadel >Server. > > Berkeley DB seems to have gained a bad reputation in the open source >community. > Much of it began in 2013 when Oracle switched it from the Sleepycat >license to the AGPL. Debian discontinued updating it completely, which >of course makes Citadel's life difficult because we have to bring in >our own version of it, and that can create conflicts with the ancient >version that's already on the system, which can't be removed because >there are still things dependent on it, etc. etc. Well, this brings back memories. I would imagine you can avoid most system-level conflicts by configuring it with an alternate --prefix. who knows how much a burden it will be if the source becomes incompatible with the next version of Linux, though. My answer would be to use SQL, even if only sqlite.
