Cameras can fail, the communication links between the camera and whatever serves video stream can fail, the displays themselves can fail, power to the displays can fail, etc.

If you do a simple HUD overlaid on top of the conventional glass window, at least you are not completely screwed even if there is a compounded instrumentation failure as long as you can still get visual cues somewhere such as the moon, stars, city lights, runway and slope guidance beacons when landing, etc.

As long as you still have some degree of flight control left, line-of-sight, skills and luck, you can land a plane even with extensive instrumentation failures - there have been many seemingly impossible yet successful landings.

Having cockpit displays/HUDs to aggregate, complement and supplement existing instruments is fine but for completely replacing direct line-of-sight as a backup? I don't think so.

Geoblocking and all the unnecessary middlemen that try to use it to secure their artificial geographic monopolies need to die if they refuse to compete globally.

To be fair to local online vendors though, there would need to be an international standard for sales taxes such as one harmonized rate per country so international vendors would at least not need to deal with the countless regional variants within countries when charging foreign taxes. Another possibility would be to let financial institutions charge domestic taxes on the taxable part of electronic purchases since they are well-versed in the tax codes of whatever regions they do business in so vendors would not need to worry about managing international taxes at all.

If developers do not want to worry about the underlying hardware, all they need to do is stick to Google's developer guidelines and use Java. Let the JRE and native recompiler abstract all the hardware-dependent stuff. Not quite as compute/power-efficient (at least in theory) but from what I have seen, there seems to be tons of developers who waste tons of cycles regardless of portable vs native anyway.

I'm using Classic Shell too and I agree it does fix nearly everything that annoyed me in Win 8.x

Many people on the other hand are still upset (exaggeratedly so IMO) with needing third-party applications to restore classic start menu functionality or are adamantly opposed to any sort of such work-around.

If your "secure" applications run on Linux, Windows or any other major modern OS, that's hundreds of million lines of code that even experienced developers have little to no insight into and many of the security exploits that pop up, Heartbleed being the latest high-profile case, are tied to baked code and libraries that get reused by thousands of developers with implicit trust since almost nobody can afford to re-audit that code for themselves even when they have the expertise to do so.

Even if your application's own code is technically flawlessly secure, there are countless ways the OS, other applications running on the same machine and hardware may be used to undermine your otherwise perfect security.

The problems extend far beyond self-taught programming... and self-taught programmers are not intrinsically bad either.

Systems these days are so hopelessly complex due to running full-blown OSes (mainly Linux derivatives like Android these days) for convenience that guaranteeing security is practically impossible most of the time since nobody ever knows the system inside-out so everyone is relying on everyone else making their own part of the source tree work properly without unforeseen unexpected interactions between software components and also with the hardware.

Most developers and companies do not have the time and resources to go over and get intimately acquainted with every minute detail of their development environment, libraries, OS, etc. to understand the millions of ways things can possibly go wrong assuming they even have access to the source code in the first place. If they had to do that before getting to work on their actual project, most of them would die from old age before doing anything so demanding that degree of understanding is simply not realistic.

The threat of severe legal penalties for things that are often nearly impossible to foresee would make tons of would-be developers give up on the idea - it simply makes no sense.

Gases ionize when hit with atomic decay particles/radiations. A transistor with a high probability of spontaneously turning on in radioactive environments sounds dangerous to me.

Your attempt to confuse here isn't really helpful.

Google does *sell* Google Glass and Nexus phones and tablets and Chromecast and Nest and soon Dropcams and probably more. They are "Google products" branded and sold by Google as theirs.

Mozilla only has one device that it works on directly, the Firefox OS Flame reference phone. The rest of the hardware you see out there is being made and sold by someone else.

And that's not just true of the hardware. Much of the work going on to extend Firefox OS software into areas outside of phones is being done by third parties for their products.

Mozilla doesn't build hardware. We make software, including Firefox OS. Firefox OS is a completely open platform freely available for any company to build on top of without restriction. There are dozens of companies building Firefox OS-based products today and there will be more tomorrow, covering mobile phones, tablets, TVs, set top boxes, game consoles, streaming dongles, wearables, and more. Some of those companies are working directly with Mozilla and others are taking the code and running with it on their own.

DisplayPort did not support 2160p60 out-of-the-box either; it needed v1.2 to get there.

HDMI can do 2160p60 too, just needs v2.0.

Weight measurements are simple: the weight of a non-volatile substance (or volatile substance in a container) does not change with time, temperature or other variables. You have a quantity of whatever, put it on the scale and you are done.

Jewelry is a poor example for W&M policing since jewelry is luxury goods and jewelry is not sold by weight in the first place. Try the retail food and gas industry instead. I do not know how it works in the USA but in Canada, calibration stickers for pumps and balances used for retail must be in plain sight where consumers can easily inspect them and merchants are required to stop using the equipment if their calibration is out of date. No calibration, no sale.

Available bandwidth through a network of networks however is infinitely variable: there is nothing that can be "calibrated" to guarantee any amount of bandwidth along any particular route at any given time since the whole standard internet operates on a "best-effort" basis where "best-effort" actually means no special effort at all - just leave the equipment on and forwarding packets. If you want guaranteed performance between two points across the internet, you need to pay intervening networks for a private virtual circuit of some sort.

If you have 50Mbps over phone lines, you have VDSL2 and VDSL2 remotes typically have at least 20Mbps of available upstream capacity per port so if everyone on the same remote has 50Mbps service, about 40% of people connected to it can simultaneously use their service at full speed before the remote actually becomes a choking point. This part of the service is something the ISP has full direct control and visibility into. Even ancient ADSL1 DSLAMs had the ability to probe lines for service quality monitoring/provisioning purposes, everyone knows performance on xDSL depends on line quality and that part of the service has absolutely nothing to do with network neutrality.

Where things become far less predictable is when the traffic leaves the ISP's middle-mile infrastructure, interconnects with peers and transit providers, internal hops across those external parties the ISP has absolutely no visibility into or power to do anything about, interconnect between those third-parties and others beyond, the far-end interconnects between those third-parties' third-parties, the far-end network, etc.

If you want network neutrality to start defining some degree of end-to-end performance guarantees (unless further limited by technical limitations such as maximum sustainable line sync), the whole internet would be affected; not only the first-mile operators.

Good luck with that.

There are thousands of variables that can affect the bandwidth available between points A and B across the internet, many of which beyond the end-users and the ISPs' control, which makes any sort of bandwidth guarantees with "best-effort" transit impossible to actually guarantee in any remotely meaningful way. Throwing W&M, NIST or whatever else at this is not going to do anyone any good.

If you want everyone's internet service to effectively be covered by an end-to-end bandwidth SLA of some sort, things are likely going to get a fair bit more expensive if the minimum guarantee is to be remotely usable.