Hacker News Board Hacker News, browsed like a classic message board
Live data from Hacker News

Limbo: A complete rewrite of SQLite in Rust

turso.tech

Post reply on HN
Print view View original

231–238 of 238 posts

Re: Limbo: A complete rewrite of SQLite in Rust

#231

Post by School-Cotton »

bruce511 wrote: post #115
quotemstr wrote: post #103

Earlier quoted context omitted.

I read the text: it's license hermenuetics at best and FUD at worst. Has there been a single instance in recorded history of the author of a public domain work trying to enforce usage, modification, or distribution permissions. Sure, you can point to theoretical variation in the precise semantics of the public domain in various jurisdictions, but it feels like a bar exam puzzle, not a real world practical concern. In…

Public Domain is not Free Software (in the FSF sense) because it has none of the encumbrances of a Free Software license. In other words you don't use PD software "like Free Software". You can use it in many places where Free Software would not be permissible. In terms of -developer- freedom, public domain is top of the pile, the Open Source, then Free Software. In terms of -user- freedoms Free Software is top of the…

You’re making the common mistake of confusing the copyleft vs. permissive distinction with the free software vs. open source distinction.

GPL is copyleft. MIT, BSD etc. are permissive. But all of those are both free software and open source, which are essentially synonyms.

The reason so many people get confused by this is that some of the people who prefer copyleft licenses (notably the FSF) also tend to prefer the term “free software”, for philosophical reasons.

Re: Limbo: A complete rewrite of SQLite in Rust

#232

Post by hnarn »

pjmlp wrote: post #209
hnarn wrote: post #205

Earlier quoted context omitted.

> The OSI and co. re-defining the term I don't know where you got this idea but it's not true. The OSI is simply defending the definition as it has been generally understood since the start of its usage in the 1980s by Stallman and others. The only group of people "re-defining" -- quite successfully I suppose, which you are an example of -- what open source software means are those that have a profit motive to use th…

In the 1980s we had Shareware, Beerware, Postware, whateverWare, Public Domain, "send me a coffee", "I don't care" open source, magazine and book listings under their own copyright licenses (free for typing, not distribution). Most of us on 8 and 16 bit home computers didn't even knew "Stallman and others" were. Additionally, GCC only took off after Sun became the first UNIX vendor to split UNIX into two SKUs, making…

I don't really understand what your point is, but shareware has never been "open source".

Nobody's arguing that public domain code, or the MIT, or whatever is not open source; it's obviously open source because it's _more_ free than the GPL.

Sure, devs can call any "source available" project "open source" because it gets people interested even though you have zero interest in using an open source development model or allowing others to make changes to the code. Devs can also expect well deserved flak from people who understand that "open source" is not marketing speak.

Re: Limbo: A complete rewrite of SQLite in Rust

#233

Post by cryptonector »

glommer wrote: post #143
_ugfj wrote: post #63

Earlier quoted context omitted.

And it never will The first 90% is easy, it's the second 90% that is very hard.

dunno, we rewrote a database before, much larger and harder than sqlite, and it was pretty successful. In my experience the 10% that doesn't get done is the 10% that people don't care too much about it anyway.

Which one?

Re: Limbo: A complete rewrite of SQLite in Rust

#234

Post by orthelt »

cryptonector wrote: post #21
danieljanes wrote: post #12

Given the code quality and rigid testing, SQLite is probably the last project that should be rewritten. It'd be great to see all other C code rewritten first!

That was my take when LibSQL was announced. And it still is and would be my take if LibSQL remains C-coded. But a Rust-coded rewrite of SQLite3 or LibSQL is a different story. The SQLite3 business model is that SQLite3 is open source but the best test suite for it is proprietary, and they don't accept contributions to any of either. This incentivizes anyone who needs support and/or new features in SQLite3 to join the…

Just stumbled onto this forum. Really, appreciated such a thoughtful and insightful comment. Nice corner of the internet you have here.

Re: Limbo: A complete rewrite of SQLite in Rust

#235

Post by jmull »

Retr0id wrote: post #229
jmull wrote: post #218

Earlier quoted context omitted.

They had been talking about making the high-level interface to sqlite async (sqlite3_step()). With io_uring you're talking about the low-level, where blocks are actually read and written. As-is, sqlite is agnostic on that point. It doesn't do I/O directly, but uses an OS abstraction layer, called VFS. VFS implementations for common platforms are built-in, but you can create your own that handles storage IO any way yo…

The VFS interface is synchronous, I don't see how a custom VFS could meaningfully implement asynchronous IO. > Well, it's perfectly possible to do that with the current sqlite. If you want to wrap a blocking API in python, with actual parallelism, you have to use multiple processes with communication between them. The main advantage of sqlite in the first place is that it's in-process, and you'd lose that.

> The VFS interface is synchronous

On a single thread. There can be multiple threads.

Of course leaving a thread idle while waiting for IO isn't great. That's why I noted it at the beginning. But it doesn't seem idling threads has proven to be much of a problem with sqlite, so it wouldn't be much justification for a rewrite.

> If you want to wrap a blocking API in python, with actual parallelism, you have to use multiple processes

You can use multiple threads in the same process.

(Python has some limitations in that respect, but that's not a sqlite issue and can't be fixed by a sqlite rewrite.)

Re: Limbo: A complete rewrite of SQLite in Rust

#236

Post by DeathMetal3000 »

pizlonator wrote: post #140

You can have a memory safe SQLite today if you compile it with Fil-C. Only tiny changes required. I almost have it passing the test suite (only two test failures left, both of which look specious).

Did a little reading on Fil-C and… “Also, it's slow – about 1.5x-5x slower than legacy C.”

So that’s dead on arrival.

Re: Limbo: A complete rewrite of SQLite in Rust

#237

Post by dang »

orthelt wrote: post #234
cryptonector wrote: post #21

Earlier quoted context omitted.

That was my take when LibSQL was announced. And it still is and would be my take if LibSQL remains C-coded. But a Rust-coded rewrite of SQLite3 or LibSQL is a different story. The SQLite3 business model is that SQLite3 is open source but the best test suite for it is proprietary, and they don't accept contributions to any of either. This incentivizes anyone who needs support and/or new features in SQLite3 to join the…

Just stumbled onto this forum. Really, appreciated such a thoughtful and insightful comment. Nice corner of the internet you have here.

Welcome to HN! (I'm a mod here.) I'm curious—how did you find us?

Re: Limbo: A complete rewrite of SQLite in Rust

#238

Post by PenisBanana »

rcxdude wrote: post #196
PenisBanana wrote: post #194

Earlier quoted context omitted.

> conversational casual chitchat : "open source" includes "public domain" No. What are you talking about? They are not related... other than for people virtually completely new to, well, open source. You are also completely confused, here, too: > Yes, the SQLite home page does say "public domain". However, when people interview SQLite create, Richard Hipp, he himself calls it "open source". He also doesn't correct ot…

This quickly gets into the details of definitions, but I think by most people's definitions of 'open source', something that is 'public domain' qualifies as such (see also 'source available' or 'copyleft/free software', one of which is not quite open source and the other is a more restrictive kind of open source. 'permissive' licenses like MIT and similar are closer to public domain but are different to varying degre…

^ is a confused demonstration of my point:

> They are different things. A project can be both; a person can talk about these two aspects of one project.

BTW, your pouring on of qualifiers (elsewhere "weasel words") shows your (correct) lack of conviction:

> the details of definitions, but I think by most people's definitions of 'open source', something that is 'public domain' qualifies as such

Post reply on HN