What surprises me is - this same IMEI blacklist is already in use in the USA. At the very least, AT&T uses it.

Google never released an app. They accidentally left code enabled deep in the frameworks for which user-facing control was never exposed except via third-party modifications.

FYI, this is EXACTLY why the first iteration of privacy controls in CyanogenMod (that which was present in CM7) was removed - too many apps crashed.

The newer PG implementation in CM10.1 was such that permissions would not be denied, but an empty dataset would be returned.

Now the claim made in TFS - "The disappearance of App Ops is alarming news for Android users. The fact that they cannot turn off app permissions is a Stygian hole in the Android security model, and a billion people's data is being sucked through."

Every single permission granted to an app is listed in that app's summary, and ALSO is explicitly listed in such a way that the user must accept the list when installing.

Don't like a permission? Don't install the app.

Yup. As much as you might claim to not mind the weather, unless there is something on your resume that you actually HAVE long-term experience with similar weather, you're in for a rough time.

I know in the past, managers at the location I live in (Southern Tier of New York State) have a strong preference to see that the applicant has spent at least 2-3 winters in the area or an area with similar weather. (e.g. grew up in the area, worked for an extended period of time in the area, or went to a school in upstate New York such as Cornell, Binghamton, RIT, Clarkson, etc.)

Yup. In fact, this accident could be blamed on them.

At least one of the Fukushima reactors was originally scheduled for decommissioning prior to the accident. However, because it's so damn difficult to get new modernized plants with improved safety features built, and the population still needs electricity - the end result is that old clunkers like Fukushima (which consisted of some of the oldest operating reactors on the planet) get service life extensions.

Yup. The reactor sustained no damage from the earthquake itself.

It was the following tsunami they didn't properly plan for.

Also - more modern plants would have weathered this tsunami without problems. Newer plant designs have significantly improved passive safety, rendering the diesel generators (which are safety-critical in older plants) non-safety-critical.

Yeah... This product existed before Glass was even announced I'm fairly certain.

It's also stuck running Froyo...

I've seen this device in person (someone had one at the Big Android BBQ last year) and also now own Glass - it doesn't even remotely compare to Glass.

You didn't RTFA - this new "breakthrough" depends on the availability of brine that is significantly more concentrated than the ocean.

Basically this "breakthrough" provides zero benefit compared to existing technology when used for ocean water.

It requires saline that is MUCH more concentrated than seawater... So you need to somehow concentrate the saltwater before using it.

Although this might allow for some rather unconventional solar power projects - feeding brine from salt concentration ponds might be workable here.

One thing that always leads to confusion is a situation like this - where a developer just disappears without a word.

It's usually considered common courtesy to not fork a project if someone just needs to take a break for a while, or for that person to delegate in their absence.

Here, the person behind the project simply stopped with no warning - and at least for a month or two I'm sure any potential replacements were nervous about stepping on this guy's toes.

The most likely part of a connector to wear out are the springs - which is why in the MicroUSB standard, the springs are in the plug (e.g. the cable) and not the socket.

One issue with this (and many other power meters) is - What is the burden voltage of the ammeter? e.g. how much voltage does it drop.

Meters can often have a burden voltage of 0.1-0.2 volts when measuring currents on the order of an ampere. This might not seem like much, but considering that the original (2012) Nexus 7 drops charge current by approximately 200 mA for every 0.1 volt drop below 5.0 volts - http://forum.xda-developers.com/showthread.php?t=2065404 - 0.2 volts can drop your power by 400 mA (around 2 watts) - Many initial characterizations of Nexus 7 charging severely underreported charging current because the meter's burden voltage caused the device to reduce charging current.

Also, most devices now charge well in excess of 5 watts - so a meter that only shows that you're in the 5-10W range but not where in that range you are isn't very useful.

Last but not least - Forcing a device to pull more than 500 mA from a laptop can damage the laptop. That's a blatent violation of the USB charging standard. Yes, some hosts now support higher charging currents AND the method for reporting this is standardized as part of the USB charging standard - but making a device assume it is always connected to a wall charger could do damage if you connect it to an SDP (Standard Downstream Port) instead of a CDP (Charging Downstream Port).

(Unfortunately, only the very latest devices can successfully detect a CDP...)

Based on that account, the change Tesla SHOULD be making is to be MUCH firmer about the warnings in the case of battery damage. The fire was not in any way sudden - the car was bitching at the driver for *5 minutes* before he pulled over, calmly collected his belongings, and walked away...

(Although, without possibly some extra integrity checking circuitry such as a wire mesh through the battery case, it might not be easy to distinguish battery puncture from other failure modes.)

Yeah. Sometimes projects can wind up in a nightmarish situation in terms of getting new contributors, because the bar to contribution is perceived to be high (even if it might not be).

I used to be a contributor to a fairly large open source project - Overall it was good, but the leads could be downright pricks. They would often trash talk potential contributors, even ones that did show potential. (Sadly, this particular area had a lot of "wannabes" out for glory too...) - While their smacktalk would keep the "wannabes" at bay, it also drove away some exceptional talent.

I was always frustrated by some of these "lone wolf" developers that weren't upstreaming, until myself and a few contributors had a massive disagreement with the project leadership regarding an attempt they made to obtain dual-license commercial rights to a contribution. We started working on founding our own project, and we've found that many of those who I originally (mistakenly) perceived as "lone wolves" and not contributing because something was wrong with them were actually not contributing because there were so many things wrong with our former project and we had been drinking the kool-aid. Quite a few of them have proven to be spectacularly talented and excellent team players.

In addition to this, if you recall some of the recent Lavabit disclosures, we know that large Internet companies have been forced to provide their private SSL certs via secret court orders.

If the NSA/GCHQ have a site's private certs, they can MITM you without you knowing.