While I'm unhappy with many aspects of CM - They have never forcefully EOLed a device that was technically capable of running newer versions of Android.

Yes, prior to "inc" everything was volunteer based, and sometimes a volunteer would drop a device. Other devices (such as the original GalaxyS family) are going on forever.

There are only two cases I know of where CM "aggressively" EOLed anything:
1) The announcement that Snapdragon S1 series devices (such as the MSM7227 - NOT the 7227A) would be dropped. This was due to the fact that it was not possible for these devices to run 4.0 and later while still passing Google CTS. One of the rules for CM was "don't break apps" - Now, some CTS violations were just stupid (like anything related to root, or allowing apps to write to external SD) and CM used to let these slide. But if a device had a GPU that had no chance of rendering apps correctly on ICS and beyond - that would get EOLed.
2) EOLing of Nvidia Tegra2 sometime around Android 4.2 or 4.3 - This was because gapps for 4.2 or 4.3 *required* NEON instructions, which Tegra2 lacks

In your case - the problem lies with the fact that you have a shitty carrier that is an MVNO of one of the worst offenders in the business (Verizon) with respect to blocking alternate firmwares of any sort, not with CM. Seriously, if you want a decent Android device, your chances are slim to none on Verizon or any of their MVNOs.

In this specific case - the CM team tried to use the project's Contributor Licensing Agreement (CLA) as an intimidation tactic. (Effectively, saying it allowed them to relicense Focal when, in reality, it didn't.)

In the end, Focal was never relicensed BECAUSE Guillaume chose a license that protected him - BUT there is the fact that they tried to convince him that their CLA would allow them to relicense his code whether he liked it or not.

(Note: Some CLAs, such as Canonical's Harmony CLA, explicitly grant the recipient of a contribution rights to do this. The AOSP CLA, which CM's is a nearly identical copy of, does NOT grant such rights.)

They potentially get shafted - https://plus.google.com/+GuillaumeLesniak/posts/L8FJkrcahPs

One of the new company's first actions as a corporate entity was to try and use the CyanogenMod Contributor License Agreement to relicense a major GPLv3 contribution (a total rewrite of the camera app) AFTER work was completed (even though work was started well after they had formed as a company).

So they are promising that "everything you see now will remain open source" - but actions speak louder than words, and one of their first actions was to seek rights to create a closed-source version of the camera app.

Fortunately, their CLA didn't give them the power they thought it did. They claim the whole thing was just a "misunderstanding" - but if they were unaware that Guillaume wanted to keep the GPL, why were they bringing up the CLA, a document which serves solely to mediate licensing *disputes*?

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...)