Live data from Hacker News

Show HN: Cachegrand – a fast OSS Key-Value store built for modern hardware

github.com

51–59 of 59 posts

Re: Show HN: Cachegrand – a fast OSS Key-Value store built for modern hardware

#51

The redis compatibility layer seems to be very early stage, see https://github.com/danielealbano/cachegrand/blob/main/docs/a... Compare with e.g. dragonflydb: https://github.com/dragonflydb/dragonfly/blob/main/docs/api_... Interesting to see how this will develop over time.

DragonflyDB is not open source, unfortunately.

It will be in 2027 and, unless you plan to run a SaaS that sells Dragonfly (like AWS), then it's Open Source for you today. (The license is Business Source License[0])

0: https://github.com/dragonflydb/dragonfly/blob/main/LICENSE.m...

Re: Show HN: Cachegrand – a fast OSS Key-Value store built for modern hardware

#52
post #51

Earlier quoted context omitted.

DragonflyDB is not open source, unfortunately.

It will be in 2027 and, unless you plan to run a SaaS that sells Dragonfly (like AWS), then it's Open Source for you today. (The license is Business Source License[0]) 0: https://github.com/dragonflydb/dragonfly/blob/main/LICENSE.m...

Please don't confuse free source with open source, there is quite a massive difference.

There is a reason for which the BSL is not a recognized open source license.

Re: Show HN: Cachegrand – a fast OSS Key-Value store built for modern hardware

#53
post #49

Is there a document on how cachegrand achieves this speed over redis?

I replied in a few posts in the thread with some details, if you want more there is also this presentation I did at the London performance summit https://www.youtube.com/watch?v=ZSpxuWQK7sM

Most of the performance exploits for the hashtable (which is the driving engine here) are explained after minute 8.30 (although I would suggest you to watch the entire presentstion).

I will present my work at the p99conf as well.

Re: Show HN: Cachegrand – a fast OSS Key-Value store built for modern hardware

#54
Awesome stuff, Daniele!

For folks wanting to learn more, we'll have Daniele's session for cachegrand at P99 CONF next month (free, virtual event): https://www.p99conf.io/

[edit: just realized we'll also have Roman Gershman of DragonflyDB. So you can hear two different ways to tackle the issue.]

Re: Show HN: Cachegrand – a fast OSS Key-Value store built for modern hardware

#55

Awesome stuff, Daniele! For folks wanting to learn more, we'll have Daniele's session for cachegrand at P99 CONF next month (free, virtual event): https://www.p99conf.io/ [edit: just realized we'll also have Roman Gershman of DragonflyDB. So you can hear two different ways to tackle the issue.]

Thanks!

I also promise to document more the actual inner workings of the various components, I have some scattered documentation here and there which will help me in the task!

Re: Show HN: Cachegrand – a fast OSS Key-Value store built for modern hardware

#56
post #51

Earlier quoted context omitted.

It will be in 2027 and, unless you plan to run a SaaS that sells Dragonfly (like AWS), then it's Open Source for you today. (The license is Business Source License[0]) 0: https://github.com/dragonflydb/dragonfly/blob/main/LICENSE.m...

Please don't confuse free source with open source, there is quite a massive difference. There is a reason for which the BSL is not a recognized open source license.

It'll still become Open Source in 2027 under a GPL compatible license. That at least ensures that it won't ever die unlike most "source available" code out there.

Re: Show HN: Cachegrand – a fast OSS Key-Value store built for modern hardware

#57
post #56

Earlier quoted context omitted.

Please don't confuse free source with open source, there is quite a massive difference. There is a reason for which the BSL is not a recognized open source license.

It'll still become Open Source in 2027 under a GPL compatible license. That at least ensures that it won't ever die unlike most "source available" code out there.

It's definitely not entirely true, the license grants that "the current version" under "the current license" will be under the Apache license in 5 years that translates to in 5 years dragonflydb 0.6.0 / 0.7.0 will be under the apache license. That's the only guarantee.

The change date can be changed at any time, the license allows it, almost all the projects I saw using the BSL actually use a sentence like "X years from the release", on top of this it can be even removed and if that would be the case than the paragraph below would apply, which clearly refers to 5 years from the released versions.

> Effective on the Change Date, or the fifth anniversary of the first publicly available distribution of a specific version of the Licensed Work under this License, whichever comes first, the Licensor hereby grants you rights under the terms of the Change License, and the rights granted in the paragraph above terminate.

5 years old software is a dead software :)

The only reason for adopting the BSL is to prevent companies like Amazon to take ownership and don't give back to the project (e.g. elastic), which is totally understandable.

Do you think that future releases, much more feature-complete and flexible, will be given under the apache license as they are meanwhile less feature complete versions aren't? Looking at the facts, I would say the answer is very likely no.

Would you build something in 5 years based on dragonflydb 0.7.0 when most likely there will be a v2.0 or even a v3.0 out there?

When it comes to non open source licenses and companies it should be clear that the companies want (and need) to take care of their own interests: the BSL "change date" is a way to be able to say "yes but it will become OSS" so you can keep using and contributing, like the sop you give to a kid to stop him from crying.

Re: Show HN: Cachegrand – a fast OSS Key-Value store built for modern hardware

#58
post #56

Earlier quoted context omitted.

It'll still become Open Source in 2027 under a GPL compatible license. That at least ensures that it won't ever die unlike most "source available" code out there.

It's definitely not entirely true, the license grants that "the current version" under "the current license" will be under the Apache license in 5 years that translates to in 5 years dragonflydb 0.6.0 / 0.7.0 will be under the apache license. That's the only guarantee. The change date can be changed at any time, the license allows it, almost all the projects I saw using the BSL actually use a sentence like "X years f…

Thank you for taking the time to respond in depth!

I do agree that 5 year old software is dead software, which is a pretty aggressive number for Dragonfly to take here, but at least it's not 10+ years.

> The only reason for adopting the BSL is to prevent companies like Amazon to take ownership and don't give back to the project (e.g. elastic), which is totally understandable.

I also agree with this. It's a dog-eats-dog-world and businesses have to figure out how to compete.

> The change date can be changed at any time, the license allows it, almost all the projects I saw using the BSL actually use a sentence like "X years from the release", on top of this it can be even removed and if that would be the case than the paragraph below would apply, which clearly refers to 5 years from the released versions.

There is still Git involved here. The authors can't re-write history. A commit from today will convert at the same date regardless of future commits, even if the BSL clause is updated in future commits. Dragonfly pushing a commit publicly seems like it should constitute a "release date" to me!

> When it comes to non open source licenses and companies it should be clear that the companies want (and need) to take care of their own interests: the BSL "change date" is a way to be able to say "yes but it will become OSS" so you can keep using and contributing, like the sop you give to a kid to stop him from crying.

That's the glass-half-empty perspective of this. The glass-half-full perspective is: At least it is going to be _eventually_ Open Source! (which is better than yet-another-proprietary-vendor popping up.)

> Would you build something in 5 years based on dragonflydb 0.7.0 when most likely there will be a v2.0 or even a v3.0 out there?

Almost certainly not. I would be worried about the security vulnerabilities and not having patches to fix them.

But, given that their BSL clause does allow commercial use for a private company or an Open Source project, I would think about if using the latest version was the right tool for the job. I just won't expect to go to AWS and get a managed version of the service -- I'd have to go to Dragonfly (which is their goal).

I am empathetic to both sides of this and I'm happy to see licenses like BSL becoming a thing because I think it will continue to accelerate the rate of innovation. (I've had to debug too many vendor binaries in my life. Even just "source available" is valuable when you have production infrastructure heavily reliant on a piece of software because you can still debug it + fix it without requiring the vendor!)

Re: Show HN: Cachegrand – a fast OSS Key-Value store built for modern hardware

#59
post #58

Earlier quoted context omitted.

It's definitely not entirely true, the license grants that "the current version" under "the current license" will be under the Apache license in 5 years that translates to in 5 years dragonflydb 0.6.0 / 0.7.0 will be under the apache license. That's the only guarantee. The change date can be changed at any time, the license allows it, almost all the projects I saw using the BSL actually use a sentence like "X years f…

Thank you for taking the time to respond in depth! I do agree that 5 year old software is dead software, which is a pretty aggressive number for Dragonfly to take here, but at least it's not 10+ years. > The only reason for adopting the BSL is to prevent companies like Amazon to take ownership and don't give back to the project (e.g. elastic), which is totally understandable. I also agree with this. It's a dog-eats-d…

I am empathetic as well but...

Let me start saying that no one prevents a company from selling the software with licenses allowing to access the source code, companies even provide the code under the GPL because the BSD or the GPL nowhere state that the code has to be provided for free, big companies have provided the code under open source licenses behind fees for quite a while so far (redhat is one of the examples).

The BSL certainly allows you to access the code without having a license but I would dare to say that most of the companies out there, especially for critical components like this, prefer managed and supported solutions, for which rights to access the source code can be granted.

But in general it's absolutely true that it allows accessing the source code without having to buy the license and this is certainly a plus for the final user.

But that's it :)

I will not say that I know the legal language but I will say that the legal language really differs form what we perceive and a judge or a court perceive and the interpretation is dictated by the national law.

The sentence

> Effective on the Change Date, or the fifth anniversary of the first publicly available distribution of a specific version of the Licensed Work under this License, whichever comes first, the Licensor hereby grants you rights under the terms of the Change License, and the rights granted in the paragraph above terminate.

Use the word "version" which is broad and generic, can be read as "the commit makes a new version" or "the intent for the developer to release a new version".

Do, again, no certainty really ok the long term.

Going open source require sacrifices, I have given for free more than 1 year of research and development I did to build the technology behind the hashtable implemented in cachegrand and I did because I believe that true technological advancement should be available to anyone and meanwhile my work is not a game changer it my small bit to try to help.

That's why when I see a license like BSL pointed out as open source or "quasi" open source I do feel the need to give some context.

Try to imagine if Linus at the time would have decided to give Linux under BSL... Nowadays would be very different!

Post reply on HN