It's trivial to produce 2x4s in metric too. You'd just call them 5.08x10.16s and you'd put them 40.64 cm apart on-center when building a wall.
Units are just the language of measurement; it's not that we can't produce things with measurements that form round numbers in metric units, it's that those things are physically different size than things that form round numbers in imperial units, and the cost of converting is non-trivial. If passing a law could make my 1/2" bolt 13mm it would be easy to convert, but as it turns out I'll still have a machine full of 1/2" bolts even if I relabel all my tools as 12.7mm, and I'll still need a separate set of tools to work on a machine full of 13mm bolts.
That's such a lie. Many industries use measurements that are not only non-metric, but industry-specific. They do so because it's convenient in their trade, and they'll continue to do so for the foreseeable future. Those industry-specific measures have SI (and ANSI) equivalents, and those standard units might appear on marketing material for reference by those outside the industry, but there are all sorts of perfectly valid reasons that people use their own local measures and will continue to do so no matter what the "standard" is declared to be.
This applies much more broadly; language, endian-ness, etc. all have local variants, and all have valid reasons for such variation. Standardization is useful but not without cost; it's much more valuable to be comfortable with conversion than to insist that everyone speaks your language.
But that same argument applies in the other direction -- converting to a new system is costly and creates possible points of failure when/if the conversion isn't done correctly.
It's great to say "we should all use the same system" -- there are certainly advantages to standardization. But there are also costs to conversion, and as in most things there are arguments to be made in favor of both system A and system B.
A more balanced approach might be "we should all be comfortable with conversion, and use whatever system suits us best locally", which is exactly the same approach we apply to language, laws, and 1000 other things.
There are a number of solutions available to go from Ethernet (or Bluetooth) to IR. Or if you buy components designed for remote control, you can get Ethernet (and/or serial) ports that allow bi-directional control without any adapter.
There are probably devices with IR transmitters, but if you seriously want to control things you don't mean IR in the first place. Most of the usefulness of having a tablet/phone to control your devices is lost if that controller doesn't know what's happening in the real world -- it's just a giant, hard-to-hold remote with no hard buttons, an over-bright screen, and a form factor poorly suited to the line-of-sight necessary for IR transmission.
High-end users don't do IR control. It's unidirectional, unreliable, requires line-of-sight, etc. There are already a number of more suitable radios available in a typical phone/tablet; most "high-end" equipment has a serial port and/or Ethernet (and sometimes Bluetooth these days) so you can actually communicate with the device and not just blindly send commands toward it. Plus it's trivial to convert from WiFi/Bluetooth/serial/etc. to IR at the destination if there's some component that does not support a more useful interface (which at least eliminates the LoS and reliability issues).
But no matter what the device interface looks like, the real challenge is programming the thing to be useful with the millions of different devices people want to control, without making them learn anything. The value in Harmony isn't the technology in their remotes, it's their huge database of IR codes and their consumer-friendly(ish) programming interface.
Either there's a way to get data in and out of these computers -- and therefore the potential for attack -- or the computers are just sitting their twiddling their thumbs. The idea that somehow disconnecting from the big scary Internet will keep you safe is ridiculous; there have been a number of high-profile attacks that did not require Internet access in recent years, and before Internet access was common most viruses spread via shared physical access, not network access.
The electoral college was created primarily because there's no requirement that states allow their citizens to vote for president. And in fact that was the common case in the early union -- electoral college delegates were often chosen by state legislatures. It wasn't an attempt to redirect power away from the electorate, it was an attempt to redirect power away from the federal government, insofar as states were all free to make their own choices about how to select a president.
Yes. Cell towers are often much easier to use (better building penetration, more visible sources, etc.) and are at least as good a timing source as the average GPS receiver (stationary transmitters at near-field ranges). Even if you don't trust them to have the right time they're highly reliably oscillators; if they weren't it would be impossible to synchronize phones to them.
Or, as I suggested before, you could simply not use the CPU time source as your local NTP clock. There are a whole slew of other oscillators available that work just fine in a VM, for both NTP and kernel timekeeping. Not to mention VMs that will pass through access to a high-precision timing source even if the virtualized tick clock is unreliable. If you need high accuracy (and not just good consistency) you need to know what you're doing, but that's the case with or without a VM -- there really is no good reason an NTP server can't run in a VM even given an unpredictable CPU tick counter.
The same way credit cards are good for "most users" -- for the convenience and security of using a trusted third party as a transaction moderator you pay a little extra for the transaction. You can argue that Apple shouldn't force people into this setup, or that their fees or too high, but it's ridiculous to argue that they add no value.
RFC 2018 is widely adopted -- it's supported in modern linux, Windows, and Mac OS (generally called "SACK" in the TCP tuning parameters) and on by default in all those for a number of years.
RFC 1072 was not implemented mostly because it was never proposed as a standard, just as a basis for further study. And as of RFC 6247 it is now a "historic" RFC.
First, it's dangerous to drive into any obstacle. You do you know that box/balloon/etc. doesn't have a bowling ball in it?
Second, why do you assume the system would be any worse at choosing among the options -- left/right/straight -- than a human would? There aren't a lot of details on this system, but there's no reason to believe it doesn't *also* check beside the car before telling you which way to turn.
Please lay out your mathematical solution to this positioning problem using only 3 birds. Until and unless you can do that you're not going to convince anyone here.
And if you *can* do that it's worth big money, so you should file for a patent immediately.
That's like asking why you drive on roads instead of using an ATV for all your transit needs -- you use a car because it's cheaper, easier, faster and more reliable than the alternatives. Why would you expect agribusiness to do anything different?
It's pretty common to use radio navigation in modern, large-scale agricultural machines. Whether or not it's "required" is a matter of efficiency; they all still have steering wheels, and could in theory be driven manually, but you'd pay for it in more input materials and/or lower yields, so it may not be economically viable (or may drive up food prices if it affected the entire market).
But it's probably also fair to say these same machines could be adapted to other navigation systems without a major redesign. It's possible to build small-scale navigational systems with sufficient accuracy and adapt the computer to deal with the different data set. On the other hand, that change wouldn't be instantaneous, and there would probably be new hardware required both on-board and in the field, so it's not a trivial or quick change.
The problem is the contractor the government hires to do the same work is still subject to the same isolation from market forces -- just because they aren't technically government employees doesn't necessarily make them more efficient. They've been hired to do the same job with the same budget and same expectations -- why would they do anything differently? Sure, the boss might want to skim a little more off the top, but there's no real motivation to change anything.
That's a moderately argument against using only a fingerprint (and there are others, like limited enrollment). But it's not an argument against using a biometrics as part of larger authentication system -- you only need to be able to revoke one of the required tokens to restore the the security of the system.
Biometrics are a useful addition to an authentication system not just for the user/admin benefits (hard to forget, hard to share) because the methods by which they are lost or duplicated are significantly different than the methods by which passwords or external physical tokens are lost or duplicated.
Slashdot Mirror
The inverse square law
It's trivial to produce 2x4s in metric too. You'd just call them 5.08x10.16s and you'd put them 40.64 cm apart on-center when building a wall.
Units are just the language of measurement; it's not that we can't produce things with measurements that form round numbers in metric units, it's that those things are physically different size than things that form round numbers in imperial units, and the cost of converting is non-trivial. If passing a law could make my 1/2" bolt 13mm it would be easy to convert, but as it turns out I'll still have a machine full of 1/2" bolts even if I relabel all my tools as 12.7mm, and I'll still need a separate set of tools to work on a machine full of 13mm bolts.
That's such a lie. Many industries use measurements that are not only non-metric, but industry-specific. They do so because it's convenient in their trade, and they'll continue to do so for the foreseeable future. Those industry-specific measures have SI (and ANSI) equivalents, and those standard units might appear on marketing material for reference by those outside the industry, but there are all sorts of perfectly valid reasons that people use their own local measures and will continue to do so no matter what the "standard" is declared to be.
This applies much more broadly; language, endian-ness, etc. all have local variants, and all have valid reasons for such variation. Standardization is useful but not without cost; it's much more valuable to be comfortable with conversion than to insist that everyone speaks your language.
But that same argument applies in the other direction -- converting to a new system is costly and creates possible points of failure when/if the conversion isn't done correctly.
It's great to say "we should all use the same system" -- there are certainly advantages to standardization. But there are also costs to conversion, and as in most things there are arguments to be made in favor of both system A and system B.
A more balanced approach might be "we should all be comfortable with conversion, and use whatever system suits us best locally", which is exactly the same approach we apply to language, laws, and 1000 other things.
That's a trick question. The temperature in Seattle is always 43F.
There are a number of solutions available to go from Ethernet (or Bluetooth) to IR. Or if you buy components designed for remote control, you can get Ethernet (and/or serial) ports that allow bi-directional control without any adapter.
There are probably devices with IR transmitters, but if you seriously want to control things you don't mean IR in the first place. Most of the usefulness of having a tablet/phone to control your devices is lost if that controller doesn't know what's happening in the real world -- it's just a giant, hard-to-hold remote with no hard buttons, an over-bright screen, and a form factor poorly suited to the line-of-sight necessary for IR transmission.
"Things the mother-in-law can figure out [on a tablet]" is a strict subset of "things the iPad can do".
High-end users don't do IR control. It's unidirectional, unreliable, requires line-of-sight, etc. There are already a number of more suitable radios available in a typical phone/tablet; most "high-end" equipment has a serial port and/or Ethernet (and sometimes Bluetooth these days) so you can actually communicate with the device and not just blindly send commands toward it. Plus it's trivial to convert from WiFi/Bluetooth/serial/etc. to IR at the destination if there's some component that does not support a more useful interface (which at least eliminates the LoS and reliability issues).
But no matter what the device interface looks like, the real challenge is programming the thing to be useful with the millions of different devices people want to control, without making them learn anything. The value in Harmony isn't the technology in their remotes, it's their huge database of IR codes and their consumer-friendly(ish) programming interface.
Exactly. Which is why you can't find RSS, VNC, email, maps or notes apps for iOS.
Either there's a way to get data in and out of these computers -- and therefore the potential for attack -- or the computers are just sitting their twiddling their thumbs. The idea that somehow disconnecting from the big scary Internet will keep you safe is ridiculous; there have been a number of high-profile attacks that did not require Internet access in recent years, and before Internet access was common most viruses spread via shared physical access, not network access.
You could also get a computer (or person) to block ads in a magazine on your behalf, so you never have to see them at all.
The electoral college was created primarily because there's no requirement that states allow their citizens to vote for president. And in fact that was the common case in the early union -- electoral college delegates were often chosen by state legislatures. It wasn't an attempt to redirect power away from the electorate, it was an attempt to redirect power away from the federal government, insofar as states were all free to make their own choices about how to select a president.
Yes. Cell towers are often much easier to use (better building penetration, more visible sources, etc.) and are at least as good a timing source as the average GPS receiver (stationary transmitters at near-field ranges). Even if you don't trust them to have the right time they're highly reliably oscillators; if they weren't it would be impossible to synchronize phones to them.
Or, as I suggested before, you could simply not use the CPU time source as your local NTP clock. There are a whole slew of other oscillators available that work just fine in a VM, for both NTP and kernel timekeeping. Not to mention VMs that will pass through access to a high-precision timing source even if the virtualized tick clock is unreliable. If you need high accuracy (and not just good consistency) you need to know what you're doing, but that's the case with or without a VM -- there really is no good reason an NTP server can't run in a VM even given an unpredictable CPU tick counter.
I think it will be fine, so long as it's not using the CPU for a timing source.
And you know this how? Even if you do actually know they aren't sharing their videos, how do you know that will continue to be true in the future?
The same way credit cards are good for "most users" -- for the convenience and security of using a trusted third party as a transaction moderator you pay a little extra for the transaction. You can argue that Apple shouldn't force people into this setup, or that their fees or too high, but it's ridiculous to argue that they add no value.
RFC 2018 is widely adopted -- it's supported in modern linux, Windows, and Mac OS (generally called "SACK" in the TCP tuning parameters) and on by default in all those for a number of years.
RFC 1072 was not implemented mostly because it was never proposed as a standard, just as a basis for further study. And as of RFC 6247 it is now a "historic" RFC.
First, it's dangerous to drive into any obstacle. You do you know that box/balloon/etc. doesn't have a bowling ball in it?
Second, why do you assume the system would be any worse at choosing among the options -- left/right/straight -- than a human would? There aren't a lot of details on this system, but there's no reason to believe it doesn't *also* check beside the car before telling you which way to turn.
Please lay out your mathematical solution to this positioning problem using only 3 birds. Until and unless you can do that you're not going to convince anyone here.
And if you *can* do that it's worth big money, so you should file for a patent immediately.
It's pretty common to use a localization signal in agricultural radio navigation to provide much greater accuracy than is available over the air.
Because it's free and universally available?
That's like asking why you drive on roads instead of using an ATV for all your transit needs -- you use a car because it's cheaper, easier, faster and more reliable than the alternatives. Why would you expect agribusiness to do anything different?
It's pretty common to use radio navigation in modern, large-scale agricultural machines. Whether or not it's "required" is a matter of efficiency; they all still have steering wheels, and could in theory be driven manually, but you'd pay for it in more input materials and/or lower yields, so it may not be economically viable (or may drive up food prices if it affected the entire market).
But it's probably also fair to say these same machines could be adapted to other navigation systems without a major redesign. It's possible to build small-scale navigational systems with sufficient accuracy and adapt the computer to deal with the different data set. On the other hand, that change wouldn't be instantaneous, and there would probably be new hardware required both on-board and in the field, so it's not a trivial or quick change.
The problem is the contractor the government hires to do the same work is still subject to the same isolation from market forces -- just because they aren't technically government employees doesn't necessarily make them more efficient. They've been hired to do the same job with the same budget and same expectations -- why would they do anything differently? Sure, the boss might want to skim a little more off the top, but there's no real motivation to change anything.
That's a moderately argument against using only a fingerprint (and there are others, like limited enrollment). But it's not an argument against using a biometrics as part of larger authentication system -- you only need to be able to revoke one of the required tokens to restore the the security of the system.
Biometrics are a useful addition to an authentication system not just for the user/admin benefits (hard to forget, hard to share) because the methods by which they are lost or duplicated are significantly different than the methods by which passwords or external physical tokens are lost or duplicated.