91–100 of 308 posts
Ok, so many thank you here, thanks! It's very nice to read the comments here. But I hope to interact more on HN, since basically the idea is to write more blog posts, write more OSS software too. Just totally random :D I'll just do whatever every morning I want to do for a long time. Then maybe I'll find a new long term interest.
So they're moving to a new "community based", "light governance" model. [1] There are plenty of problems with BDFL-style projects, but I think there are a lot of advantages too. Redis is unique in my experience in that it works the way you'd expect - it doesn't cause outages, it is fast, and it has a vanishingly small number of gotchas. The feature set is well curated and for the most part fits together cohesively. T…
In essence, Antirez has protected the core of Redis from needing to bloat, by making it possible for anyone who wants to build on top of Redis to literally do so—build on top, rather than inside. As such, I expect future PRs to Redis Core to look much like current PRs to Redis Core: just fixing bugs, adding stability, and resolving infrastructure-level interoperability concerns.
So they're moving to a new "community based", "light governance" model. [1] There are plenty of problems with BDFL-style projects, but I think there are a lot of advantages too. Redis is unique in my experience in that it works the way you'd expect - it doesn't cause outages, it is fast, and it has a vanishingly small number of gotchas. The feature set is well curated and for the most part fits together cohesively. T…
> There are plenty of problems with BDFL-style projects, but I think there are a lot of advantages too. BDFL governance is extremely underrated in the opensource world. People attribute the success of the Linux kernel to its open contribution style, but I will argue that Linux is successful because there's a dictator at the top that enforces a direction, a long term goal, and most importantly, says NO. Community base…
We don't have enough data points to determine if what you are saying is correct. I have also seen lots of BDFL projects smoke out.
Is the lesson that actual dictatorships only survive long term if 1) the dictator is a nice person and 2) they eventually get managed by an open democratic process?
I think you are actually describing the two clocks problem. Lots of BDFL projects have their own Cascade of Attention-Deficit issues, the project only goes in the direction the BDFL actually cares about.
Earlier quoted context omitted.
I think its website need a fast cache.
Actually the web site uses Redis as the only store. And Redis is using 0.1% of CPU. The problem is that Ruby sucks at doing anything scalable. It's just a Ruby/Sinatra app. If you do that in PHP, it will work out of the box with many concurrent accesses. With Ruby not the case. There are ways to deploy it better, but it should be fast as default, which is not the case.
What does it mean that Yossi and Oran are taking over as maintainers - are they doing so in their personal capacity or as employees of Redis Labs ?
How are potential conflicts between the business interests of Redis Labs and the interests of the community to be identified and resolved ?
Who will own the copyright over the newly submitted code and are there any safeguards against future versions of Redis being released under licenses more restrictive than the current one ?
Earlier quoted context omitted.
I think its website need a fast cache.
Actually the web site uses Redis as the only store. And Redis is using 0.1% of CPU. The problem is that Ruby sucks at doing anything scalable. It's just a Ruby/Sinatra app. If you do that in PHP, it will work out of the box with many concurrent accesses. With Ruby not the case. There are ways to deploy it better, but it should be fast as default, which is not the case.
So they're moving to a new "community based", "light governance" model. [1] There are plenty of problems with BDFL-style projects, but I think there are a lot of advantages too. Redis is unique in my experience in that it works the way you'd expect - it doesn't cause outages, it is fast, and it has a vanishingly small number of gotchas. The feature set is well curated and for the most part fits together cohesively. T…
> The most important thing Antirez did, in my opinion, was to say "No" to things. No to new features that didn't make sense. Redis has had tremendous mission creep over the years. It started of course mostly as a volatile cache but I've now seen it also used as a message bus (in three different ways: BLPOP, PUB/SUB and Streams), for service discovery and as a general purpose database - something that Redis Labs (in m…
But... things that are also just useful often and for what you'd need to spin off a separate service for, or make suboptimally in whatever (No)SQL you use to store your data.
So it is perfect if you just want to prototype whether given approach is viable, and "good enough" for many apps.
Ok, so many thank you here, thanks! It's very nice to read the comments here. But I hope to interact more on HN, since basically the idea is to write more blog posts, write more OSS software too. Just totally random :D I'll just do whatever every morning I want to do for a long time. Then maybe I'll find a new long term interest.
Wishing you the best in whatever you do next.
not that i don't like it but antirez has been hesitated about adding those before.
So they're moving to a new "community based", "light governance" model. [1] There are plenty of problems with BDFL-style projects, but I think there are a lot of advantages too. Redis is unique in my experience in that it works the way you'd expect - it doesn't cause outages, it is fast, and it has a vanishingly small number of gotchas. The feature set is well curated and for the most part fits together cohesively. T…
> The most important thing Antirez did, in my opinion, was to say "No" to things. No to new features that didn't make sense. Redis has had tremendous mission creep over the years. It started of course mostly as a volatile cache but I've now seen it also used as a message bus (in three different ways: BLPOP, PUB/SUB and Streams), for service discovery and as a general purpose database - something that Redis Labs (in m…
Redis has stayed the same, architecturally, from the beginning: it’s a keyspace where the values are arbitrary in-memory objects owned by their keys, and where commands resolve to synchronous function-calls against the objects (or ref-cells) at those keys.
Anything that can be done without changing that architecture, is in-scope for Redis. (Though if a data structure doesn’t have wide use outside of a domain, it’s best left to a module.) Anything that cannot be done without changing the architecture, won’t be done.
Much of the “fun” I’ve personally had in watching Redis evolve, has been seeing how Antirez has managed to solve the puzzles of getting features that intuitively wouldn’t be a good fit for this architecture, to fit into it anyway: changing technologies that are implemented one way everywhere else, into something else for Redis, that still work, are still performant, and still solve isomorphic use-cases—if not with the same steps you’d use to solve them in other systems. (E.g. using Streams vs. using a regular MQ; using Redis Cluster vs. using regular RDBMS replication; etc.)