Some practically undiscovered tribes in the Amazon jungle don't speak Portuguese...
Granted, the numbers are too small to really matter, but still.

Actually it's slightly more interesting than that, and even more rewarding, when you realize that the Cyrillic alphabet has direct roots in the Greek alphabet. (The Latin alphabet used by Western European languages also has its roots in Greek, but slightly farther).

How is this relevant? Let me give you two examples that you are already familiar with:

The letter that looks exactly like a p actually derives from the Greek letter rho. Thus, it has an R sound.

The letter that looks like a cross between a lowercase N and Greek letter pi is pronounced like a P because... ah, I guess I already gave that one away.

Other examples include a letter that looks like phi and sounds like and F, an uppercase gamma that sounds like G, a deformed upper-case delta that sounds like D, an uppercase upsilon that sounds like U, and of course the descendants of alpha, beta, epsilon, kappa, mu, tau, and others that look (and sound) almost the same in Russian and in English.

So... 68.3% of smartphones run some version of Android, while 18.8% run iOS. So Android phones outnumber iPhones at a ratio of 3.6. Cool.

But on the other hand, web traffic from handheld devices (in mainstream sites, not niche sites like Slashdot) stays pretty much stable at around 67% for iOS and 33% Android. So it would seem like iOS users browse 7.2 times as much as Android users (note this includes tablets).

Do iPad owners browse at such a pace as to skew the results by so much?

Note I'm not saying either of the studies is flawed. I'm just pointing out an apparent contradiction that I find rather puzzling.

Actually, a good chunk of those funny blunders falls into the third of these categories of problems with Apple's iOS 6 Maps:

1. 1. Functionality that was there in the old (Google Maps-based) version, and that was lost in the new one.
2. 2. Errors due to outdated or incomplete information, which conduces to bad navigation directions, misplaced locations, and other funny results. (That is, funny if you are not depending on the feature).
3. 3. Errors in rendering of certain features (Hoover Dam, Eiffel Tower) which can be quite hilarious.

The first category includes things like directions for public transportation, pedestrians, and bike trails, as well a more robust search system, but it doesn't produce funny errors, they don't get pointed out very often.

The second category makes a good chunk of the hilarity, but it's something that Apple will (slowly) correct as they refine their databases. Google has many years of headstart here, so it's no wonder their database is in much better shape.

The third category is the one that produces the most hilarious errors but... well, it turns out that it reflects artifacts in the renderings produced by the flyover feature, a feature that AFAIK is not really part of Google Maps, and thus the criticism is rather silly!

Yes, Google has similar flyovers in Google Earth, but that's a separate product. Furthermore, Google Earth is plagued by similar errors in rendering. Examples:
In Google Earth, go to this location in Houston: 29.713347 -95.382174, and follow the bayou (river) as it goes West and South-west towards the Texas Medical Center. See how all those bridges appear to sink to the level of the water? A similar example can be found in Philadelphia: 39.958905 -75.180871.

tl;dr My point is: The 3D rendering errors are funny but not exclusive to Apple. The inaccurate database is easy to fix, but will take time. The missing features are the real problem and we don't know if Apple even intends to add them.

According to the paper (p. 4, emphasis mine):

By the beginning of the 24th month, 50–80% of female animals had developed tumors in all treated groups, with up to 3 tumors per animal, whereas only 30% of controls were affected.

Expanding on my reply to the sibling post of yours:

Of the 87 presumably non-overclocked S III in the list, 43 are quad-cores. Those 43 have an average score of 1739.6 which is clearly higher (8.66%) than the only score known for an iPhone 5, but I wouldn't call that "kicking its ass". (They also have a bizarrely high standard deviation of 213.1).

Still, they are statistically faster on average than the iPhone 5. Too bad that according to the table here in the USA we only get a dual core version (n=10, average=1350.8, stdev=230.22, i.e. slower than the iPhone 5). Thus it seems that the superior speed of the quad-cores S III is only a curiosity for those of us in the USA, which is also the biggest market for the iPhone.

Yes, but by a very small margin:

There are in total 106 entries in that table, 87 are "non-overclocked" and 19 that we believe are "overclocked". The 87 that are no overclocked have an average score of 1612.6, i.e., slightly faster than the iPhone 5, but with a huge standard deviation of 243.6.

Unfortunately we only have one data point for the iPhone 5, which kind of sucks. But based on the information we have it seems that the the speeds of the processors in the iPhone 5 and the non-overclocked S III are statistically the same.

(The average score for the 19 presumed overclocked S III is 1768, which is surprisingly low given the average of the other 87.)

Thanks for the info. I did see that link briefly after I posted as it was linked in another comment, so please allow me to reiterate what I asked over there:

I see a lot of Galaxy S III handsets in that list with processors running at 1,800 MHz, yet everywhere I look for the specifications of the SIII I only find 1.4 and 1.5 GHz. Are those phones overclocked?

If they are overclocked, the relevance of the comparison is greatly diminished. If they are not overclocked, it would be interesting to know in what markets and carriers is Samsung selling S III handsets with those processors.

I see a lot of Galaxy S III there with processors running at 1,800 MHz, yet everywhere I look for the specifications of the SIII I only find 1.4 and 1.5 GHz. Are those phones overclocked?

If they are overclocked, the relevance of the comparison is greatly diminished. If they are not overclocked, it would be interesting to know where Samsung is selling S III handsets with those processors.

Sorry, I can't find the text you mention as "from the linked article". Can you please point out where one of the linked articles says that?

The only thing I could find is this page saying that the A6 running at 1.02 GHz scored 1601, while this chart says that the average Galaxy S3 running at 1400 MHz gets a score of 1560, i.e., the S3 scores slightly lower even though the clock runs 37% faster.

What am I missing?

I can tell you how I have done similar stuff on Mac OS X, using only built-in tools and features and very simple bash scripts. Of course you are using Windows, so you will have to change some of the steps to use the matching Windows tools (like using .bat files instead of bash, etc) and may even need to install some stuff. Even if you don't use it, it may be of interest for other Mac users.

Here it goes:

First, save this very crude bash script into a file (sorry, I'm not a bash programmer):

#!/bin/bash

function navigate_directory {
        cd "$1"
        for anItem in *
        do
                if [ -d "$anItem" ]
                then
                        echo $level$anItem
                        export level=$level"."
                        navigate_directory "$anItem"
                        export level=${level:1:`expr ${#level} - 1`}
                elif [ `mdls -name md5cs -raw "$anItem"` = "(null)" ]
                then
                        #echo \ \ $anItem
                        md5cs=`md5 -q "$anItem"`
                        #echo \ \ \ \ $md5cs
                        xattr -w com.apple.metadata:md5cs $md5cs "$anItem"
                fi
        done
        cd ..
}

crawlDirs=$@;

export level="."
for anItem in "$*"
do
        echo $anItem
        navigate_directory "$anItem"
done

All that script does is crawl through all the directories in the input, and for each file it calculates the MD5 checksum (hint: md5cs=`md5 -q "$anItem"` ). Then it uses xattr to save the MD5 checksum as an extended attribute that can be searched using Spotlight (you would need to use the equivalent search feature in Windows 7).

Because you want it to be searchable through Spotlight the "legal" way to do this is by creating your own little application that "registers" the attribute in the system. But that is waaaaaay too much work for something that you don't plan to use a week from now, so just cheat and register it as an Apple metadata attribute: xattr -w com.apple.metadata:md5cs $md5cs "$anItem"
  (if this makes you uncomfortable you can later delete the attributes using a similar function)

To index everything, run the script from the base directory of your filesystem (not sure how to do that in Windows, you may have to run it on every drive), or just run on the directories that have your files (it's pointless to index the system files). The time it will take depends on the number and size of the files you have. Given your 4.2 million files in 4.9 TB it should take a day or so given your fast hardware.

At this point if you do a Spotlight search for the MD5 checksum of a file you will almost immediately get a list of all its dupes. (If you don't, you may need to rebuild the Spotlight indexes by running mdutil -i on and then off on every drive. I don't think it's necessary but YMMV).

Now copy this other bash script. Note how it is very similar to the above one.

#!/bin/bash

function get_md5_for_file {
        # Return the MD5 checksum of a file, stored in the md5cs
        # extended attribute.
        md5cs=` mdls -raw -name md5cs "$1" `

        if [ $md5cs = "(null)" ]
        then
                # If the attribute hasn't been created, do it now for future queries
                md5cs=` md5 -q "$1" `
                xattr -w com.apple.metadata:md5cs $md5cs "$1"
        fi
        echo $md5cs
}

function navigate_directory {
        cd "$1"
        for anItem in *
        do
                if [ -d "$anItem" ]
                then
                        navigate_directory "$anItem"
                else
                        # If $anItem is a file, get the md5 checksum, search for it
                        # using mdfind, and count the number of hits.
                        md5cs=`get_md5_for_file "$anItem"`
                        numDupes=`mdfind -count "md5cs == '$md5cs'"`
                        if [ $numDupes -gt 1 ]
                        then
                                # The file has at least one dupe.
                                # List them all in the results file.
                                echo $md5cs\ $numDupes\ $anItem >> ~/search_results.txt
                                echo \ `mdfind "md5cs == '$md5cs'"` >> ~/search_results.txt
                        else
                                # This is optional: all non-dupes are listed in the
                                # uniques file.
                                echo $md5cs\ $anItem >> ~/search_uniques.txt
                        fi
                fi
        done
        cd ..
}

if [ $# -eq 1 ] && [ -f "$1" ]
then
        # If the input is a normal file, get its MD5 checksum and launch a
        # Spotlight search for it in a Finder window.
        md5cs=`get_md5_for_file "$1"`
        echo $md5cs | pbcopy

        osascript /path/to/script/start_find.scpt
        pbpaste
        echo "$@"
else
        for anItem in "$@"
        do
                #echo $anItem
                navigate_directory "$anItem"
        done
fi

Sorry for the sparse comments and the crudeness of the code. The second script basically takes the input and (if the input is several files or one or more directories) crawls through it identifying which files have one or more dupes anywhere in the system (not only on the selected dirs), and saves those results in a text file. To use it, you identify a directory (or directories) on which you wish to search for dupes.

It has a bonus: if the input is a single file, it will perform a Spotlight search for its dupes in a Finder window, but for that you need to save this AppleScript (its the start_find.scpt called by osascript above):

tell application "Finder" to activate
tell application "System Events"
        click menu item "New Finder Window" of ((process "Finder")'s (menu bar 1)'s
                (menu bar item "File")'s (menu "File"))
end tell
tell application "System Events"
        click menu item "Find" of ((process "Finder")'s (menu bar 1)'s
                (menu bar item "File")'s (menu "File"))
end tell
tell application "System Events"
        click menu item "Paste" of ((process "Finder")'s (menu bar 1)'s
                (menu bar item "Edit")'s (menu "Edit"))
end tell

Another bonus: you can save the second script as a service made with Automator: remove the #!/bin/bash line, and paste it in a "Run Shell Script" Action (/bin/bash shell), Service receives selected files or folders in Finder.app. Then, you can select the target files/dirs in the Finder and run the service from the contextual menu (right click or control-click).

Caveats:
I have tested this only in Snow Leopard.
MD5 does not guarantee that all hits are really duplicates, so to prevent the very unlikely event of a collision (two files that happen to have the same MD5 in spite of being different) you may want to do additional checks for size, etc, or just verify the supposed dupes manually before nuking them.
And finally, again, this technique uses several Mac OS X exclusive features, you will need to adapt it to your system's matching features.

Until I read your comment I had never tried to go to maps.google.com in Safari on my iPhone. It's quite pointless since there is a native app for that, but still I find funny that I never even tried to do it.

So, I just went there, did a couple of searches including driving directions. Let me tell you that I am very impressed with how well it works, especially since it is very unlikely that Google has invested any significant amount of resources in it (again, because it's pointless since all devices from all major mobile platforms come with a Google Maps app preinstalled).

It is very fast and easy to use. It is also very ugly, but that's easy to fix. I wouldn't use it instead of the native app if it was available, but if a service that I am really interested in performs as good as this web app does I would be OK with it.

It's worse than that, as most reasonable people who are not familiar with the history of Intel processors will believe that x64 is inferior or at least precedes x86, and that's precisely backwards.

I disagree. x64 is a terrible name for the architecture, as it suggests that it is quite inferior to x86, a name normally associated to the 32 bit architecture that preceded it.

With US unemployment at a six month high [...]

The US unemployment in March, April, and May was 8.2, 8.1, and 8.2% respectively. Although that is certainly way too high, is is by far not the highest in the last six months. In fact, it's the lowest since January 2009.

Because those are the cooked U3 numbers that just forget about workers if they've been unemployed long enough. The more realistic - and honest - U6 unemployment rate has never dropped below 14% since Obama took office.

The other fact usually left out of the storyline: anything less than 200,000 new jobs a month is an increase in the unemployment rate - because we need that many new jobs just to keep up with population increases.

Wow, way to absolutely miss the point of my reply to brunes69. According to the site you linked to, the U6 unemployment rate in January 2009 was 14.2%. From February 2009 to Frebruary 2012 it was never bellow 14.9% (in fact it was never bellow 15.1% except in February 2012). In March, April, and May 2012 it was 14.5%, 14.5%, 14.8%.

Therefore, what I said still holds true even if you use the U6 unemployment rate. What did I say? Oh yes: