Almost two hundred comments, and not one person has commented (that I saw) about how this might encourage engineers and users to start letting out the magic smoke on purpose.

Or maybe more like this magic smoke is REALLY magic.

Putting the magic in magic smoke.

etc...

* yes, I am quite aware that you are more likely to get cancer from putting your nose close to that super-cap when it blows than getting high, but the comment potential is still 'high'. *rimshot*

Dell was punished for just this (sale to a company who resold to an embargoed country) in the past. I got to watch the videos Dell employees were subjected to (kind of in the 'if you see something, say something' vein) and I wasn't on the business side, I was under the CTO umbrella. I seem to recall the punishment lasted 5 years and was blamed for a significant reduction in growth for those years. While I worked there, some of my interactions with the sales side of the house gave me the chance to watch the due diligence in progress, it seemed in-depth and comprehensive particularly with respect to dealings in the M.E..

If Dell is quickly found to be at fault this time around, it will be interesting to see how it affects the plan to go private. If it takes a while and the plan has already taken place, it could extend the time it takes them to do a new IPO from 3 or 4 years to 8 to never.

D'oh! Thanks!

I thought the .sx address was being blocked by the GFWoC, but apparently the DNS just hasn't propagated, because I can't access the new address from my USA based VPN, either, at this point.

  While trying to retrieve the URL: http://www.piratebay.sx/

The following error was encountered:

        Unable to determine IP address from host name for www.piratebay.sx

The dnsserver returned:

        Server Failure: The name server was unable to process this query.
his means that:

  The cache was not able to resolve the hostname presented in the URL.
  Check if the address is correct.

Your cache administrator is webmaster.
Generated Wed, 01 May 2013 05:48:57 GMT by google.com (squid/2.7.STABLE6)

I forgot how good the original Futurama series was. It's a pity there never were any Futurama movies.

Any game with tea breaks doesn't qualify as a sport.

Furthermore, any game bet played while not-sober shouldn't be in the Olympics (yeah, I am looking at you, curling!).

How could you leave out the gourmet indulgence that is poutine from your list?

'94 Ford Taurus SHO stick, daily driver for about 15 years: I replaced the battery about the middle of every Texas summer- yeah, heat kills, but still, in spite of buying 60+ month batteries. Had a vampirism problem with a faulty alarm that took out two in one year, but other than that, eating batteries was just the price I paid for the enjoyment that car gave me.

Strangely enough, I am using an ACER notebook now that I keep plugged in probably 80% of the time that I use it (and, yes, I know better, I just don't care enough to change). The battery life is down only 20% over when I bought it close to a year ago. I am thinking that the BIOS might be limiting the battery charge to 80% to slow down the destruction of the battery, because I didn't get the expected life out of the battery compared to my previous notebook at the start, but at the one year mark and same usage pattern, this Acer is doing much, much better.

Ah, I thought this was somehow working on living tissue, even after casually examining the Nature abstract.

Since it does require dead tissue, I have an IT admin here with a brain he isn't using that could be donated to help with this research. Really, I insist.

In my building, there are computers running Windows 7 on single core 2.4 GHz Celerons and on-board graphics happily, as long as they have 2 GB of RAM (max the mobos can handle), just with zero eye candy (fine by me). Granted, they aren't computers I would be willing to use on a day-to-day basis, but I have higher expectations. Same computers with only 1 GB (or less, there are some with only 256 MB of RAM) run XP like dogs. Your parents computer can't handle 2 GB of RAM? Are they running a CPU older than a Northwood or AMD equivalent? That is some serious pain there if so.

Sorry for the late reply, but if what you said is really what you believe:

Then the system we have is not fair, even with all those loopholes you referred to. Wealthy people pay far more than non-wealthy (please make sure to go all the way down the page to 'Average Tax Rate By Average Gross Income').

Tax laws are going to change (example proposal), because the govt. beast is insatiable as long as fiscal insanity reigns as it has for many decades, but the problems are a) not taxes as much as spending and b) the income spreads have gotten too great for any tax system to be 'fair' to anyone. Whatever tax system you want to return to (including 0%, at least with respect to income taxes), it would have a far greater chance of success if wage disparities were at a 1960's level instead of the tax system.

Rude of me to reply to myself, but I should have added that when the vector units were added to PowerPC in the mid-late '90s, dst (data stream) instructions had the ability to indicate whether the fetches were transient or not and affect only the L1 if they were. gcc has supported the ability to do this since not long after the MPC7400 was released, IIRC.

You say newer, I was teaching people to use dcbt/icbt in PowerPC (and similar instructions in other architectures) to do that in the 90's (granted, they affected the L2 if one existed, no one had implemented an L3 on-die at that point). I love the instructions, and used the heck out of them when I hand optimized assembly code- not a career choice I would recommend at this point in time, btw. Compilers exist that can make use of them, fortunately, and they do help maintain the performance curve, but they don't break it out to a new level.

Back in 1997, it was determined that ~90% of the benchmarks and customer applications (provided to us for testing purposes, the NDAs were amazing) used on PowerPC were completely dominated by cache misses. That means that if we knew how many times the processor touched a bus (data easily obtained in real time), we could be accurate to within 5% of what the performance would be using a spreadsheet calculation (Thanks, Dr. Jenevein) vs running the apps on a cycle accurate system simulation which could take weeks to develop a meaningful profile. Every time the caches got bigger, the code to solve customer problems would get proportionally bigger. That hadn't changed in 2007 and isn't anticipated to change by 2017. There are edge cases, but until people are satisfied with continuing to play Lode Runner instead of Crysis N, it won't matter for the mass market.

That doesn't mean that CPUs don't need to get bigger/faster, but it does mean that there is a meaningful limit on performance relative to the cache size, the calculation of which is probably left to an exercise for the student in H&P's Computer Architecture.

Right here, just not quite as small.