This comment made me think Dragonfly is a much better choice:
"We use keydb at work, and I absolutely do NOT recommend it due to its extreme instability, in fact we're currently in the process of switching to dragonfly precisely due to keydb's instability."
We evaluated DragonflyDB for Memcache. It was repeatably orders of magnitude slower under default configurations than original Memcache, using their own benchmark setup.
Either they didn't even test their own product, lied entirely about the performance, or got the marketing department to write the copy without any input from the development department.
I assume you are the lead developer or someone in an exeuctive position associated with Dragonfly. Your defensive, holier-than-thou attitude and tone here and elsewhere is another reason we decided not to adopt Dragonfly internally.
Yes, your results are either inaccurate or deceptive at best. I challenge you run to memcached, under all default settings, and Dragonfly, under all default settings, and memtier_benchmark, under all default settings. Performance is reproducibly orders of magnitude slower, and Dragonfly is also much less efficient--consuming more than double the CPU usage for the same workload.
We also created a test Dragonfly cluster mirroring a small percentage of production traffic in order to do a side-by-side comparison with Memcache. Dragonfly consumed 47% higher CPU usage and regressed P99 latency by 22%. Perhaps our workload is unique, but claiming Dragonfly outperforms Memcache the way you do in your marketing material is an outright lie.
I apologize. I must say that my tone, as you rightly wrote, was inappropriate.
Indeed, I am the lead developer for Dragonfly. As such, I am deeply concerned with the performance aspects of our product. Dragonfly claims to be a drop-in, better performant replacement for Redis and Memcached. Every test & benchmark we've run on multiple cpus reinforced that. I've never faked or tweaked any of these benchmarks. That is, of course, not an excuse, and is why I opened by apologizing. I'd like to take this opportunity, if I can kindly ask so, to learn what made your results differ so much from ours. I'll personally try to reproduce what you described. If you could also reach out to me, I'd be happy to learn more about the environments in which you've conducted the aforementioned tests.
I've never seen this license. It looks like it will be open source under the Apache license after 5 years though. That is, I can save the code now, and in 5 years I can do whatever I want with it (under the Apache license terms). When open-source isn't an option, then this is the next best thing.
Huh, interesting concept. It's definitely a big step above "source available". It even kind of allows maintaining a community version with outside patches, albeit slowly.
It kind of rivals the KDE/Qt deal of "freely licensed when the company goes under" in its effects of the code eventually being community-maintainable once the company doesn't care for it anymore.
Well "source available" would probably be better. It is not open source by the definitions most follow in this case the OSI definition. Eg it goes against §6 of their definition. https://opensource.org/osd/
Please don't try to delude people by changing the definition of open source. While sadly Open Source Initiative were not able to get the trademark for open source, the de-facto definition of open source is practically the same as free software.
Dragonfly is source available which is a completely different thing.
> Please don't try to delude people by changing the definition of open source.
Don't blame it on me, that ship has sailed over two decades ago. That's why RMS didn't like the term in the first place. Even if I disagree with RMS on most things, I have to admit I'm 100% with him on this one. It's almost as if the term was coined to create this kind of confusion.
In my opinion, the mental gymnastics around the definition of "open source" led to abominations like CDDL, which was carefully and explicitly designed to make it impossible/impractical/illegal to properly integrate ZFS or DTrace with Linux. CDDL is perfectly "open source" by definition, but its primary purpose was to lock people out of actually using software licensed under it, unless they happen to be running Solaris.
In all this mess, I actually think BSL is cool. It's a legally binding vow to actually make a particular release free (as in freedom) down the line. They could have kept it proprietary (which I think is totally fair), or made vague promises instead.
> but its primary purpose was to lock people out of actually using software licensed under it, unless they happen to be running Solaris.
And yet here we are, with DTrace (CDDL) shipping in macOS, ZFS having shipped in OS X for several releases, and FreeBSD shipping both. Even Windows (on the "insider" builds) has DTrace [1] _shipped by Microsoft_.
That makes any argument that you can't use any of this stuff unless using Solaris looking rather... wrong - and the idea that Sun lawyers would have overlooked FreeBSD, macOS or Windows if the goal were to restrict the software to be used in Solaris is laughable.
In the case of CDDL specifically, even RMS [2] refers to it as a "free software license", though not one which is GPL-compatible.
> And yet here we are, with DTrace (CDDL) shipping in macOS, ZFS having shipped in OS X for several releases, and FreeBSD shipping both. Even Windows (on the "insider" builds) has DTrace [1] _shipped by Microsoft_.
That's why I personally strongly prefer BSD systems (OpenBSD in particular) and permissively-licensed software.
> That makes any argument that you can't use any of this stuff unless using Solaris looking rather... wrong
The intent was to lock out Linux specifically, otherwise they would've used a more restrictive license.
> [...] and the idea that Sun lawyers would have overlooked [...]
You're not violating the CDDL by linking it with GPL-licensed software, you're violating the GPL. Which goes to show just how devious that move was: even if Sun went belly up with no lawyers left to lift a finger, relicensing Linux with a CDDL linking exception would still be a massive clusterfuck. So Ubuntu & whoever else is shipping zfs.ko is risking getting sued by any of the half a million people who have their code in the kernel.
> In the case of CDDL specifically, even RMS [2] refers to it as a "free software license", though not one which is GPL-compatible.
You can also license your software even more permissively, but hold a patent on it, and not grant a patent license to your users. It would technically be free, but still released with an intent of restricting the freedom of certain users.
As has been discussed many times on HN before[0], your read of history here is just wrong: we at Sun certainly did not think that Linux would let their own read of the GPL prevent them from integrating DTrace. More generally, other faults aside, Sun was emphatically not "devious"; as I have quipped in the past, one of Sun's greatest strengths was that it was insufficiently organized to be evil.
I think the parallels to free software are markedly correct. They're just words after all. It will forever be used in ways incompatible with the OSI definition, showing up after every misuse to correct folks isn't helpful.
https://www.dragonflydb.io/