Here's a couple of other differences that might be worth reflecting on:
1. What support Eich provided for proposed law vs actions he's likely to support as CEO -- in other words, what you can actually tell about Eich by the fact that he provided financial support for the law, and what you might know about him by considering a larger totality of his actions.
If you want a parallel, consider what Janis Ian has said about Orson Scott Card:
2. Now vs then. In 2008, the then president of the united states supported prop 8. The current president of the US was on record as not sure about it (and against gay marriage). If we're talking about the height of the profile of a position -- and you seem to be in making a distinction between an employee and CEO -- then I'd say leadership of Mozilla is pretty pale by comparison.
3. While Mozilla is arguably a "values" organization (presumably an important distinction), it's working in a sphere that's pretty orthogonal from identity-minority rights. If you'd argue that doesn't matter, I suppose that's one approach, but if so, I presume that you'd also decide that GLAAD should also be generally boycotted because of their 2011 support of the T-Mobile/AT&T merger and opposition to Net Neutrality principles.
I think we do not share the same opinion about the significance of those differences. But that is ok. I promise not to boycott your company because you have a different belief than me.
Googled "Neal Stephenson README" expecting a thriller involving a government agency plot to inject malicious code into a open-source crypto-library, and the final commmit to the github project made by a hacker found murdered in front of the computer in his basement.
Wow, you're absolutely correct. I read REAMDE about 2 months ago so the plot is still pretty fresh in my mind. It's a great, so consider this a recommendation.
More likely like a modern William Gibson plot. Mystery and modern technology in the same place. Objects that do not want to be tracked. Definitively Gibson style.
No, you misunderstand. Stephenson actually had a hijacked 747 in one of his books shadowing another to avoid radar detection in the same way as described by this article.
The story also had the jet ‘disappear’ on the boundary between ATC zones. This was actually the first thing that came to my mind when I heard the first reports about MH370.
sync.Once() instead of init(). Having the Do closed to where the channels being used makes sure we do not run into deadlock. It's a nice pattern for lazy initializing of channels and goroutine too.
For example idiomatic Java was a clusterfuck for nearly a decade, with all the EJB's and FactorySingletonProxies and XML everywhere. It would be better for Java programmers to ignore the idiomatic BS prevalent in the community, and just use the language in a saner way.
Idiomatic is often just another name for "how lots of people prefer to do it" or "cargo cult".
Agreed. In particular, I found the "reference value" approach that Go uses for time parsing incredibly quirky, but ultimately intuitive and unambiguous.
It seems that antirez believes he's allowing Redis to approach AP and/or CP semantics by providing primitives that users can compose in ad-hoc ways according to their requirements.
Unfortunately, that's not a valid methodology to achieve availability or (especially) consistency.
In Redis Cluster there is nothing you can do to tune availability or consistency. The only thing you can tune is write "safety" using WAIT, but actually most users should never use it since the system is mostly designed to be low-latency.
Redis Cluster is not AP nor CP. It resembles more AP since it has no strong consistency, however it is not able to reach "A" of AP that is very strict. Like AP systems have some form of consistency, but not "C" of CAP. Redis does this for "A" as well, it has some form of availability, but not as strict as "A" of CAP.
Why this? You'll notice that there are not AP database systems with the powerful commands of Redis, and that there are not CP systems with the latency of Redis. So it is a very opinionated trade off to get both sacrificing other stuff (especially "A").
If it's not AP or CP, then what is the value? Cassandra is eventually consistent. Consistency is pretty important. It seems like Redis Cluster doesn't have consistency, nor availability, nor partition tolerance. Maybe I misunderstand it though.
> Cassandra is eventually consistent. Consistency is pretty important.
Your above statement unfortunately has no match in distributed systems theory or practice. Basically eventually consistent means that the system is not consistent from the point of view of CAP, so it does not feature strong consistency.
As an alternative eventual consistency means: our contract with the user is, that, at least, when there are no partitions, the system will no show split-brain conditions, so a given information will converge to a given value for all the nodes.
This alone is a contract with the user, but does not tell a lot, it just tells you:
1) No strong consistency, sorry.
2) No split-brain conditions when the partitions heal.
So "It features eventual consistency, consistency is important" statement, I'm afraid, means that you don't have the tradeoffs about distributed systems clear.
Now, if EC alone does not mean a lot, how to classify an EC system? It depends on the exact implementation of what happens when there is a partition, and what happens when the partition heals.
There are EC systems that are configured by default to accept writes in the minority side (even in partitions when there is a single DB node if we want to honor "A" of CAP), and later will merge depending on "wall clock" timestamps.
This is a form of consistency (and is weak), but is not Consistency with capital-C of CAP.
Other systems will use vector clocks instead of timestamps, which is stronger but slower. Other systems will instead merge values together doing a "Set union" operation. Here we still have no strong consistency, but the safety of the system is improved.
Now that we understand what means strong consistency, and what means eventual consistency, we can talk about Redis Cluster from this point of view. In Redis Cluster, which is eventual consistent, when the partition heals all the nodes will agree by selecting an history between the histories available for a given "hash slot" (a set of keys). However we need to consider what happens during partitions to have a better picture of what happens. In the case of Redis Cluster the minority side of the partition will stop accepting writes after some time. This gives up "A" of CAP in order to put a bound to how much two histories can diverge.
Ok, now let's explore "A". CAP Availability is the ability to reply with a positive reply (so, basically, to be able to accept writes is required) to requests even in a minority partition with a single node.
This is a very strong idea of availability, but this is not the only possibility to be fault tolerant. For example CP systems don't feature "A", but they are able to work correctly even if N/2-1 nodes will fail. This is a pretty strong failure tolerance! So they are reliable systems for a lot of works even if they don't have "A".
As a counter example, Cassandra or Riak would still be very useful tools even without "A" availability, but just with N/2-1 nodes allowed to fail.
Ok, back to Redis Cluster. It does not provides "A" since minority partitions are not available. It does not provide "C" since it is eventually consistent. But it still provides a form of consistency (its contract with the user about what happens during partitions) and provides some degree of resilience to failures.
AP or CP are just the theoretical limits you can get if you want to exploit the max in this regard, however it is not like a system is useless if it is not AP or CP.
In the case of Redis Cluster to renounce to "C" was obvious since it is asynchronously replicated and is not a good fit for high latency interactions. To renounce to the strong availability of "A" was a tradeoff to feature Redis data structures that are limited in size (number of elements) only by available memory.
Actualy, the NSA - just like the CIA, is known to carry out false flag acttacks to achieve a certain outcome. This point should not be overlooked.
In this case Meetup is a perfect NSA 'false-flag' target because it's not a financial institution (NSA ally), and yet is used by millions of people. Thus millions of people starting to ask if GCHQ/NSA will keep them 'safe' online.
There is no reason why "editing plain text" should be anything other than immediately intuitive. Advanced, time-saving features, like multi-cursors or regexp-based find-and-replace, can and should be progressively revealed through normal use of the software.
This ludditic reverence for user-hostile text editors is one of the more perplexing and frustrating things about our industry.
> There is no reason why "editing plain text" should be anything other than immediately intuitive.
Are you suggesting that it isn't in Emacs?
Well, I remember using Emacs for the first time. It opened up and I started editing the opened file. I saved the file from the file menu (which also showed me the shortcut for saving the file the next time I have to save something). Done. Now, this is exactly what a novice would do with notepad.
I found that many people 'demonize' Emacs just because they found it unfamiliar. Sure it's unfamiliar. For about a day. Then, it's just as familiar as any other user interface. I now used Emacs for, well, the shell, the dired and wdired, multiple cursors, keyboard macros, project-wide grepping and everything in between. Getting familiar with the editor was a great thing to have done, however unfamiliar it was in the beginning.
With the benefit of hindsight, I can truly say that learning how to properly use a text editor, especially one so powerful as Emacs, is the one thing the any programmer absolutely must do. So, even if the editor isn't "anything other than immediately intuitive", it's still a good idea to wrap your head around the non-intuitive things.
Ah, but you forget to provide a reason to support your claim unlike me, who presented a basic use case which in fact refutes your claim (in the last comment).
> Emacs is obviously and inarguably not immediately intuitive.
"obviously" : I find it anything but obvious.
"inarguably": Really? So it can't even be argued? Well, I don't know what to say to that.
What is immediately intuitive about anything a programmer does on their machine? I assume you have used a Unix shell, right? Was there anything immediately intuitive about that? You've probably done some programming, so was there anything immediately intuitive about your programming language?
Editing plain text is in fact very easy. Structured text requires a little more logic, however. Ultimately, you could use emacs in the exact way one would use notepad++ and be none the wiser to the rich customizations under the hood. If thats your bag of tea, drink it.
