This fork has exactly zero new code, but they already managed to change the license and the code of conduct. Their plans include io_uring, Rust and WASM functions - the first two negate the "single-.c-and-.h multi-platform" paradigm that made SQLite what it is, the third thing seems like a feature very few people would care about. They also want to make SQLite distributed for some reason (uh, just use Postgres?)
What part(s) is/are inflammatory? (I'm honestly asking because I don't see anything obvious and I wish to understand your perspective. I'm not trying to imply that there's nothing inflammatory there by using a question)
SQLite cannot accept random contributions. It's on A350 flight systems, where failure is not an option. The maintainers are able to uphold this quality, but random contributors are not.
It appears that the true desire is log shipping (archived logs, transaction logs, etc.) - the ability to move transaction data between databases, perhaps in multimaster.
The only way such functionality is getting into SQLite is if the project agrees to write it, likely for major funding.
A fork implementing these features will be regarded with interest, but will not be accepted without substantial rework.
Linux is used to run the world and there are failures as well as contributors.
It is implied that SQLite is not run properly because it is not responsive to many of its users. User contributors will be sorely disappointed.
There is an assertion that SQLite is behind the times. It has a laser focus on reliability, which hold back features desired by some.
The article disregards the TH3 testing compliance, and asserts that forks are inevitable, which is not true. TH3 is a moat around SQLite that dissuades such attempts, and ignoring this fact also likely invokes umbrage.
There is also a mention of the code of conduct that SQLite has chosen. It does not inspire universal admiration.
The article wants the following, and some are unlikely to ever appear upstream:
1. We would like to use io_uring and asynchronous interfaces
2. We would like to provide replication hooks for distributed systems
3. We would like to allow for WASM-based user-defined functions
NASA uses nodejs and kubernetes. Everyone's safety threshold and threat model is not the same.
https://mobile.twitter.com/gitlab/status/1174427375347666944...
Do you think Airbus updates their copy of SQLite to the newest version constantly? Bugs make it into SQLite every release, and no released version of SQLite is known to be DO-178B compliant. Seems a lot more likely that it is as Dr Hipp said a few years ago [1], that some customers have qualified specific versions of SQLite in specific configurations for use in applications that require DO-178B compliance. He says that he thinks that those companies certified it to D or C level, which is non-critical stuff, like failure leading to passenger discomfort, e.g. they may be using SQLite in the in flight infotainment system.
Awesome! That sounds kick ass! Turn up the perf some orders of magntude, use a safer kanguage with better tools, and make it usable safely from anywhere!? My heavens this db could go to all kinds of new places!
> the first two negate the "single-.c-and-.h multi-platform" paradigm that made SQLite what it is,
Seriously feels like c needs to grow past keeping everyone rubbing two sticks together to eek out cross-compatibility. We've been stuck at such a silly minima in c/c++ for so so long. Why is code not reusable?
Also it helped, yes, but im not sure this simplicity is the defining "lite" thing of sqlite. Yes: that is damned lite to use/consume, abut it's just one characteristic mong other lite-nesses. It doesnt strike me as that essential.
And if it's impedeing exoloration & growth & other uses... then heck yes a breakaway attempt should be formed. There's excellent material here, & limiting it to a tiny quaint shape & form, purely to help the ridiculous mess of build systems/package management (and especially their absences), seems like an extreme tradeoff. For sure there should be ventures to try to explore & go on, see what the other untapped values might be!!
> the third thing seems like a feature very few people would care about.
Well, i'd hope there's a lot of people who wouldnt think to care today that might tune in & turn on, if they had a lightweight db system that was easy to embed. I dont know how many billion devices have access to the web, but giving them the ability to use sqlite seems sharp & obvious!
Yesterdays post on qemu painted a great picture of a similar case, of there being a ton of excellent materials here, but it being locked into a very conservative & narrow perspectuve of use. The breakout of qemu-kvm unlocking trapped potential, rewriting the world, seems apt. Progress ought have representation!