Why I can't have conversations using Twitter

Long ago I learned that if you want to have "viral" success, even on a more informed site like HN, avoid making more than one statement or claim in a piece.

"Modern Java application servers offer surprisingly high performance" (followed by details of performance improvements, etc), for instance, is okay: everyone who agrees will forward and agree and post, while those who might not agree or care will remain ambivalent and disengaged.

Change that up slightly, though, and conversationally add "...which might allow you to deploy on fewer servers than a similar solution built in Ruby" and you'll instantly gain armies of very motivated detractors who will go forth to denounce everything you've ever said, declare everything you've written stupid and misinformed, etc. Not based on objective disagreements, but based on a knee-jerk opposition that, much as with politics, can't be on a point or issue (e.g. "agree to disagree"), but has to encompass everything.

People who might agree or yield value skip the piece after seeing endless criticisms and complaints.

The crux being that it's very hard to gain agreement, easy to gain enemies. If you state ten things, people who disagree with but one of them will often fall in the latter camp.

Not that this changes how I personally write -- where I'll load pieces with things that people can disagree with -- but I see it constantly as stories tread the bottom of the front page, the detractors who find that one tiny thing they disagree with and blow it up to be all-encompassing, and it gets flagged to oblivion.

Well, for a lot more than Redis.

About pointing to relevant papers: things like pointing to timestamped replication paper, which is a CP system for replicated state machines, in response to the fact that Redis does not support slaves when the master disk persistence is turned off, is actually just another instance of why it is not possible to have decent tech conversations on Twitter.

The problem experienced at Stripe is a result of Redis replication documented behavior, regardless of using Sentinel or not. Redis replication is a very simple system where replicas will try to exactly mimic the master, and if the link breaks, will try to connect with it again and again forever. There is no builtin HA, nor failover or alike.

So before considering failover (and yet IMHO pointing to timestamped replication is not very informative even in this context, since in distributed systems the details matter, and you can't just give a random reference to a completely different system which happens to have just superficially similar issues to fix), there were different useful observations to do.

Like: Hey @antirez, what about supporting master-slaves setups where the master can be configured without persistence at all, and yet when it reboots, it will not be considered viable for reconnections? Which is the fundamental problem: stopping the basic Redis replication behavior from working as it works, with slaves that always want to replicate the current master, which is not ok if we want a system supporing the master restarted without persistence (which wipes the dataset on restart).

However the whole problem with that is that there are a lot of people like you that will regard linking to a paper as a great way to help, and as a very smart thing, while there are other that are instead trying to work to really make stuff better. Before commenting you should make the effort to understand exactly the problem domain and its subtleness: exact details or what you say is not relevant in a discussion which is all about details.