Are we sure edge computing providers have io_uring enabled? It is disabled in inter alia, ChromeOS and Android, because it's been a significant source of vulnerabilities. Seems deadly in a multi tenant environment.
Not an expert at all: I wonder if getting the perf requires trading-off some (advertised) safety. IO uring has been noted to be confusing with async in Rust, https://news.ycombinator.com/item?id=41992975
I'm reminded of how Confluent advertised Kafka as a database. They quietly externalized key guarantees of an RDBMS onto their customers, who were then saddled with implementing those guarantees in application level logic. By obscuring the trade-offs, Confluent made developers feel they could have their cake and eat it too.
IMHO, most of io_uring's performance should come from reducing transition between kernel and userspace. There doesn't need to be a safety tradeoff there (although in practice, there have been several safety issues). There may be a trade off against having a simple concurrency model; without io_uring you can't really request an accept and not handle the response that comes back, because a syscall is necessarily synchronous from the point of view of the caller; the calling thread can't continue until it gets a response, even if that's EINTR.
Out of my league / knowledge, but a tidbit that you might understand better: last time I mentioned this, someone said something about SELinux can't do security checks and implied it's some fundamental mismatch, rather than some work SELinux can do
Well I'm a little outside my league on SELinux, but as I understand it, SELinux a way to limit syscalls by configuration.
io_uring operations are similar to syscalls, but not exactly the same thing, so if I've read up correctly, I think SELinux originally may not have covered operations --- if the config allowed you to use io_uring, you could bypass SELinux restrictions, and the easiest/safest thing to do for that is to restrict io_uring. I think this may have been resolved, it looks like there was work on SELinux controls for io_uring back in 2021 [1] that looks like it got merged, but I haven't really followed this. There's also the issue that what happened in Linus's tree 2021 doesn't necessarily reflect what's in common kernels in 2024; some distributions are built from ancient branches.
Based on the language in the pull request, I would think you'd end up needing to have near duplicate policy entries for regular syscalls and io_uring operations, which sounds tedious (but the whole SELinux thing sounds tedious to me, so I'm maybe not the right person to ask :D )
Might've replied to the wrong comment: I don't think io_uring is bad, and the comment doesn't contain 'bad', and I certainly don't think async IO is bad :)
I think you've taken the most cynical view possible.
SQLite is open source but not open contribution. So if they "won't do it for us" and "we need it", what else are they supposed to do? They're offering SQLite in the cloud, obviously they need to offer a streaming backup solution. Is there something wrong in building that?
Alternatively, do you want them to reimplement features in SQLite already built out by the SQLite team?
Really sounds like you're complaining about getting an open source, MIT licensed, open contribution bit of software for free that you're under no obligation to use. And here you are complaining about "community consensus".
It seems they proposed a way to resolve the contradiction I raised (io_uring isn't supported on cloud providers) with the ground reality in the company's blog post.
Namely, that:
* it is intended for edge function deployment.
* the paper they mention that is informing their decision to rewrite is based on perf improvements in the longtail by using io_uring.
I framed it as "Are we sure...?", but truth is, I know providers don't have io_uring support. This is relatively straightforward to derive from edge functions are well-known to be multi-tenant.
A cursory search shows unresolved AWS tickets re: this, and multiple announcements from Google about how it has been disabled in gCloud.
Thus, it is likely they understood I was framing it politely, and that there was a clear contradiction here, hence their reply to me, raising a potential resolution for that contradiction, a resolution I hadn't considered.
I don't see anything complaining, or bringing up, or implicitly denying, all the other stuff ("open source", "MIT licensed", "open contribution", "software for free" "under no obligation to use."). In fact, they explicitly indicated they completely agree with that view ("it's very cool that they're making parts of their tech FOSS.")
The Turso company provisions infrastructure using fly.io, which uses firecracker VM (which as of now does support io_uring afaict). They are using the term “serverless” liberally maybe? Goodness knows we all do.
io_uring isn't supported on cloud providers for now, but it may not be the case in future. Which is fine, because Limbo won't be ready for a few years at least.
The problem is that SQLite already exists, and is public domain. It's a fantastic piece of software engineering that has had a lot of time and effort put into making it great.
The pitch for these SQLite alternatives is:
- SQLite is public domain so there's no problem with us rewriting it
- We're going to rewrite it in Rust because that's going to make it inherently better (and don't question this)
- We're going to MIT license our rewrite because there's various reasons why people would rather use MIT-licensed code than public domain code (but SQLite being public domain means we get to do all of this rewriting and re-licensing to begin with)
- Also we're going to extend SQLite to be “cloud-capable” because that's our business use-case, even though it's completely at odds with SQLite's intended use-case
- Also we're going to foster a “community” around our rewrite(-in-progress) (because people still think this is something desirable for some reason, as though a nonzero part of SQLite's greatness is that it operates entirely without having do deal with “nerd drama” that such “communities” inevitably breed)
- Also, we replaced that pesky, unsavory-to-our-sensibilities “Code of Ethics” with a bog-standard “Code of Conduct”—because, again: “community”
- But we're not going to even attempt to replicate the rigorous, arduous, and closed-source testing that goes into developing SQLite (which really makes up the bulk of its engineering effort)
- We've made some progress toward all of this, but it's nowhere near done yet
- But we're announcing it now anyway, because “hype” and “community” and “modern”
- Also, look at our microbenchmarks that show that our unfinished SQLite rewrite is already faster than SQLite (because we haven't reimplemented everything from SQLite yet) (and also we don't plan to reimplement everything from SQLite anyway)
I find it really odd that I can only seems to find criticism of any of this here on HN, and in a couple of reddit threads. It's kind of like when there was that Godot controversy awhile back, and some people made a fork and announced it, despite being identical aside from the Code of Conduct. Merely announcing a fork/rewrite of existing open-source software as a means of "building hype" and “creating a community”, while benefiting from untold man-hours of work done by others, strikes me personally as rather untoward behavior—regardless of whether the reasoning behind said fork/rewrite is ideological (Redot) or business (libSQL/“Limbo”).
Software—especially software used to create other software—should be lauded for its engineering efforts, rather than its ability to “build hype” or “build and foster online ‘community’ ‘engagement’”. If SQLite was abandonware, then it would be a somewhat different story, but SQLite is an amazing piece of software—perhaps the most widely-used on the planet—that is still being actively developed and supported. So, piggybacking on its success, without having concrete, demonstrable improvements to its functionality, comes across as… well, I can't think of another polite, applicable adjective than “untoward”.
> we're not going to even attempt to replicate the rigorous, arduous, and closed-source testing
Almost everything you've said is wrong, but this one is trivially easy to prove wrong. You say "not even going to attempt" but they plan to take testing seriously from the get go. They say:
> Since this is a reimplementation, doesn’t that mean that testing is now even harder? The reality is that it is the other way around. Since we are reimplementing it from scratch, we are doing it with Deterministic Simulation Testing (DST) built-in from the get-go. We have both added DST facilities to the core of the database, and partnered with Antithesis to achieve a level of reliability in the database that lives up to SQLite’s reputation.
> Deterministic Simulation Testing is a paradigm made famous by the folks at TigerBeetle, that we at Turso already dipped our toes into with our server-side code. With DST, we believe we can achieve an even higher degree of robustness than SQLite, since it is easier to simulate unlikely scenarios in a simulator, test years of execution with different event orderings, and upon finding issues, reproduce them 100% reliably.
But fuck it, I got time. I'll tackle the other dubious claims you've made as well.
> Also, we replaced that pesky, unsavory-to-our-sensibilities “Code of Ethics”
They haven't replaced it because Limbo is a new project. LibSQL is a fork of an existing project but again, they haven't replaced the "Code of Ethics" in the repo (https://sqlite.org/src/dir?ci=trunk) because it never existed in the repo, just on the sqlite.org website.
So they "replaced" nothing. They simply added their own code of conduct, which (I agree with you) is bog standard for a project on Github.
---
> Announcing before it's ready
Yes? That's normal? You're objecting to a project even existing on Github if it's not 100% done? They specifically explain why they've done it. They're building in the open, they're seeing excitement from outside contributors who want to contribute. So they're announcing to make more potential contributors aware this project exists.
Only someone with a warped mind could find something objectionable about starting small and iterating with the community.
---
> Also we're going to extend SQLite to be “cloud-capable” because that's our business use-case, even though it's completely at odds with SQLite's intended use-case
Nothing you've said makes me think you understand the social side of building software, but this makes me think you don't understand the technical side either. Perhaps you missed the link on this thread where they explain why SQLite works well in the cloud.
I'll explain for you though, in case you're unable to find the link at the top of this page. SQLite relies on random access from disk, which made it a poor fit for cloud workloads when the cloud used HDDs exclusively. HDDs work much better for sequential access, which is why LSM trees were invented. So rather than reading from a random part of the local disk (10-20ms) you'd rather pay the network cost (0.5-2ms) and read from a database on a different machine that has optimised it's data storage for sequential read.
But SSDs change the game. A random read of 4k from a local SSD is 150 microseconds (https://gist.github.com/jboner/2841832), always less than the network round trip. Local SQLite running on an SSD is suddenly the lowest latency database.
For infrequently changing data that needs to be served with low latency, SQLite is the best choice in the cloud.
If you don't follow this, it's alright. I didn't expect you to.
---
> SQLite is public domain so there's no problem with us rewriting it and We're going to MIT license our rewrite because there's various reasons why people would rather use MIT-licensed code than public domain code
Yes, this is true. I don't think this was an objection from you.
---
> We're going to rewrite it in Rust because that's going to make it inherently better (and don't question this)
What should they be writing it in? I notice you don't say. You reckon they should start a new C code base in 2024?
---
> Redot comparison
Redot is a fork created solely because the creators didn't like a tweet about Godot being welcoming to LGBT game developers. LibSQL was created because they wanted to add features to the SQLite codebase and weren't allowed.
No one disagrees that SQLite is highly useful, rock-solid reliable software. But I disagree with you that it is perfect in every way and no one should ever second guess any decision made by the maintainers. Turso wants to try something different. Nothing wrong with trying.
> [DST and Antithesis is just as good if not better than TH3]
Remains to be proven.
> So they "replaced" nothing. They simply added their own code of conduct
This is pedantic. Yes, the Code of Ethics is on the SQLite website, and not in its source directory, so yes, technically cloning the repo and adding a Code of Conduct is not “replacing” the Code of Ethics in terms of files in repositories. Arguing this point as you have is simply inane. SQLite has a Code of Ethics, and libSQL/“Limbo” are unbeholden to the SQLite Code of Ethics and instead have a Code of Conduct. Taking umbrage with describing this as “replacing the Code of Ethics with a Code of Conduct” is just being pedantic for the sake of it.
> Only someone with a warped mind could find something objectionable about starting small and iterating with the community.
Wholly unnecessary, overemotional ad hominem. If SQLite was abandonware then there would be no issue—but it's not, it's great software that is regularly updated (without a “community”, in the sense being discussed here), so, announcing a rewrite long before it's done and declaring how much better than SQLite it is going to be comes across as rather untoward.
For many people, such as myself, the lack of “community” in the SQLite project is a selling point, rather than some kind of problem—such that when an incomplete fork/rewrite with an emphasis on “community” is announced, myself and many others see that as yet another point against it. Sure, you're going to have many naive or otherwise inexperienced developers who care more about Codes of Conduct and “community policing” and “feeling like you're part of a community” or whatever, and that's fine, go right ahead and have fun with that. But for the rest of us, who enjoy using well-made software without getting into any of that nonsense, SQLite and the way it goes about doing things will remain the superior option.
> What should they be writing it in? I notice you don't say. You reckon they should start a new C code base in 2024?
Part of what makes SQLite so useful is that it is written in C, and therefore is easy to compile and integrate into just about anything. I'm generally unfamiliar with Rust, so I don't know, maybe it's possible to make a SQLite clone in Rust with full C ABI compatibility. But if this is not the case, or this is not what “Limbo” is aiming for here, then yes, it is strictly worse in the general sense than SQLite, except for specific use-cases.
If libSQL and “Limbo” were being presented as alternatives to SQLite that are more useful for specific use-cases, then I wouldn't've felt the need to comment in the first place. The problem is when you begin undertaking a project of this enormity, baselessly assert that the thing you're trying to do is straight-up better than the existing SQLite gold standard, and even position it in the market as an objectively better replacement for SQLite for various reasons, including “community”, “modern”, and “Rust”.
Additionally, naming your SQLite rewrite library “libSQL” is also quite clearly a means of semantically positioning it as a better, “more ‘modern’”, more generic SQL library than SQLite—and that's great marketing for a specific kind of developer. When searching e.g. Twitter for “libSQL”, one will find posts where people describe things they're working on, saying things like, “Uses SQLite for database (plan to replace with libSQL soon!)”, which proves my point—they've succeeded in positioning libSQL as “a more modern SQLite”, to the point where some developers see the need to replace SQLite with libSQL just for the sake of doing so. Again, this would be totally fine if SQLite was abandonware—but, once again, it's quite the opposite of that.
Interesting that you didn't respond to the substance of my comment - the technical reasons that cloud SQLite works so well. That after making an awfully wrong categorical statement "even though it's completely at odds with SQLite's intended use-case".
> [Rust C API] ... I'm generally unfamiliar with Rust
Evidently. But then should you be writing snarky comments like "We're going to rewrite it in Rust because that's going to make it inherently better (and don't question this)". Really makes it sound like you know that the choice of Rust should be questioned.
For what it's worth, Rust codebases can be compiled to expose a C ABI that other applications can integrate with. For example, the rustls project exposes an OpenSSL compatible interface (https://www.memorysafety.org/blog/rustls-nginx-compatibility...) which makes it trivial to integrate into applications that expect OpenSSL.
> [Limbo SQLite compatibility] ... But if this is not the case, or this is not what “Limbo” is aiming for here
You know ... you could just read a little before writing so much. On https://github.com/tursodatabase/limbo it says their stated goals are - "SQLite compatibility. SQL dialect support. File format support. SQLite C API". They want to expose the exact same C API that SQLite exposes.
Does that sufficiently address your concerns around Rust codebases being used from other languages and Limbo's compatibility with SQLite?
---
> even position it in the market as an objectively better replacement for SQLite for various reasons, including “community”, “modern”, and “Rust”.
To be clear, at no point did anyone say it was "an objectively better replacement for SQLite". No one said it, because Limbo is years away from feature parity.
It seems acceptable to aim to build something better than SQLite. Having a goal is fine, because it points them in a direction. But for some reason, you're getting upset that ... they have goals? Bizarre.
And if their reach feature parity while using io_uring, then yeah it is likely that it will outperform SQLite which uses synchronous I/O.
---
> Testing
We are agreed, it remains to be seen if DST can make something as reliable SQLite's testing strategy has made SQLite. But we'll only see it if someone tries, and that is something you seem quite hostile to.
At least Limbo will do their testing in the open and we can all learn from it whether they succeed or not.
---
> Code of Conduct
I feel changing/replacing files from the repo is important, because it feels similar to replacing a LICENSE file. You can't relicense someone's work just because you feel like it. Similarly, if the Code of Ethics had been replaced in the repo, that would have felt similar to relicensing, although not the same.
Again, I'll be blunt. Do you want anyone who works on this public domain code to adopt principles like "Prefer nothing more than the love of Christ". Not being Christian, I personally prefer nearly all things to the love of Christ. I know I'm not the only developer who feels this way.
The force with which you're arguing this makes me wonder if you really want this sort of religious fervour to become more widespread in open source. Where some projects are Christian, some are Muslim and so on. Of course, then we can really segment the projects into Catholic, Protestant, Anglican, Eastern Orthodox, Sunni, Shia - really experience the full power of religion in open source software development. Wouldn't it be great when OSS projects have a code of ethics that start with "All current developers agree that there is no deity but Allah and Mohammad is his Prophet".
From a legal point of view - there is no reason to adopt this because the code is in public domain. From an ethical point of view - there is no reason for the libSQL to adopt a code that they likely personally disagree with ("all current developers agree ..."). From a practical point of view - they want to encourage contributors, not discourage them (like Hipp was and is), so there's no reason to adopt a code that deliberately drives away contributors.
I don't know how you feel because you carefully dance around that. You simply criticise the libSQL folks for anything they do. Criticising is easy, doing is difficult. So say precisely what Code libSQL and Limbo should adopt and why you think it's such a good idea.
Of course they are scratching their own itch, so to speak. Thats what companies do. I think the fact that they are doing so much in the open is the indication of good stewardship itself. I'm not sure what else they would do or release that they didn't need internally. For that matter, I'm not really aware of many significant contributions to FLOSS at all that aren't initially intended for company use, that's kinda how it works. Where I'm surprised here is how much secret sauce Turso is sharing at all.
I have no problem with them scratching their itch. That's par for the course.
I'm salty about them describing the SQLite licensing, development model, and code of ethics as almost toxic, setting up a separate entity with a website and a manifesto promising to do better, and then folding “libSQL into the Turso family” within the year.
They forked, played politics, added a few features (with some ill-considered incompatibilities), and properly documented zero of them.
And I'm salty because I'm actually interested in some of those features, and they're impossible to use without proper documentation.
I've had much better luck interacting with SQLite developers in the SQLite forum.
> We take our code of conduct seriously, and unlike SQLite, we do not substitute it with an unclear alternative. We strive to foster a community that values diversity, equity, and inclusion. We encourage others to speak up if they feel uncomfortable.
The word toxic clearly stung, but putting “unlike SQLite … we encourage others to speak up if they feel uncomfortable” in a manifesto is fine. Well, I could argue I'm just speaking up.
> libSQL was always part of Turso. So, I don't get your point.
> We have our own self interest in making those changes (…) But we also wanted to create a welcoming community, that is open to everybody, abides by a modern code of conduct and a clear OSS license, and reimagined what SQLite could be in broader ways than just our narrow needs.
A little latter down that line you sum it up: doing the above (living up to your grandiose claims of a more welcoming SQLite) “meant twice the investment” (aka a lot of money) and didn't pan out as a marketing play (showed engagement).
So instead of a community that “reimagined what SQLite could be in broader ways than just our narrow needs" we just get the features you had your "own self interest in making."
Which is fine, but doesn't really match the manifesto.
> Again this is incorrect. There are some docs…
Emphasis on some.
Do you have any documentation on how to build on the Virtual WAL (internal SQLite API that you simply opened up)? Or is that's still a Rust example of an implementation that simply wraps another and logs without detailing anything beyond function names?
Do you have any documentation about the new WAL API that isn't "libsql_wal_insert_begin begins WAL insertion"?
I'm sorry, but goal here isn't to make things useful to others. Which is fine really: you're doing more than you're required. But compared to SQLite developers, and their forum, it's not much.
> One project in particular was very suitable for us, SQLite Multiple Ciphers. Since it is licensed under MIT, we have just moved the code into libSQL.
Hard to believe they actually went after D. Richard Hipp--a guy I've only ever heard described as extremely warm, honest, and generous--and for his faith, no less. But then again, these are Rust people, so I guess I shouldn't be surprised, should I?
