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

161–170 of 238 posts

Re: Limbo: A complete rewrite of SQLite in Rust

#161

Post by froh »

cryptonector wrote: post #158
bruce511 wrote: post #59

Earlier quoted context omitted.

>> The SQLite3 business model is that SQLite3 is open source This is going to sound pedantic, but SQLite is not Open Source. It's Public Domain. The distinction is subtle, but it is important.

open source != Open Source. If I had meant the latter I would have written Open Source, but I wrote open source because I meant the former. How's that for being pedantic?

not helpful.

capitalization is not bearing meaning in these contexts.

open source means OSI compliant, broadly speaking, and licensed as such.

in contrast, public domain doesn't exist in some jurisdictions, which is why sqlite as a company had to create an option to provide an official license. which they found so annoying that they charged a sweet fee to send a signed printed letter...

Re: Limbo: A complete rewrite of SQLite in Rust

#163

Post by froh »

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…

> The SQLite3 business model is that SQLite3 is open source but the best test suite for it is proprietary

no.

the business model is services, and a red phone to companies who use sqlite in production. like nokia back in the days when we had these little flip phones, or desk phones had a "rolodesk" built in, or many other embedded uses of a little lovely dependable data store.

the services include porting to and "certification" on specifically requested hardware and OS combinations, with indeed proprietary test suites. now these are not owned by sqlite, but by third parties. which license them to sqlite (the company).

and it started with being paid by the likes of nokia or IBM to make sqlite production ready, add mc/dc coverage, implement fuzzing, etc etc etc.,

their license asks you to do good not evil. and they take that serious and try their best to do the same. their own stuff is to an extreme extend in the public domain.

Re: Limbo: A complete rewrite of SQLite in Rust

#164

Post by cryptonector »

wmf wrote: post #65
bruce511 wrote: post #59

Earlier quoted context omitted.

>> The SQLite3 business model is that SQLite3 is open source This is going to sound pedantic, but SQLite is not Open Source. It's Public Domain. The distinction is subtle, but it is important.

Public domain is a form of open source.

Yes, public domain is a form of open source, but not of Open Source (for reasons that IMO are silly).

Re: Limbo: A complete rewrite of SQLite in Rust

#165

Post by heisenbit »

vitiral wrote: post #120

> SQLite’s test suite is proprietary This is literally the first time I've ever heard of this, for any project anywhere. I suppose Android is built a bit in this way, but that's a whole other can of worms.

Well, Java during its initial life was controlled to a degree through the control of the tests: https://en.wikipedia.org/wiki/Technology_Compatibility_Kit .

Re: Limbo: A complete rewrite of SQLite in Rust

#166

Post by TheGoodBarn »

So many good things with incremental improvements in the space, but as a consumer it kinda stresses me out having to worry about libsql vs sqlite vs duckdb etc.

I personally use SQLite and DuckDB daily, but recently adopted turso in lieu of litestream for a something. I appreciate that they all are relatively compatible but I'd love to just have a tool.

Even then thats why I love the relationship between SQLite and DuckDB. I can backend my system with SQLite and run analytics and processing via DuckDB and they service specific purposes.

The hard thing with this for me is being a split consumer and not having the bandwidth to split my attention between who is doing better innovation and just using a tool I can rely on to predictably get the job done for me.

That being said, hats off this is awesome. I really appreciate turso.

Re: Limbo: A complete rewrite of SQLite in Rust

#168

Post by galangalalgol »

vitiral wrote: post #120

> SQLite’s test suite is proprietary This is literally the first time I've ever heard of this, for any project anywhere. I suppose Android is built a bit in this way, but that's a whole other can of worms.

It could be simply to prevent forks, but if it really is 100% branch coverage, why do they still have memory safety related CVE coming out? With asan turned on, and full static analysis, that should make such errors exceedingly rare. Part of the benefit of rust is that it makes coverage both easier to get due to its type system, and less necessary because of the guarantees it makes. But if they really went all the way to 100% branch coverage that should be almost as good if all the samitizers are running.

Re: Limbo: A complete rewrite of SQLite in Rust

#169

Post by znpy »

jasode wrote: post #111
bruce511 wrote: post #59

Earlier quoted context omitted.

>> The SQLite3 business model is that SQLite3 is open source This is going to sound pedantic, but SQLite is not Open Source. It's Public Domain. The distinction is subtle, but it is important.

>This is going to sound pedantic, but SQLite is not Open Source. It's Public Domain. Well, there are 2 different modes of communication: (1) official language-lawyer pedantic communication: "open source" != "public domain" (2) conversational casual chitchat : "open source" includes "public domain" Yes, the SQLite home page does say "public domain" . However, when people interview SQLite create, Richard Hipp, he himse…

> (2) conversational casual chitchat : "open source" includes "public domain"

it's wrong though. like, can't be more wrong than that. you can't do whatever you want with open source software, the license tells what you can and cannot do.

with public domain software you can do most things.

Re: Limbo: A complete rewrite of SQLite in Rust

#170

Post by ale42 »

froh wrote: post #163
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…

> The SQLite3 business model is that SQLite3 is open source but the best test suite for it is proprietary no. the business model is services, and a red phone to companies who use sqlite in production. like nokia back in the days when we had these little flip phones, or desk phones had a "rolodesk" built in, or many other embedded uses of a little lovely dependable data store. the services include porting to and "cert…

> companies who use sqlite in production

It's not just old Nokias or desktop phones, nor just embedded sytsems. sqlite is almost everywhere. Adobe, Apple, Microsoft, Google, Mozilla and many other companies use it in very widely deployed software.

Post reply on HN