Not quite a normal off-the-shelf. It is a high power adapter - 40W (~8A at 5.25V). Most high-end phone chargers max out at 10W (2A at 5V).
The difference in higher power is probably taken by the higher draw that the screen would have vs a phone. Likewise the larger battery would need a higher draw to charge within reasonable times.
I also note that the comment is "plugged in while in use". This hits the higher draw for the battery charging + higher run-time draw. Most likely the current limiting is not working properly on the power supply which is causing too much heat.
The amount of content (text) to mostly irrelevant Pictures (fluff) went bad pretty quickly. If they are stock photos or Logos, why bother making it larger and apparently more relevant than the article?
If it is an image from the relevant article, i'm not so against it.
This is a true scene from the early 2000's when I was involved in some Linux conferences as a speaker...
Imagine if you will a white male, late teens/early twenties. Full length leather jacking swaying as he walks the floor. His sunglasses obscuring where he is looking. He is clearly carrying something under the leather jacket, but you can't quite see what it is...
Something catches his attention from across the floor. Quickly he moves across the aisle, his jacket and whatever is underneath following a split second later, the inertia of something heavy slowing it down. He walks across to a booth, and nervously asks a question or two. He looks agitated and frustrated. He adjusts his glasses reaches under his jacket and pulls out... His laptop.
I think it was LinuxWorld in 2000. There was a guy that had all his gadgets attached to cables under a full length Morpheus-style jacket. I swear, everything up above is true (well maybe not the agitated and frustrated part).
I can't quite recall if his sunglasses where nose-clip glasses...
Vetting and getting a good engineer who can troubleshoot isn't easy.
But I would almost guarantee you'll have problems transitioning to a new provider, and there will be a different set of problems with the new provider. The cost benefit of staying/debugging vs moving/restabilizing are something you'll need to make.
If the vendor isn't helping or finding a root cause, then it may be better for you to hire an external engineer to look into the problem for you. As mentioned elsewhere there are no details on the application... But as per the HTTP standard 503 is a generic "server unavailable". This could be caused by load or a transient application failure or simply a real repeatable bug that is triggered periodically.
My recommendation would be to contract a developer (how is left as a problem for the OP), and have them debug the problem on behalf of your organization, make the SOW a root cause analysis for the issue.
Assuming you are using a web application of some description, you will most likely run into a similar problem when you move to a new provider. A rule of thumb that I use is that when making drastic changes to a deployment/infrastructure/application/software/etc. You will be invariably swapping a set of painful intractible problems that you know and understand and work around, for a set of new intractible problems that will take time for you to know and understand and work around.
The art is in known whether the unknown intractable problem is going to be better or worse than the previous ones. I am sure most of the SW people on slashdot have seen far too many "Our new system is going to solve all our problems". Only to get given something that is different, but just as bad - but cost a hell of a lot more to put together than the workarounds for the old system...
0 (C) != 0 (F). But fortunately -40 (F) = -40 (C). Or you can just double and add 30, or maybe you prefer to divide by 9 and multiply by 5...
Hell, let's just go duodecimal... Software engineers will be comfortable with the A and B value, and young kids learning to write will be happy with the reversed 2 and 3.
Got to love measures. I seriously hope we *do not* come across aliens any time soon and get tempted with a true universal (well maybe galactic, well probably just an Orion Arm (our part of the galaxy) specific set of measures. Let's hope that physics is consistent at that level too....
The CIA World factbook has a snarky "At this time, only three countries - Burma, Liberia, and the US - have not adopted the International System of Units (SI, or metric system) as their official system of weights and measures. Although use of the metric system has been sanctioned by law in the US since 1866, it has been slow in displacing the American adaptation of the British Imperial System known as the US Customary System. The US is the only industrialized nation that does not mainly use the metric system in its commercial and standards activities, but there is increasing acceptance in science, medicine, government, and many sectors of industry."
Don't worry though, moving 300 million takes a hell of a long time - measured in generations. If you go to the store you will see lots of metric rounded numbers (drinks in 500 mls). Dates on the immigration forms have moved to ISO DD-MM-YYYY. Give it another 50 years, globalisation will take care of it.
Although it can be nutritionally appropriate, it may still not be good for the body. I am not a biologist, but I don't believe that the body is built for finely processed food. I am assuming that there is some research correlating highly processed/refined foods and the some of the common ailments in the western world.
A great example I have seen showing processed vs non-processed foods is to simply put the food in a bowl of water. A lot of processed food will within a matter of minutes puff up to a multiple of their size, and when stirred will simply break up into a liquid solution. Natural (unprocessed, even minimally processed) foods will generally stay together for a lot longer.
Give it a couple of centuries, and we'll see how the human gut and digestive system evolve. Oh wait, we'll have medical systems to prevent natural selection, so we're going to be co-dependently evolving with our technology.
Beyond this, there are some important differences.
Google has successfully gone from monetizing search to monetizing their search algorithms (data matching) for advertising. For example, I go to google to look up something, yes there are ads there, but they are non intrusive. There are also ads extended out to other sites, but again are non intrusive. Google now can focus on data acquisition instead of monetization. A lot of their still remaining technologies (google voice, youtube, email, etc, translate) are all about learning about associations and re-inforcing their understanding the data to help providing a better match. G+ is about mapping that information to users and user associations.
Facebook on the other side is trying to find ways to monetize their core business and why people go to them. They are interrupting the experience (video playing will grab more attention than other parts of the facebook timeline). If Facebook doesn't screw it up, they might be able to get to a google-style place and be able to focus on data collection.
Time will tell, I haven't ever got into facebook. I have an account for authentication purposes, but that is about it.
This isn't too surprising. As a 40 yr old engineer, I am halfway in between the two worlds. For the record, I am in management, but still can hold my own against a lot of engineers.
(Good) older engineers usually can bring either broad system experience where they see patterns and nothing phases them. The other type of (good) older engineers have a depth of vertical experience in a very tight sub-domain. iOS, Android and Windows Phone are Yet-Another-Operating-System (YAOS), same general patterns, same problems. System thinkers (the first type of "good engineer") revel in this type of YAOS.
Some of the newer areas like.com world is a bit different in that the domain is extremely wide (that reduces the pool of those that meet the "good" bar above) to know everything, you need to know databases, HTML, javascript, networking, etc... This younger engineers have the benefit of a similar depth of expertise as the old ones, but the breadth of the area is too wide to help the system thinkers show their strength. Plus the younger engineers don't have the commitments, don't always have the work/life balance, and have more stamina.
The normal flu is quite virulent, but outside of high risk groups, the mortality rate is also quite low. Not pleasant, but low mortality.
(IANAI - I Am Not An Immunologist) The dangers about these cross-over influenzas is that they tend have a higher-than-average kill rate for generally higher. With global transfer of diseases, a mortality rate of just 1% and infection rate of 10% of the global populate is still around 7 million people. Spanish flu in 1919 had a hit rate of between 2% and 20% (according to wikipedia). A *very* sobering number.
If we have a contagious, long incubation, high mortality virus hit the globe, we are in a very bad state. Any signal of a pandemic needs to be taken seriously.
Most good estimates have a range - and not a number, or a number with a confidence (both are interchangeable).
If an engineer says it will take two weeks - I push for a range or a confidence. If the range is weird (2-8 weeks), I push for the engineer to tighten their estimate through discussing or raising and discovering the unknowns or the risks that they are aware off. That sort of estimate would usually end up around 3-5 weeks which is a reasonable margin - and a lot better than than underestimating by 50%.
Same with estimates that are too narrow. "2 weeks +/- day". That implies a full level of understanding, no risk and no dependencies. Almost never happens. Work through the same risks/unknowns and the estimates usually become really bad - typically at least double of the "high confidence" estimate - similar to TFA.
There is a lot of reasonably applicable theory behind this (confidence intervals, cone of uncertainty, etc). But we don't necessary focus on mastery of our art...
Most good estimates have a range - and not a number, or a number with a confidence (both are interchangeable).
If an engineer says it will take two weeks - I push for a range or a confidence. If the range is weird (2-8 weeks), I push for the engineer to tighten their estimate through discussing or raising and discovering the unknowns or the risks that they are aware off. That sort of estimate would usually end up around 3-5 weeks which is a reasonable margin - and a lot better than than underestimating by 50%.
Same with estimates that are too narrow. "2 weeks +/- day". That implies a full level of understanding, no risk and no dependencies. Almost never happens. Work through the same risks/unknowns and the estimates usually become really bad - typically at least double of the "high confidence" estimate - similar to TFA.
The is lots of reasonably applicable theory behind this (confidence intervals, cone of uncertainty, etc).
My wife is now a fully-fledged closet-trekkie and general sci-fi junkie...
As she is less of a night owl, but would fall asleep on the couch, I would turn on the TV show as she fell asleep. The voices, music and so on become familiar over a week or so. Then occasionally disturb her to wake her up.
Eventually, you can try to watch one with her one night. The familiarity gap won't be there, so she'll probably enjoy it.
Be careful though, my wife ended up becoming more hooked than I was which meant that she watch more of the shows in order than I did, so I'm the one ultimately with gaps in the series. It's worked with ST:TNG, DS9, BG:Reimagined SG:Atlantis, SG-1 and SG:Universe and Firefly. Ultimately I don't have to fight on Sci-Fi anymore, but our bar is pretty high.
Okay. It's clear you haven't looked into the Phoronix Test Suite. (PTS)
The software product itself is a Test Execution Environment. The suite's value add is that it simplifies the download and execution of the actual tests and benchmarks that are executed. Those test or benchmarks are in whatever language the author of that test profile wanted to write it in.
PHP is not involved in any actual _measuring_ of performance, but is involved in the orchestration, interpretation and aggregation of the results.
Check out the version of PTS in your local convenient distribution (it's in most of the recent ones).
Feel free to contact me (I'm not posting an email address here), but it shouldn't be difficult for you to find me (visit Phoronix-Test-Suite.com or openBenchmarking.org). I'm more than happy to explore your experience and look how it can be made.
PHP has allowed Phoronix Test suite to support everything from embedded ARM systems to cloud compute infrastructure. The fact it uses PHP makes it extremely portable. Virtually anywhere that there is a compiler and PHP, Phoronix Test Suite can run. Note that the benchmarking itself is not in PHP, it's done in whatever native language the benchmark needs.
How do you know that running on an AMD doesn't affect one kernel version more than another vs Intel. The same argument stands. It's a machine layer for running code.
Sure, it's not what you want, but don't consider it completely invalid. There are many people who have interest in virtualized performance.
At the last companies I have worked at, the modern hardware doesn't run the old version of Red Hat. The result is that they run RH or other legacy versions of Linux are easier to deal with a consistent and simple hardware abstraction provided by a VM. I haven't seen a bare metal deployment of anything older RHEL 5 for a while (either that or the system it's running on is on life support).
I agree about embedded devices having older kernels - I'm regularly involved in "shiny and new" vs "old and known" discussions. Of course we're talking about PC class hardware that EOLs faster than the software. Again, my comments are focused on the enterprise use of older kernels which is a sensible interpretation of the article.
When Phoronix does a distro-comparison the crowd calls out that the tests are only really testing gcc differences, and should have less variables changing. When Phoronix does a fixed comparison varying only one part of the system, the crowd calls out that it isn't a good basis since people don't run it that way.
Phoronix runs tests in different ways to explore the performance landscape. For some it precisely gives the information that they need, for other it's completely irrelevant. In this particular case, I'm glad that the data gave you enough to have some open questions about 2.6.32 vs 2.6.37. If people walk away with those sorts of first order interpretation, the article served it's purpose.
Of course the next step would be how do we take a tighter look at the delta between 2.6.32 and 2.6.37 - any thoughts?
Regarding meaningful vs meaningless tests. The tests Phoronix runs are a collection of tests to explore. The tests were run, and for some of them, the results yielded nothing interesting but were still reported. You don't know until you run the tests, and if the tests are run, you report on them. Some tests may be stable now, but may have sensitivity to other parts of the systems. Even CPU bound tests will yield different results in different cases (scheduler, etc).
The "get to statistical variance" has been in Phoronix Test Suite for the better part of a year.
As part of the new work happening with Phoronix Test Suite, and the online aggregation site OpenBenchmarking.org, we'll be looking to expose the raw data and allow people to view a particular set of results in a possible more meaningful way. What is being examined now is raw data (scatter diagram), box plot (percentiles), violin plots (kernel function based), full standard error reporting (error bars, numerical reference to SD and SE.
Of course the general articles just show a simple form.
Obviously, infinite time and infinite runs with a broad variance of hardware would be better. As per usual, contact us at Phoronix with a fully baked suggestion for improvements in Phoronix Test Suite or a benchmark suggestion or article suggestion and we are more than willing to consider it.
Slashdot Mirror
Not quite a normal off-the-shelf. It is a high power adapter - 40W (~8A at 5.25V). Most high-end phone chargers max out at 10W (2A at 5V).
The difference in higher power is probably taken by the higher draw that the screen would have vs a phone. Likewise the larger battery would need a higher draw to charge within reasonable times.
I also note that the comment is "plugged in while in use". This hits the higher draw for the battery charging + higher run-time draw. Most likely the current limiting is not working properly on the power supply which is causing too much heat.
Yet another link to an internal slashdot.org story under the datacenter topic... http://slashdot.org/topic/datacenter/invisibility-using-force-field-not-cloak/
Looks like slashdot is trying to be theverge or engadget...
The amount of content (text) to mostly irrelevant Pictures (fluff) went bad pretty quickly. If they are stock photos or Logos, why bother making it larger and apparently more relevant than the article?
If it is an image from the relevant article, i'm not so against it.
This is a true scene from the early 2000's when I was involved in some Linux conferences as a speaker...
Imagine if you will a white male, late teens/early twenties. Full length leather jacking swaying as he walks the floor. His sunglasses obscuring where he is looking. He is clearly carrying something under the leather jacket, but you can't quite see what it is...
Something catches his attention from across the floor. Quickly he moves across the aisle, his jacket and whatever is underneath following a split second later, the inertia of something heavy slowing it down. He walks across to a booth, and nervously asks a question or two. He looks agitated and frustrated. He adjusts his glasses reaches under his jacket and pulls out... His laptop.
I think it was LinuxWorld in 2000. There was a guy that had all his gadgets attached to cables under a full length Morpheus-style jacket. I swear, everything up above is true (well maybe not the agitated and frustrated part).
I can't quite recall if his sunglasses where nose-clip glasses...
3 head ati cards are easy to come by.
In 2009, we did 24 displays on on PC. Each 3x2 quadrant is randr based. That is what you want.
Http://youtube.com/watch?v=N6Vf8R_gOec
+1 for option 4, +0.5 for option 3.
Vetting and getting a good engineer who can troubleshoot isn't easy.
But I would almost guarantee you'll have problems transitioning to a new provider, and there will be a different set of problems with the new provider. The cost benefit of staying/debugging vs moving/restabilizing are something you'll need to make.
If the vendor isn't helping or finding a root cause, then it may be better for you to hire an external engineer to look into the problem for you. As mentioned elsewhere there are no details on the application... But as per the HTTP standard 503 is a generic "server unavailable". This could be caused by load or a transient application failure or simply a real repeatable bug that is triggered periodically.
My recommendation would be to contract a developer (how is left as a problem for the OP), and have them debug the problem on behalf of your organization, make the SOW a root cause analysis for the issue.
Assuming you are using a web application of some description, you will most likely run into a similar problem when you move to a new provider. A rule of thumb that I use is that when making drastic changes to a deployment/infrastructure/application/software/etc. You will be invariably swapping a set of painful intractible problems that you know and understand and work around, for a set of new intractible problems that will take time for you to know and understand and work around.
The art is in known whether the unknown intractable problem is going to be better or worse than the previous ones. I am sure most of the SW people on slashdot have seen far too many "Our new system is going to solve all our problems". Only to get given something that is different, but just as bad - but cost a hell of a lot more to put together than the workarounds for the old system...
Thankfully it isn't like temperature.
0 (C) != 0 (F). But fortunately -40 (F) = -40 (C). Or you can just double and add 30, or maybe you prefer to divide by 9 and multiply by 5...
Hell, let's just go duodecimal... Software engineers will be comfortable with the A and B value, and young kids learning to write will be happy with the reversed 2 and 3.
Got to love measures. I seriously hope we *do not* come across aliens any time soon and get tempted with a true universal (well maybe galactic, well probably just an Orion Arm (our part of the galaxy) specific set of measures. Let's hope that physics is consistent at that level too....
Me too. If the dates require numbers, I double check. If not, I *always* put the 3 letter (ISO) month name.
Kind of like official language of the USA. There isn't one. Just like customary units, there are customary languages.
Metrification is already happening. Executive order http://www.osha.gov/dts/osta/otm/otm_x/otm_x_1.html. The Federal government has a preference, but it is only that.
The CIA World factbook has a snarky "At this time, only three countries - Burma, Liberia, and the US - have not adopted the International System of Units (SI, or metric system) as their official system of weights and measures. Although use of the metric system has been sanctioned by law in the US since 1866, it has been slow in displacing the American adaptation of the British Imperial System known as the US Customary System. The US is the only industrialized nation that does not mainly use the metric system in its commercial and standards activities, but there is increasing acceptance in science, medicine, government, and many sectors of industry."
Don't worry though, moving 300 million takes a hell of a long time - measured in generations. If you go to the store you will see lots of metric rounded numbers (drinks in 500 mls). Dates on the immigration forms have moved to ISO DD-MM-YYYY. Give it another 50 years, globalisation will take care of it.
Although it can be nutritionally appropriate, it may still not be good for the body. I am not a biologist, but I don't believe that the body is built for finely processed food. I am assuming that there is some research correlating highly processed/refined foods and the some of the common ailments in the western world.
A great example I have seen showing processed vs non-processed foods is to simply put the food in a bowl of water. A lot of processed food will within a matter of minutes puff up to a multiple of their size, and when stirred will simply break up into a liquid solution. Natural (unprocessed, even minimally processed) foods will generally stay together for a lot longer.
Give it a couple of centuries, and we'll see how the human gut and digestive system evolve. Oh wait, we'll have medical systems to prevent natural selection, so we're going to be co-dependently evolving with our technology.
Beyond this, there are some important differences.
Google has successfully gone from monetizing search to monetizing their search algorithms (data matching) for advertising. For example, I go to google to look up something, yes there are ads there, but they are non intrusive. There are also ads extended out to other sites, but again are non intrusive. Google now can focus on data acquisition instead of monetization. A lot of their still remaining technologies (google voice, youtube, email, etc, translate) are all about learning about associations and re-inforcing their understanding the data to help providing a better match. G+ is about mapping that information to users and user associations.
Facebook on the other side is trying to find ways to monetize their core business and why people go to them. They are interrupting the experience (video playing will grab more attention than other parts of the facebook timeline). If Facebook doesn't screw it up, they might be able to get to a google-style place and be able to focus on data collection.
Time will tell, I haven't ever got into facebook. I have an account for authentication purposes, but that is about it.
This isn't too surprising. As a 40 yr old engineer, I am halfway in between the two worlds. For the record, I am in management, but still can hold my own against a lot of engineers.
(Good) older engineers usually can bring either broad system experience where they see patterns and nothing phases them. The other type of (good) older engineers have a depth of vertical experience in a very tight sub-domain. iOS, Android and Windows Phone are Yet-Another-Operating-System (YAOS), same general patterns, same problems. System thinkers (the first type of "good engineer") revel in this type of YAOS.
Some of the newer areas like .com world is a bit different in that the domain is extremely wide (that reduces the pool of those that meet the "good" bar above) to know everything, you need to know databases, HTML, javascript, networking, etc... This younger engineers have the benefit of a similar depth of expertise as the old ones, but the breadth of the area is too wide to help the system thinkers show their strength. Plus the younger engineers don't have the commitments, don't always have the work/life balance, and have more stamina.
The normal flu is quite virulent, but outside of high risk groups, the mortality rate is also quite low. Not pleasant, but low mortality.
(IANAI - I Am Not An Immunologist) The dangers about these cross-over influenzas is that they tend have a higher-than-average kill rate for generally higher. With global transfer of diseases, a mortality rate of just 1% and infection rate of 10% of the global populate is still around 7 million people. Spanish flu in 1919 had a hit rate of between 2% and 20% (according to wikipedia). A *very* sobering number.
If we have a contagious, long incubation, high mortality virus hit the globe, we are in a very bad state. Any signal of a pandemic needs to be taken seriously.
As per my blog post a couple of years ago at http://use-cases.org/2011/06/04/getting-good-estimates/ [use-cases.org] and http://use-cases.org/2011/06/22/updates-on-getting-good-estimates/ [use-cases.org]
Most good estimates have a range - and not a number, or a number with a confidence (both are interchangeable).
If an engineer says it will take two weeks - I push for a range or a confidence. If the range is weird (2-8 weeks), I push for the engineer to tighten their estimate through discussing or raising and discovering the unknowns or the risks that they are aware off. That sort of estimate would usually end up around 3-5 weeks which is a reasonable margin - and a lot better than than underestimating by 50%.
Same with estimates that are too narrow. "2 weeks +/- day". That implies a full level of understanding, no risk and no dependencies. Almost never happens. Work through the same risks/unknowns and the estimates usually become really bad - typically at least double of the "high confidence" estimate - similar to TFA.
There is a lot of reasonably applicable theory behind this (confidence intervals, cone of uncertainty, etc). But we don't necessary focus on mastery of our art...
Damn. Too many articles open... See in context http://developers.slashdot.org/story/13/04/23/2021201/overconfidence-why-you-suck-at-making-development-time-estimates :).
As per my blog post a couple of years ago at http://use-cases.org/2011/06/04/getting-good-estimates/ and http://use-cases.org/2011/06/22/updates-on-getting-good-estimates/
Most good estimates have a range - and not a number, or a number with a confidence (both are interchangeable).
If an engineer says it will take two weeks - I push for a range or a confidence. If the range is weird (2-8 weeks), I push for the engineer to tighten their estimate through discussing or raising and discovering the unknowns or the risks that they are aware off. That sort of estimate would usually end up around 3-5 weeks which is a reasonable margin - and a lot better than than underestimating by 50%.
Same with estimates that are too narrow. "2 weeks +/- day". That implies a full level of understanding, no risk and no dependencies. Almost never happens. Work through the same risks/unknowns and the estimates usually become really bad - typically at least double of the "high confidence" estimate - similar to TFA.
The is lots of reasonably applicable theory behind this (confidence intervals, cone of uncertainty, etc).
What happened to me..
My wife is now a fully-fledged closet-trekkie and general sci-fi junkie...
As she is less of a night owl, but would fall asleep on the couch, I would turn on the TV show as she fell asleep. The voices, music and so on become familiar over a week or so. Then occasionally disturb her to wake her up.
Eventually, you can try to watch one with her one night. The familiarity gap won't be there, so she'll probably enjoy it.
Be careful though, my wife ended up becoming more hooked than I was which meant that she watch more of the shows in order than I did, so I'm the one ultimately with gaps in the series. It's worked with ST:TNG, DS9, BG:Reimagined SG:Atlantis, SG-1 and SG:Universe and Firefly. Ultimately I don't have to fight on Sci-Fi anymore, but our bar is pretty high.
Okay. It's clear you haven't looked into the Phoronix Test Suite. (PTS)
The software product itself is a Test Execution Environment. The suite's value add is that it simplifies the download and execution of the actual tests and benchmarks that are executed. Those test or benchmarks are in whatever language the author of that test profile wanted to write it in.
PHP is not involved in any actual _measuring_ of performance, but is involved in the orchestration, interpretation and aggregation of the results.
Check out the version of PTS in your local convenient distribution (it's in most of the recent ones).
Feel free to contact me (I'm not posting an email address here), but it shouldn't be difficult for you to find me (visit Phoronix-Test-Suite.com or openBenchmarking.org). I'm more than happy to explore your experience and look how it can be made.
PHP has allowed Phoronix Test suite to support everything from embedded ARM systems to cloud compute infrastructure. The fact it uses PHP makes it extremely portable. Virtually anywhere that there is a compiler and PHP, Phoronix Test Suite can run. Note that the benchmarking itself is not in PHP, it's done in whatever native language the benchmark needs.
How do you know that running on an AMD doesn't affect one kernel version more than another vs Intel. The same argument stands. It's a machine layer for running code.
Sure, it's not what you want, but don't consider it completely invalid. There are many people who have interest in virtualized performance.
At the last companies I have worked at, the modern hardware doesn't run the old version of Red Hat. The result is that they run RH or other legacy versions of Linux are easier to deal with a consistent and simple hardware abstraction provided by a VM. I haven't seen a bare metal deployment of anything older RHEL 5 for a while (either that or the system it's running on is on life support).
I agree about embedded devices having older kernels - I'm regularly involved in "shiny and new" vs "old and known" discussions. Of course we're talking about PC class hardware that EOLs faster than the software. Again, my comments are focused on the enterprise use of older kernels which is a sensible interpretation of the article.
This made me laugh - in a good way, not at you :).
When Phoronix does a distro-comparison the crowd calls out that the tests are only really testing gcc differences, and should have less variables changing. When Phoronix does a fixed comparison varying only one part of the system, the crowd calls out that it isn't a good basis since people don't run it that way.
Phoronix runs tests in different ways to explore the performance landscape. For some it precisely gives the information that they need, for other it's completely irrelevant. In this particular case, I'm glad that the data gave you enough to have some open questions about 2.6.32 vs 2.6.37. If people walk away with those sorts of first order interpretation, the article served it's purpose.
Of course the next step would be how do we take a tighter look at the delta between 2.6.32 and 2.6.37 - any thoughts?
Regarding meaningful vs meaningless tests. The tests Phoronix runs are a collection of tests to explore. The tests were run, and for some of them, the results yielded nothing interesting but were still reported. You don't know until you run the tests, and if the tests are run, you report on them. Some tests may be stable now, but may have sensitivity to other parts of the systems. Even CPU bound tests will yield different results in different cases (scheduler, etc).
The "get to statistical variance" has been in Phoronix Test Suite for the better part of a year.
As part of the new work happening with Phoronix Test Suite, and the online aggregation site OpenBenchmarking.org, we'll be looking to expose the raw data and allow people to view a particular set of results in a possible more meaningful way. What is being examined now is raw data (scatter diagram), box plot (percentiles), violin plots (kernel function based), full standard error reporting (error bars, numerical reference to SD and SE.
Of course the general articles just show a simple form.
Obviously, infinite time and infinite runs with a broad variance of hardware would be better. As per usual, contact us at Phoronix with a fully baked suggestion for improvements in Phoronix Test Suite or a benchmark suggestion or article suggestion and we are more than willing to consider it.