Live data from Hacker News

The End of the Redis Adventure

antirez.com

281–290 of 308 posts

Re: The End of the Redis Adventure

#281

Earlier quoted context omitted.

Instead of a single BDFL, you could also have a board of e.g. 3 BDFLs. Those 3 people would have the final word, but they rank equal, and have to come to a common conclusion, e.g. by discussing internally. That only works if the board is not too big, and the people are somewhat compatible to each other. But in that case, I think it works much better, because there is less pressure on a single person, also less work (…

I think the mixed historical record of consul republics might be relevant to why a single leader is often a better idea than 2-3.

I'm thinking that a project that starts out with 3 BDFLs (like yours, @albertzeyer) and works fine & builds sth people "love" — it'll continue working fine with those 3 BDFLs.

And a project that starts with just 1 BDFL, and works fine & builds sth people "love", it'll continue working fine with that 1 BDFL.

If, however, replacing one of those 3, or adding another BDLF to a one person project — I'd think that by default, that won't work.

... Unless the new person has worked next to the earlier BDFLs for years, so the previous BDFLs can be ok certain s/he is "the right one"?

Whatever works fine, works fine — the risky thing, is introducing a change (a new person)?

Re: The End of the Redis Adventure

#282
post #152

It's long past due that we should move to software which isn't maintained - because there's nothing to do. Adding features could be done either by writing a new one - because the requests don't really fit the meaning of old one, the creators saw that and rejected; fixing bugs - yes, fixing bugs may remain, but are there many bugs in, say, TEX code? We don't yet know how to write a completed software well - the one wh…

I think video games fit in the area of 'completed software'. Most video games today rarely see updates a few years after they're released. And older video games were on read only mediums, so you would hope whatever you release is very stable and feature complete.

Re: The End of the Redis Adventure

#283
post #259
post #59

Earlier quoted context omitted.

This. The underground in underground programming refers to maintaining low visibility, as to present low target silhouette. Additional benefit is not attracting too many participants that are in it for the clout, rather than for solving problems & good engineering. Open Source is no longer sufficient for software freedom; the current 'battlefield' is maintaining security from activist pressure or gradual take-over.

I created the Occupy Wall Street website nine years ago. Believe me when I say the lengths people will go, to try and control community projects, is downright traumatizing. I never could have imagined that same kind of nastiness would impact open source. If you don't feel comfortable engaging with the new toxic culture, you can use my underground liferaft. My liferaft isn't an operating system, but rather an attempt…

Thank you for the interesting angle.

>the lengths people will go, to try and control community projects

I've heard that echoed a couple times in Tim Pool's discussions of the (american) OWS. Scary stuff indeed.

Re: The End of the Redis Adventure

#284
post #276
post #186

Earlier quoted context omitted.

Did FreeBSD not have the discussion about this years ago? Though they did not have a single person, but a 20 person core team, which were cut down to a 9 person core team that is voted for every 2 years. http://freebsd.dk/sagas/freebsd/#id1

The core team doesn’t really make technical decisions. It’s more for administrative/social/governance type stuff.

Who would then make the technical decisions? The owners of the different sub systems?

Re: The End of the Redis Adventure

#285

Earlier quoted context omitted.

Redis is extremely simple to scale. Treat each instance in a cluster as wholly independent from other instances, and build a thin layer on top to implement whatever sharding and availability requirements your use case requires. I've done it many times and it's always been simple and worked brilliantly. Redis's predictability makes it a joy to operate.

We've done just that. Some folks at work wanted sentinel in front as a cluster management layer, but our particular use case did not work well there. Instead, we have some "logical clusters" of 3 nodes that we replicate reads and writes to, sharded to (currently) six clusters. Some logic around quorum for ensuring writes make it to at least 2/3 nodes in a given cluster, with some optimizations for reads sometimes onl…

@sagichmal "... scale ... implement ... sharding ..."

@sethammons "... sharded to (currently) six clusters ..."

I wonder, when did you start sharding? How many GB memory did your previously single-machine-Redis-instance use, before it was time to shard? How much memory does each "sharded node" have?

(It wasn't the CPU (Redis single threaded) that forced you to shard? But because you needed more memory? (Or sth else?))

> "nearly 200 redis nodes"

How much memory in each node, if I may ask?

Re: The End of the Redis Adventure

#287
post #284
post #276

Earlier quoted context omitted.

The core team doesn’t really make technical decisions. It’s more for administrative/social/governance type stuff.

Who would then make the technical decisions? The owners of the different sub systems?

There's no hard rule. The committers are expected to behave like a civilised human beings, ie talk to each other to reach consensus.

Let's say you have a fix for some driver used on ARM. You'll submit it via Phabricator to get ARM maintainers to review it. If they don't, because eg they don't have time, then you'll probably commit it anyway, but if someone points out you did something wrong, you'll be expected to fix it.

Re: The End of the Redis Adventure

#288
post #78

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.

I really enjoyed your Youtube "Writing System Software" episodes. Would be awesome to see some more of that in the future too ... !

Re: The End of the Redis Adventure

#289
post #100

Earlier quoted context omitted.

> 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…

Memcache is what saying no to changing the use-case looks like. Redis is what saying no to changing the architecture in order to implement features looks like. 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. An…

[deleted]

Re: The End of the Redis Adventure

#290
post #100

Earlier quoted context omitted.

> 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…

Memcache is what saying no to changing the use-case looks like. Redis is what saying no to changing the architecture in order to implement features looks like. 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. An…

Wow you totally got it. This is exactly the idea I was using, I even saw an opportunity when the Redis model was potentially able to solve a new use case.
Post reply on HN