That would not necessarily work: it would definitely fry the IO front-end but most of the NVRAM matrix would likely remain intact and recoverable by stripping the top encapsulation and top metal layers then scanning the NVRAM cells with a magnetic force microscope.
Also, if the devices self-destructs through high voltage, someone who has already dissected one of these phones before would know where the high-voltage components are, how they operate, how they are triggered and would likely be able to come up with a way to prevent the high voltage pulse from reaching the NVRAM chips such as using a pneumatic framing nailer to destroy/short the high voltage circuitry faster than it can be triggered by tamper sensors.
So, even with physical destruction built-in, you would still need strong device-level encryption as a fail-safe.
The most beautiful thing about having a decryption key embedded in a secure microcontroller managing tamper-proofing sensors (which is itself embedded in the SoC running the rest of the device's functions) is that disabling tamper-proofing is impossible to do without disabling the secure micro-controller and disabling it either physically or by cutting power kills the decryption key just like tripping tamper-proofing sensors would.
You might want to re-check your definition of reckless driving.
By most states' definition, a reckless driver must display *wanton* (violent, intentional and unprovoked) disregard for the public's safety and traffic rules. As long as your electronic-device-using driver sticks to his lane in traffic, maintains safe speed and distances, follows signs, etc. reasonably well, there is no reckless there. Distracted and potentially dangerous, sure. But not reckless.
Weaving through traffic, ignoring speed limits, road signs, tailgating, street racing, etc. are reckless driving - deliberately ignoring safety and putting others at significant risk.
BTW, which one do you think is the most dangerous driver on the road: 1- a lost driver getting flustered from having no clue where he is 2- a lost driver using a GPS to pull a map and directions
From my experiences getting lost both with and without GPS as a backup, I would say having the GPS is safer: yes, the initial setup has potentially higher risk but once that is done, it immediately removes the stress from having no clue where I am and allows me to get off the road much quicker than driving around in a flustered state until I reach a road or highway I'm familiar with, continue on my way from there and hopefully not get lost on my next attempt.
Except many studies have shown that hands-free phone operation is about just as bad as hands-on.
Most of the distraction-based accidents are caused by people picking the wrong time to do something, even simple things like changing radio station, heating/AC settings or checking their speedometer.
Hands-free does not prevent people from letting themselves get distracted by or otherwise focusing their attention on the wrong things at the wrong time. Some people have suggested locking out non-essential controls while vehicles are in movement so drivers have no choice but to focus on the road but going to such an extreme would likely become a grievance for many people and cause its own lot of problems such as passengers being unable to access those controls either.
Ideally, people should be able to gauge circumstances and their own abilities to decide the most appropriate moments to do something safely but most people grossly over-estimate their abilities and the safety margins around them so we end up with stiff restrictions to eliminate most variables.
The simplest way to self-destruct data on the device is to simply encrypt it using a large key stored in CMOS embedded in the SoC's hardware crypto-engine and clear it (either with an actual reset signal or simply killing power) if tampering is detected to instantaneously render all stored data useless. The next time the boot-loader runs if the device is ever powered up again before being restored to factory specs, it can generate a new encryption key and start erasing storage to make the data completely unrecoverable.
I would not be too surprised if they only implemented the device encryption part of this with managed encryption keys so devices can be decrypted if ever recovered.
What about driving at night, or in poor weather, where visibility is significantly reduced and many drivers already travel too fast for the distance ahead they can see clearly? While the speeds and distances involved are obviously much lower, your reasoning about the fighter pilot applies almost verbatim.
While it does apply, the problem is economic feasibility: a typical passenger car does not have the budget for million-dollar sensor and camera arrays with the computational power to put everything together correlated to driver head and eye position to make overlays line up correctly with whatever is outside. You may be able to display some driving assistance data but the HUD won't replace direct sight any time soon. Also keep in mind that the first reason many of those sensors are in airplanes in the first place is to enhance the autopilot's accuracy and reliability. Cars do not have auto-pilot yet.
Also, when driving a car, you sometimes have only centimeters of clearance so the importance of perfect HUD and real-world alignment is much more critical than planes where clearances usually are in thousands of meters through the bulk of the flight apart from take-off and landing. Planes may typically fly 3-4X as fast as cars drive on highways but most clearances are well over 100X larger, more if you clear things with air traffic controllers along your path. There would be far fewer car accidents if moving cars rarely came within 500m of each other the same way planes usually are 5+km apart unless taxiing, taking off or preparing to land.
Additionally, when a plane's autopilot or other system failure causes the plane to misbehave, pilots usually have several seconds if not minutes to figure it out after they notice something has gone wrong. If a car driver blindly follows the HUD's erroneous instructions (brain off, follow HUD - manual auto-pilot), he might crash into something before realizing something went wrong... exactly like people do today by blindly following their GPS.
By the time car navigation systems become sophisticated enough to correctly model and represent the space around the driver and vehicle to provide genuinely enhanced security through situation awareness, it will likely be cheaper, simpler and safer to simply give cars auto-pilot.
And when you pilot a jet, you are flying practically blind anyway: you can see only a small fraction of the airspace in front of you and need to rely on radar and other instruments for pretty much everything else. At 300+km/h, by the time you see something, it is often too late to do anything about it unless you used your instruments to plan your path accordingly and be near the sweet spot by the time you do get line-of-sight.
Flying with a HUD when direct sight is nearly useless in the first place is intrinsically safer than flying practically blind.
How much piloting do aircraft pilots do? Modern planes can take off, make the trip and land on auto-pilot. The pilots are there mostly for the paperwork, take-off and landing routines and backup for all the fancy automation in case something goes wrong.
For fighter plane pilots, these guys are flying practically blind most of the time and need the HUD overlays to keep tabs on whatever is happening around them since the cockpit window only allows them to see 10-15% of the space around them and they cannot keep track of targets that are 10km away (that's only 30 seconds ahead at Mach 1) by direct sight or things coming in at high speeds: by the time they enter line-of-sight, it is often too late to correct course, aim or evade. So if you are going to do 90+% of your critical flying entirely by instruments because direct sight is nearly useless, the HUD naturally becomes essential.
For everyday driving though, HUDs are not going to provide anywhere near as valuable navigation instruction as direct sight will any time soon under most driving conditions. That said, it can have its uses for reducing the amount of eye travel necessary to keep tabs on simple things that could otherwise become significant distractions such as next turn(s) from the GPS.
Personally, an always-on HUD that displays rarely needed data within my field of view would annoy the heck out of me when my primary driving information source is direct sight. I would much prefer an unobtrusive display near my peripheral vision. IMO, GPS running on Google Glass would be a much smaller distraction than GPS displayed on the middle console where most car manufacturers put it, forcing you not only to take your eyes off the road to look at it but also turn your head and possibly mess around with angles to find one where you can read the screen well enough.
What makes HUDs essential for fighter planes is that most of the information the pilot needs is all over the place and the pilot is flying nearly blind a lot of the time so he needs to rely almost entirely on instrumentation and the HUD allows overlaying maps, IR and radar imagery on top of often nearly useless direct sight to give him the best situation awareness possible.
For HUDs to make everyday driving significantly safer, they would need to be able to do things like highlight road signs, street names, keep track of speed zones, highlight potholes and other road hazards, etc. - all those little things that usually distract drivers while driving in unfamiliar territory or might easily get missed.
Microwaves can be used to heat up almost any material. The specific frequency household microwave ovens operate at is tuned to the resonant frequency of water molecules for maximum efficiency at heating the most common molecule found in food and other molecules that may get excited near that frequency band but other frequencies can be used to heat other stuff.
At 1TW though, things are going to seriously heat up seriously fast regardless of what they are made up and whatever the frequency might be tuned at. Once some of the material gets vaporized into plasma, the plasma will absorb tons of energy and vaporize whatever lies under it - that's the fundamental principle of how laser cutting works: apply enough heat to instantaneously ionize the surface of whatever you point it at and Bob's your uncle..
Even if the first mile market was fully open, infrastructure is almost always a natural monopoly: the fewer infrastructure providers of a given type there are, the higher the existing providers' network attach rates are and the lower total network maintenance costs per home passed become. That's why even the most "competitive" markets all around the world only have 1-3 wired communication infrastructure providers.
The very high building costs make it impractical for extra players to enter the market, fight to gain an increasingly small chunk of the market and hold on to it long enough to recover the initial costs: if it costs 2G$ to wire a market of 1M potential subscribers, that's 2k$/sub if you had 100% take-up rate but if that market already has two established players, you are going to have a hard time reaching 33% market share and that knocks your expected build cost up to 6k$/sub.
Having only one hypothetical company investing 2G$ to offer services to 100% of the subscribers is a lot more cost-efficient than three companies investing an aggregate total of 6G$ to serve only ~33% of the public each.
Most of the semi-recent gear I remember looking at does IPv6 at wire speed but where it does "come short" is that it only supports 1/4 as many routing table entries for IPv6 as it does for IPv4 since each IPv6 entry consumes four times as much space in the hardware look-up tables. That should not be a problem since the much flatter and much less fragmented address space on IPv6 should require far fewer routing entries in the first place.
As for how many IPs ISP should be required to give out to subscribers, the IPv6 standard calls for subscribers each getting a whole/64 subnet (~1.7e19 addresses) through prefix delegation so the end-users can either run DHCP-PD on their router to manage their public IPv6 space or do a route advertisement across their LAN and let clients pick their own IPv6 suffix using SLAAC.
The cheapest/smallest allocation ARIN gives to ISPs is/40 and even if ISPs served the entire world population with an average of 30 subnets each, they would still have enough address space to afford giving everyone/78s out of that/40 so there is no reason to go any smaller than that on IPv6 even for the greediest ISPs. If your ISP ends up giving you a/121 (128 IPs), it might actually backfire on them due to breaking stuff - that's just not how IPv6 is intended to get deployed and there is absolutely no reason for customer subnets to be anywhere near that small.
Most carrier-grade equipment has a useful service life of 7-8 years and practically all carrier-grade equipment that got on the market in the last 10 years does support IPv6.
At the customer edge of the network, those upgrades are necessary to enable VDSL2 and DOC3. In the network core and backbones, router upgrades are necessary every ~7 years because new router generations have 3-4X the routing capacity per RU and bandwidth per watt as older equipment which is a major saving in floor space, power and cooling bills. Trying to cope with the 40-70%/year traffic growth using hardware from 6+ years ago would be practically impossible.
Until traffic growth collapses, carriers and everyone else involved in large-scale transit does not have a choice to refresh large chunks of their network periodically to accommodate demand.
Ironic how governments' failure to fix patent systems is forcing companies to the point they have to cross-license to reduce patent troll liabilities.
If everyone cross-licenses with almost everyone else, it would end up almost as if patents did not exist beyond the purpose of crediting the initial inventor(s). I imagine this would make the patent trolls' lives much more difficult due to the high probability of similar, related or prerequisite patents in those extended patent pools.
Most LCD displays, even older CCFL-based ones, use less than 50W so there would be no problem powering most of those off the PC's PSUs if LCDs and PCs had such power options. With the USB3/3.1 power spec going up to 5A @ 20V and LED-lit LCDs usually using less than 30W unless either very large or very bright, we might actually see PC-powered 20+" displays in a year or two.
You cannot do black on a reflective or emissive screen without material to absorb light. These reflective screen technologies work by adding light on top of whatever you are already seeing... kind of like an additive alpha overlay where "black" simply means don't add anything to whatever is already there.
There are multiple different types of optical fibers out there and not all of them are suitable for DWDM, polarization and various other schemes... so "greased lightning" fiber does exist if you compare fiber from ~30 years ago with state-of-the-art specialty fiber.
As for fiber not having the same problems as DSL, most of the electromagnetic stuff that applies to DSL also applies to fiber; just on such drastically different scales that they become negligible in most cases.
I wouldn't let the ABS light bother me; I'm used to driving on icy roads without ABS. People just need to remember that if they lock wheels on ice or other surface, they need to release brake pressure until tires start gripping again instead of stomping on the brakes harder. For people who have mastered this reflex, ABS has little benefit other than helping find the grip-slip limit a little faster. Even people who drive with ABS can benefit from mastering this since the less time ABS spends correcting braking pressure due to slip detection (ideally, it should not have to), the more time the tires spend actually gripping... and the more familiar drivers get with driving without triggering ABS, the more likely they are to react properly if they end up driving a vehicle with broken or no ABS... and if the ABS does not need to work as hard as often, its electromechanical components should last longer too.
Basically, for me, ABS is a feature that is there to teach people who are willing to learn how to brake without using it. But for many people, ABS is a feature that simply reduces the skill level required for decent braking.
"Not obvious to practicioners skilled in the art" means that people with adequate knowledge cannot duplicate your results with a trivial amount of work - at least not without getting lucky on a shortcut such as accidental discoveries.
Example of obvious patent (IMO): double data rate - separate logic operating on rising and falling clock edges already existed prior to DDR patents and for most intents and purposes, all DDR does is put both circuits inside a single IOB circuit, which requires close to zero effort aside from tighter timing tolerances but the semiconductor industry has been improving those anyway to increase clock rates so that part of research requirements is covered regardless of DDR.
I only need eye movement to go from corner to corner on my 24" LCD but I usually sit at 30-36" since any closer than that strains my eyes when I have my glasses on.
Peripheral vision is somewhat rubbish for reading or writing: put your mouse pointer in a random location, then focus your eyes on it and try to see how many words around the pointer you are able to read without moving your head or eyes off the mouse pointer... the ability to recognize stuff like letters drops off sharply beyond 10-15 degrees from the focal point. You are still aware of everything in peripheral vision, particularly movement, but will need to move your focal point to whatever drew attention from your peripheral vision to positively identify it if you have doubts about your guess at what it may have been.
As others have said, the biggest benefit to having larger, higher-resolution displays for professionals is to have more information available on-screen instead of having to tab through dozens of open windows to find the one you need every few minutes. That alone saves me several minutes per day and also spares my wrists that much extra tabbing/mousing. Having the specs for a chip I'm trying to interface to a FPGA open on one screen while I write documentation or HDL code on the other screen (or open side by side if I had one higher-res screen) makes me at least 30% more productive for those sorts of tasks than if I had to constantly tab between the two/three.
A PWM should never reach 100% since that means it has run out of headroom to adjust to input voltage fluctuations and therefore cannot regulate output anymore. A plain backlight PWM will be firing at well over 1kHz, far beyond anything the human eye could possibly detect and with LED-based backlights, the PWM's output may very well be filtered to DC current. On a display with Lightboost enabled though, the strobe rate is proportional to vsync and could yield perceivable flicker.
With my camera on 1/800s shutter speed, I'm not managing to capture any signs of flicker on my LED-lit LCD set at 20% brightness, which tells me either the pulse rate is much higher than that (otherwise I would have wild fluctuations in brightness between shots depending on the -1/0/+1 pulses in a given exposure) or the backlight LEDs are receiving filtered output from the PWM. (Most likely both since it is much easier and cheaper to filter higher frequency PWM output and it eliminates the need to shield the LED array for EMI compliance.)
HDL is not that steep of a learning curve for people who have no problem thinking in parallel instead of serial. Personally, I have an easier time writing VHDL code than C/C++ and a large part of this is because writing HDL requires much more clearly defined goals than high-level languages.
The biggest problem with translating C-code to gates is that even if there were "magic compilers" to do this automatically, the number of gates will vary drastically depending on how much loop unrolling, pipelining and other parallelism the algorithm allows, the available gate budget, the actual performance goals, the ASIC process itself with its primitives library, etc. It is extremely unlikely that automatic tools will manage to achieve a good balance between all factors without substantial guidance and if you are going to set compiler hints all over the C-code to tell the HDL translator how you want it to unroll loops and exactly how you want stuff to get pipelined, it may end up cheaper, faster, cleaner and far more efficient to simply ask an HDL programmer to port the algorithm. There is not much point in using a "magic compiler" if you still need HDL/FPGA/ASIC specialists to go through the whole algorithm and re-think it from a hardware point of view to put the relevant hints in the code to assist the compiler in producing at least somewhat sensible code... might as well pay them for a proper port since this is pretty much what those guys need to have in mind to put meaningful hints in the original code.
As you said, it has been the holy grail of some software developers for a while and I have a hard time imagining a successful "magic compiler" any time soon.
Only if your problem is important enough to justify the extra development time and cost.
For very common or urgent problems, there is enough motivation to go all the way to full-custom ASIC which is several times faster and also much cheaper to mass-produce than FPGA. For one-off problems, there may not even be enough budget and development time to accommodate an FPGA-based prototype.
The problem space where FPGAs are an economically viable option is wildly circumstantial.
Programming FPGAs is far more complex than programming GPGPUs and you would need a huge FPGA to match the compute performance available on $500 GPUs today. FPGAs are nice for arbitrary logic such as switch fabric in large routers or massively pipelined computations in software-defined radios but for general-purpose computations, GPGPU is a much cheaper and simpler option that is already available on many modern CPUs and SoCs.
BitCoin has ASIC miners with ~10X the mining power per watt than most programmable alternatives such as GPGPU and FPGA. Anything less efficient than that is or soon will become cost-prohibitive to run.
The newer Bitcoin alternatives use memory-bound algorithms to prevent such a steep mining power escalation since memory capacity and bandwidth scale much more slowly than processing power but much more quickly on costs: with Bitcoin, increasing throughput by 10X simply required 10X the processing power but with the memory-bound alternatives, you also need 10X the RAM and 10X the memory bandwidth.
Slashdot Mirror
That would not necessarily work: it would definitely fry the IO front-end but most of the NVRAM matrix would likely remain intact and recoverable by stripping the top encapsulation and top metal layers then scanning the NVRAM cells with a magnetic force microscope.
Also, if the devices self-destructs through high voltage, someone who has already dissected one of these phones before would know where the high-voltage components are, how they operate, how they are triggered and would likely be able to come up with a way to prevent the high voltage pulse from reaching the NVRAM chips such as using a pneumatic framing nailer to destroy/short the high voltage circuitry faster than it can be triggered by tamper sensors.
So, even with physical destruction built-in, you would still need strong device-level encryption as a fail-safe.
The most beautiful thing about having a decryption key embedded in a secure microcontroller managing tamper-proofing sensors (which is itself embedded in the SoC running the rest of the device's functions) is that disabling tamper-proofing is impossible to do without disabling the secure micro-controller and disabling it either physically or by cutting power kills the decryption key just like tripping tamper-proofing sensors would.
You might want to re-check your definition of reckless driving.
By most states' definition, a reckless driver must display *wanton* (violent, intentional and unprovoked) disregard for the public's safety and traffic rules. As long as your electronic-device-using driver sticks to his lane in traffic, maintains safe speed and distances, follows signs, etc. reasonably well, there is no reckless there. Distracted and potentially dangerous, sure. But not reckless.
Weaving through traffic, ignoring speed limits, road signs, tailgating, street racing, etc. are reckless driving - deliberately ignoring safety and putting others at significant risk.
BTW, which one do you think is the most dangerous driver on the road:
1- a lost driver getting flustered from having no clue where he is
2- a lost driver using a GPS to pull a map and directions
From my experiences getting lost both with and without GPS as a backup, I would say having the GPS is safer: yes, the initial setup has potentially higher risk but once that is done, it immediately removes the stress from having no clue where I am and allows me to get off the road much quicker than driving around in a flustered state until I reach a road or highway I'm familiar with, continue on my way from there and hopefully not get lost on my next attempt.
Except many studies have shown that hands-free phone operation is about just as bad as hands-on.
Most of the distraction-based accidents are caused by people picking the wrong time to do something, even simple things like changing radio station, heating/AC settings or checking their speedometer.
Hands-free does not prevent people from letting themselves get distracted by or otherwise focusing their attention on the wrong things at the wrong time. Some people have suggested locking out non-essential controls while vehicles are in movement so drivers have no choice but to focus on the road but going to such an extreme would likely become a grievance for many people and cause its own lot of problems such as passengers being unable to access those controls either.
Ideally, people should be able to gauge circumstances and their own abilities to decide the most appropriate moments to do something safely but most people grossly over-estimate their abilities and the safety margins around them so we end up with stiff restrictions to eliminate most variables.
The simplest way to self-destruct data on the device is to simply encrypt it using a large key stored in CMOS embedded in the SoC's hardware crypto-engine and clear it (either with an actual reset signal or simply killing power) if tampering is detected to instantaneously render all stored data useless. The next time the boot-loader runs if the device is ever powered up again before being restored to factory specs, it can generate a new encryption key and start erasing storage to make the data completely unrecoverable.
I would not be too surprised if they only implemented the device encryption part of this with managed encryption keys so devices can be decrypted if ever recovered.
What about driving at night, or in poor weather, where visibility is significantly reduced and many drivers already travel too fast for the distance ahead they can see clearly? While the speeds and distances involved are obviously much lower, your reasoning about the fighter pilot applies almost verbatim.
While it does apply, the problem is economic feasibility: a typical passenger car does not have the budget for million-dollar sensor and camera arrays with the computational power to put everything together correlated to driver head and eye position to make overlays line up correctly with whatever is outside. You may be able to display some driving assistance data but the HUD won't replace direct sight any time soon. Also keep in mind that the first reason many of those sensors are in airplanes in the first place is to enhance the autopilot's accuracy and reliability. Cars do not have auto-pilot yet.
Also, when driving a car, you sometimes have only centimeters of clearance so the importance of perfect HUD and real-world alignment is much more critical than planes where clearances usually are in thousands of meters through the bulk of the flight apart from take-off and landing. Planes may typically fly 3-4X as fast as cars drive on highways but most clearances are well over 100X larger, more if you clear things with air traffic controllers along your path. There would be far fewer car accidents if moving cars rarely came within 500m of each other the same way planes usually are 5+km apart unless taxiing, taking off or preparing to land.
Additionally, when a plane's autopilot or other system failure causes the plane to misbehave, pilots usually have several seconds if not minutes to figure it out after they notice something has gone wrong. If a car driver blindly follows the HUD's erroneous instructions (brain off, follow HUD - manual auto-pilot), he might crash into something before realizing something went wrong... exactly like people do today by blindly following their GPS.
By the time car navigation systems become sophisticated enough to correctly model and represent the space around the driver and vehicle to provide genuinely enhanced security through situation awareness, it will likely be cheaper, simpler and safer to simply give cars auto-pilot.
And when you pilot a jet, you are flying practically blind anyway: you can see only a small fraction of the airspace in front of you and need to rely on radar and other instruments for pretty much everything else. At 300+km/h, by the time you see something, it is often too late to do anything about it unless you used your instruments to plan your path accordingly and be near the sweet spot by the time you do get line-of-sight.
Flying with a HUD when direct sight is nearly useless in the first place is intrinsically safer than flying practically blind.
How much piloting do aircraft pilots do? Modern planes can take off, make the trip and land on auto-pilot. The pilots are there mostly for the paperwork, take-off and landing routines and backup for all the fancy automation in case something goes wrong.
For fighter plane pilots, these guys are flying practically blind most of the time and need the HUD overlays to keep tabs on whatever is happening around them since the cockpit window only allows them to see 10-15% of the space around them and they cannot keep track of targets that are 10km away (that's only 30 seconds ahead at Mach 1) by direct sight or things coming in at high speeds: by the time they enter line-of-sight, it is often too late to correct course, aim or evade. So if you are going to do 90+% of your critical flying entirely by instruments because direct sight is nearly useless, the HUD naturally becomes essential.
For everyday driving though, HUDs are not going to provide anywhere near as valuable navigation instruction as direct sight will any time soon under most driving conditions. That said, it can have its uses for reducing the amount of eye travel necessary to keep tabs on simple things that could otherwise become significant distractions such as next turn(s) from the GPS.
Personally, an always-on HUD that displays rarely needed data within my field of view would annoy the heck out of me when my primary driving information source is direct sight. I would much prefer an unobtrusive display near my peripheral vision. IMO, GPS running on Google Glass would be a much smaller distraction than GPS displayed on the middle console where most car manufacturers put it, forcing you not only to take your eyes off the road to look at it but also turn your head and possibly mess around with angles to find one where you can read the screen well enough.
What makes HUDs essential for fighter planes is that most of the information the pilot needs is all over the place and the pilot is flying nearly blind a lot of the time so he needs to rely almost entirely on instrumentation and the HUD allows overlaying maps, IR and radar imagery on top of often nearly useless direct sight to give him the best situation awareness possible.
For HUDs to make everyday driving significantly safer, they would need to be able to do things like highlight road signs, street names, keep track of speed zones, highlight potholes and other road hazards, etc. - all those little things that usually distract drivers while driving in unfamiliar territory or might easily get missed.
Microwaves can be used to heat up almost any material. The specific frequency household microwave ovens operate at is tuned to the resonant frequency of water molecules for maximum efficiency at heating the most common molecule found in food and other molecules that may get excited near that frequency band but other frequencies can be used to heat other stuff.
At 1TW though, things are going to seriously heat up seriously fast regardless of what they are made up and whatever the frequency might be tuned at. Once some of the material gets vaporized into plasma, the plasma will absorb tons of energy and vaporize whatever lies under it - that's the fundamental principle of how laser cutting works: apply enough heat to instantaneously ionize the surface of whatever you point it at and Bob's your uncle..
Imagine how much fun a hacker could have with a couple of 1TW microwave beams!
Even if the first mile market was fully open, infrastructure is almost always a natural monopoly: the fewer infrastructure providers of a given type there are, the higher the existing providers' network attach rates are and the lower total network maintenance costs per home passed become. That's why even the most "competitive" markets all around the world only have 1-3 wired communication infrastructure providers.
The very high building costs make it impractical for extra players to enter the market, fight to gain an increasingly small chunk of the market and hold on to it long enough to recover the initial costs: if it costs 2G$ to wire a market of 1M potential subscribers, that's 2k$/sub if you had 100% take-up rate but if that market already has two established players, you are going to have a hard time reaching 33% market share and that knocks your expected build cost up to 6k$/sub.
Having only one hypothetical company investing 2G$ to offer services to 100% of the subscribers is a lot more cost-efficient than three companies investing an aggregate total of 6G$ to serve only ~33% of the public each.
Most of the semi-recent gear I remember looking at does IPv6 at wire speed but where it does "come short" is that it only supports 1/4 as many routing table entries for IPv6 as it does for IPv4 since each IPv6 entry consumes four times as much space in the hardware look-up tables. That should not be a problem since the much flatter and much less fragmented address space on IPv6 should require far fewer routing entries in the first place.
As for how many IPs ISP should be required to give out to subscribers, the IPv6 standard calls for subscribers each getting a whole /64 subnet (~1.7e19 addresses) through prefix delegation so the end-users can either run DHCP-PD on their router to manage their public IPv6 space or do a route advertisement across their LAN and let clients pick their own IPv6 suffix using SLAAC.
The cheapest/smallest allocation ARIN gives to ISPs is /40 and even if ISPs served the entire world population with an average of 30 subnets each, they would still have enough address space to afford giving everyone /78s out of that /40 so there is no reason to go any smaller than that on IPv6 even for the greediest ISPs. If your ISP ends up giving you a /121 (128 IPs), it might actually backfire on them due to breaking stuff - that's just not how IPv6 is intended to get deployed and there is absolutely no reason for customer subnets to be anywhere near that small.
Most carrier-grade equipment has a useful service life of 7-8 years and practically all carrier-grade equipment that got on the market in the last 10 years does support IPv6.
At the customer edge of the network, those upgrades are necessary to enable VDSL2 and DOC3. In the network core and backbones, router upgrades are necessary every ~7 years because new router generations have 3-4X the routing capacity per RU and bandwidth per watt as older equipment which is a major saving in floor space, power and cooling bills. Trying to cope with the 40-70%/year traffic growth using hardware from 6+ years ago would be practically impossible.
Until traffic growth collapses, carriers and everyone else involved in large-scale transit does not have a choice to refresh large chunks of their network periodically to accommodate demand.
Ironic how governments' failure to fix patent systems is forcing companies to the point they have to cross-license to reduce patent troll liabilities.
If everyone cross-licenses with almost everyone else, it would end up almost as if patents did not exist beyond the purpose of crediting the initial inventor(s). I imagine this would make the patent trolls' lives much more difficult due to the high probability of similar, related or prerequisite patents in those extended patent pools.
Most LCD displays, even older CCFL-based ones, use less than 50W so there would be no problem powering most of those off the PC's PSUs if LCDs and PCs had such power options. With the USB3/3.1 power spec going up to 5A @ 20V and LED-lit LCDs usually using less than 30W unless either very large or very bright, we might actually see PC-powered 20+" displays in a year or two.
You cannot do black on a reflective or emissive screen without material to absorb light. These reflective screen technologies work by adding light on top of whatever you are already seeing... kind of like an additive alpha overlay where "black" simply means don't add anything to whatever is already there.
There are multiple different types of optical fibers out there and not all of them are suitable for DWDM, polarization and various other schemes... so "greased lightning" fiber does exist if you compare fiber from ~30 years ago with state-of-the-art specialty fiber.
As for fiber not having the same problems as DSL, most of the electromagnetic stuff that applies to DSL also applies to fiber; just on such drastically different scales that they become negligible in most cases.
I wouldn't let the ABS light bother me; I'm used to driving on icy roads without ABS. People just need to remember that if they lock wheels on ice or other surface, they need to release brake pressure until tires start gripping again instead of stomping on the brakes harder. For people who have mastered this reflex, ABS has little benefit other than helping find the grip-slip limit a little faster. Even people who drive with ABS can benefit from mastering this since the less time ABS spends correcting braking pressure due to slip detection (ideally, it should not have to), the more time the tires spend actually gripping... and the more familiar drivers get with driving without triggering ABS, the more likely they are to react properly if they end up driving a vehicle with broken or no ABS... and if the ABS does not need to work as hard as often, its electromechanical components should last longer too.
Basically, for me, ABS is a feature that is there to teach people who are willing to learn how to brake without using it. But for many people, ABS is a feature that simply reduces the skill level required for decent braking.
"Not obvious to practicioners skilled in the art" means that people with adequate knowledge cannot duplicate your results with a trivial amount of work - at least not without getting lucky on a shortcut such as accidental discoveries.
Example of obvious patent (IMO): double data rate - separate logic operating on rising and falling clock edges already existed prior to DDR patents and for most intents and purposes, all DDR does is put both circuits inside a single IOB circuit, which requires close to zero effort aside from tighter timing tolerances but the semiconductor industry has been improving those anyway to increase clock rates so that part of research requirements is covered regardless of DDR.
I only need eye movement to go from corner to corner on my 24" LCD but I usually sit at 30-36" since any closer than that strains my eyes when I have my glasses on.
Peripheral vision is somewhat rubbish for reading or writing: put your mouse pointer in a random location, then focus your eyes on it and try to see how many words around the pointer you are able to read without moving your head or eyes off the mouse pointer... the ability to recognize stuff like letters drops off sharply beyond 10-15 degrees from the focal point. You are still aware of everything in peripheral vision, particularly movement, but will need to move your focal point to whatever drew attention from your peripheral vision to positively identify it if you have doubts about your guess at what it may have been.
As others have said, the biggest benefit to having larger, higher-resolution displays for professionals is to have more information available on-screen instead of having to tab through dozens of open windows to find the one you need every few minutes. That alone saves me several minutes per day and also spares my wrists that much extra tabbing/mousing. Having the specs for a chip I'm trying to interface to a FPGA open on one screen while I write documentation or HDL code on the other screen (or open side by side if I had one higher-res screen) makes me at least 30% more productive for those sorts of tasks than if I had to constantly tab between the two/three.
A PWM should never reach 100% since that means it has run out of headroom to adjust to input voltage fluctuations and therefore cannot regulate output anymore. A plain backlight PWM will be firing at well over 1kHz, far beyond anything the human eye could possibly detect and with LED-based backlights, the PWM's output may very well be filtered to DC current. On a display with Lightboost enabled though, the strobe rate is proportional to vsync and could yield perceivable flicker.
With my camera on 1/800s shutter speed, I'm not managing to capture any signs of flicker on my LED-lit LCD set at 20% brightness, which tells me either the pulse rate is much higher than that (otherwise I would have wild fluctuations in brightness between shots depending on the -1/0/+1 pulses in a given exposure) or the backlight LEDs are receiving filtered output from the PWM. (Most likely both since it is much easier and cheaper to filter higher frequency PWM output and it eliminates the need to shield the LED array for EMI compliance.)
HDL is not that steep of a learning curve for people who have no problem thinking in parallel instead of serial. Personally, I have an easier time writing VHDL code than C/C++ and a large part of this is because writing HDL requires much more clearly defined goals than high-level languages.
The biggest problem with translating C-code to gates is that even if there were "magic compilers" to do this automatically, the number of gates will vary drastically depending on how much loop unrolling, pipelining and other parallelism the algorithm allows, the available gate budget, the actual performance goals, the ASIC process itself with its primitives library, etc. It is extremely unlikely that automatic tools will manage to achieve a good balance between all factors without substantial guidance and if you are going to set compiler hints all over the C-code to tell the HDL translator how you want it to unroll loops and exactly how you want stuff to get pipelined, it may end up cheaper, faster, cleaner and far more efficient to simply ask an HDL programmer to port the algorithm. There is not much point in using a "magic compiler" if you still need HDL/FPGA/ASIC specialists to go through the whole algorithm and re-think it from a hardware point of view to put the relevant hints in the code to assist the compiler in producing at least somewhat sensible code... might as well pay them for a proper port since this is pretty much what those guys need to have in mind to put meaningful hints in the original code.
As you said, it has been the holy grail of some software developers for a while and I have a hard time imagining a successful "magic compiler" any time soon.
Only if your problem is important enough to justify the extra development time and cost.
For very common or urgent problems, there is enough motivation to go all the way to full-custom ASIC which is several times faster and also much cheaper to mass-produce than FPGA. For one-off problems, there may not even be enough budget and development time to accommodate an FPGA-based prototype.
The problem space where FPGAs are an economically viable option is wildly circumstantial.
Programming FPGAs is far more complex than programming GPGPUs and you would need a huge FPGA to match the compute performance available on $500 GPUs today. FPGAs are nice for arbitrary logic such as switch fabric in large routers or massively pipelined computations in software-defined radios but for general-purpose computations, GPGPU is a much cheaper and simpler option that is already available on many modern CPUs and SoCs.
BitCoin has ASIC miners with ~10X the mining power per watt than most programmable alternatives such as GPGPU and FPGA. Anything less efficient than that is or soon will become cost-prohibitive to run.
The newer Bitcoin alternatives use memory-bound algorithms to prevent such a steep mining power escalation since memory capacity and bandwidth scale much more slowly than processing power but much more quickly on costs: with Bitcoin, increasing throughput by 10X simply required 10X the processing power but with the memory-bound alternatives, you also need 10X the RAM and 10X the memory bandwidth.