I would be happier to learn that I had less choices in browsers. But that is the developer bias. Still, it seems to me that you really have to raise the bar if you want to be taken seriously, not just be Chrome+1. And I'm resistant to features which are tied in to services offered by certain companies (Facebook, Twitter) instead of just standardized services (RSS, FTP).

Larger question... would we not be better served if we started treating the browser more like a commodity item? Basic, standard features in an unglamorous browser, and... that's it. And then with a nice stable development platform that doesn't change around every 2 weeks, the real interesting features can start arriving at the web application layer. Standardize the browsers so we can forget about their individual features.

It seems like a mistake to go to some place and look for the absence of an anomaly. The burden of proof is on the one who makes the claim. You will never prove that ghosts don't exists in a house. Maybe they will be there tomorrow when you aren't around. Maybe you don't have the proper equipment to detect one.

Oh, come on. The point of doing this can only be geek joy. To say that it is a good idea to replace a musician with this is stupid. It's not about technical prowess in the end. The robot is metal (or at least comprised of it, in part). Yet it does not rock.

Uh, go get the open source and build it yourself. Why should Netflix be obliged to implement a Linux port? Not doing something is not the same as preventing it from happening.

The electric utility providers are just positioning themselves in the best possible way when they make press statements like this. They will be happy to supply the needed power and make lots of money from it. But of course, they will go on about the infrastructure investments they'll need to make. Because that makes it easier for them to benefit from government help (deregulation, tax credits, etc) and for specialized services to be sold to EV customers. I'm all for the power companies recouping their costs--I'm just not even slightly worried about them being successful here.

If you scramble the cell frequencies, that effectively means no networking capabilities for in-vehicle systems. These all go over SMS, GPRS, 3G+ packet data, and for really old crap, the voice channel with a wonky modem. So that means...

• No way for the car to report break-ins.
• No OnStar-style accident reports sending an ambulance to pick you up.
• For electric vehicles, no battery-related warnings, i.e. you forgot to plug in your car.
• No traffic data added to your route-finding.
• Lots and lots of other useful things, some of which haven't been invented yet. That driverless vehicle stuff Google's been playing with? Look for it in some other country first.

I respect the paranoia about privacy issues, and to a lesser extent, the concern over safety. But this is a big baby getting thrown out with the bathwater. Cars sold in America will suck.

Have we not yet reached a point where everyone that wants and is infrastructurally able to have access to e-mail, has got it? Are there a bunch of people that Google hasn't reached yet? Better start another GMail invite campaign, I guess.

Note that the operation was shut down and the people involved are likely going to have problems starting up a new scam now that they've got this record. And now that one group of people has been successfully stopped, it should at least push other thieves to think of a slightly different way to screw people over. I wrote a complaint to the FTC about these dicks a year ago when I got my first letter from ILS. I got angry every time I saw a letter from them. They didn't get what they deserved, but this FTC action represents progress.

"That aims to dispel the myth that some languages will guarantee that an application will be more or less secure than other languages."

Whoever said, besides your 16-year-old cousin that just figured out how to add a flaming skull animation to his MySpace page, that there is any web application programming language that will guarantee security. Sheesh.

Hey, freaky, death-threatening Muslims, you've got a lot of work ahead of you...

http://www.google.com/images?q=muhammad

Please catch all of these sucky programmers before they graduate, my company hires them, and I have to work with them. Make them change their majors early to philosophy, animal husbandry, underwater basketweaving, or anything else. Especially, weed out the diligent and responsible types that have no knack for solving technical and logical problems. They can become project managers, which is also a high-paying job.

I remember when programming was a calling, not just a career. Those were better days.

I always thought it was a terrible design to require installation of hardware-specific drivers for a remote printer. You know how you get some crummy nonstandard print status window popping up when you print? Like it will be this hyperbranded thing with a zazzy, colorful diagram of your printer and "buy toner online now" button on it. Almost indistinguishable from a pop-up advertisement except that there is a progress bar showing your print job going through. As far as I can tell, that is the only reason for there to be local drivers for remote printers--so manufacturers can bring up their fancy nonstandard dialogs out of some paranoid necessity to convince you your printer is not a commodity item. In fact, they would probably prefer you called it something other than a "printer", i.e. your "HP-SmartPaperDuplicator TM".

So, yes, this is one thing Google seems to be getting right--a standard print dialog with no local drivers for remote printers.

I would guess that Google shrugs off "Just 21% of Android users purchase one or more paid apps per month, compared with 50% of iPhone users". A lot of the free apps are ad-supported. Google bought AdMob which seems to be the dominant way to deliver ads to Android phone apps. From Google's point of view, having lots of free ad-supported apps is just fine. I agree with O'Neil that the incentives for investing in development for Android are bad now, but that must be more a function of the smaller number of Android devices out there than the Android Market working poorly. More Android phones will get released and there will be more money in the pot for developers.

A more sophisticated search interface to the same selection of Android Market games would be good. I feel like you need one interface for newcomers, (the current one) and another interface for power users, i.e. Let's see all the titles from one publisher or have some tags or subgenres to look through. Still, I have never had much trouble finding anything with keyword searches. So I don't know what all the whining is about.

Hardware compatibility is a BFD, and yeah, it's only going to get worse. Unsophisticated developers will always be inclined to test just on whatever phone they have. And there is no practical way to make Android SDK developer-proof at this point. I don't want the solution to be filter-by-hardware queries on Android Market. It is possible to write one app that runs on all devices, it's just that developers don't write the apps correctly. There might be some automated testing tools that run on the submission side that check for more obvious errors like "Force closes" on hardware X. Maybe also some sort of automated collection of it-works-on-hardware-x votes from users downloading an app will earn an app a certain gold star, which in turn can be used to filter out "doesnt-work" apps from an individual users search results.

But holy jeezus, do not do not do not let the goddamn carriers run the app store. Oh my god, the horrors we have put up with. If BREW were a physical object, I would happily defecate on it.

I agree and would mod you up if I could. Run the same set of tests again but pinch the subject on the arm every 5 seconds. The subjects will be a little agitated and distracted and maybe give similar results.