It compares a process with a listening port with another process with a listening port. To give another example - nobody compares minio with bunch of disks to which you can write separately, and probably more efficiently.
I made an honest mistake. While I saw DragonflyBSD, I didn't realize its prominence within the BSD community. I assumed that since our project only focuses on Linux, having a similar name in a different "namespace" wasn't a significant issue.
DragonflyDB cofounder here. I am not shy about our choice of license.
Like with software design, everything is about trade-offs. Folks here voiced reasons why we chose BSL. I am sure you perfectly aware about all this.
I do not know personally you but I noticed that you posted the link to the announcement. I am guessing you are passionate about the technology and innovation. Dragonfly is much more than the licensing choice we made. I wish HN discussions here were about how fibers work in Dragonfly and how SSD tiering is gonna be implemented and how we provide atomicity for lua scripts while running many of them in parallel etc.
Btw, Dragonfly relies on an io-engine called helio (roughly equivalent to tokio) that has been developed by me and open sourced under Apache 2.0.
While technical discussion about those details would be interesting, HN is also a strong entrepreneurial community and your license choice has a big impact on whether or not a business would choose to depend on your product. I would not choose to build on a BSL licensed foundation for my product because of real business concerns with vendor lock-in. I would also not choose to contribute to a BSL licensed code base because the CLA means I am not free to use the code base on equal grounds with other contributors (DragonflyDB Ltd in this case).
Because of these two things, I didn't spend a lot of time looking into the technical details and therefore can't really say much on them. By all means it sounds like a very interesting piece of technology- but the license makes it useless to me.
Please do not express your opinion as the opinion of the majority. Instead of discussing license choices, create your project and open source it as you like. Do not tell others how to build their business, especially on HN.
I never expressed my opinion as that of the majority. I expressed my opinion as my opinion, and I can express whatever opinion I want to and discuss whatever I want to on Hacker News, so long as as Y Combinator (Who owns Hacker News) is okay with it.
Are you a representative of Y Contaminator/Hacker News? If you are, I will be glad to comply with your request.
The reply wasn't directed at DragonFly, but simply an answer to parent. I think you got a lot of sticks on HN. [1] In case you are wondering, I am much closer to Laymen in my definition of Open Source so I am actually extremely supportive of BSL. A perfect balance of Business Needs and Open Source. But HN has gotten a lot more ideological than it used to be. So please keep up the good work.
[1] Part of the reason why I submitted Dragonfly, interesting technology should get more coverage on HN, and not be ignored simply because of some over zealotry ideological reason.
Dragonfly is better with
1. Memory utilization (read the announcement, they mention it)
2. Deployment/orchestration - your initial threshold that forces you to scale horizontally just went up by order of magnitude. In fact for many use-cases you will never need to go horizontally with Dragonfly.
3. Dragonfly also provides a better experience when working with the system. Just a week ago one of the community contributors submitted a PR that introduces automatic recognition of the hot keys: https://github.com/dragonflydb/dragonfly/pull/951 (this feature is not ready for production use yet but we will get there).
It also has a built-in open-metrics support, built in cpu-profiler support, fully asynchronous I/O that allows answering INFO commands even under load etc.
I agree. This is why DashCache is designed to be very efficient in terms of CPU and memory, while providing very strong adaptive capabilities for mixed workloads.
If think the most important part in this design is the realization that we do not need a global order in order to choose an entry to evict: other heuristics like LRU, LFU, frecency - they strive to provide a single number, a metric. Obviously this metric lies because a single number can not represent well both qualities like frequency and recency. DashCache, on the other hand, does not try to do it at all. Instead, it implicitly defines a partial order between entries in the same bucket or segment....
> the most important part in this design is the realization that we do not need a global order in order to choose an entry to evict
This is a key insight many people miss. The optimal eviction is not computable, so any reasonable approximation will likely have a similar outcome. Given this, it makes sense to pick an approximation that facilitates other objectives, like computational performance.
