And, if you're not into the Cyanogen custom experience, or if you have a T-Mobile Vibrant (which will probably never get ICS CyanogenMod support), then check out this project to bring ICS to the Galaxy S series. It's already very stable:
http://code.google.com/p/ice-cream-sandwich-sgs/

I'm not sure why you're not getting modded up. Verizon is as much "Ma Bell" as AT&T is.

http://www.freepress.net/files/att_history.jpg

When I am using the rear facing camera to capture videos of my family or the front facing camera for video conferencing.

Agreed. I drew a similar conclusion:
A typical hypothetical Perl programmer probably has a questions about some Perl libraries from time to time and posts about it. That programmer probably very rarely posts a question about C# or Ruby because that programmer doesn't ever need to touch those languages in his day to day work. That programmer will probably start asking questions about Javascript if he is tasked with writing a web application. I would have expected the same for the declarative languages SQL and CSS - neither of which were in the list probably because they aren't in TIOBE's list.

The conclusion I drew is that web programmers have to program in several languages at the same time (a frequent complaint of the RoR crowd) even if those programmers specialize in a subset of those languages. It's natural that we would see an increase in questions asked about questions outside of that specialized subset but required to get the job done.

Another issue I have with this data is that some languages (particularly dynamic typed languages and functional languages) can often get more done in fewer lines of code - the TIOBE root measurement. So, we expect an under-representation of languages with a lot of boilerplate such as Java. Interestingly, that doesn't seem to be the case.

My final issue is that languages that are on the decline (fewer users new to the language asking questions) or mature languages (many more well answered questions, even before StackOverflow started, already available so no need to ask) should be under-represented. Languages that are on the rise or experiencing a lot of volatility such as Javascript (in both respects) should be over-represented because new users are entering the pool of questions and new functionality needs to be discussed.

You mean like reporting it?

I'm just splitting hairs here, but 2^128 bits... Each of those bits is a boolean - on and off. Each of those locks is nothing more than a light switch. What makes those bits work is that flipping any one doesn't provide the feedback of a further open door. So, it's actually more like a lock on a door with 2^128 light switches that all much be flipped in just the right positions before only ONE door opens.

But, isn't the pattern to the very lock you describe a "secret" or obscure in as much that the lack of knowledge about how to duplicate that key is what keeps intruders out?

Most forms of security rely on some form of obscurity to decide which group of people is allowed access and which group of people is not. A password or a private key, if known to everybody would allow everybody into the system. Only those who hold that extra piece of information are able to access the system through the means by which it was intended to be accessed.

I believe that the point of contention is whether obscuring the system in some way prevents people from entering the system in ways it was NOT intended to be accessed. We could make an argument either way here: Does holding back information on a vulnerability until the vendor has a few days to release a patch first make the system more secure in that period of time? Maybe because fewer people (good and bad) know about this exposed surface. Does keeping ALL of the source code to an application away from open peer review make the system less secure? Mabe, but perhaps the answer depends on if that specific system has more security brain-power put behind breaking into the system or making the system better. There is probably a lot more brain-power behind keeping popular security libraries secure, so open peer-review is surely better. But, I suppose that there exists at least one piece of software with no open source community that if suddenly showed up on github would see the black-hats use it negatively before the white-hats start helping contribute patches.

I work as a software engineer for an affiliate networking advertising company. Our business wouldn't exist if we couldn't track a click from a publisher (affiliate, like a deal blog or a search engine) to an advertiser (merchant, somebody selling stuff). I am extremely familiar with how we handle customer data, and we have no use for it. Our tracking technology aggregates the majority of the information related to sales fairly early on in the data pipeline and discards a lot of it after a relatively short time (hours). We have external and internal auditors that check up on the methods we use to clean personally identifiable information (PII, as they always call it). Even something as relatively benign as our own client's e-mail addresses are secure. When it comes to the likes of our actual advertisements, our company culture is nearing paranoia about NOT storing PII because even an accidental leak would reflect poorly on our clients and be devastating to our business. I really hope the other advertising companies see the risk of collecting this information as expensive as we do and take as much effort to avoid letting it be traceable back to individuals.

I have to say this: the opinions and statements are my own and not those of my company in any way.

Collective bargaining is another word for collusion. The head of lettuce analogy only holds if all of the grocerie stores get together and decide how much lettuce will cost in some dark back room. It's possible, but illegal.

The vast majority of applications you COULD write would work just fine as web applications. If you want to reach the largest audience with the least API-lock-in, think HTML/Javascript. Frameworks like Sancha, Worklight, Sproutcore, Phonegap, Rhodes, and jQueryMobile are providing an extremely good API that allows you to target the web browser so that you not only can have users on iOS and Android, but also Blackberry, Symbian, Windows Mobile, webOS, and any other touch-based web browser.

These frameworks allow you to take advantage of the new features of HTML5 such as local/offline SQLight storage, canvas, drag/drop, OpenGL, etc. The main downsides are that you DON'T get listed in the various markets, you don't have access to many platform-specific features - notifications are still a little tricky, but I'm sure that there will be an open source app to handle web-based notifications in a multi-platform way in the future.

I wish most of the apps in the Android/iOS Markets would just go away and become web sites, because they have no purpose as downloaded apps, including many games.

Before the printing press, the duplication of data was a tedious, expensive and error-prone process. Burning books represented the destruction of knowledge. Countless volumes of data have been lost to all time at the hand of ancient book burnings. Today, we look back on every book burning as an act of ignorance. While I agree with the bulk of the comments that state, "who cares, it's just a book", I still feel upset when I see people exercising their right to destroy their own property (and whatever permanent knowledge it contained) even though I know there are an infinite number of copies of that knowledge now contained in digital media.

I just hope we don't reach a time where the mass-destruction of knowledge becomes possible again.

You're right. Or, as a large corporation, I would have a HUGE incentive to grease whatever wheels I can to make sure that:

1. My technology doesn't become an official open standard but remains an unofficial one.
2. My competitors technology DOES become an open standard to drive him out of business.
3. My technology DOES become an open standard, but some essential tooling to use my technology remains outside the standard and very costly.
4. Some really poor technology becomes the open standard so that I can achieve #1.

The result of a government policy of taking property (even patented inventions) from the ultra successful for the benefit of the common always provides an incentive for the ultra-successful to take it's business elsewhere. This is why countries that frequently practice such a policy of radical socialism or communism tend to grow at a slower pace in the long run than more capitalist oriented countries in terms of GDP, or any useful quality of life measurement.

Any economist I know would tell you that the greatest benefit to the people is to allow the successful to enjoy the fruits of their labour so long as they don't stifle competition more than to allow them to make a modest profit from their hard work. And, the political discussion then can surround what exactly is a "modest profit", and how do we keep from stifling competition "too much". You've stepped outside that argument with complete disregard for the rightful owner of property under the auspices of "the good of the people" which has been shown in the real world, at least until now, to be a failed philosophy due to the fact that determining "the good of the people" never actually happens better by some governing body when a free and open market is available (which isn't always the case: sanctioned monopolies, military, health care, fire/police, etc).

The G1 originally shipped with Android 1.0. It was upgraded to 1.5 which provided for an on-screen keyboard and bluetooth audio, and then to 1.6 with navigation and other useful features.

iPhone OS, on the other hand, is just now getting multitasking, something that has been around since the 1.0 version of Android.

What was once Android playing catchup to iPhone has quickly become iPhone playing catchup to Android, and now that the 3GS is being brought to the level of Android 1.6, then we can't really compare upgrade paths of the two phones in terms of time.

I agree that Javascript is quickly becoming an assembly language. GWT (the tooling Google used to get Quake running in Javascript) is exactly that. Java code is compiled to "native" Javascript.

Although, what you say about browser oddities is largely irrelevant with the usage of toolkits like jQuery, Prototype, Dojo, etc. Instead of targeting the Javascript DOM API, you target your toolkit's API. The DOM API is the part that differs between browsers, except for a few very rare cases. Targeting a toolkit's API is a thinner way to abstract the differences between browsers instead of inheriting the overhead of compiling one language to another before running against a machine. For instance, managing C++ pointers in a language with built in garbage collection is probably not the most performant process.

Additionally, there is a subset of the actual language that some consider the "good part" from which you can also target at the language level. This is a great book about how to do that:
http://oreilly.com/catalog/9780596517748