Your perspective is naive, but I'll err on the side of caution with regard to possible explanatory factors and simply assume ignorance. You forgot to account for the totality of advantageous traits in your hurry to point to "disadvantageous" traits. The fitness of an individual is not gauged by individual traits, but by the holistic picture of the individual and it complex interactions with other organisms in a particular environment over the lifespans of all involved entities.
In other words, "it's a tad more complication than your portrayal," and formal mathematics quickly becomes useful in viewing these things at any scale.
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.
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.
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.
PHK's biggest issue IMHO is that HTTP/2 will break his software (Varnish), by requiring things his internal architecture can't really deal with (TLS).
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.
That's a darn good find, and definitely a really annoying issue. You're correct that 99% of the stuff I manage is x86-64; I've only got a couple of legacy x86 systems floating around, and fortunately in this case they don't use XFS. I can only imagine the amount of $head_desk you went through before realizing what the root cause was in the case you described.
So we're all absolutely certain you understand the "whoosh" notes you've received, the GP was obviously making a humorous reference to the old expression RAID is not a backup. HTH, HAND.
I only use XFS and ZFS on Linux these days, with exception of ext2 on some/boot volumes. Nobody has shown me a compelling reason to deviate from what works.
Nothing in the GPL prevents you from charging money for GPL licensed software. You appear to be confused on this point. Based on a large sample set of previous discussions on the effects and merits of various licensing schemes, I suspect you are also confused on the definition of the word "freedom." In case you're not confused, but offering a goalpost moving teaser into a discussion on the latter point, I'll preemptively note that neither you nor Stallman get to redefine words to fit any particular ideology. I choose to license most of my software under derivatives of BSD style and Artistic licenses, and I do so for what I believe are good reasons. While I absolutely encourage you to engage in persuasive public discourse on the merits of your favorite licensing schemes, I also absolutely insist on honesty while doing so.
Slashdot Mirror
Your perspective is naive, but I'll err on the side of caution with regard to possible explanatory factors and simply assume ignorance. You forgot to account for the totality of advantageous traits in your hurry to point to "disadvantageous" traits. The fitness of an individual is not gauged by individual traits, but by the holistic picture of the individual and it complex interactions with other organisms in a particular environment over the lifespans of all involved entities.
In other words, "it's a tad more complication than your portrayal," and formal mathematics quickly becomes useful in viewing these things at any scale.
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.
PHK's biggest issue IMHO is that HTTP/2 will break his software (Varnish), by requiring things his internal architecture can't really deal with (TLS).
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.
You should probably ask the BBC about that. Cheers!
If you felt the product's price was excessive compared to the value delivered, why did you buy the product?
Robyn doesn't look like a "he" to me.
That's the spirit. :)
That's a darn good find, and definitely a really annoying issue. You're correct that 99% of the stuff I manage is x86-64; I've only got a couple of legacy x86 systems floating around, and fortunately in this case they don't use XFS. I can only imagine the amount of $head_desk you went through before realizing what the root cause was in the case you described.
So we're all absolutely certain you understand the "whoosh" notes you've received, the GP was obviously making a humorous reference to the old expression RAID is not a backup. HTH, HAND.
I only use XFS and ZFS on Linux these days, with exception of ext2 on some /boot volumes. Nobody has shown me a compelling reason to deviate from what works.
Why did you attend university?
Nothing in the GPL prevents you from charging money for GPL licensed software. You appear to be confused on this point. Based on a large sample set of previous discussions on the effects and merits of various licensing schemes, I suspect you are also confused on the definition of the word "freedom." In case you're not confused, but offering a goalpost moving teaser into a discussion on the latter point, I'll preemptively note that neither you nor Stallman get to redefine words to fit any particular ideology. I choose to license most of my software under derivatives of BSD style and Artistic licenses, and I do so for what I believe are good reasons. While I absolutely encourage you to engage in persuasive public discourse on the merits of your favorite licensing schemes, I also absolutely insist on honesty while doing so.