The nasty trick in this case is that they shouldn't have had to test against a zillion awful webcams to know that they had a problem.
The USB Video Class Spec and Microsoft's own driver for it defines support for both uncompressed and compressed video output; and for programs to negotiate with a UVC device to change video parameters.
The extra abstraction layer they added between the driver and the applications only supports one uncompressed format; and breaks if you try to negotiate for something different. That's not a weirdo edge case with somebody's ghastly rev. A product that never should have made it out the door; that's "break a substantial portion of a spec we used to support and hope everything turns out for the best". Not good.
It does seem to be the case that any business with 'EZ-franchise' opportunities or heavy use of consumer credit gets pretty slimy; but it's hard to dismiss it as wholly analogous to a 'bubble' when panel prices have continued to fall and people continue to be pretty interested in using electricity.
The vendors might well be chasing a bubble, I suspect that, in the end, it will turn out that selling "own your own business opportunities" will prove more lucrative than owning one of those "opportunities"; but the buyers of the solar capacity (while quite possibly paying the early-adopter penalty for jumping in before the product has matured) aren't really good bubble candidates.
Indeed, it's far from an original concern; but it does seem like one that could be a nagging problem.
Aside from any zOMG Society!!! questions, they are taking on a game-balance issue: people get frustrated when they lose; but get bored of winning if you don't provide the convincing illusion of a challenge. As long as you are just building sex toys, that's not a problem; but it will be trickier to impress people with 'love' that they know has nothing to do with them. Unconditional love is handy because you can't screw it up; but being the recipient of love-so-durable-even-our-customers-can't-fuck-it-up probably won't leave you feeling terribly lovable. Even a puppy is higher standards than that.
There will, surely, be nothing more satisfying than the affection of an expert system that has been tuned to love absolutely anyone whose licensing agreements and software maintenance contract are in order.
There's also the problem that (even if you somehow have a helicopter with operating costs closer to those of a taxi, which would be quite a departure from current models) you can't exactly just land it on any street corner; which means that you'll be limited to relatively patchy coverage around the locations where you can land. Just as with airports, the travel time to and from the landing pads will then make the overall trip time uncompetitive except for longer flights.
It's a good thing that there are absolutely zero terrorism-promoters who might have some level of familiarity with basic automated spamming techniques.
Extra credit for the situations(most common in customer 'support') where the guy in Hyderabad and on the wrong end of a ghastly phone link and a strong accent has enough experience to know that things are totally futile and just resort to the ICAO phonetic alphabet. I can't argue with the strategy as a pragmatic response to the situation they are stuck with(it's not as though the poor bastard working the call center has any power, and he's almost certainly having a worse day than you); but if you want to transmit text over phone lines, a phonetic alphabet encoding would make even an '80s modem experience either pity or scorn.
Even that benefit sometimes gets lost. Text is inferior for conveying emotional nuance; but that fact has been repeated often enough that people sometimes try to compensate by being clearer and more explicit.
Since 'everyone knows' that voice is just so much more emotionally rich, they tend to assume that because you got their voicemail you were able to interpret exactly what they were thinking and feeling when they sent it, no matter how poor the quality or patchy the message.
Dangers that people know about aren't harmless; but at least we sometimes try to avoid them.
Plus, there's the fact that, while a giant pile of email is never a good thing, tools for sorting text are pretty mature and widely available.
Tools for sorting audio? Even the 'cloud' ones, where you give up all pretense of privacy in exchange for access to the really fancy tech trained on a huge dataset, are mediocre and error prone; and standalone speech to text tend to be pricey, poorly integrated, and still only accurate for the user it has been trained on.
If your problem is that you are missing the personal touch, audio might be better; but if your problem is that you are drowning in a sea of inane chatter, text is the closest thing to a solution, short of restructuring your entire life.
Maybe I'm just old and curmudgeonly; but I'm pretty sure that we welcomed email in no small part because of how miserable dealing with voicemail was.
Now some brilliant specimen is patting themselves on the back for reinventing voicemail on top of a new platform? It beats paying international calling rates to your local telco racket and suffering voicemail, I suppose; but that's damning by very, very, faint praise.
The library issue will be interesting to see. As the existence of Origin and U-play demonstrate, there is certainly a desire for Steam competitors(both from those who dream of also extracting transaction costs; and from those who want to avoid their entire business existing at the power and mere pleasure of Valve); but only the most deluded can imagine that Facebook has any interest in being the lesser partner in an arrangement on their precious social network.
Being not-Valve will likely be somewhat attractive; but Facebook's reputation for treatment of their platform thralls isn't good, so anyone using them as a hedge against Valve is likely to be doing so with some caution.
If nothing else, at least Steam doesn't start with the giant pile of user data to enthusiastically tie to whatever abortion of a 'gaming platform' they end up rolling out.
Steam has certainly made strong attempts to add 'social' to the basic buying-games process; but it remains an afterthought. Facebook is likely to make it so exciting and mandatory that it'll make Google's attempt to ram 'plus' down the throat of every user of anything remotely connected to them look like a gentle suggestion.
They bought the 'StrongARM' series from DEC in the late 90s, which became 'Xscale' until it was mostly sold to Marvell in 2005. I think they retained some limited amount of the family for NIC offload and RAID chipsets; but they don't do application processors anymore.
The problem here is that the NSA deliberately sacrificed the opportunity to improve our security in order to retain the effectiveness of their toys and couldn't keep them from being directly pilfered, much less independently discovered.
If, hypothetically, the Manhattan Project had squandered the opportunity to make us nuke-resistant in order to preserve the utility of their weapon; then, yes, I'd say that they screwed up pretty atrociously. The difference, of course, is that no such option existed, while the process of disclosing bugs to vendors is very much an option.
The "you aren't the only ones who could exploit those vulnerabilities" argument was previously largely hypothetical; now, not so much.
Now, if you had just disclosed those vulnerabilities they could probably have been fixed by now. Instead, you failed at keeping them a secret and unknown unsavory parties have a handy trove of exploits ready to be used. I'm not sure that this is what "National Security" looks like, and that's kind of your job.
They also announced(though I can't find a price) a "Euclid" device that does include the camera and the computer; specs aren't specified beyond 'atom processor' but it would be pretty unsurprising if that hardware is either built around one of these modules or very similar in specs; but the camera is not included with this one.
It's obviously x86 based; but Intel's big push with this thing appears to be their "realsense" camera and machine vision stuff. They obviously aren't going to forbid other uses; but that seems to be the feature they were most interested in repeating themselves about.
"Because the Intel Joule platform is based on an Intel® Atom SoC, transitioning a
product design to high-volume production can be done with modest engineering expense, providing
a mature platform for companies who require the option to scale down the road."
That suggests that the asking price, even in volume, is going to be at least modestly higher than the cost of stuffing the same parts onto your board; unless compactness is the only reason a customer would care about cutting the module and connector out of the design; but they probably care more about moving CPUs than about charging a markup on that specific packaging option, so I'd assume that they would offer the same deal for the SoC and wifi module whether purchased for your own board or integrated onto their board; with the cost of the rest of the assembly not being given away; but not being something it would make sense to mark up too much.
ARK doesn't list either of those Atom parts, though, so I don't know what the SoC itself would be expected to cost.
Yes and no: the interactions between the browser and the CDM defined by the 'encrypted media extension' stuff are indeed pretty narrow; but the spec allows, and deliberately doesn't not define, what the CDM itself does, what privileges it runs with, and so on. There are a few plaintive encouragements to avoid incompetence or malice; but those are optional. It is less likely to be useful for attacking the browser than an NPAPI plugin is; but the security and behavior of the CDM itself are restricted only by the vendor's implementation choices.
I'm sure there's a perfectly reasonable explanation for how helping protect Fiji's military government from possible plots connects with the goal of protecting the US from terrorism, right?
Was the NSA trying to protect the TSA from dehydration by ensuring that American air travelers would continue to have that Fiji bottled water to confiscate?
If something is relatively scarce, isn't volume(combined with sorting) essentially the only option? I suspect that the fuzzy optimists who think that just increasing access to CS courses will get all the kiddies involved in Tomorrow's App Economy or some nonsense are going to be disappointed; but the difference between the optimists and the pessimists isn't really a question of how many people you want to evaluate for potential; just what percentage of them you expect to wash out.
There is an element of public delusion to this, in that it isn't polite to mention the suspicion that most of your eager students will be culled or identified as mediocre and relegated to grunt work; but the more pessimistic you are about the quality of the average candidate, the greater your incentive to evaluate as many as possible to find the really promising ones.
I'm willing to make an exception for the original batch of emoji: unicode has plenty of other miscellanious symbols and dingbats and the custom of adding specific chunks of 'bad unicode practice' characters in order to facilitate the demise of legacy encodings is a longstanding and accepted one.
Beyond that point, though, things descended into insanity. Unicode already has a nearly hopeless task(encode all the symbols used in natural langages, plus some other math, phonetic, etc. stuff? That is...ambitious.); and its design is really best suited to alphabet-based languages and technical stuff with restricted symbol sets, which are effectively alphabets without a natural language. Character-based languages and ones with a need for digraphs and ligatures and such are more difficult and complex; but some major world languages qualify, so they are worth the effort. Pictographic stuff is a just plain lousy fit for Unicode's glyph/rendering concept, since the glyph and the rendering aren't really easy to separate when dealing with pictographs. You can get away with it for largely static pictographic symbol sets(various dead languages, Egyption hieroglyphs, Linear A and B, etc. have been included for the convenience of scholars in those areas; and it isn't elegant but you don't have somebody demanding a new glyph every ten minutes so it's largely inert); but for 'living' pictographic applications, especially ones with both a constant parade of new proposals and various hot-button demands for changes(guns, skin tones, assorted family representations, etc.) Unicode is a terrible fit and the task is essentially unbounded.
I don't know if the better approach is something along the lines of the one you describe, with a specially tagged string that gets a picture if available or is displayed as a fallback if not; or whether an image-based approach for the standardized embedding of small PNG images in text streams(or something to that effect, I leave the question of best implementation to the experts) is the better way to go; but Unicode sure as hell isn't the correct answer.
I imagine that the problem is complicated by the fact that a lot of emoji are transferred in situations where the message might go over one of the newer, fully IP based, messaging services; but also might end up being shoved into an SMS/MMS(and possibly both, if you send a message to multiple people who are receiving it on different devices with different service plans); so some of the more flexible and architecturally sane options would work fine on the newer messaging mechanisms; but if you want little pictures in SMS overloading Unicode is certainly cheaper than having a message with some emoji in it end up being broken into a bunch of MMS messages(each billed separately and typically at a higher rate than SMS) and then reassembled.
The fact that SMS needs to die is a separate issue; but I suspect that it isn't helping in this case.
Aside from his foray into hedge funds, which went...poorly.... Thiel has a pretty decent track record as a VC; but if he weren't a real person I'd assume that he was a ham-fisted parody of a randroid libertarian written by somebody setting up a strawman.
Slashdot Mirror
The nasty trick in this case is that they shouldn't have had to test against a zillion awful webcams to know that they had a problem.
The USB Video Class Spec and Microsoft's own driver for it defines support for both uncompressed and compressed video output; and for programs to negotiate with a UVC device to change video parameters.
The extra abstraction layer they added between the driver and the applications only supports one uncompressed format; and breaks if you try to negotiate for something different. That's not a weirdo edge case with somebody's ghastly rev. A product that never should have made it out the door; that's "break a substantial portion of a spec we used to support and hope everything turns out for the best". Not good.
It does seem to be the case that any business with 'EZ-franchise' opportunities or heavy use of consumer credit gets pretty slimy; but it's hard to dismiss it as wholly analogous to a 'bubble' when panel prices have continued to fall and people continue to be pretty interested in using electricity.
The vendors might well be chasing a bubble, I suspect that, in the end, it will turn out that selling "own your own business opportunities" will prove more lucrative than owning one of those "opportunities"; but the buyers of the solar capacity (while quite possibly paying the early-adopter penalty for jumping in before the product has matured) aren't really good bubble candidates.
Indeed, it's far from an original concern; but it does seem like one that could be a nagging problem.
Aside from any zOMG Society!!! questions, they are taking on a game-balance issue: people get frustrated when they lose; but get bored of winning if you don't provide the convincing illusion of a challenge. As long as you are just building sex toys, that's not a problem; but it will be trickier to impress people with 'love' that they know has nothing to do with them. Unconditional love is handy because you can't screw it up; but being the recipient of love-so-durable-even-our-customers-can't-fuck-it-up probably won't leave you feeling terribly lovable. Even a puppy is higher standards than that.
That's just Best Korea being decades ahead of the rest of the world in controlling light pollution. Surely not a surprise?
There will, surely, be nothing more satisfying than the affection of an expert system that has been tuned to love absolutely anyone whose licensing agreements and software maintenance contract are in order.
There's also the problem that (even if you somehow have a helicopter with operating costs closer to those of a taxi, which would be quite a departure from current models) you can't exactly just land it on any street corner; which means that you'll be limited to relatively patchy coverage around the locations where you can land. Just as with airports, the travel time to and from the landing pads will then make the overall trip time uncompetitive except for longer flights.
I'm going with "Most euphoric mood only state capable of bearing crushing burden of getting shit done; otherwise too bleak and hopeless." on this one.
It's a good thing that there are absolutely zero terrorism-promoters who might have some level of familiarity with basic automated spamming techniques.
Otherwise this would seem pretty futile.
Extra credit for the situations(most common in customer 'support') where the guy in Hyderabad and on the wrong end of a ghastly phone link and a strong accent has enough experience to know that things are totally futile and just resort to the ICAO phonetic alphabet. I can't argue with the strategy as a pragmatic response to the situation they are stuck with(it's not as though the poor bastard working the call center has any power, and he's almost certainly having a worse day than you); but if you want to transmit text over phone lines, a phonetic alphabet encoding would make even an '80s modem experience either pity or scorn.
Even that benefit sometimes gets lost. Text is inferior for conveying emotional nuance; but that fact has been repeated often enough that people sometimes try to compensate by being clearer and more explicit.
Since 'everyone knows' that voice is just so much more emotionally rich, they tend to assume that because you got their voicemail you were able to interpret exactly what they were thinking and feeling when they sent it, no matter how poor the quality or patchy the message.
Dangers that people know about aren't harmless; but at least we sometimes try to avoid them.
Plus, there's the fact that, while a giant pile of email is never a good thing, tools for sorting text are pretty mature and widely available.
Tools for sorting audio? Even the 'cloud' ones, where you give up all pretense of privacy in exchange for access to the really fancy tech trained on a huge dataset, are mediocre and error prone; and standalone speech to text tend to be pricey, poorly integrated, and still only accurate for the user it has been trained on.
If your problem is that you are missing the personal touch, audio might be better; but if your problem is that you are drowning in a sea of inane chatter, text is the closest thing to a solution, short of restructuring your entire life.
Maybe I'm just old and curmudgeonly; but I'm pretty sure that we welcomed email in no small part because of how miserable dealing with voicemail was.
Now some brilliant specimen is patting themselves on the back for reinventing voicemail on top of a new platform? It beats paying international calling rates to your local telco racket and suffering voicemail, I suppose; but that's damning by very, very, faint praise.
The library issue will be interesting to see. As the existence of Origin and U-play demonstrate, there is certainly a desire for Steam competitors(both from those who dream of also extracting transaction costs; and from those who want to avoid their entire business existing at the power and mere pleasure of Valve); but only the most deluded can imagine that Facebook has any interest in being the lesser partner in an arrangement on their precious social network.
Being not-Valve will likely be somewhat attractive; but Facebook's reputation for treatment of their platform thralls isn't good, so anyone using them as a hedge against Valve is likely to be doing so with some caution.
If nothing else, at least Steam doesn't start with the giant pile of user data to enthusiastically tie to whatever abortion of a 'gaming platform' they end up rolling out.
Steam has certainly made strong attempts to add 'social' to the basic buying-games process; but it remains an afterthought. Facebook is likely to make it so exciting and mandatory that it'll make Google's attempt to ram 'plus' down the throat of every user of anything remotely connected to them look like a gentle suggestion.
They bought the 'StrongARM' series from DEC in the late 90s, which became 'Xscale' until it was mostly sold to Marvell in 2005. I think they retained some limited amount of the family for NIC offload and RAID chipsets; but they don't do application processors anymore.
The problem here is that the NSA deliberately sacrificed the opportunity to improve our security in order to retain the effectiveness of their toys and couldn't keep them from being directly pilfered, much less independently discovered.
If, hypothetically, the Manhattan Project had squandered the opportunity to make us nuke-resistant in order to preserve the utility of their weapon; then, yes, I'd say that they screwed up pretty atrociously. The difference, of course, is that no such option existed, while the process of disclosing bugs to vendors is very much an option.
The "you aren't the only ones who could exploit those vulnerabilities" argument was previously largely hypothetical; now, not so much.
Now, if you had just disclosed those vulnerabilities they could probably have been fixed by now. Instead, you failed at keeping them a secret and unknown unsavory parties have a handy trove of exploits ready to be used. I'm not sure that this is what "National Security" looks like, and that's kind of your job.
They also announced(though I can't find a price) a "Euclid" device that does include the camera and the computer; specs aren't specified beyond 'atom processor' but it would be pretty unsurprising if that hardware is either built around one of these modules or very similar in specs; but the camera is not included with this one.
It's obviously x86 based; but Intel's big push with this thing appears to be their "realsense" camera and machine vision stuff. They obviously aren't going to forbid other uses; but that seems to be the feature they were most interested in repeating themselves about.
Their promotional literature says the following:
"Because the Intel Joule platform is based on an Intel® Atom SoC, transitioning a product design to high-volume production can be done with modest engineering expense, providing a mature platform for companies who require the option to scale down the road."
That suggests that the asking price, even in volume, is going to be at least modestly higher than the cost of stuffing the same parts onto your board; unless compactness is the only reason a customer would care about cutting the module and connector out of the design; but they probably care more about moving CPUs than about charging a markup on that specific packaging option, so I'd assume that they would offer the same deal for the SoC and wifi module whether purchased for your own board or integrated onto their board; with the cost of the rest of the assembly not being given away; but not being something it would make sense to mark up too much.
ARK doesn't list either of those Atom parts, though, so I don't know what the SoC itself would be expected to cost.
Yes and no: the interactions between the browser and the CDM defined by the 'encrypted media extension' stuff are indeed pretty narrow; but the spec allows, and deliberately doesn't not define, what the CDM itself does, what privileges it runs with, and so on. There are a few plaintive encouragements to avoid incompetence or malice; but those are optional. It is less likely to be useful for attacking the browser than an NPAPI plugin is; but the security and behavior of the CDM itself are restricted only by the vendor's implementation choices.
I'm sure there's a perfectly reasonable explanation for how helping protect Fiji's military government from possible plots connects with the goal of protecting the US from terrorism, right?
Was the NSA trying to protect the TSA from dehydration by ensuring that American air travelers would continue to have that Fiji bottled water to confiscate?
If something is relatively scarce, isn't volume(combined with sorting) essentially the only option? I suspect that the fuzzy optimists who think that just increasing access to CS courses will get all the kiddies involved in Tomorrow's App Economy or some nonsense are going to be disappointed; but the difference between the optimists and the pessimists isn't really a question of how many people you want to evaluate for potential; just what percentage of them you expect to wash out.
There is an element of public delusion to this, in that it isn't polite to mention the suspicion that most of your eager students will be culled or identified as mediocre and relegated to grunt work; but the more pessimistic you are about the quality of the average candidate, the greater your incentive to evaluate as many as possible to find the really promising ones.
I'm willing to make an exception for the original batch of emoji: unicode has plenty of other miscellanious symbols and dingbats and the custom of adding specific chunks of 'bad unicode practice' characters in order to facilitate the demise of legacy encodings is a longstanding and accepted one.
Beyond that point, though, things descended into insanity. Unicode already has a nearly hopeless task(encode all the symbols used in natural langages, plus some other math, phonetic, etc. stuff? That is...ambitious.); and its design is really best suited to alphabet-based languages and technical stuff with restricted symbol sets, which are effectively alphabets without a natural language. Character-based languages and ones with a need for digraphs and ligatures and such are more difficult and complex; but some major world languages qualify, so they are worth the effort. Pictographic stuff is a just plain lousy fit for Unicode's glyph/rendering concept, since the glyph and the rendering aren't really easy to separate when dealing with pictographs. You can get away with it for largely static pictographic symbol sets(various dead languages, Egyption hieroglyphs, Linear A and B, etc. have been included for the convenience of scholars in those areas; and it isn't elegant but you don't have somebody demanding a new glyph every ten minutes so it's largely inert); but for 'living' pictographic applications, especially ones with both a constant parade of new proposals and various hot-button demands for changes(guns, skin tones, assorted family representations, etc.) Unicode is a terrible fit and the task is essentially unbounded.
I don't know if the better approach is something along the lines of the one you describe, with a specially tagged string that gets a picture if available or is displayed as a fallback if not; or whether an image-based approach for the standardized embedding of small PNG images in text streams(or something to that effect, I leave the question of best implementation to the experts) is the better way to go; but Unicode sure as hell isn't the correct answer.
I imagine that the problem is complicated by the fact that a lot of emoji are transferred in situations where the message might go over one of the newer, fully IP based, messaging services; but also might end up being shoved into an SMS/MMS(and possibly both, if you send a message to multiple people who are receiving it on different devices with different service plans); so some of the more flexible and architecturally sane options would work fine on the newer messaging mechanisms; but if you want little pictures in SMS overloading Unicode is certainly cheaper than having a message with some emoji in it end up being broken into a bunch of MMS messages(each billed separately and typically at a higher rate than SMS) and then reassembled.
The fact that SMS needs to die is a separate issue; but I suspect that it isn't helping in this case.
Aside from his foray into hedge funds, which went...poorly.... Thiel has a pretty decent track record as a VC; but if he weren't a real person I'd assume that he was a ham-fisted parody of a randroid libertarian written by somebody setting up a strawman.