Something represented by one unicode codepoint? (making your statement a tautology) Grapheme cluster? (what most users would consider a character) A position in the character grid of a console?
Which brings us to the real question. to what extent do you want to support unicode? do you care about
* Grapheme clusters that take multiple code points to represent? (letters with multiple diacritics, unusual letter/diacritic combinations etc) * Right to left languages? (hebrew, arabic etc) * Languages where chracters merge together such that computer output looks more like handwriting than type? (see above) * Languages where "fixed" width fonts use two different widths giving "single width" and "double width" characters? (chineese, japanese, korean) * Characters outside of the basic multilingual plane? (rare Chinese characters, dead languages, made up languages, rare mathematical symbols)
Once you have worked though that design decision it will help you make others. What you find is that "length in unicode code points" and "unicode code point n" really aren't much more useful than "length in utf-k code units" and "utf-k code point n". Either is fine for sanity checking string length or iterating through a string looking for delimiter. Neither is much use for anything more than unless you are doing a very limited implementation.
UTF-32 seems enticing initially but turns out to be fairly pointless, by the time you get to caring about non-BMP characters you are probably also going to be caring about combining characters etc and it will massively increase the size of the vast majority of text.
UTF-8 vs UTF-16 is something of a tossup. UTF-16 lets you get away with treating each unit of the string as one "character" much longer which may be considered either a blessing (because you don't care about the cases where it doesn't work) or a curse (because you realise your assumptions were wrong much later after basing much more code on them). UTF-8 is smaller for text with lots of latin chracters, UTF-16 is smaller for text with lots of CJK characters. UTF-8 is the usual choice on *nix systems and internet protocols. UTF-16 is the encoding chosen by windows and Java.
1: mechanisms for interoperability were bolted on later, not included as core features that every client and router should support and enable by default. The result is that relays for the transition mechanisms are in seriously short supply on the internet and often cause traffic to be routed significantly out of it's way. 2: the designers were massively anti-nat, as a result we don't have any interoperability mechanisms that go with the flow of NAT, instead we have two incompatible interoperability mechanisms one of which doesn't work with NAT at all and the other of which makes itself unnessaceraly fragile by fighting the NAT rather than going with it. The company behind the latter mechanism also disabled it by default for machines on "managed networks"*, presumablly because they were afraid of annoying corporate network admins. 3: there was lots of dicking around with trying to solve other problems at the same time rather than focusing on the core problem of address shortage. For example for a long time it was not possible to get IPv6 PI space because of pressure from people who wanted to reduce routing table size. Stateless autoconfiguation and the elimination of NAT seemed like good things at the time but they raised privacy issues and added considerable complexity to home/small buisness deployments. 4: there was little incentive to support it and so the time when you can use an IPv6 only system as a general internet client or server without resorting to transition mechanisms seems as far off as ever.
* Defined as any network with something windows thinks is a domain controller.
1: they are explicitly volatile, application developers don't know your usecase and therefore often err on the side of preserving your data over power failures and so use calls like fsync. Even when the app doesn't use fsync the OS will usually try and push the data out to disk reasonablly quickly. If you know you don't care about preserving the data across power cycles and you know you have sufficient ram then a ramdrive can be a much better option. 2: operating systems don't have precognition of what data you will need, when and on what timescales, they can only make educated guesses based on the accesses that have happened recently. If you know you will be accessing a particular set of data a lot and you want those accesses to be low latency then manually bringing it into memory in advance can be a better option than letting the OS fetch each peice as it needs it.
Hence you can have a situation where for things like PCIe and USB the high end stuff is behind.
USB? yes, SATA? yes, PCIe? no.
None of intels chipsets has PCIe 3.0 on the chipset, not even X99. The only PCIe 3.0 lines on intel systems so-far have been those from the processor and the lanes on the processor have been PCIe 3.0 since "sandy bridge e" on the high end and and ivy bridge on the mainstream. So high end got PCIe 3.0 before mainstream did. Furthermore the high end platforms have a lot more PCIe lanes. One lane of 3.0 is equivilent to 2 lanes of 2.0 or 4 lanes of 1.0 so in terms of total PCIe data rate even the venerable X58/ICH10/LGA1366 setup (which offers 36 pcie 2.0 lanes and 6xPCIe 1.0 lanes which adds up to the equivilent of 78 PCIe 1.0 lanes ) is comparable to current upper-mainstream Z97/LGA1150 (which offer 16 PCIe 3.0 lanes and 8 PCIe 2.0 lanes which adds up to the equivilnet of 80 PCIe 1.0 lanes).
If we look back to the transition from PCIe 1.1 to 2.0 then again it seems the high end X38 chipset was the first desktop chipset (not sure about server ones) to feature PCIe 2.0 (note: at that time you could mix and match a high end chipset with a low end CPU or vice-versa) and it had 32 lanes of it which is more than any mainstream chipset ever had.
Another thing to remember is that Intel has not put PCIe 3.0 into their PCH chips yet. So the only PCIe 3.0 lanes are those direct from the processor which are usually used for the big slots intended to take graphics cards. Especially on mainstream (LGA115x) boards.
The approach taken by the http key pinning draft is to require sites using it to have at least one spare key. The spare key can then be used to order a new cert in the event that the main key is compromised.
Of course if you were stupid/careless enough to get your spare key lost or stolen too then you have a problem:(.
The GP post is clearly bullshit, it's in no way in spacex's interests to deliberately kill an astronaut, especially given that the government has multiple contractors working independently on commercial crew transport. However I have a feeling you are being overoptimistic.
overall chance of casualties from launch and landing activities of its Dragon capsule at 30-in-1 million
Yet the actual crew loss rate for manned space vehicles has been in the single digit percentages. The space shuttle has had two crew loss failures and according to wikipedia has had 135 launches putting the credw loss rate at about 1.5%. Apollo had one crew loss incident during launch preperations and had about 17 manned missions (including skylab, appollo-soyuz and the aforementioned failure on the pad) putting the crew loss rate at about 5.9%. Soyuz has had 124 manned launches and has had two crew loss failures putting it's crew loss failure rate at about 1.6%.
Hopefully both failure analysis and our understanding of spaceship components have improved, but i'd still consider a figire two orders of manitude better than previous vehicles hard to belive without substantial data from actual flights.
Soemtimes it works out that way, other times however things do converge, it used to be that every phone vendor needed their own chargers (or at least adaptor cables but even that could be dodgy). Nowadays they all use 5V and most of them use a microUSB connector to deliver it. In the early days of power over ethernet there were serveral competing standards. Nowadays all the major vendors use the IEEE standard. In the early days of computer networks there were many standards, now pretty much everyone uses BASE-T etehrnet with TCP/IP unless they have a very good reason not to.
That works if all you care about but it breaks down as soon as you have to handle future and regularly scheduled events and/or deal with external constraints that are defined in term of local time.
For example suppose you divide the day into shifts, and the shifts are defined in terms of local time (and have been since long before your computer system came along). Once a year you will have a shift that is an hour longer than normal and once a year you will have a shift that is an hour shorter than normal. That means many calculations can no longer assume shifts or "days" (where a "day" is a group of shifts) of constant length.
And then theres the fact you can't reliablly convert future local times to UTC because DST rules are at the whim of the legislature. If your users schedule a meeting at 9am local time in a few months time they will expect it to stay scheduled at that local time even if the government changes the mapping from local time to universal time in the time between the meeeting being scheduled and it happening. Have fun with meetings between users in different jurisdictions.
Personally I suspect that slight variations in the length of a "wallclock second" would be much less disruptive than a special case 22:59:60 time which can't be represented in many time formats and is sufficeiently rare that problems with it's handling are likely to go unnoticed during testing.
Yes a mechanism for adjusting the speed of clocks would be needed, but we already have such mechanisms to deal with the crap tolernaces of most local clocks.
Out of interest are they using DRM to stop people buying the high res release and downconverting it themselves? or are they just relying on people to be too ignorant to realise that is an option?
Given the overall shady nature of the organisations surrounding bitcoin trusting a service to store your bitcoins is folly. So you have to store them yourself.
How you do that is a tradeoff between cost/inconviniance and risk.
The normal method of risk management for those holding large numbers of bitcoins is to have a "hot wallet" and a "cold wallet". The hot wallet is where you keep the bitcoins you need on a day to day basis, you accept that if you get hacked you have a good chance of losing it's contents.
The cold wallet is where you keep the bulk of your bitcoins. You keep the keys to the cold wallet offline and possiblly consider using a secret sharing algorithm with parts of the key distributed between multiple secret locations (e.g. if you use a 2 of 3 secret sharing setup then the comprimise of any one location won't cause loss or compromise of the secret).
The real distinction is "partial coverage" vs "full coverage".
AIUI there have been soloutions that divert the authentication/setup traffic via a US ISP but still allow the bulk traffic to flow directly between the user and the netflix CDN. Presumablly this works because the CDN servers don't re-check the geo blocking. This is much cheaper than diverting everything through a proxy or VPN but also much easier for netflix to stop if they decide to do so.
It probably won't happen unless content owners sue.
Or the contracts come up for renewal and the content owners require netflix to agree to more explicit terms about what exactly they will do to minimise out-of-region users come renewal time.
The "war of the currents" was won by AC because at the time AC voltage conversion (transformer) was much simpler and more effcient than DC voltage conversion (motor-generator set). Efficient voltage conversion is nessacery for large scale electrification to work because without it either end use voltages are too dangerous or resitive lesses are crippling.
However taking a more modern look things are not so clear cut, certainly both DC and AC transmission and distribution systems are now feasible. Each has pros and cons.
Pros for DC 1: pretty much all current flow represents real transfers of power from source to load, unlike in AC systems where reactive and hardmonic currents inevitablly flow due to the characteristics of loads and the inductance and capacitance of cables 2: there is no need to synchronise generators before paralelling them 3: the peak voltage is equal to the rms voltage. Since insulation requirements are generally determined by peak voltage a DC system can operate at a higher RMS voltage for a given insulation thickness/insulator size.
Pros for AC: 1: large installed base of equipment which brings economies of scale and compatibility 2: much less prone to sustaining arcs which makes switches and circuit breakers much cheaper and unplugging stuff without turning off first much safer. 3: while voltage conversion of DC is now possible with reasonablly high efficiency the converters require complex power electronics. I'm sure a DC equivilent of a "pole pig" is feasible but I would expect it to be considerablly more expensive and probablly less reliable.
NetFlix should be able to implement end-to-end security that makes sure the target device belongs to a USA IP address, even when a VPN is deployed.
They can verify that the traffic they receive and send comes from/goes to an IP address that is registered in the US. What a VPN does is allow the device to be moved outside the US while keeping the place it's packets appear on the internet from in the US. The VPN software need not be on the client device itself, it can be on a seperate system that acts as the client devices default gateway if desired/needed. I guess they could try looking at latency and assume anyone with an unexplained high latency was using a VPN but I expect the false positive rate would be unacceptable.
They can mess with the "partial VPN" soloutions (which are popular because they are cheaper and more conviniant than forcing all the traffic through a VPN) and they can block known VPN providers but there isn't a whole lot they can do against a "full traffic" VPN with it's endpoint located on a non-suspiscious US network.
The key to remember which V, I and R you are talking about.
In a DC or single phase AC system* your cable is essentially** a pair of resistors in series with the load. Current through the resistors represending the cable the same as current through the load. Voltage accross the resistors representing the cable is not determined by voltage across the load.
For a given load power higher voltage means lower current which means less resistive loss for a given cable size (or alternatively a smaller cable size for the same loss).
* Things get a little more complex with 3 phase AC but the principles hold. ** Ignoring leakage
For example when a French or Chinese air traffic controller is communicating with an aircraft of their own nationality it must be in English, so that all the traffic which is listening on the same channel knows what is going on.
Do you have a source for that claim? it contradicts wikipedia which claims "Pursuant to requirements of the International Civil Aviation Organization (ICAO), ATC operations are conducted either in the English language or the language used by the station on the ground.[2] In practice, the native language for a region is normally used; however, the English language must be used upon request.[2]" http://en.wikipedia.org/wiki/A...
UTF-16 is a system for "shoehorning" modern unicode into systems designed arround early unicode (e.g. Java, The NT line of windows) in the same way that UTF-8 is a system for "shoehorning" unicode into systems designed around sequences of bytes where values 0-127 are ASCII and values 128-255 are something vendor/locale specific.
The main downside of UTF-16 is because the multi-unit case is much rarer than in UTF-8 bugs regarding it are much less likely to be noticed and dealt with early.
The rarely used meaning relates to the last, with lead meaning a cord used with animals to guide them - but even that definition is a derivative use of the 2nd.
there appears to be a difference between British english and american english here. Here in england we would normally call the thing used to guide/control animals a "lead" (e.g. you will see signs saying "keep your dog on a lead")while americans seem to preffer the term "leash" (at least that is my experiance from watching american shows on animal planet)
We brits also use the term lead to refer to other cords, for example "mains lead" (power cord in american english) or "extension lead" (extension cord in american english)
The problem is to work out average performance you need to know how probable different inputs are. That probability will be very application dependent.
Also people subconsciously process the images from their eyes and this processing can sometimes mislead the conscious brain. In particular we take the 2D images from our eyes and process them into a 3D scene. Unfortunately a 2D image does not directly tell us the size of or distance to an object, merely the angle the object takes up in the view. This angle is roughly proportional to size/distance.
The brain uses several cues to try and resolve this ambiguity. 1: binocular vision, this works great at short distances but it quickly falls off in effectiveness as the distance between the eyes becomes negligable compared to the distance to the object. 2: position in the scene, if the object is on a surface then the brain can use it's mental model of the surface to resolve the distance to the object and hence work out the size. but this doesn't apply to a flying object 3: occlusion, if one object can be seen to be behind another that gives an obvious cue about thier respective distance. Unlikely to apply to flying objects though since the only thing occluded is likely to be clouds and the average person has no mental feel for the distance to those. 4: expected size of the object, this is about the only one left for flying objects.
So if people expect flying saucers to be huge they will see them as huge, even if in reality they are just someone playing a prank with an RC model.
Slashdot Mirror
What does "character" mean?
Something represented by one unicode codepoint? (making your statement a tautology)
Grapheme cluster? (what most users would consider a character)
A position in the character grid of a console?
Which brings us to the real question. to what extent do you want to support unicode? do you care about
* Grapheme clusters that take multiple code points to represent? (letters with multiple diacritics, unusual letter/diacritic combinations etc)
* Right to left languages? (hebrew, arabic etc)
* Languages where chracters merge together such that computer output looks more like handwriting than type? (see above)
* Languages where "fixed" width fonts use two different widths giving "single width" and "double width" characters? (chineese, japanese, korean)
* Characters outside of the basic multilingual plane? (rare Chinese characters, dead languages, made up languages, rare mathematical symbols)
Once you have worked though that design decision it will help you make others. What you find is that "length in unicode code points" and "unicode code point n" really aren't much more useful than "length in utf-k code units" and "utf-k code point n". Either is fine for sanity checking string length or iterating through a string looking for delimiter. Neither is much use for anything more than unless you are doing a very limited implementation.
UTF-32 seems enticing initially but turns out to be fairly pointless, by the time you get to caring about non-BMP characters you are probably also going to be caring about combining characters etc and it will massively increase the size of the vast majority of text.
UTF-8 vs UTF-16 is something of a tossup. UTF-16 lets you get away with treating each unit of the string as one "character" much longer which may be considered either a blessing (because you don't care about the cases where it doesn't work) or a curse (because you realise your assumptions were wrong much later after basing much more code on them). UTF-8 is smaller for text with lots of latin chracters, UTF-16 is smaller for text with lots of CJK characters. UTF-8 is the usual choice on *nix systems and internet protocols. UTF-16 is the encoding chosen by windows and Java.
Theres also providers who will provide you with a fax number that forwards to email.
ways in which IPv6 sucks or sucked.
1: mechanisms for interoperability were bolted on later, not included as core features that every client and router should support and enable by default. The result is that relays for the transition mechanisms are in seriously short supply on the internet and often cause traffic to be routed significantly out of it's way.
2: the designers were massively anti-nat, as a result we don't have any interoperability mechanisms that go with the flow of NAT, instead we have two incompatible interoperability mechanisms one of which doesn't work with NAT at all and the other of which makes itself unnessaceraly fragile by fighting the NAT rather than going with it. The company behind the latter mechanism also disabled it by default for machines on "managed networks"*, presumablly because they were afraid of annoying corporate network admins.
3: there was lots of dicking around with trying to solve other problems at the same time rather than focusing on the core problem of address shortage. For example for a long time it was not possible to get IPv6 PI space because of pressure from people who wanted to reduce routing table size. Stateless autoconfiguation and the elimination of NAT seemed like good things at the time but they raised privacy issues and added considerable complexity to home/small buisness deployments.
4: there was little incentive to support it and so the time when you can use an IPv6 only system as a general internet client or server without resorting to transition mechanisms seems as far off as ever.
* Defined as any network with something windows thinks is a domain controller.
BS.
Ramdrives have several advantages.
1: they are explicitly volatile, application developers don't know your usecase and therefore often err on the side of preserving your data over power failures and so use calls like fsync. Even when the app doesn't use fsync the OS will usually try and push the data out to disk reasonablly quickly. If you know you don't care about preserving the data across power cycles and you know you have sufficient ram then a ramdrive can be a much better option.
2: operating systems don't have precognition of what data you will need, when and on what timescales, they can only make educated guesses based on the accesses that have happened recently. If you know you will be accessing a particular set of data a lot and you want those accesses to be low latency then manually bringing it into memory in advance can be a better option than letting the OS fetch each peice as it needs it.
Hence you can have a situation where for things like PCIe and USB the high end stuff is behind.
USB? yes, SATA? yes, PCIe? no.
None of intels chipsets has PCIe 3.0 on the chipset, not even X99. The only PCIe 3.0 lines on intel systems so-far have been those from the processor and the lanes on the processor have been PCIe 3.0 since "sandy bridge e" on the high end and and ivy bridge on the mainstream. So high end got PCIe 3.0 before mainstream did. Furthermore the high end platforms have a lot more PCIe lanes. One lane of 3.0 is equivilent to 2 lanes of 2.0 or 4 lanes of 1.0 so in terms of total PCIe data rate even the venerable X58/ICH10/LGA1366 setup (which offers 36 pcie 2.0 lanes and 6xPCIe 1.0 lanes which adds up to the equivilent of 78 PCIe 1.0 lanes ) is comparable to current upper-mainstream Z97/LGA1150 (which offer 16 PCIe 3.0 lanes and 8 PCIe 2.0 lanes which adds up to the equivilnet of 80 PCIe 1.0 lanes).
If we look back to the transition from PCIe 1.1 to 2.0 then again it seems the high end X38 chipset was the first desktop chipset (not sure about server ones) to feature PCIe 2.0 (note: at that time you could mix and match a high end chipset with a low end CPU or vice-versa) and it had 32 lanes of it which is more than any mainstream chipset ever had.
Another thing to remember is that Intel has not put PCIe 3.0 into their PCH chips yet. So the only PCIe 3.0 lanes are those direct from the processor which are usually used for the big slots intended to take graphics cards. Especially on mainstream (LGA115x) boards.
The approach taken by the http key pinning draft is to require sites using it to have at least one spare key. The spare key can then be used to order a new cert in the event that the main key is compromised.
Of course if you were stupid/careless enough to get your spare key lost or stolen too then you have a problem :(.
The GP post is clearly bullshit, it's in no way in spacex's interests to deliberately kill an astronaut, especially given that the government has multiple contractors working independently on commercial crew transport. However I have a feeling you are being overoptimistic.
overall chance of casualties from launch and landing activities of its Dragon capsule at 30-in-1 million
NASA management came out with similar figures for the space shuttle. http://sunnyday.mit.edu/accide...
Yet the actual crew loss rate for manned space vehicles has been in the single digit percentages. The space shuttle has had two crew loss failures and according to wikipedia has had 135 launches putting the credw loss rate at about 1.5%. Apollo had one crew loss incident during launch preperations and had about 17 manned missions (including skylab, appollo-soyuz and the aforementioned failure on the pad) putting the crew loss rate at about 5.9%. Soyuz has had 124 manned launches and has had two crew loss failures putting it's crew loss failure rate at about 1.6%.
Hopefully both failure analysis and our understanding of spaceship components have improved, but i'd still consider a figire two orders of manitude better than previous vehicles hard to belive without substantial data from actual flights.
Soemtimes it works out that way, other times however things do converge, it used to be that every phone vendor needed their own chargers (or at least adaptor cables but even that could be dodgy). Nowadays they all use 5V and most of them use a microUSB connector to deliver it. In the early days of power over ethernet there were serveral competing standards. Nowadays all the major vendors use the IEEE standard. In the early days of computer networks there were many standards, now pretty much everyone uses BASE-T etehrnet with TCP/IP unless they have a very good reason not to.
That works if all you care about but it breaks down as soon as you have to handle future and regularly scheduled events and/or deal with external constraints that are defined in term of local time.
For example suppose you divide the day into shifts, and the shifts are defined in terms of local time (and have been since long before your computer system came along). Once a year you will have a shift that is an hour longer than normal and once a year you will have a shift that is an hour shorter than normal. That means many calculations can no longer assume shifts or "days" (where a "day" is a group of shifts) of constant length.
And then theres the fact you can't reliablly convert future local times to UTC because DST rules are at the whim of the legislature. If your users schedule a meeting at 9am local time in a few months time they will expect it to stay scheduled at that local time even if the government changes the mapping from local time to universal time in the time between the meeeting being scheduled and it happening. Have fun with meetings between users in different jurisdictions.
Personally I suspect that slight variations in the length of a "wallclock second" would be much less disruptive than a special case 22:59:60 time which can't be represented in many time formats and is sufficeiently rare that problems with it's handling are likely to go unnoticed during testing.
Yes a mechanism for adjusting the speed of clocks would be needed, but we already have such mechanisms to deal with the crap tolernaces of most local clocks.
Out of interest are they using DRM to stop people buying the high res release and downconverting it themselves? or are they just relying on people to be too ignorant to realise that is an option?
Given the overall shady nature of the organisations surrounding bitcoin trusting a service to store your bitcoins is folly. So you have to store them yourself.
How you do that is a tradeoff between cost/inconviniance and risk.
The normal method of risk management for those holding large numbers of bitcoins is to have a "hot wallet" and a "cold wallet". The hot wallet is where you keep the bitcoins you need on a day to day basis, you accept that if you get hacked you have a good chance of losing it's contents.
The cold wallet is where you keep the bulk of your bitcoins. You keep the keys to the cold wallet offline and possiblly consider using a secret sharing algorithm with parts of the key distributed between multiple secret locations (e.g. if you use a 2 of 3 secret sharing setup then the comprimise of any one location won't cause loss or compromise of the secret).
The real distinction is "partial coverage" vs "full coverage".
AIUI there have been soloutions that divert the authentication/setup traffic via a US ISP but still allow the bulk traffic to flow directly between the user and the netflix CDN. Presumablly this works because the CDN servers don't re-check the geo blocking. This is much cheaper than diverting everything through a proxy or VPN but also much easier for netflix to stop if they decide to do so.
It probably won't happen unless content owners sue.
Or the contracts come up for renewal and the content owners require netflix to agree to more explicit terms about what exactly they will do to minimise out-of-region users come renewal time.
The "war of the currents" was won by AC because at the time AC voltage conversion (transformer) was much simpler and more effcient than DC voltage conversion (motor-generator set). Efficient voltage conversion is nessacery for large scale electrification to work because without it either end use voltages are too dangerous or resitive lesses are crippling.
However taking a more modern look things are not so clear cut, certainly both DC and AC transmission and distribution systems are now feasible. Each has pros and cons.
Pros for DC
1: pretty much all current flow represents real transfers of power from source to load, unlike in AC systems where reactive and hardmonic currents inevitablly flow due to the characteristics of loads and the inductance and capacitance of cables
2: there is no need to synchronise generators before paralelling them
3: the peak voltage is equal to the rms voltage. Since insulation requirements are generally determined by peak voltage a DC system can operate at a higher RMS voltage for a given insulation thickness/insulator size.
Pros for AC:
1: large installed base of equipment which brings economies of scale and compatibility
2: much less prone to sustaining arcs which makes switches and circuit breakers much cheaper and unplugging stuff without turning off first much safer.
3: while voltage conversion of DC is now possible with reasonablly high efficiency the converters require complex power electronics. I'm sure a DC equivilent of a "pole pig" is feasible but I would expect it to be considerablly more expensive and probablly less reliable.
NetFlix should be able to implement end-to-end security that makes sure the target device belongs to a USA IP address, even when a VPN is deployed.
They can verify that the traffic they receive and send comes from/goes to an IP address that is registered in the US. What a VPN does is allow the device to be moved outside the US while keeping the place it's packets appear on the internet from in the US. The VPN software need not be on the client device itself, it can be on a seperate system that acts as the client devices default gateway if desired/needed. I guess they could try looking at latency and assume anyone with an unexplained high latency was using a VPN but I expect the false positive rate would be unacceptable.
They can mess with the "partial VPN" soloutions (which are popular because they are cheaper and more conviniant than forcing all the traffic through a VPN) and they can block known VPN providers but there isn't a whole lot they can do against a "full traffic" VPN with it's endpoint located on a non-suspiscious US network.
The key to remember which V, I and R you are talking about.
In a DC or single phase AC system* your cable is essentially** a pair of resistors in series with the load. Current through the resistors represending the cable the same as current through the load. Voltage accross the resistors representing the cable is not determined by voltage across the load.
For a given load power higher voltage means lower current which means less resistive loss for a given cable size (or alternatively a smaller cable size for the same loss).
* Things get a little more complex with 3 phase AC but the principles hold.
** Ignoring leakage
For example when a French or Chinese air traffic controller is communicating with an aircraft of their own nationality it must be in English, so that all the traffic which is listening on the same channel knows what is going on.
Do you have a source for that claim? it contradicts wikipedia which claims "Pursuant to requirements of the International Civil Aviation Organization (ICAO), ATC operations are conducted either in the English language or the language used by the station on the ground.[2] In practice, the native language for a region is normally used; however, the English language must be used upon request.[2]" http://en.wikipedia.org/wiki/A...
UTF-16 is a system for "shoehorning" modern unicode into systems designed arround early unicode (e.g. Java, The NT line of windows) in the same way that UTF-8 is a system for "shoehorning" unicode into systems designed around sequences of bytes where values 0-127 are ASCII and values 128-255 are something vendor/locale specific.
The main downside of UTF-16 is because the multi-unit case is much rarer than in UTF-8 bugs regarding it are much less likely to be noticed and dealt with early.
The rarely used meaning relates to the last, with lead meaning a cord used with animals to guide them - but even that definition is a derivative use of the 2nd.
there appears to be a difference between British english and american english here. Here in england we would normally call the thing used to guide/control animals a "lead" (e.g. you will see signs saying "keep your dog on a lead")while americans seem to preffer the term "leash" (at least that is my experiance from watching american shows on animal planet)
We brits also use the term lead to refer to other cords, for example "mains lead" (power cord in american english) or "extension lead" (extension cord in american english)
The problem is to work out average performance you need to know how probable different inputs are. That probability will be very application dependent.
What arcitectures have you encountered the problems you describe on?
I think you are forgetting the impact of communications latency.
Also people subconsciously process the images from their eyes and this processing can sometimes mislead the conscious brain. In particular we take the 2D images from our eyes and process them into a 3D scene. Unfortunately a 2D image does not directly tell us the size of or distance to an object, merely the angle the object takes up in the view. This angle is roughly proportional to size/distance.
The brain uses several cues to try and resolve this ambiguity.
1: binocular vision, this works great at short distances but it quickly falls off in effectiveness as the distance between the eyes becomes negligable compared to the distance to the object.
2: position in the scene, if the object is on a surface then the brain can use it's mental model of the surface to resolve the distance to the object and hence work out the size. but this doesn't apply to a flying object
3: occlusion, if one object can be seen to be behind another that gives an obvious cue about thier respective distance. Unlikely to apply to flying objects though since the only thing occluded is likely to be clouds and the average person has no mental feel for the distance to those.
4: expected size of the object, this is about the only one left for flying objects.
So if people expect flying saucers to be huge they will see them as huge, even if in reality they are just someone playing a prank with an RC model.