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.
In addition to my other comment in this thread (in response to shykes), I want to add respond to this:
> but does not support fast, incremental build and deploy or tagging
Deploy/tagging is actually already a PR to Packer and will be merged in shortly. Incremental builds are under development. They'll make it in hopefully in the next version of Packer, but if not, the following.
And the incremental builds will work for AWS, VirtualBox, etc. as well.
What does a typical packer config file look like for building a docker container? I think of it as a useless abstraction on top of docker, but that's probably because I only generate containers and don't need the other packer targets. I only ever need one AMI, GCE image or vbox: the boot2docker base. And even that is exported from a container :)
Since building Docker support into Packer, I've heard a few beneficial points from some companies I've helped integrate it into as well as some users. I'm not here to convince you, but just to share what I feel are some valid use cases. Alas, portability is not the only reason, but is one.
* Software installation/configuration knowledge remains solely in existing Chef/Puppet/etc. code-bases. Dockerfiles can add another format for software to be "installed" (or "packaged" if you prefer). Packer + Docker allows you to use your existing expertise, CI process, etc in order to create these containers.
* Common "image" configuration format: again Dockerfiles represent a Docker-specific way of building images. This is all well and good, but it is still very common to have multiple types of images (AMIs, Docker containers, VirtualBox, etc.). In a world where Docker isn't used everywhere, it is a burden to maintain multiple methods of building images. Packer provides a single way to do it that is flexible to multiple platforms. And even if an org decides to transition completely to Docker, Packer helps get them there. Perhaps they want to switch to Dockerfiles after that, but there is still point #1 above.
* Portability: Packer represents a low-risk way to adopt Docker containers, if you use Docker. Dockerfiles are somewhat of an "all-in" approach to Docker. If you don't like Docker, or Docker isn't good for this specific use case (yet, or ever, doesn't matter), then Dockerfiles have to be translated over to another format. As I'm sure you know, big IT is all about minimizing risk when adopting new technologies (actually, a top point to NOT adopt new technologies that we have to fight!). Packer represents a way to say "yes, Docker is new, but Packer provides a pretty low-risk way to get into it. Let's first build vSphere images, like you're used to, and see how those transition to Docker containers. If you don't like it, we still built automation to build vSphere VMs!"
* Extensibility: Packer is very plugin-friendly. You can hook into almost anything. This allows some nice plugins to exist to help augment the process for building images, whether they be containers or not. If Dockerfiles don't support a command to do something, then Packer plugins can very easily do that for you. Maybe it doesn't make sense for this certain feature to be a core feature of Dockerfiles, OR Packer. Either way, it doesn't matter, because the org can just build a plugin for themselves and use it internally. No harm done.
* Process friendliness: In addition to the portability above, centralizing on Packer for image creation is 1..N less processes to adhere to. Docker has a different process for building containers. Aminator has a different process. Every new process is a new special snowflake CI handler to run them, new education for employees, new maintenance. By using Packer, you can use the same CI runners/parsers/steps (Bamboo, Jenkins, etc.) to build any sort of image.
And to answer your question on "what does a Packer config file look like" here is a basic, but fairly typical config file:
Pretty simple. Easily human and machine editable/readable. Also, if you happened to want to build an AMI too, it is not much different. And finally, if you use Chef/Puppet/etc, you can just drop that in there, and it works just like you'd expect. Packer even installs Puppet/Chef for you (if you want)!
I hope that clears things up. Packer has been helping with adoption of Docker for many people I've helped! I think its clear from my work on Vagrant and Packer (and some future stuff), that the one thing I try to avoid is lock-in of any sort. I focus instead of human process, rather than technical specifics. You can argue that Packer itself is a lock-in format, but the point is that its a single similar format for many. Its agenda is to be as helpful to as many projects as possible that need images, and not to discriminate in any way.
And to address the grandparent (I'll comment directly on that to): with regards to speed, we're working on what we're calling "snapshotting" functionality in Packer now. With this, Packer will snapshot containers at various points in the build process, just like `docker build`. So when you run a `packer build`, it'll start only from the point it needs to, rather than from scratch. A cool thing is that this feature will extend to all the other builders, too, so if you're building a VirtualBox VM from an ISO, for example, it won't reinstall the OS if it doesn't have to. Cool stuff.
Using Docker in production is about stability of API, not technology.
Meaning, for those companies/projects with fast, iterative cycles, who want to take advantage of Docker but understand it's an investment in time over the long run, it's a great fit today.
For those companies/projects with slower cycles, who want a solution which will fit their needs out of the box backed by some sort of support.. 1.0 is the target.
I downvoted you. It's natural to be skeptical about the things you see online, especially when it's almost too good to be true. And there's no need to start name-calling.
Oh gosh, come off it. I agree with wellington's subsequent post that such contextual information is worth knowing because anyone looking to learn programming from scratch will probably be demotivated by this post. I mean, Github by itself will confuse from-scratch beginners! Imagine seeing that as your benchmark, and looking at your own work on day 10.
It's an amazing feat, and she clearly has much more aptitude (and dedication) for the skills than I do. I applaud what she's done. But I'm hard-pressed to believe she started with a blank slate, and I wouldn't want any true beginner to believe that either. I'm not saying that she knew even one programming language before starting, or that she had any sort of expertise whatsoever. But a rudimentary understanding of some key terms and concepts? Seems plausible-to-likely.
I don't think that diminishes the work in any way whatsoever. The work and the effort are amazing.
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.
I don't accept redefinitions of words that pack in political assumptions. Lots of people use "socialist" to mean "anyone to the left of Ronald Reagan" but we have no problem dismissing that as biased hyperbole.
What you're essentially doing is trying to pack into the word "sexism" the notion that everything in society is systemically biased in favor of men, at the expense of women. But rather than establishing and defending that notion, you pack it in as an unquestioned assumption so that you don't have to defend it explicitly.
As a result, you deliberately minimize any injustices suffered by men to the benefit of women, implicitly saying that it doesn't matter as much when a man faces sexual discrimination. Again, you could simply argue this point explicitly, but for some reason you're trying to pack it into your language.
Steve Klabnik's point, stated explicitly, would be something like this: "that instance of sexual discrimination against men, in favor of women, doesn't really count for much, because on aggregate, society still discriminates against women in favor of men." As far as I can tell that's what he meant, and it's even a defensible argument from a feminist perspective, but it also lays bare a lot of assumptions that not everyone might agree with, so it's couched in the superficial form of a semantic argument. This not only makes the controversial premises of the argument easier to swallow, but renders them in a form of a simple factual claim giving the illusion of certitude.
As far as the scope of this discussion is concerned, I don't have a problem with Mr. Klabnik's point, but simply the dishonest way he expresses it.
"Prejudice, stereotyping, or discrimination, typically against women, on the basis of sex" (Google)
"prejudice or discrimination based on sex; especially : discrimination against women" (Merriam-Webster)
"prejudice or discrimination based on sex; behavior, conditions, or attitudes that foster stereotypes of social roles based on sex" (Wikipedia)
I think these are all perfectly acceptable "plain English" definitions of "sexism".
Definitions are nothing but arbitrary convention anyway--my point is that when you explicitly unpack the feminist definition of "sexism", seemingly semantic arguments like Mr. Klabnik's are packing in a lot of assumptions that deserve to be unpacked. Generally, I don't favor definitions that pack in tendentious assumptions for political purposes.
As you noted, those definitions are all arbitrary, but needless to say they leave out the entire history of the origin of the word, an origin which seeks to critically describe both individual instances of sexism as well as the systemic, social factors of sexism. It should be noted though that the Wikipedia definition does include something about more than just individual instances of sexism.
I disagree that there are extra meanings being packed into the word sexism beyond the meanings you cited. That you are unaware of the origins and issues that go into sexism doesn't remove the meanings of the word. To be fair, no mainstream outlet or publication tends to talk about things at that length and level for a variety of reasons, many of which are due to systemic sexism, but don't confuse common understanding for the only understanding. Common understandings that lack depth or more rigorous information are what contribute to a common understanding that promotes racism, sexism, and other issues.
That post seems to unpack more or less the same assumptions I'm unpacking:
"A running theme in a lot of feminist theory is that of institutional power: men as a class have it, women as a class don’t"
"What this imbalance of power translates to on an individual level is a difference in the impact of a man being prejudiced towards a woman and a woman being prejudiced towards a man"
Or as I called it: "the notion that everything in society is systemically biased in favor of men, at the expense of women", leading to the conclusion that "it doesn't matter as much when a man faces sexual discrimination".
Fine. We agree that the same assumptions are being packed into the feminist usage of the word "sexism". My argument is that these assumptions need to be called out and defended in this forum. If this were a feminist forum where everyone could be reasonably assumed to have already accepted those assumptions already, perhaps the implicit jargon would be more appropriate. Furthermore, the act of imposing this jargon is a backhanded way of imposing the assumptions behind that jargon.
I totally agree about the inaccessibility of a lot of feminist literature, including things on sexism. Talking about the meaning and reasons behind sexist incidents and sexism, as steveklabnik did, is important and esp. so in places where basic, fundamental info is not known.
There's nothing Orwellian about that, though, because we are talking about information that hasn't been made available or accessible for others rather than taking terminology and changing its meaning to suit a political agenda diametrically opposed to what the original term stood for. In fact, that mass media has perpetuated sexism and feminism as things that do not have a systemic basis or ignoring that they do is the more Orwellian thing going on in US society.
As for imposing assumptions, the notion that using terminology correctly and explaining and examining that terminology is somehow backhanded in a discussion or argument is silly. How else are we going to get better understanding without using actual terms and the ideas behind them?
Your argument seems to be that since feminists invented the word, it's pretty much up to them what it means. Fine. My response: that definition still packs in assumptions unfairly and it would be better to abandon the word entirely, at least in forums where the assumptions packed into that word's definition are not universally held premises.
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.
It doesn't help that Apache has a setting "kEDH - Ephemeral (temp.key) Diffie-Hellman key exchange (no cert)" and "EDH - all ciphers using Ephemeral Diffie-Hellman key exchange" that (I think) maps to what IETF TLS calls "DHE - Ephemeral DH".
I get these confused all the time, and now they add in an "EC" prefix!
http://lattice.cf/