I'm not trying to sell you anything. In fact, you just reinforced my point. Recognition of and debate on the specific mechanisms and historical data associated with a theory are critical to the process of scientific examination. Abusing the word "theory" to the point that the implication becomes minimization or outright dismissal is at best a poorly executed deflection, as handily demonstrated by the GP.

Again, thank you for supporting proper open discourse via notation of avenues for further research and debate, and by extension supporting my point. I greatly appreciate it.

Everything is relative, of course, but I'm not sure I would have run with the headline "The Andromeda Galaxy Just Had a Bright Gamma Ray Event" when the event occurred over two million years ago.

Selection of genetic traits over generations based on fitness/utility is a fact, not a theory. This process has been directly observed over time in the wild in various species, and is the entire foundation for selective breeding activities undertaken by humans for crop and livestock improvement over several thousand years. By pushing layman's version of the term "theory" and framing evolution as a single claim, you do a gross disservice to the scientific process and truth. Please educate yourself, as the topic covers a tad more in breadth and depth than you're implying.

It's worth mentioning that special relativity is a theory, and yet mass-energy equivalence is a demonstrated fact. Again, please stop diluting the discourse.

I wouldn't exactly call that enhancement, unless you enjoy the sadomasochistic aspects of MIME. If you haven't written software to parse raw SMTP messages, you may not understand.

Whoosh.

I've mostly just stuck with Perl and Bash, and I'm still not sorry.

I'll add one more bit of fuel to the fire of Slashdot irresponsibility. It appears slashdot.org uses Apache 2.2.3 on CentOS to serve its content, and while this could be due to an obfuscated host response header, the issuance date for their wildcard SSL certificate (which really shouldn't be used in this case anyhow) was April 20, 2013. Unless Slashdot went to the trouble of avoiding OpenSSL all this time, this means the private key for their wildcard certificate was vulnerable to the Heartbleed vulnerability widely reported just a short while back (heavily discussed on Slashdot, ironically enough), but their management couldn't be bothered to revoke and reissue the certificate. I'm sure I don't need to elaborate on the information security implications in this case.

To add to the heap of bad practices in relation to the current conversation, I'll repeat my earlier comment that Slashdot has still not renewed their certificate, and thus even subscribers are in a bit of a pickle with regard to TLS unless they happen to have previously noted the key fingerprint of the now-expired certificate and place rather high trust in the internal integrity of Slashdot operations. Given the circumstances, I could not in good professional conscience recommend such trust.

I'm explicitly not referring to Slashdot. As much as I may disagree with said practices (and Slashdot has a seemingly ever-increasing pile of bad practices following the last buyout), poor practices on the part of a particular site operator bear no relation to responsible use cases.

I'm keenly aware of the many issues surrounding mixed content. I'm not referencing any use cases where that would be an issue; far from it, I'm referencing cases where a single entity controls the serving of non-sensitive content, and I'm certainly not suggesting serving session cookies over plaintext under any circumstances. You might be interested to learn that I spend a considerable amount of time every week educating people on issues far more complex than the limited fundamentals you've referenced here, and in any event we appear to be discussing completely different use cases.

On an entirely separate note, it seems Slashdot still has not renewed their own certificate.

Varnish was never intended to support TLS, nor do the majority of Varnish users (myself included) want it to. The core issues being discussed have little to do with Varnish, aside from the fact that PHK has an excellent understanding of HTTP and high performance content delivery. Having written an HTTP proxy of my own to perform certain other tasks, I understand and largely agree with his sentiments.

That said, it should be noted that many people who need to support TLS connections already use separate software in front of Varnish for cases where high performance intermediate HTTP caching is desirable. This is really a separate topic from discussion of HTTP/2 and/or SPDY, but implementation of a SPDY to HTTP proxy could handle cases where an administrator wishes to run software that only speaks HTTP, albeit with the drawback that SPDY-specific features would be unavailable.

For many use cases, the ability to support 30,000 concurrent HTTP connections with a single VM outweighs the value proposition of encrypting the content in transit, especially for cases where the content in transit isn't remotely sensitive in nature. While "encryption doesn't add much overhead, Google said so" is a commonly parroted idea these days, if you take the opportunity to test various deployment scenarios you'll quickly find that assertion is false for many of those use cases.

I couldn't help but think of Episode #12 - Using Proper English - The Many Uses of the F word.

If you understood statistics, you'd be able to answer your own question.

PHYSICAL, CHEMICAL, AND ME CHANICAL PROPERTIES OF BAMBOO AND ITS UTILIZATION POTENTIAL FOR FIBERBOARD MANUFACTURING

That was the first result of about 299,000 for the simple Google query "physical properties of bamboo." Have a nice day.