The US is already on the metric system, it's just that most people never noticed. All packaged goods in the US are labeled in US and metric, our cars support MPH & KPH, our Liquor is is sold in 750ml, 1l and 1.75l bottles. All of our electronic fuel pumps and odometers can be switched between US & metric. Oh, we still use mile markers on the interstate, and we pretend we're still using non-metric measurements of oz, pound, gallon, inch, foot, mile, but in reality, everything is made and sold in metric quantities, and dual labeled with the more familiar measurements.
Most of the country is still in denial about it, and computers have helped keep it relatively hidden, but we're on the metric system whether we realize it or not.
Think these things through before making irrelevant arguments:
1. All it has to do is warn you when you're nearing the edge of the maps you have cached and let the user choose whether or not to download more maps. That leave the user in control of their data usage. 2. If the user is using the maps to navigate while driving, they're using bandwidth to download those maps anyway.
Or, they could just automatically cache the maps within ~ 100mi of your current location, then, if you lose signal, you've still got a useful GPS and maps. Or since they know where you are, and approximately where there is coverage, they could cache a smaller area when you're in an area with good coverage, and cache a larger area when you get to areas with less coverage.
It's a simple concept, when possible, let the computer do the work.
Maybe the phone should do that for you instead of making the user have to set hidden options prior traveling to areas where the map/GPS functionality is most likely to be needed. It works when they're at home, why would they expect it to not work when they go elsewhere, and how would they know to look for the option to archive the maps before leaving?
That analysis doesn't apply because n in this instance is no greater than 2^32 in order to ensure than the ID is no more than 32-bits. That fails to meet the criteria Shamir stated "given, that both p and q are large primes which are being kept secret so that factoring n = p*q is computationally infeasible."
Therefore, 32-bit hashes are not "provably collision resistant". See my post for the actual likelihood of collisions.
Collisions of random numbers with approximately equal distribution across the sample space are variations of the classic "birthday problem". And, with a 32-bit sample space, you have a 50% chance of a collision with slightly fewer than 77,500 entries.
I tried calculating it for a 64-bit hash, but the online calculator I used using was apparently using a linear calculation and didn't validate the input. It timed out after about 15 minutes. Oops, sorry I hammered the server. Maybe next time he'll validate the input and maybe even use a more efficient algorithm.
So, lets just say it'll take ~ (77500^2) *.8 ~ 4.8E9 IDs for a 64-bit hash to have a 50% chance of a collision. Take it up to 80 or more bits and the likelihood of a collision becomes very small even if everyone on the planet has an ID.
They'll have pirated an image of a fake, so clearly LV doesn't have a claim, and WB would be trying to assert IP rights for a fraudulent product. IANAL, but that could create some interesting arguments.
After all, anyone who buys one clearly has more money than sense, and therefore, should be separated from their money. It has been foretold "a fool and his money are soon parted", who are we to interfere with such a prophecy?
Others have pointed out compatibility issues due to differing hardware, different versions of the OS, different UI modules added by manufacturers, poor quality hardware from some manufacturers, inconsistent/poor availability of updates, etc. All of those are valid complaints. But having used an Android phone, here is what I see as the biggest flaw; the UI design is fundamentally inconsistent. It fails to follow many of the user interaction guidelines from the person who is certainly one of the top UI experts, Bruce Tognazzini, aka Tog.
Is it a touch screen system, or a keyboard system? Both, and neither. Almost everything is done using the touch screen, except "back", "menu/settings", and changing apps (plus power and volume controls). You can't complete common tasks using just one or the other, you must use both. Using a separate button to change apps doesn't interfere with normal work flow, as changing apps itself is an interruption in work flow, so it makes some sense. However, having to switch from the touchscreen to the dedicated keys to go back (a critical part of most apps), or to access a menu (e.g. add, delete, edit, change settings, etc.) is an unnecessary, and non-intuitive UI design. It's consistent in that the whole OS and almost all apps use it, but switching between touchscreen and dedicated keys for essential parts of in-app functionality is an interruption in workflow. Everything done in an app should be possible using a single UI model on the touchscreen.
Another annoyance (at least on my phone, don't know about others) is that auto-correct (and automatically adding apostrophes in contractions) only works when using swype. If you want those when typing in text, you must go back after the fact and tap the word to get a list of alternatives. Why would auto-correct only work with one input method? There is no auto-punctuation and it doesn't even offer auto-complete except in the browser.
Syncing my contacts list between the Mac OS X address book, Google contacts and the phone was a challenge. Not all of the blame for that falls on Android, but it took 2 hours to initially sync and eliminate duplicates (there were only 10 contacts in the phone to start with) because contacts and numbers were getting duplicated, and deleting them from one didn't always delete them from another, so next sync they would dup again. Once it's set up, it mostly works, but again, deleting or changing info on one may cause duplication problems next time, so it's an ongoing annoyance. An average user would probably have given up on syncing the contacts, but with 500 contacts, I wasn't going to give up easily.
Individually, these are "little" annoyances and inconsistencies, but they're pervasive and significant enough to harm an otherwise pleasant user experience. Because of these annoyances (and several others) I would much rather have an iPhone.
Yeah, it's not like there's no precedence for this sort of thing.
rant And it's not like there's no precedents on slashdot for misusing precedence. How many times does someone have to point this out before people start using the correct word? /rant
When someone shows it has battery life comparable to the current dual-core ARM A9 SoCs, then they will have something to talk about. Until then, it's just a PR pipedream.
It just makes it harder and more costly for the people who actually need the information for legitimate purposes to get it. The criminals will get it either way.
Can't wait for my new rust based electronics. Of course the 3000f operating temperature and 690k ATM pressures might make them unsuitable for mobile electronics.
Yeah Mozilla. Refusing to remove the add-in was the correct thing to do. Censorship doesn't work, and it must be fought every time some government idiot tries it.
...Mac OSX (only available on Apple hardware, Apple openly sues you for building hackintoshes).
No, Apple sued Psystar for selling hackintoshes in violation of the OS X EULA and a copyright violation. As far as I can tell, Apple hasn't sued anyone for building their own hackintosh.
FF 9 wasn't showing as available earlier, but I just downloaded in and ran Peacekeeper. My testing shows a slight (~3%) decrease in JS performance vs FF8.01. While that's trivial, it's far short of the 20%-30% increase they're claiming.
It's not the rapid release of fixes that's a problem. It's the constantly changing version numbers. Even if the new version would otherwise be compatible, the fact that it's identified as a new version breaks most plug-ins.
And then there is the issue of getting it validated for corporate use, where the testing and approval of a new "version" is far more difficult than getting approval for a minor version (.x) or security update. Chrome suffers from this as well.
Or maybe that's when more newly hired programmers (from last spring's graduating class) are first allowed to put code into the repository (or production).
You're correct, however, there are two charts, the side effects experienced by the group receiving the medication, and the side effects of those receiving a placebo. What's relevant are the ones that differ significantly (positive or negative) in frequency between the groups. That's where you see both the benefits, and the potential side effects.
Run the Peacekeeper benchmark and watch during the Canvas and HTML5 video tests. You'll see that Chrome and Firefox are the only MAJOR browsers that don't suck at video and Canvas. Overall, Opera 11.6 performed well, but video was jerky on all supported codecs. Chrome (16.0.x tested) handled all the codecs correctly, handled the Canvas test correctly, and was fastest overall. FF (8.0.1 tested) handled most of the codecs, handled Canvas correctly, but overall performance was about 1/2 that of Chrome. Safari 5.x on Mac OS 10.6 handles video well, but didn't do well on the current Canvas test and failed to complete the benchmark.
Notes: I tested on WinXP and Mac OS 10.6, therefore, I haven't tried IE9. I did not have Adobe Flash installed, except the built-in Flash in Chrome, so Chrome may (or may not) have had an advantage on the video codecs. Tests were run on 1.86GHz and 2.2GHz Core2 Duo systems with plenty of RAM and decent video controllers (plenty fast enough for video and low/mid range games, but not anything a "gamer" would even consider). YMMV.
With so much video on the internet these days, and especially now that Adobe has finally acknowledged that Flash isn't the future, I believe that the above tests a relevant to the average user. Until Opera addresses the poor video playback issue, no amount of JS performance is going to win them market share. IE9 being Win7 only (Vista doesn't count) puts some limits on it's market for now. So, it comes down to Chrome, Firefox, and Safari. Safari on Windows sucks.
So, the real choice for most users comes down to Chrome vs Firefox, and both are good choices (each with strengths and weaknesses). Safari (Mac OS), IE (Win) have the advantage of being installed by default, and they can be competitive on their native platforms if you're using the latest versions, but don't have much to recommend them beyond being preinstalled. Chrome is faster, FF has more plugins and configurability. Take your pick.
Yes, yellow lights must be timed correctly. The must be long enough for the longest of these factors:
1. A driver in a large vehicle (e.g. SUV, commercial truck, etc.) driving 5 mph under the speed limit who sees the light turn yellow, but doesn't have time react to the yellow, and stop before entering the intersection, must have sufficient time to continue through the intersection at that speed.
2. Same as #1, but allow enough time for driver to react and stop safely before entering the intersection.
3. Same as #1, but with driver traveling 5 MPH over the speed limit. Because of the higher speed, the driver must be farther from the intersection to allow for a safe stop and therefore, the time could be greater than in #1.
4. Same as #2, but with driver traveling 5 MPH (or 10%, whichever is greater) over the speed limit. Because of the higher speed, the driver must be farther from the intersection to allow for a safe stop and therefore, the time could be greater than in #3.
Then add.5-1.0 seconds to allow for a distracted driver (or slower than normal reaction time). The greatest of those 4 times gives a minimum safe time for a yellow light. Add ~ 2 seconds for the maximum safe yellow time.
The other critical factor is that other lights should remain RED for at 0.5-2.0 seconds after the yellow turns red. to allow any traffic to fully clear the intersection. In most instances, 0.5-1.0 seconds is best, longer delays tend to impede traffic flow and make for anxious drivers, increasing the likelihood of an accident.
The added delay factors (0.5-1.0) above can (and probably should) be random within the ranges given so that drivers don't "learn" and anticipate the change timing. For maximum safety and traffic flow, you want drivers paying attention to and reacting to the actual change in the signal, not reacting to predicted changes.
Slashdot Mirror
The only digit in unary is 0.
The US is already on the metric system, it's just that most people never noticed. All packaged goods in the US are labeled in US and metric, our cars support MPH & KPH, our Liquor is is sold in 750ml, 1l and 1.75l bottles. All of our electronic fuel pumps and odometers can be switched between US & metric. Oh, we still use mile markers on the interstate, and we pretend we're still using non-metric measurements of oz, pound, gallon, inch, foot, mile, but in reality, everything is made and sold in metric quantities, and dual labeled with the more familiar measurements.
Most of the country is still in denial about it, and computers have helped keep it relatively hidden, but we're on the metric system whether we realize it or not.
If you're using the navigation, it's already killing your battery life. This doesn't change that.
Think these things through before making irrelevant arguments:
1. All it has to do is warn you when you're nearing the edge of the maps you have cached and let the user choose whether or not to download more maps. That leave the user in control of their data usage.
2. If the user is using the maps to navigate while driving, they're using bandwidth to download those maps anyway.
Or, they could just automatically cache the maps within ~ 100mi of your current location, then, if you lose signal, you've still got a useful GPS and maps. Or since they know where you are, and approximately where there is coverage, they could cache a smaller area when you're in an area with good coverage, and cache a larger area when you get to areas with less coverage.
It's a simple concept, when possible, let the computer do the work.
Maybe the phone should do that for you instead of making the user have to set hidden options prior traveling to areas where the map/GPS functionality is most likely to be needed. It works when they're at home, why would they expect it to not work when they go elsewhere, and how would they know to look for the option to archive the maps before leaving?
That analysis doesn't apply because n in this instance is no greater than 2^32 in order to ensure than the ID is no more than 32-bits. That fails to meet the criteria Shamir stated "given, that both p and q are large primes which are being kept secret so that factoring n = p*q is computationally infeasible."
Therefore, 32-bit hashes are not "provably collision resistant". See my post for the actual likelihood of collisions.
Collisions of random numbers with approximately equal distribution across the sample space are variations of the classic "birthday problem". And, with a 32-bit sample space, you have a 50% chance of a collision with slightly fewer than 77,500 entries.
I tried calculating it for a 64-bit hash, but the online calculator I used using was apparently using a linear calculation and didn't validate the input. It timed out after about 15 minutes. Oops, sorry I hammered the server. Maybe next time he'll validate the input and maybe even use a more efficient algorithm.
So, lets just say it'll take ~ (77500^2) *.8 ~ 4.8E9 IDs for a 64-bit hash to have a 50% chance of a collision. Take it up to 80 or more bits and the likelihood of a collision becomes very small even if everyone on the planet has an ID.
That includes most people currently employed as programmers.
They'll have pirated an image of a fake, so clearly LV doesn't have a claim, and WB would be trying to assert IP rights for a fraudulent product. IANAL, but that could create some interesting arguments.
After all, anyone who buys one clearly has more money than sense, and therefore, should be separated from their money. It has been foretold "a fool and his money are soon parted", who are we to interfere with such a prophecy?
Others have pointed out compatibility issues due to differing hardware, different versions of the OS, different UI modules added by manufacturers, poor quality hardware from some manufacturers, inconsistent/poor availability of updates, etc. All of those are valid complaints. But having used an Android phone, here is what I see as the biggest flaw; the UI design is fundamentally inconsistent. It fails to follow many of the user interaction guidelines from the person who is certainly one of the top UI experts, Bruce Tognazzini, aka Tog.
Is it a touch screen system, or a keyboard system? Both, and neither. Almost everything is done using the touch screen, except "back", "menu/settings", and changing apps (plus power and volume controls). You can't complete common tasks using just one or the other, you must use both. Using a separate button to change apps doesn't interfere with normal work flow, as changing apps itself is an interruption in work flow, so it makes some sense. However, having to switch from the touchscreen to the dedicated keys to go back (a critical part of most apps), or to access a menu (e.g. add, delete, edit, change settings, etc.) is an unnecessary, and non-intuitive UI design. It's consistent in that the whole OS and almost all apps use it, but switching between touchscreen and dedicated keys for essential parts of in-app functionality is an interruption in workflow. Everything done in an app should be possible using a single UI model on the touchscreen.
Another annoyance (at least on my phone, don't know about others) is that auto-correct (and automatically adding apostrophes in contractions) only works when using swype. If you want those when typing in text, you must go back after the fact and tap the word to get a list of alternatives. Why would auto-correct only work with one input method? There is no auto-punctuation and it doesn't even offer auto-complete except in the browser.
Syncing my contacts list between the Mac OS X address book, Google contacts and the phone was a challenge. Not all of the blame for that falls on Android, but it took 2 hours to initially sync and eliminate duplicates (there were only 10 contacts in the phone to start with) because contacts and numbers were getting duplicated, and deleting them from one didn't always delete them from another, so next sync they would dup again. Once it's set up, it mostly works, but again, deleting or changing info on one may cause duplication problems next time, so it's an ongoing annoyance. An average user would probably have given up on syncing the contacts, but with 500 contacts, I wasn't going to give up easily.
Individually, these are "little" annoyances and inconsistencies, but they're pervasive and significant enough to harm an otherwise pleasant user experience. Because of these annoyances (and several others) I would much rather have an iPhone.
Yeah, it's not like there's no precedence for this sort of thing.
rant
/rant
And it's not like there's no precedents on slashdot for misusing precedence. How many times does someone have to point this out before people start using the correct word?
Well, you may a little slower than the Oct/Nov kids. Of course, statistically, you may have fewer bugs.
When someone shows it has battery life comparable to the current dual-core ARM A9 SoCs, then they will have something to talk about. Until then, it's just a PR pipedream.
It just makes it harder and more costly for the people who actually need the information for legitimate purposes to get it. The criminals will get it either way.
Can't wait for my new rust based electronics. Of course the 3000f operating temperature and 690k ATM pressures might make them unsuitable for mobile electronics.
Yeah Mozilla. Refusing to remove the add-in was the correct thing to do. Censorship doesn't work, and it must be fought every time some government idiot tries it.
...Mac OSX (only available on Apple hardware, Apple openly sues you for building hackintoshes).
No, Apple sued Psystar for selling hackintoshes in violation of the OS X EULA and a copyright violation. As far as I can tell, Apple hasn't sued anyone for building their own hackintosh.
FF 9 wasn't showing as available earlier, but I just downloaded in and ran Peacekeeper. My testing shows a slight (~3%) decrease in JS performance vs FF8.01. While that's trivial, it's far short of the 20%-30% increase they're claiming.
It's not the rapid release of fixes that's a problem. It's the constantly changing version numbers. Even if the new version would otherwise be compatible, the fact that it's identified as a new version breaks most plug-ins.
And then there is the issue of getting it validated for corporate use, where the testing and approval of a new "version" is far more difficult than getting approval for a minor version (.x) or security update. Chrome suffers from this as well.
Or maybe that's when more newly hired programmers (from last spring's graduating class) are first allowed to put code into the repository (or production).
You're correct, however, there are two charts, the side effects experienced by the group receiving the medication, and the side effects of those receiving a placebo. What's relevant are the ones that differ significantly (positive or negative) in frequency between the groups. That's where you see both the benefits, and the potential side effects.
Run the Peacekeeper benchmark and watch during the Canvas and HTML5 video tests. You'll see that Chrome and Firefox are the only MAJOR browsers that don't suck at video and Canvas. Overall, Opera 11.6 performed well, but video was jerky on all supported codecs. Chrome (16.0.x tested) handled all the codecs correctly, handled the Canvas test correctly, and was fastest overall. FF (8.0.1 tested) handled most of the codecs, handled Canvas correctly, but overall performance was about 1/2 that of Chrome. Safari 5.x on Mac OS 10.6 handles video well, but didn't do well on the current Canvas test and failed to complete the benchmark.
Notes: I tested on WinXP and Mac OS 10.6, therefore, I haven't tried IE9. I did not have Adobe Flash installed, except the built-in Flash in Chrome, so Chrome may (or may not) have had an advantage on the video codecs. Tests were run on 1.86GHz and 2.2GHz Core2 Duo systems with plenty of RAM and decent video controllers (plenty fast enough for video and low/mid range games, but not anything a "gamer" would even consider). YMMV.
With so much video on the internet these days, and especially now that Adobe has finally acknowledged that Flash isn't the future, I believe that the above tests a relevant to the average user. Until Opera addresses the poor video playback issue, no amount of JS performance is going to win them market share. IE9 being Win7 only (Vista doesn't count) puts some limits on it's market for now. So, it comes down to Chrome, Firefox, and Safari. Safari on Windows sucks.
So, the real choice for most users comes down to Chrome vs Firefox, and both are good choices (each with strengths and weaknesses). Safari (Mac OS), IE (Win) have the advantage of being installed by default, and they can be competitive on their native platforms if you're using the latest versions, but don't have much to recommend them beyond being preinstalled. Chrome is faster, FF has more plugins and configurability. Take your pick.
Yes, yellow lights must be timed correctly. The must be long enough for the longest of these factors:
1. A driver in a large vehicle (e.g. SUV, commercial truck, etc.) driving 5 mph under the speed limit who sees the light turn yellow, but doesn't have time react to the yellow, and stop before entering the intersection, must have sufficient time to continue through the intersection at that speed.
2. Same as #1, but allow enough time for driver to react and stop safely before entering the intersection.
3. Same as #1, but with driver traveling 5 MPH over the speed limit. Because of the higher speed, the driver must be farther from the intersection to allow for a safe stop and therefore, the time could be greater than in #1.
4. Same as #2, but with driver traveling 5 MPH (or 10%, whichever is greater) over the speed limit. Because of the higher speed, the driver must be farther from the intersection to allow for a safe stop and therefore, the time could be greater than in #3.
Then add .5-1.0 seconds to allow for a distracted driver (or slower than normal reaction time). The greatest of those 4 times gives a minimum safe time for a yellow light. Add ~ 2 seconds for the maximum safe yellow time.
The other critical factor is that other lights should remain RED for at 0.5-2.0 seconds after the yellow turns red. to allow any traffic to fully clear the intersection. In most instances, 0.5-1.0 seconds is best, longer delays tend to impede traffic flow and make for anxious drivers, increasing the likelihood of an accident.
The added delay factors (0.5-1.0) above can (and probably should) be random within the ranges given so that drivers don't "learn" and anticipate the change timing. For maximum safety and traffic flow, you want drivers paying attention to and reacting to the actual change in the signal, not reacting to predicted changes.