Interesting, I'm in the Explorers program but haven't gotten that email yet.

Surprised they even bothered to send that to you.

I agree with most of your assessment, except they've done even worse as far as iOS integration with Android Wear, and to be honest, I believe many of the iPhone integration issues were iOS limitations, not choices Google made. iOS has always been shit for "nonstandard" Bluetooth devices - for example, most Bluetooth OBD adapters don't work with iOS since iOS doesn't support Bluetooth SPP (Serial Port Profile) devices as far as I can tell. Only OBD adapters using special BLE-based protocols or acting as a Wifi AP work with iOS.

The battery life started as "OK but could use some improvement" until they deployed KitKat to Glass, which pretty much ruined Glass. XE19 made it suck less than XE16-XE18, but it was still never as good as XE12 in terms of reliability and battery life. XE21/22 brought back some of the reliability issues and made battery life even worse than XE16.

I haven't worn my device in 2+ months. Basically, it's been useless due to the battery life since XE21/22.

The current Glass XE hardware had potential, before they deployed KitKat on it and killed its battery life.

The hardware would've been great if refreshed with a more suitable CPU such as a Snapdragon 400 (The Cortex-A7 is a highly power efficient CPU, which is why most Snapdragon 400-based phones get great battery life, and in fact it has been used by all Android Wear devices except the Moto 360, which gets panned for poor battery life even after Moto made great improvements in that regard, it's still poor compared to other Android Wear devices).

But it appears that Google is moving Glass towards a design dependent on an external (belt-worn) battery pack, since some of their patent filings are clearly missing the battery and their announced partnership with Intel whose mobile chipsets are NOT suitable to a device like Glass unless it's externally powered.

All evidence from Google over the past few months (the Glass for Work initiative, their filing of design patents for Glass that are clearly dependent on an external power source such as a belt-worn battery pack, their partnership with Intel whose chipsets are not suitable to any form of Glass that does not depend on an external battery pack - note that Intel chips are suitable only to tablets/Chrombooks due to their excessively high power consumption) is that Google is targeting industrial/business uses.

They have done nothing to address Glass' biggest flaw as a consumer device - battery life/power consumption.

Same reason I went with Z-Wave.

In theory, ZigBee is a more "open" standard, but... It's too open. ZigBee HA has pretty much no interoperability guarantees.

For example, ZigBee Lighting Link (ZLL) is standardized - but there are lots of examples of ZLL devices that won't talk to each other. Hue hubs won't talk to Greenwave bulbs, Greenwave hubs won't talk to Hue bulbs, despite all devices being ZLL certified devices.

Note that Vera has a fairly robust plugin mechanism, so it's possible to add support for stuff not built in using either USB devices or network connections. Vera can't talk directly to any of the ZLL bulbs mentioned above, but there are Hue and Greenwave/TCP Lighting (horrible name to have your lighting company share an acronym with a widespread transport protocol...) plugins that will talk to the hubs to command the bulbs.

I can click one button on my phone and have:
1) My thermostat (Z-Wave) temperature setting change
2) A bunch of Z-Wave lights turn on at various brightnesses
3) My Hue bulbs change brightness and color
4) My Greenwave bulbs turn on/off at various brightnesses

Yeah. Also, unfortunately, "reprocessing" gets a bad rap due to PUREX which, while better than no reprocessing at all from a waste perspective, is still pretty bad.

The pyroprocessing process used as part of the IFR design had great potential - there was a good chance that it would have been able to fuel the USA for 1-2 centuries using only the existing LWR reactor waste stockpiles. The waste from the IFR would be incredibly dangerous - but only for 100-200 years and MUCH lower in volume compared to the amount of energy extracted than current LWR waste. (Which is something like 90-95% usable fuel still...) Such waste could be much more easily diluted using vitrification for storage on the order of 100-200 years.

At this point, Insteon's cost isn't much lower than Z-Wave which is much more flexible/modern.

I personally have a Vera Lite - it's a great device with built-in Z-Wave, but for the "hacker enthusiast" types, a group of people has created an alternative ecosystem of devices that use nRF24L01 radios for communications to do whatever you want.

For the price they'll spend on an ultra-high-end laptop (I'm guessing stuff that meets their requirements will be in the $2000-3000+ range), you can get a mid-low range desktop that still blows it away in performance AND a midrange laptop you can remote into the beast with.

I stopped buying high-end laptops long ago. I do a lot of Android platform development in my spare time - most of the time I do it on a Chromebook running Crouton, remoted into a quad-Haswell i5 buildbox with 16GB RAM and multiple 256GB SSDs. (Actually, I ran out of space, so I'm putting in a 480, retiring one of the 256s or expanding the ccache size.) (Note, by "remote" I mean "across the room" - the assumption is that laptop and desktop are on the same LAN. I intentionally made my buildbox small in order to make it easy to lug around for car trips. I didn't get it small enough to suitcase in checked baggage, should've gone mini-ITX for that.)

The initial investment (single SSD) for the buildbox was $600-700, and that was around a year and a half ago.

A Dell Precision M2800 that barely matches what the buildbox is capable of (actually, it's significantly less capable CPU-wise due to thermal limits, 2.9 GHz nominal instead of 3.4 GHz nominal, for sustained loads turbo is useless.) costs $1799

Note that the assumption here, based on what the OP has described, is that the system will primarily be used for CPU/RAM-bound tasks, not GPU-bound.

I think this is why many open source projects use IRC for communication, and good ones usually discourage people from taking things to PM.

Even if it doesn't directly pertain to someone immediately, someone will often think, "oh, I remember X and Y talking about this a few weeks ago" - at least for OSS projects, IRC replaces the "office chat"

Everything about the attack has seemed to be inconsistent with North Korea's tendency towards propaganda.

It just seems... odd... that the attackers behaved consistently like disgruntled employees/ex-employees.

Then Sony started talking about North Korea for whatever reason, and I think the attackers saw that and ran with it, thinking it was a great way to send Sony on a wilde goose chase. Heck, they might have intentionally left evidence pointing towards North Korea from the beginning (I suspect the various tools that the FBI thinks imply NK have already been traded around via underground methods and are in the possession of people other than their original creators/users...). Once there was public talk of NK, I think the attackers just decided it would be effective to screw with Sony regarding "The Interview". It's probably nothing to do with any moral objections to the movie - but it's a great way to cause a major financial loss for Sony and make them think someone else is responsible.

In fact, I believe this is one of the oldest touchscreen technologies in existence...

Also note, one of the reasons the project got canned was supposedly its inadequacy at friend vs. foe identification.

Privacy advocates are freaking out about a system that apparently can't even reliably tell the difference between "friendly" and "hostile" let alone "that vehicle belongs to John Doe! FOLLOW IT!!!!"

Also, tracking ground targets over terrain (land) is likely feasible at FAR shorter ranges than the 340 miles given in the article.

Yeah, I'm fairly certain APG's airspace is ALREADY restricted.

Hardkernel used to be one of the #1 purveyors of Samsung Exynos development boards (The other being Insignal). Unfortunately, both Insignal and Hardkernel's BSPs for Exynos boards tended to be vastly outdated. (Hardkernel was even violating the GPL with some of their Android 4.2 releases for some of the Exynos 4412 boards for a while - putting up binary images with no source code in sight.)

Now even Hardkernel is putting effort into non-Haxxinos boards...

You are wrong.

One word: Chromebook

Yes. A proper root cause analysis is important here.

Is electronics the actual root cause? I suspect not. Most of the issues the OP describes are pretty typical examples of stress/burnout.