"real" photographers don't use auto-focus, because you're almost guaranteed that it will focus on the wrong thing. When I'm taking point-and-shoot pictures with pocket camera, I have to be careful, and hope that nothing distracts the camera. When I'm doing serious photography with my nicer cameras, it stays in manual mode.
On the contrary, most "real" photographers, at least in my experience, use autofocus almost exclusively. With modern, autofocus lenses, the focus throw is relatively short, so the camera's autofocus system can achieve a much more precise focus than any human eye possibly can. (This, of course, assumes that you've chosen the right autofocus point, but that goes without saying.)
Of course, with manual focus lenses—lenses specifically designed with an extremely long focus throw so that you can focus with a moderate degree of precision—manual focusing becomes at least somewhat practical, but it still takes precious time, making it far more likely that you'll miss that perfect shot while you're getting the shot in focus. If you're photographing landscapes, that extra time isn't a big deal. For photographing anything that moves, opinions vary. Either way, your odds of getting a properly focused "bird in flight" photo using manual focus are comparable to the odds of winning the lottery. Half the time, you're lucky to have time to aim correctly, much less focus.
Sure, there are certainly photographers who refuse to use autofocus. But from what I've seen, those are mostly the same curmudgeons who insist on full manual mode for every shot. The rest of us tend to leave it on autofocus, with the camera in a full or partial automatic exposure mode (e.g. Av, Tv), reserving full manual modes for situations where the automatic modes get it hopelessly wrong (e.g. photographing a play on a flat-black stage).
E85 is 85% ethanol, 15% gasoline, not the other way around. A 10% ethanol blend (10% ethanol, 90% gasoline) is called E10, not E90. Using E10 reduces your fuel economy by about 3–4%, and a 15% blend reduces your miles per tank by about 4–5%, assuming a modern, fuel-injected engine. I would expect the impact to be worse for an engine with a carburetor, but I don't know for certain. Either way, I'm pretty sure it's nowhere near 20% even with older engines.
Yes, if it were legal to sell E90, it would reduce your fuel economy by somewhere in the neighborhood of 20%. Of course, your car wouldn't start in the winter, and in most cars, parts of your fuel system would likely rust out pretty quickly, spewing fuel all over the hot engine, thus ending your life in a blaze of glory, so fuel economy would be the least of your problems....
I'm a little bummed about this. My first reaction was, "Oh, cool. This is just like the idea I had a few days ago." Then, I realized they're trying to do it from a single photo instead of taking advantage of the camera hardware to obtain actual depth info.
You have a lens that can focus. Take your shot, throw the focus off as far as you can (in whichever direction you can move the focus farther, by some definition of farther), then take a second shot. You can then compute some reasonable approximation of distance for every pixel without guessing. You can also likely compute a reasonable bokeh based on the size and location of bright areas in the out-of-focus areas and based on how much they spread in the out-of-focus shot. It's not perfect, but I suspect you could get close enough to fool just about anybody.
Google's self-driving cars have gone 300,000 miles without an accident. That's somewhere in the neighborhood of 30–42 average-teen-driver-years worth of driving. Statistically, about 1 in five teenagers reports having an accident in any given year. So we would expect that the same number of miles driven by teenagers would have resulted in, on average, 6–8 accidents—more if we're talking about teenagers in their first year of driving.
In other words, Google's self-driving cars are already at least an order of magnitude safer than teen drivers. That's probably a statistically significant difference.
You missed one major technical rule: all browsers on iOS that support local rendering are required to use the system rendering engine.
Actually, no, I'm pretty sure they're just not allowed to use any JavaScript engine other than the built-in JavaScriptCore. And as of iOS 7, it's theoretically possible to actually do so without using WebKit.
It's not willful ignorance. It's actually a legitimate question. From everything I've read, there are roughly two types of revenge porn:
Fake revenge porn, in which someone pretends that he or she is getting revenge on a former significant other so that people will be more turned on, but in reality, it's just commercial porn, and legal.
Fake revenge porn, in which someone surreptitiously cracks into the victim's computer and records that person in his or her own home, which is already illegal. And this is what the lawsuits have mainly been about.
I suspect that the real revenge porn, if it even exists, is just about lost in the noise caused by the two forms listed above.
... the homeowner does NOT automatically gain the right to record the guest WITHOUT permission.
If that were true, then "NannyCam" footage would be inadmissable. Different states have different laws that carve out specific places where recording is not allowed—most forbid recording in bathrooms, for example—but as a rule, if you're in someone else's home, you should generally assume that you have little or no right to privacy.
I was referring to normal traffic lights that lack any indication of when the light is about to change, not the rare lights with countdown timers or the hypothetical lights with a dashboard assist. The split-second decision to floor it or slam on the brakes is a bigger problem when you're accelerating from a stop as the light changes to yellow, not when you're going way over the speed limit, for two reasons: A. there may not be any choice that doesn't result in either getting rear-ended or being in the middle of the light when it turns green in the other direction, and B. your foot is on the wrong pedal to stop, adding critical latency to that decision, should you choose to stop.
Actually, it's the opposite. The worst speed to be entering a traffic light is near zero. You've slowed down to a low speed because of someone slowing to turn right ahead of you. The traffic behind you collapses to be nearly bumper to bumper at 15 MPH in a 40 zone. The light is timed for 40 MPH. You don't realize that the light is about to turn yellow, so rather than just coming to a stop, you decide to enter the intersection. Then the light turns yellow and you're moving at a speed that will put you and the two cars behind you in the middle of the intersection when it turns green in the other direction. Whether you floor it to get through the light legally or slam on the brakes and get rear-ended, the car behind you is screwed.
I will gladly contribute money to the election campaign of any otherwise-electable congressional candidate who makes this one of his or her campaign promises.
Well, it is kind of an April Fools story. It says he came out against Prop 8 (a gay marriage ban), which would mean that he was in favor of gay marriage. Unless all the previous stories I've read were wrong, I'm pretty sure they got that backwards.
There's nothing wrong with JavaScript, language-wise. I mean, sure, I'd prefer for closures to be explicit rather than implicit, in part because it tends to confuse the newbies a bit, but otherwise, it's a reasonable language. The problems mostly stem from:
All the built-in functions—the JavaScript DOM, XHR, etc.—which are designed in strange ways that assume everyone understands closures
The single-threaded design (not inherent in the language, but mandated by the DOM spec, IIRC)
Overuse of completion handlers even for things that really don't need them, mainly to workaround the lack of threading
None of those things would improve with a different language except possibly the first one.
... all of them? Seriously the inclusion of a trained Shakespearian actor (Stewart) was the only saving grace of that branch-off of TOS.
come on... it's not like the series didn't have any redeeming qualities at all... is it?
I can think of one really good episode. It involved the captain getting his brain rewired and living an entire lifetime on another planed in a dream induced by an alien probe. Why was it good? Because it focused on one character (played by Patrick Stewart) and really developed him.
The one with Picard leading the kids up the lift shaft was also good.
And I enjoyed the whole "Sometimes a cake is just a cake" episode. I mean, it was absurd, but it was amusing.
Worst episode? Anything with Wesley Crusher. They were almost all painfully written. How many times can a single kid put everybody in mortal danger and then somehow manage to save the day in some contrived fashion?
Why would they need to compromise your CAs? They can compromise any CA, because unless the client uses a tighter-than-normal designated requirement, it will trust any cert for your domain as long as it is signed by any of dozens of CAs. That's what makes TLS so flawed.
Self checkout is just making the customer do the cashiers job for free before realizing that customers suck at doing these things correctly because it's not their job.
So what's the cashiers' excuse for not doing it correctly?:-D
No, seriously. I tend to order things with various customizations (e.g. no [insert ingredient]). I haven't done the math, but I suspect that I have at least a 10% return rate at many businesses. How hard is it to push "Only" followed by the ingredients that the customer specifies? Point-of-sales systems suck, but at least if I'm in control of it, I can see that the order is right, and if it is wrong, it's my fault.
You're on the right track, but that implementation is way more complicated than it needs to be. Any PIN should be handled by the device itself, and should be easy to change to any arbitrary PIN. Or you might even use a fingerprint reader.
You should be able to basically eliminate any additional risk from a modified device or payment terminal (except perhaps the risk of someone physically stealing the device and using it) by doing the crypto as follows:
The business generates the transaction receipt and signs it with its public key.
The user pushes the button on the card to initiate the payment handshake. This causes the device to broadcast a Bluetooth Low Energy beacon.
The payment terminal (computer, POS terminal, cell phone) detects the beacon and sends the transaction receipt to the card.
The device shows the business info, dollar amount, etc. on its screen.
The user presses a button to authorize the transaction.
The device signs the transaction using its private key and sends its response back to the payment terminal.
The payment terminal sends the doubly signed receipt back to a payment processor.
The payment processor verifies the signatures using public keys stored in the business's account and the user's account and verifies whether funds are available.
The payment processor sends back a signed response containing the transaction receipt and a status field that indicates whether the transaction was authorized or not.
The payment terminal provides the signed response to the device so that the user can verify that the payment was accepted or rejected. (This prevents double charging fraud.)
If the signatures are valid and funds are available, the payment processor automatically transfers the funds to the business.
In an ideal world, the transaction would then be applied to the default credit card in your online account profile, but you should have the ability (up to a few days after the transaction) to redirect the transaction to a different card by logging in to your online payments account and saying "Bill it to X". Alternatively, you could have multiple PK pairs, one for each account, and you could choose the account on the device itself.
The way you handle offline sales with this model is also pretty straightforward. You use either a mobile app on your phone or a website on your computer (requires browser support), as follows:
Enter the name of the business.
The payment app provides a list of matching businesses. Choose the right one.
Enter the amount of the payment.
The payment app generates a transaction.
You push a button on the device, and the payment app does the BTLE handshake.
You push another button to authorize the transaction, and the payment app sends it to the payment processor.
The payment app issues a funds hold against your account and gives you a unique transaction ID for that hold. You give that transaction ID to the store.
The store, upon accepting the order, uses that transaction ID to convert the hold into an actual charge.
The existence of that transaction ID in the merchant's account is proof that the payment occurred. At most, the only thing the merchant would have to do to prevent fraud would be to ensure that nobody uses the same transaction ID to pay for more than one purchase. This is, of course, a trivial local database lookup.
You would also need an app (mobile or desktop) that can download the public key from the device (if the device gets stolen, you'll need to associate the new device's public key with your payment account) and occasionally update its firmware to fix any bugs in the crypto code.
Slashdot Mirror
On the contrary, most "real" photographers, at least in my experience, use autofocus almost exclusively. With modern, autofocus lenses, the focus throw is relatively short, so the camera's autofocus system can achieve a much more precise focus than any human eye possibly can. (This, of course, assumes that you've chosen the right autofocus point, but that goes without saying.)
Of course, with manual focus lenses—lenses specifically designed with an extremely long focus throw so that you can focus with a moderate degree of precision—manual focusing becomes at least somewhat practical, but it still takes precious time, making it far more likely that you'll miss that perfect shot while you're getting the shot in focus. If you're photographing landscapes, that extra time isn't a big deal. For photographing anything that moves, opinions vary. Either way, your odds of getting a properly focused "bird in flight" photo using manual focus are comparable to the odds of winning the lottery. Half the time, you're lucky to have time to aim correctly, much less focus.
Sure, there are certainly photographers who refuse to use autofocus. But from what I've seen, those are mostly the same curmudgeons who insist on full manual mode for every shot. The rest of us tend to leave it on autofocus, with the camera in a full or partial automatic exposure mode (e.g. Av, Tv), reserving full manual modes for situations where the automatic modes get it hopelessly wrong (e.g. photographing a play on a flat-black stage).
E85 is 85% ethanol, 15% gasoline, not the other way around. A 10% ethanol blend (10% ethanol, 90% gasoline) is called E10, not E90. Using E10 reduces your fuel economy by about 3–4%, and a 15% blend reduces your miles per tank by about 4–5%, assuming a modern, fuel-injected engine. I would expect the impact to be worse for an engine with a carburetor, but I don't know for certain. Either way, I'm pretty sure it's nowhere near 20% even with older engines.
Yes, if it were legal to sell E90, it would reduce your fuel economy by somewhere in the neighborhood of 20%. Of course, your car wouldn't start in the winter, and in most cars, parts of your fuel system would likely rust out pretty quickly, spewing fuel all over the hot engine, thus ending your life in a blaze of glory, so fuel economy would be the least of your problems....
And they say American beer tastes like...
I'm a little bummed about this. My first reaction was, "Oh, cool. This is just like the idea I had a few days ago." Then, I realized they're trying to do it from a single photo instead of taking advantage of the camera hardware to obtain actual depth info.
You have a lens that can focus. Take your shot, throw the focus off as far as you can (in whichever direction you can move the focus farther, by some definition of farther), then take a second shot. You can then compute some reasonable approximation of distance for every pixel without guessing. You can also likely compute a reasonable bokeh based on the size and location of bright areas in the out-of-focus areas and based on how much they spread in the out-of-focus shot. It's not perfect, but I suspect you could get close enough to fool just about anybody.
Google's self-driving cars have gone 300,000 miles without an accident. That's somewhere in the neighborhood of 30–42 average-teen-driver-years worth of driving. Statistically, about 1 in five teenagers reports having an accident in any given year. So we would expect that the same number of miles driven by teenagers would have resulted in, on average, 6–8 accidents—more if we're talking about teenagers in their first year of driving.
In other words, Google's self-driving cars are already at least an order of magnitude safer than teen drivers. That's probably a statistically significant difference.
Actually, no, I'm pretty sure they're just not allowed to use any JavaScript engine other than the built-in JavaScriptCore. And as of iOS 7, it's theoretically possible to actually do so without using WebKit.
It's not willful ignorance. It's actually a legitimate question. From everything I've read, there are roughly two types of revenge porn:
I suspect that the real revenge porn, if it even exists, is just about lost in the noise caused by the two forms listed above.
If that were true, then "NannyCam" footage would be inadmissable. Different states have different laws that carve out specific places where recording is not allowed—most forbid recording in bathrooms, for example—but as a rule, if you're in someone else's home, you should generally assume that you have little or no right to privacy.
I was referring to normal traffic lights that lack any indication of when the light is about to change, not the rare lights with countdown timers or the hypothetical lights with a dashboard assist. The split-second decision to floor it or slam on the brakes is a bigger problem when you're accelerating from a stop as the light changes to yellow, not when you're going way over the speed limit, for two reasons: A. there may not be any choice that doesn't result in either getting rear-ended or being in the middle of the light when it turns green in the other direction, and B. your foot is on the wrong pedal to stop, adding critical latency to that decision, should you choose to stop.
Actually, it's the opposite. The worst speed to be entering a traffic light is near zero. You've slowed down to a low speed because of someone slowing to turn right ahead of you. The traffic behind you collapses to be nearly bumper to bumper at 15 MPH in a 40 zone. The light is timed for 40 MPH. You don't realize that the light is about to turn yellow, so rather than just coming to a stop, you decide to enter the intersection. Then the light turns yellow and you're moving at a speed that will put you and the two cars behind you in the middle of the intersection when it turns green in the other direction. Whether you floor it to get through the light legally or slam on the brakes and get rear-ended, the car behind you is screwed.
I will gladly contribute money to the election campaign of any otherwise-electable congressional candidate who makes this one of his or her campaign promises.
Well, it is kind of an April Fools story. It says he came out against Prop 8 (a gay marriage ban), which would mean that he was in favor of gay marriage. Unless all the previous stories I've read were wrong, I'm pretty sure they got that backwards.
There's nothing wrong with JavaScript, language-wise. I mean, sure, I'd prefer for closures to be explicit rather than implicit, in part because it tends to confuse the newbies a bit, but otherwise, it's a reasonable language. The problems mostly stem from:
None of those things would improve with a different language except possibly the first one.
A politician.
It wasn't a bad episode, though in retrospect, it kind of felt like a ripoff of Enemy Mine in a lot of ways (the book, that is).
I can think of one really good episode. It involved the captain getting his brain rewired and living an entire lifetime on another planed in a dream induced by an alien probe. Why was it good? Because it focused on one character (played by Patrick Stewart) and really developed him.
The one with Picard leading the kids up the lift shaft was also good.
And I enjoyed the whole "Sometimes a cake is just a cake" episode. I mean, it was absurd, but it was amusing.
Worst episode? Anything with Wesley Crusher. They were almost all painfully written. How many times can a single kid put everybody in mortal danger and then somehow manage to save the day in some contrived fashion?
Why would they need to compromise your CAs? They can compromise any CA, because unless the client uses a tighter-than-normal designated requirement, it will trust any cert for your domain as long as it is signed by any of dozens of CAs. That's what makes TLS so flawed.
You mean we get to keep the desk? If I had known that, I'd have gotten myself fired a long time ago!
So what's the cashiers' excuse for not doing it correctly? :-D
No, seriously. I tend to order things with various customizations (e.g. no [insert ingredient]). I haven't done the math, but I suspect that I have at least a 10% return rate at many businesses. How hard is it to push "Only" followed by the ingredients that the customer specifies? Point-of-sales systems suck, but at least if I'm in control of it, I can see that the order is right, and if it is wrong, it's my fault.
You're on the right track, but that implementation is way more complicated than it needs to be. Any PIN should be handled by the device itself, and should be easy to change to any arbitrary PIN. Or you might even use a fingerprint reader.
You should be able to basically eliminate any additional risk from a modified device or payment terminal (except perhaps the risk of someone physically stealing the device and using it) by doing the crypto as follows:
In an ideal world, the transaction would then be applied to the default credit card in your online account profile, but you should have the ability (up to a few days after the transaction) to redirect the transaction to a different card by logging in to your online payments account and saying "Bill it to X". Alternatively, you could have multiple PK pairs, one for each account, and you could choose the account on the device itself.
The way you handle offline sales with this model is also pretty straightforward. You use either a mobile app on your phone or a website on your computer (requires browser support), as follows:
The existence of that transaction ID in the merchant's account is proof that the payment occurred. At most, the only thing the merchant would have to do to prevent fraud would be to ensure that nobody uses the same transaction ID to pay for more than one purchase. This is, of course, a trivial local database lookup.
You would also need an app (mobile or desktop) that can download the public key from the device (if the device gets stolen, you'll need to associate the new device's public key with your payment account) and occasionally update its firmware to fix any bugs in the crypto code.
AT&T's customers would need a viable alternative first.
Err... steeenking.
The ones with the skunk glands?
Badgers? We don't need no steeeking badgers.
Way to take the high road. You could just as easily have said, "Keep on living," or "Breathe."
... to the obligatory Far Side Eggs and baby cartoon.