Lattice is a more minimalist approach, for those who desire the production hardened core of Cloud Foundry but prefer to bring their own PaaS components or simply experiment.
I make complete AMIs with packer, configure them entirely using environment variables in userdata, configuration data in etcd, and shell scripts, and run all services in docker containers, which I also build using packer. With all services in containers, AMIs are almost never rebuilt and there is no need for configuration management/mutating infrastructure.
Building containers with packer is easier than switching to Dockerfiles for existing builds, but does not support fast, incremental build and deploy or tagging. Even without those features, I see no advantages in traditional CM other than the convenience of familiarity and legacy.
I am not aware of any proposed attacks on the approved cipher suites that are anywhere near feasible. TLS deployment is far behind known best practice. We should do something about that.
That you are unable to distinguish between an instance of sexual discrimination (called sexual discrimination) and systemic sexual discrimination (called sexism) does not mean anything political or Orwellian is afoot. Words have meanings. Ignorance of the meanings of words is easily solved. Stubborn refusal to recognize your own errors is rather less so.
Asserting all members of a group of people are subhuman sure does sound like something that happened in Europe in the 30s and 40s. What point were you trying to make?
Seems like a lot of folks missed the section of the post explaining their implementation and use of _ECDHE_ not _EDH_. The performance impact of ECDHE is surprisingly small.
Much like our engineers, our software is extremely opinionated. Ordasity, Scalang, and Overlock are all small, extremely focused libraries to solve a single problem in a single way. This is quite similar to the Unix philosophy and we have found it to be similarly successful. Projects like Akka take a more maximalist, all-encompassing approach that doesn't work well for the way we build and operate services.
The formatting tool in question defaults to _not_ doing this, specifically to comply with the Scala Style Guide which does _not_ do this. The tool had to be explicitly configured to make this unfortunate change.
You've got it backwards: I haven't seen anyone, including Chas, argue for disallowing Unicode. As you say, replacing a simple, common, 2 character operator with the unusual Unicode version is an odd and inconvenient decision. At present, this is Akka-specific, though the line between Scala and Akka seems to be blurring like Erlang and OTP.
Banks are unfortunately poster children for what not to do in this space, generally. The default cipher for google.com is RC4-SHA, and I can, if so inclined, force negotiation of AES-based ciphers by client config. Not so with Citibank (RC4-MD5, DES-CBC3-SHA, or DES-CBC-SHA) & BofA is only marginally better (RC4-MD5, RC4-SHA, AES128-SHA). To their credit, they are using 2048 bit RSA keys with short lifetimes and they have significantly improved their configurations from a couple of years ago when single DES defaults and 40-bit RC4 were all too common.
While I would certainly prefer to see the major players leading the way in adoption of AES by default, RC4-MD5 persists for at least 2 reasons:
1) Habit
2) As implemented/deployed in SSL, it still provides some security
RC4 has gotten a bad reputation in large part because of its poor application in WEP that resulted in keys being rapidly recovered by sniffing traffic. The Wikipedia entry is a good place to start http://en.wikipedia.org/wiki/RC4#Security (& numerous references for the original papers/pubs cracking various bits of RC4). The RSA response to RC4 concerns (from WEP) is worth reading, as well http://www.rsa.com/rsalabs/node.asp?id=2009 .
http://lattice.cf/