What needs to be done, as a minimum, is something like Password Hasher (the firefox plugin) needs to be built into each browser.
That protects against what is probably the least interesting situation—when the user's password to one site is silently compromised by attacking that site, and the user used that same password on another site. First, it assumes that the user's password is weak enough to be readily cracked by someone hammering on the password database (which if it is salted properly, is unlikely). Second, it ignores the reality that most passwords are not compromised by server-side security holes; they're compromised by client-side security holes—keyloggers, etc.
To use a car analogy, this is like putting an un-pickable lock on a car to protect your expensive radio, but leaving the factory glass windows untouched.
I think that Google Authenticator tries to prevent mitm attacks by having any given token usable exactly once in addition to having a very short lifespan.
Here's why that doesn't work. The attack is very, very, very simple, and once you see it explained, you'll never trust those sorts of services again. A basic attack looks like this:
Attacker compromises the device and waits for user to log into Google.
Attacker captures the response to the authentication request and forwards it to their own server.
Attacker's server connects to Google's system and obtains credentials.
Attacker displays a network error message to the user. The user logs in again to the real Google server, unaware that the first attempt was successful, just for somebody else.
Elapsed time: tens of milliseconds after the user logs in. A slightly more sophisticated attack looks like this:
Attacker compromises the device and waits for user to log into Google.
Attacker captures the response to the authentication request and forwards it to their own server.
Attacker's server connects to Google's system and obtains credentials.
Attacker masquerades as a forwarder for Google's server so that the user is completely oblivious.
Elapsed time: tens of milliseconds after the user logs in. And if the service you're logging into works the way most services do, an even simpler attack looks like this:
Attacker compromises the device and waits for user to log into Google.
Attacker steals the cookies that Google stores on the user's system and uses them on another machine.
Elapsed time: zero milliseconds after the user logs in. But the best one of all is this:
Attacker compromises the device and steals the private key used to generate the authentication token.
Attacker logs in at will. From anywhere. At any time. Forever and ever.
Elapsed time: zero milliseconds after the device is first compromised or GA is first installed.
All four techniques are 100% transparent and are 100% effective attacks against software-generated time-based authentication schemes. The first two are 100% effective against hardware tokens used for time-based authentication, too. In fact, even if Google upped the ante and made the authenticator be interactive, where the Google servers sent a unique nonce that had to be encoded along with the time stamp, this scheme would still not be significantly stronger. The only change required to the first two schemes would be adding one additional step—telling the attacker's server to issue a request to Google and pass that request nonce to the compromised client. And the third and fourth schemes would continue working as-is. This is why time-based authentication is basically worthless unless the endpoint is trusted (and at this point, I'm growing more and more convinced that users should assume that their endpoints are not trusted).
The reality of the matter is that time-based authentication schemes are an anachronism. When they were first conceived by RSA in the mid-1980s, they were not intended for general users. They were intended to protect against precisely one threat—an attacker with a very specific target watching a user type in his or her password from a distance. They work well for that purpose. They can be compromised once by any attacker who gains control over the system where the authentication token is being entered, even if hardware tokens are involved, and they are permanently compromised by any attacker who gains control over the system where the secret key is stored. The reason there haven't been very many new implementations of time-based authentication since the 1990s is that such schemes just aren't particularly useful against modern attacks. They give the illusion of security without actually adding any. Well, unless you're worried about your roommate seeing you enter your password.
Put another way, creating a secure authentication scheme where the endpoint is compromised is fundamentally impossible for precisely the same reason that perfect DRM is fundamentally impossible. Alice is also Eve and Mallory. Food for thought.
Yes, lots of weak passwords are guessed by automated bots. This tends to affect websites like Facebook, message boards, etc., where the maximum possible damage is fairly limited and mostly harmless. By contrast, most people's bank account passwords are not "12345".
Not for important accounts, though. For things like banks, the password rules generally are already strong enough to make guessing problematic unless you know your victim, and to some degree, even then. It is far easier to make a virus that compromises millions of machines and looks at what letters the users just typed, or injects spyware into their browsers to detect which of those virtual PIN number pad buttons the user clicked, or whatever. Instead of an attack on a specific person that requires research, you can successfully compromise thousands or even millions of people. Why spend a high amount of effort per target when you can spend almost none and get similar results?
This, of course, ignores attacks on the infrastructure itself (e.g. attacking a credit card processor to steal credit/debit card numbers en masse or installing a card skimmer on an ATM). Those sorts of attacks also seem to be pretty popular, but they don't have much to do with passwords.
The FIDO stuff sounds like a whole lot of expensive extra technology with no real benefit over a password. A finger swipe is a replayable event just as much as a password or PIN.
The Google Authenticator is conceptually okay in theory, but in practice, AFAIK, it too becomes a gaping security hole as soon as your mobile device gets compromised.
If you want something stronger than passwords, it must have the following criteria:
Immune to replay attacks. Done correctly, this means that each authentication request must have a unique ID that must be signed or otherwise combined with some shared secret in a secure way.
Immune to man-in-the-middle attacks. Each request for authentication must be signed by the requestor so that the user can be certain that he/she is not agreeing to do something other than what is intended. Each response from the user must include at least a hash of the original request.
Immune to device compromise. The most common way that computer security is breached is through password sniffers or other compromise of the user's computer or mobile device. If you cannot trust the device that is performing the authentication, you cannot trust the action being performed, and all security goes out the window, including existing measures for preventing MITM and replay attacks, such as SSL/TLS.
None of these schemes I've seen so far address #3, and as a result, none of them are significantly more secure than typing letters at random and pasting the resulting password into a text file on your Desktop. They try to address problems that don't actually exist, while failing to address the root of the problem, which is that computers, mobile devices, etc. are not inherently secure.
For example, Google Authenticator uses a time-based token. This tries to avoid replay attacks by limiting the period during which an attack is possible. That doesn't work very well, though, unless you can delay an attacker's ability to sniff that token. This means that you have to prevent a MITM attack. As soon as the device is compromised, SSL and TLS are no longer capable of preventing a MITM attack, so the entire scheme falls apart.
Anything short of a non-networked device communicating with your computer over a very simple protocol (think "formal verification" here) is not a major win, IMO. And it can't be something silly like touching a smart card to an RFID reader, either, because the reader could perform more than one transaction, and you would have no way of knowing that you just bought some farmer in Iowa a new tractor alongside that DVD from Amazon. No, you really need a physical screen and a button on the device saying, "Do you agree to transfer $258,000 to Bank of Nigeria?" in order to significantly improve things. Anything short of that is just wasting a lot of time and expense without addressing the real problem—that if you can't trust the endpoint, you can't trust the message. Start by developing a truly trusted endpoint. After that, the entire problem becomes fairly trivial.
I, for one, am 100% gung-ho about having a 3rd-party in the 'cloud' handling every single one of my packets so that they can balance them between my connections!
There are already lots of third parties handling each of your packets. I'm not sure why one extra router would be a cause for concern.
I don't agree on the megapixel thing. As far as I can tell, consumers as a whole never cared about megapixels except as a means of helping them choose between two cameras that were otherwise basically indistinguishable. I don't know anyone who ever said, "I want to buy a new camera because it has more megapixels." They bought new cameras because their old ones started having problems, or occasionally because they saw photos from other people's digital cameras that looked better. Indeed, this is the norm when it comes to hardware. People buy new hardware when the old hardware stops working or starts to look worn out.
Now the marketing people pushed megapixels because it was the only thing they had to differentiate one cheap camera from the next, but in the end, that didn't matter because as far as consumers are concerned, there's a point at which it becomes "good enough". When cell phone cameras got to be "good enough", almost everyone stopped buying and using low-end cameras. As a result, the most popular cameras currently on the market, at least as far as the number of pictures taken, are all either some model of iPhone or some model of DSLR. Everything else is very nearly lost in the noise (or at least the long tail).
What this says is that the people who actually cared about picture quality before still do (and use DSLRs), because their goal is to take photos. Everyone else takes photos using whatever they have handy, same as they always did, and they upgrade when their old cell phone breaks or when they see somebody's new cell phone and realize that it is much better than theirs was. The only real difference is that they now carry one fewer devices than they did before.
As for the Hi-Fi thing, that's pretty much the same situation. It's not that it was a fad so much as that good quality sound takes up a lot of space, so a lot of folks switched to smaller speakers once they got "good enough" even if they didn't sound quite as good. The audiophiles still take the time to tune their rooms, buy good quality speakers, etc. Everyone else buys whatever is cheap at the time because they need something to do a particular job. It just so happens that whatever is popular tends to also be cheap, because of economies of scale.:-)
96.9% of the people in India (1.18 billion people) live on less than $5 per day (adjusted for purchasing power.) Confiscating 100% of Bill Gates wealth will only give each of them a one time payment of $61.61, less than a month of income.
The upshot of realizing these things is that you see that wealth disparity is a pretend problem, and the closest thing it is to a real problem is the fact that so many people can be so easily fooled into droning on about it like it actually was a problem.
That's specious reasoning for two reasons.
First, the only useful measure of wealth is a local one, because most commerce occurs locally. The people in India don't pay American prices for food, shelter, clothing, etc., so Bill Gates being rich doesn't affect them significantly. The more interesting question is what his wealth would do if redistributed to the poorest people in his own country, where there are a quarter as many people, and where only about 15% of those are living in poverty relative to the rest of Bill Gates's home country.
Second, your argument assumes only a single ultra-wealthy person. When you actually look at real numbers instead of your strawman assumptions, the reality is very different from what you're presenting. Here are the cold, hard facts:
If you took away all the wealth of just the Forbes 400 (the richest 400 people in the U.S.) and redistributed it, you could give $35,000 apiece to every single American living below the poverty line. That's enough to wipe out their debt entirely and put them on the road to financial recovery.
If you extend that to the top 1% of Americans, you would have enough to give every American currently living below the poverty line nearly a million dollars apiece—enough for them to retire right now and live off the interest for the rest of their lives while still making about as much per year as they currently do!
Frankly, wealth is even more unequally distributed in the U.S. today than it was in the days leading up to the French Revolution. The only reasons things aren't as bad as they were then are because we have a middle class, we allow people other than the top couple of percent to own land, and we are geographically large enough to be resistant to local droughts that would cause famine in a country as small as France. Those differences make the wealth disparity no less real, though.
I'm not suggesting that it's time to behead the top 1% and redistribute their wealth, but clearly we cannot afford to ignore the problem indefinitely.
A trillion apples is a roughly 4.5-apple-thick layer of large apples covering all of Manhattan.
Now that I've said that, it's easy to conceptualize it. In fact, you've already visualized it in your mind, and if you're from anywhere other than Manhattan, you're also probably thinking that it sounds like a good idea.
For actual bartending work involving complex cocktail production, where the bartender needs to have extremely high perception, flexibility, stability, control in mixing the drinks in just the perfect timing, temperature, amount, AND on top of that being social and friendly with ability to reply to the drinkers who sit at the bar?
Well, except for that last part, I'd expect the robots to immediately do a better job. The last part can be handled by an ordinary member of the wait staff without lots of experience at tending bar. This doesn't really remove the need for the people, but it does remove the need for the training and experience, which means the pay is likely to go down.
The state of California can claim that as much as they want to. That doesn't make it even remotely true.
The speed limits are, in practice, at least partially based on:
The general rule that speed limits should increase or decrease by no more than 10 MPH between one sign and the next.
The requirement that the speed limit stay at a particular speed for a certain minimum distance.
As a result, speeds are set based on the maximum speed for the worst spot over the course of several miles. For example:
On highway 17 near Santa Cruz, the speed limit drops to 55 MPH way earlier than it needs to, all because the speed needs to be that low for the fishhook, even though there's no real reason to slow down until you approach the merge zone.
On Highway 237 in Mountain View, the speed limit drops to 55, AFAICT, solely because of a single bad entrance off of 101 on one side of the highway, and because they can't raise it back up to 65 because there isn't time to drop it back down by 10 MPH at a time going into town. Unfortunately, this means that the cars who are going onto 85 southbound have to drive much slower to accommodate the handful of cars who are getting off onto a city street in Mountain View.
The speed limit on De Anza Blvd is 35. The speed limit on El Camino is 40. There is really no appreciable difference between these roads, and both would be marked 45 in other states.
The maximum speed limit is generally 65, even though nearly every major highway would be marked at 70 or 75 in any other state.
And so on. California's credibility in this matter is pretty much zero. You need only drive around for a few days to conclude as much.
You say "Nonsense" when you've just said pretty much everything that I said as an argument to my post. Thanks for the corroboration.
Not at all. You said that if Intel built an ARM chip, it would be a huge beast that draws lots of power. They did build an ARM chip, and it wasn't huge, slow, or high-wattage. It was used in lots of handheld devices for many years, in fact.
Intel builds x86 chips that way because the x86 and x86-64 ISAs are entirely too complex, so they have to build ever-more-complex hardware to hide the performance that would otherwise result from that fundamental limitation. And they are getting better about that, but it has taken a long time to get them to come around to a more mobile way of thinking.
Congratulations. Your city is one of the few where the traffic engineers have insisted on upgrading to more modern hardware. Either that or your traffic lights were added more recently. What you are describing is the exception that proves the rule, though.
People love certain types of change. They love cool new features. People hate when existing functionality that they’re used to using goes away, or when those new features get in the way of doing what they’ve been doing, forcing them to do something different right now. For a consumer, an ideal app upgrade does exactly what the old version does in exactly the same way, but lets them try new things at their leisure. They like new features and new technology, so long as they are free to adopt them on their own schedules, rather than when the manufacturer decides that it is time to make a few extra bucks off of them, or when a hardware upgrade forces them onto a new version of the OS or whatever.
The fundamental disconnect between tech companies and their consumers is that tech companies like to get rid of old features and functionality, because maintenance has a cost associated with it. They don’t care if the new way forces new usage patterns, which is something consumers almost universally hate. This is why any well-designed app has means for disabling major UI features and rolling back to the old behavior. It’s not that consumers aren’t willing to change or hate change, but rather that they want to be able to enable those new features on their schedule, not on the software manufacturer’s schedule.
I don't think it's just Florida that's abusing traffic citations for profit. I visited Santa Cruz, CA on Sunday and parked by the beach. There were cars on either side of me, white space dividing lines and a meter right in front of the space where I parked. I got a $48 citation for "parking in a red zone". So I called them up and asked what this meant, it means "no parking at any time under any circumstances". That means the ticket was quite obviously wrong as no-parking zones don't have parking meters in them.
Any chance you could tell us where in Santa Cruz this was? I'm curious.
The problem is, nearly all traffic lights are stupid. They fall into one of two camps:
Simple, timed walk lights. These work the way you described, and always show a walk light without the need to press a button.
Smarter, button-driven walk lights. These lights typically show "Walk" for about five seconds and then begin counting down. When they reach zero, the pedestrian light goes to a solid "Don't Walk", but there may an entire walk cycle worth of time between then and when the light itself turns red.
If someone is used to the first type, when they encounter the second, they start slowing down for a light that isn't about to change, and end up causing a substantial increase in traffic backup (and possibly even rear-end collisions). Similarly, if someone is used to the second type, they ignore the countdown, and it provides no benefit even when the light in question was of the first type.
In short, pedestrian countdowns aren't particularly useful for cars because they aren't consistently implemented, even within a single major metropolitan area. They're also too small to easily be read at anything approaching the speed of a fast road. What we actually need are car-specific countdown timers above the driving lanes, with larger numbers, that (when they exist) are guaranteed to be timed based on when the light will actually shut down.
If Intel did the ARM, it would measure six feet by eleven feet, weigh 900lbs, and use four kilowatts of electricity, and would need to have Microsoft's lipstick on it.
Nonsense. Intel used to have an ARM division (bought from DEC). They called it StrongARM, later renamed to XScale. They were basically popular for devices in the same general category as iPhone and iPod Touch. Intel sold off that business to Marvell in 2006 because they thought they could get the power consumption of x86 down enough by 2010 that it would kill demand for ARM.
They were wrong. They couldn't do it and still produce a chip that was usable. Atom's in-order execution model sucked for performance, giving ARM a sizable advantage. And in parts that don't have that limitation (e.g. Haswell), the power consumption even three years after that deadline is still at least an order of magnitude too high. (An iPhone, assuming no changes to the battery, would get fewer than 8 hours of life with a Haswell CPU even if the CPU did nothing but sit in its lowest idle power state for the entire time.)
But worse than that, Intel bet the farm on the concept of standalone CPUs that hardware makers could tie into a custom northbridge, if desired. The problem is, that isn't what the manufacturers wanted. And for the most part, they didn't want standardized SOCs, either. They wanted raw cores that they could integrate into their own SOCs.
For example, most of the guts of an iPhone 5 are in a single chip that, according to Wikipedia, provides two ARM codes, three GPU cores, and RAM all in a single package. That's the level of integration that you want when you're trying to build a tiny device. Every additional component on a board represents an additional set of interconnects waiting to fail.
Could be, or it could be that in some spots, the spec itself is ambiguous, and that the LSP is returning an error code that indicates an interrupted system call that should be retried or something, in which case, iTunes might dutifully retry the request an infinite number of times or whatever. If that's the sort of situation you're seeing, then arguably both Apple and the antivirus software are at least partially to blame. It's hard to say without actually running a debugger on an affected machine to determine what the heck is actually happening, followed by poring through the specification to figure out whether the LSP is actually violating it or not.
Either way, assuming that updating the problematic AV software always fixes this bug, then one could reasonably argue that there's no need to work around the bug in iTunes, and if that isn't the case, then the affected users should file a bug.:-)
Human nature means that the vast majority of humans act that way. I complain whether things happen to me or not, too, but folks like us are in the minority.
The problem with your definition is that minimum advertised price (MAP) policies are generally considered to be legal (since about 2008), and they're unfortunately fairly common—Canon and Nikon, many major clothing companies, etc. There's little difference between a typical MAP and the agency model with a "most favored nation" clause beyond that a reseller is requiring the manufacturer to set a MAP in order to sell through that channel. If the MAP itself isn't anticompetitive, then neither is an MFN clause, IMO.
Personally, I'd love to see the courts find MAP policies to be inherently anticompetitive. Unfortunately, there's a fair amount of legal precedent for MAPs being legal, so I'm not holding my breath on the courts prohibiting them. If they did, however, that would also make MFN clauses like the one they're talking about here illegal, too, because a contract term cannot require you to break the law.
Not really. 99% of people won't be willing to reboot just to go to a bank website. And even if they were, a suitably compromised BIOS/EFI could render the additional security worthless.
It's human nature to say, "It won't happen to me," until it does. Nearly everything bad in the world would be prevented if we could simply stamp out that part of human nature.
There are two problems with using fixed cameras for speed measurement. First, in California, where I live, the law explicitly forbids doing that. Second, they can only compute your average speed. In a congestion situation, you might easily miss ticketing someone who is running 15 under the limit for a while, then fifteen over when a lane clears, then back to 15 under. So as I said, cameras on poles aren't able to accurately judge a vehicle's speed.
Slashdot Mirror
That protects against what is probably the least interesting situation—when the user's password to one site is silently compromised by attacking that site, and the user used that same password on another site. First, it assumes that the user's password is weak enough to be readily cracked by someone hammering on the password database (which if it is salted properly, is unlikely). Second, it ignores the reality that most passwords are not compromised by server-side security holes; they're compromised by client-side security holes—keyloggers, etc.
To use a car analogy, this is like putting an un-pickable lock on a car to protect your expensive radio, but leaving the factory glass windows untouched.
Here's why that doesn't work. The attack is very, very, very simple, and once you see it explained, you'll never trust those sorts of services again. A basic attack looks like this:
Elapsed time: tens of milliseconds after the user logs in. A slightly more sophisticated attack looks like this:
Elapsed time: tens of milliseconds after the user logs in. And if the service you're logging into works the way most services do, an even simpler attack looks like this:
Elapsed time: zero milliseconds after the user logs in. But the best one of all is this:
Elapsed time: zero milliseconds after the device is first compromised or GA is first installed.
All four techniques are 100% transparent and are 100% effective attacks against software-generated time-based authentication schemes. The first two are 100% effective against hardware tokens used for time-based authentication, too. In fact, even if Google upped the ante and made the authenticator be interactive, where the Google servers sent a unique nonce that had to be encoded along with the time stamp, this scheme would still not be significantly stronger. The only change required to the first two schemes would be adding one additional step—telling the attacker's server to issue a request to Google and pass that request nonce to the compromised client. And the third and fourth schemes would continue working as-is. This is why time-based authentication is basically worthless unless the endpoint is trusted (and at this point, I'm growing more and more convinced that users should assume that their endpoints are not trusted).
The reality of the matter is that time-based authentication schemes are an anachronism. When they were first conceived by RSA in the mid-1980s, they were not intended for general users. They were intended to protect against precisely one threat—an attacker with a very specific target watching a user type in his or her password from a distance. They work well for that purpose. They can be compromised once by any attacker who gains control over the system where the authentication token is being entered, even if hardware tokens are involved, and they are permanently compromised by any attacker who gains control over the system where the secret key is stored. The reason there haven't been very many new implementations of time-based authentication since the 1990s is that such schemes just aren't particularly useful against modern attacks. They give the illusion of security without actually adding any. Well, unless you're worried about your roommate seeing you enter your password.
Put another way, creating a secure authentication scheme where the endpoint is compromised is fundamentally impossible for precisely the same reason that perfect DRM is fundamentally impossible. Alice is also Eve and Mallory. Food for thought.
Sigh. Ignore the first sentence in the second paragraph. This is what over-editing does.
Yes, lots of weak passwords are guessed by automated bots. This tends to affect websites like Facebook, message boards, etc., where the maximum possible damage is fairly limited and mostly harmless. By contrast, most people's bank account passwords are not "12345".
Not for important accounts, though. For things like banks, the password rules generally are already strong enough to make guessing problematic unless you know your victim, and to some degree, even then. It is far easier to make a virus that compromises millions of machines and looks at what letters the users just typed, or injects spyware into their browsers to detect which of those virtual PIN number pad buttons the user clicked, or whatever. Instead of an attack on a specific person that requires research, you can successfully compromise thousands or even millions of people. Why spend a high amount of effort per target when you can spend almost none and get similar results?
This, of course, ignores attacks on the infrastructure itself (e.g. attacking a credit card processor to steal credit/debit card numbers en masse or installing a card skimmer on an ATM). Those sorts of attacks also seem to be pretty popular, but they don't have much to do with passwords.
The FIDO stuff sounds like a whole lot of expensive extra technology with no real benefit over a password. A finger swipe is a replayable event just as much as a password or PIN.
The Google Authenticator is conceptually okay in theory, but in practice, AFAIK, it too becomes a gaping security hole as soon as your mobile device gets compromised.
If you want something stronger than passwords, it must have the following criteria:
None of these schemes I've seen so far address #3, and as a result, none of them are significantly more secure than typing letters at random and pasting the resulting password into a text file on your Desktop. They try to address problems that don't actually exist, while failing to address the root of the problem, which is that computers, mobile devices, etc. are not inherently secure.
For example, Google Authenticator uses a time-based token. This tries to avoid replay attacks by limiting the period during which an attack is possible. That doesn't work very well, though, unless you can delay an attacker's ability to sniff that token. This means that you have to prevent a MITM attack. As soon as the device is compromised, SSL and TLS are no longer capable of preventing a MITM attack, so the entire scheme falls apart.
Anything short of a non-networked device communicating with your computer over a very simple protocol (think "formal verification" here) is not a major win, IMO. And it can't be something silly like touching a smart card to an RFID reader, either, because the reader could perform more than one transaction, and you would have no way of knowing that you just bought some farmer in Iowa a new tractor alongside that DVD from Amazon. No, you really need a physical screen and a button on the device saying, "Do you agree to transfer $258,000 to Bank of Nigeria?" in order to significantly improve things. Anything short of that is just wasting a lot of time and expense without addressing the real problem—that if you can't trust the endpoint, you can't trust the message. Start by developing a truly trusted endpoint. After that, the entire problem becomes fairly trivial.
There are already lots of third parties handling each of your packets. I'm not sure why one extra router would be a cause for concern.
I don't agree on the megapixel thing. As far as I can tell, consumers as a whole never cared about megapixels except as a means of helping them choose between two cameras that were otherwise basically indistinguishable. I don't know anyone who ever said, "I want to buy a new camera because it has more megapixels." They bought new cameras because their old ones started having problems, or occasionally because they saw photos from other people's digital cameras that looked better. Indeed, this is the norm when it comes to hardware. People buy new hardware when the old hardware stops working or starts to look worn out.
Now the marketing people pushed megapixels because it was the only thing they had to differentiate one cheap camera from the next, but in the end, that didn't matter because as far as consumers are concerned, there's a point at which it becomes "good enough". When cell phone cameras got to be "good enough", almost everyone stopped buying and using low-end cameras. As a result, the most popular cameras currently on the market, at least as far as the number of pictures taken, are all either some model of iPhone or some model of DSLR. Everything else is very nearly lost in the noise (or at least the long tail).
What this says is that the people who actually cared about picture quality before still do (and use DSLRs), because their goal is to take photos. Everyone else takes photos using whatever they have handy, same as they always did, and they upgrade when their old cell phone breaks or when they see somebody's new cell phone and realize that it is much better than theirs was. The only real difference is that they now carry one fewer devices than they did before.
As for the Hi-Fi thing, that's pretty much the same situation. It's not that it was a fad so much as that good quality sound takes up a lot of space, so a lot of folks switched to smaller speakers once they got "good enough" even if they didn't sound quite as good. The audiophiles still take the time to tune their rooms, buy good quality speakers, etc. Everyone else buys whatever is cheap at the time because they need something to do a particular job. It just so happens that whatever is popular tends to also be cheap, because of economies of scale. :-)
That's specious reasoning for two reasons.
First, the only useful measure of wealth is a local one, because most commerce occurs locally. The people in India don't pay American prices for food, shelter, clothing, etc., so Bill Gates being rich doesn't affect them significantly. The more interesting question is what his wealth would do if redistributed to the poorest people in his own country, where there are a quarter as many people, and where only about 15% of those are living in poverty relative to the rest of Bill Gates's home country.
Second, your argument assumes only a single ultra-wealthy person. When you actually look at real numbers instead of your strawman assumptions, the reality is very different from what you're presenting. Here are the cold, hard facts:
Frankly, wealth is even more unequally distributed in the U.S. today than it was in the days leading up to the French Revolution. The only reasons things aren't as bad as they were then are because we have a middle class, we allow people other than the top couple of percent to own land, and we are geographically large enough to be resistant to local droughts that would cause famine in a country as small as France. Those differences make the wealth disparity no less real, though.
I'm not suggesting that it's time to behead the top 1% and redistribute their wealth, but clearly we cannot afford to ignore the problem indefinitely.
About half as much power as a low-current LED.
A trillion apples is a roughly 4.5-apple-thick layer of large apples covering all of Manhattan.
Now that I've said that, it's easy to conceptualize it. In fact, you've already visualized it in your mind, and if you're from anywhere other than Manhattan, you're also probably thinking that it sounds like a good idea.
Well, except for that last part, I'd expect the robots to immediately do a better job. The last part can be handled by an ordinary member of the wait staff without lots of experience at tending bar. This doesn't really remove the need for the people, but it does remove the need for the training and experience, which means the pay is likely to go down.
The state of California can claim that as much as they want to. That doesn't make it even remotely true.
The speed limits are, in practice, at least partially based on:
As a result, speeds are set based on the maximum speed for the worst spot over the course of several miles. For example:
And so on. California's credibility in this matter is pretty much zero. You need only drive around for a few days to conclude as much.
Not at all. You said that if Intel built an ARM chip, it would be a huge beast that draws lots of power. They did build an ARM chip, and it wasn't huge, slow, or high-wattage. It was used in lots of handheld devices for many years, in fact.
Intel builds x86 chips that way because the x86 and x86-64 ISAs are entirely too complex, so they have to build ever-more-complex hardware to hide the performance that would otherwise result from that fundamental limitation. And they are getting better about that, but it has taken a long time to get them to come around to a more mobile way of thinking.
Congratulations. Your city is one of the few where the traffic engineers have insisted on upgrading to more modern hardware. Either that or your traffic lights were added more recently. What you are describing is the exception that proves the rule, though.
People love certain types of change. They love cool new features. People hate when existing functionality that they’re used to using goes away, or when those new features get in the way of doing what they’ve been doing, forcing them to do something different right now. For a consumer, an ideal app upgrade does exactly what the old version does in exactly the same way, but lets them try new things at their leisure. They like new features and new technology, so long as they are free to adopt them on their own schedules, rather than when the manufacturer decides that it is time to make a few extra bucks off of them, or when a hardware upgrade forces them onto a new version of the OS or whatever.
The fundamental disconnect between tech companies and their consumers is that tech companies like to get rid of old features and functionality, because maintenance has a cost associated with it. They don’t care if the new way forces new usage patterns, which is something consumers almost universally hate. This is why any well-designed app has means for disabling major UI features and rolling back to the old behavior. It’s not that consumers aren’t willing to change or hate change, but rather that they want to be able to enable those new features on their schedule, not on the software manufacturer’s schedule.
Any chance you could tell us where in Santa Cruz this was? I'm curious.
The problem is, nearly all traffic lights are stupid. They fall into one of two camps:
If someone is used to the first type, when they encounter the second, they start slowing down for a light that isn't about to change, and end up causing a substantial increase in traffic backup (and possibly even rear-end collisions). Similarly, if someone is used to the second type, they ignore the countdown, and it provides no benefit even when the light in question was of the first type.
In short, pedestrian countdowns aren't particularly useful for cars because they aren't consistently implemented, even within a single major metropolitan area. They're also too small to easily be read at anything approaching the speed of a fast road. What we actually need are car-specific countdown timers above the driving lanes, with larger numbers, that (when they exist) are guaranteed to be timed based on when the light will actually shut down.
Nonsense. Intel used to have an ARM division (bought from DEC). They called it StrongARM, later renamed to XScale. They were basically popular for devices in the same general category as iPhone and iPod Touch. Intel sold off that business to Marvell in 2006 because they thought they could get the power consumption of x86 down enough by 2010 that it would kill demand for ARM.
They were wrong. They couldn't do it and still produce a chip that was usable. Atom's in-order execution model sucked for performance, giving ARM a sizable advantage. And in parts that don't have that limitation (e.g. Haswell), the power consumption even three years after that deadline is still at least an order of magnitude too high. (An iPhone, assuming no changes to the battery, would get fewer than 8 hours of life with a Haswell CPU even if the CPU did nothing but sit in its lowest idle power state for the entire time.)
But worse than that, Intel bet the farm on the concept of standalone CPUs that hardware makers could tie into a custom northbridge, if desired. The problem is, that isn't what the manufacturers wanted. And for the most part, they didn't want standardized SOCs, either. They wanted raw cores that they could integrate into their own SOCs.
For example, most of the guts of an iPhone 5 are in a single chip that, according to Wikipedia, provides two ARM codes, three GPU cores, and RAM all in a single package. That's the level of integration that you want when you're trying to build a tiny device. Every additional component on a board represents an additional set of interconnects waiting to fail.
Could be, or it could be that in some spots, the spec itself is ambiguous, and that the LSP is returning an error code that indicates an interrupted system call that should be retried or something, in which case, iTunes might dutifully retry the request an infinite number of times or whatever. If that's the sort of situation you're seeing, then arguably both Apple and the antivirus software are at least partially to blame. It's hard to say without actually running a debugger on an affected machine to determine what the heck is actually happening, followed by poring through the specification to figure out whether the LSP is actually violating it or not.
Either way, assuming that updating the problematic AV software always fixes this bug, then one could reasonably argue that there's no need to work around the bug in iTunes, and if that isn't the case, then the affected users should file a bug. :-)
Human nature means that the vast majority of humans act that way. I complain whether things happen to me or not, too, but folks like us are in the minority.
The problem with your definition is that minimum advertised price (MAP) policies are generally considered to be legal (since about 2008), and they're unfortunately fairly common—Canon and Nikon, many major clothing companies, etc. There's little difference between a typical MAP and the agency model with a "most favored nation" clause beyond that a reseller is requiring the manufacturer to set a MAP in order to sell through that channel. If the MAP itself isn't anticompetitive, then neither is an MFN clause, IMO.
Personally, I'd love to see the courts find MAP policies to be inherently anticompetitive. Unfortunately, there's a fair amount of legal precedent for MAPs being legal, so I'm not holding my breath on the courts prohibiting them. If they did, however, that would also make MFN clauses like the one they're talking about here illegal, too, because a contract term cannot require you to break the law.
Not really. 99% of people won't be willing to reboot just to go to a bank website. And even if they were, a suitably compromised BIOS/EFI could render the additional security worthless.
It's human nature to say, "It won't happen to me," until it does. Nearly everything bad in the world would be prevented if we could simply stamp out that part of human nature.
There are two problems with using fixed cameras for speed measurement. First, in California, where I live, the law explicitly forbids doing that. Second, they can only compute your average speed. In a congestion situation, you might easily miss ticketing someone who is running 15 under the limit for a while, then fifteen over when a lane clears, then back to 15 under. So as I said, cameras on poles aren't able to accurately judge a vehicle's speed.
I'm pretty sure that it is real CPU load. It is caused by a conflict with some network filtering software (e.g. antivirus software, content filtering software, etc.). Try updating the relevant software.