Yeah, I shouldn't have described it like that - my bad (see retraction above). It's been a while since I worked on PS games, and I think I remembered them as a little more OpenGL-like than they were. The PS2 was nothing like OpenGL, while the PS3 native libs were vaguely similar, but certainly not OpenGL in any sense.
I shipped PS2, PS3, Gamecube, Xbox, and Xbox 360 titles, but I've been out of consoles after that (PC only for quite a few years), so I'll defer to your knowledge on current-gen APIs. The PS2 was certainly not very similar to OpenGL (very low-level stuff), but I remember the PS3's libgcm being somewhat similar to earlier OpenGL versions, although the SPUs made it much more challenging, and the focus on the command buffer was a bit different. Still, you could more or less substitute many of the basic function calls, and terminology was certainly closer to OpenGL than DirectX. The Gamecube was much more similar to OpenGL than Sony's libraries from what I recall, and much easier to use.
I suppose it's still a bit of a misnomer, because console APIs have always allowed much more direct access to hardware, since there's less of a need for layers of abstraction (as the underlying hardware doesn't really change). As such, I think you're correct in that "inspired by OpenGL" is probably more accurate than "customized OpenGL", and probably much more appropriate in the case of Nintendo's consoles. So, correction noted.
I still dont know why the desktop is and ever was a battle ground, Linux / Android has won the Mobile space. M$ can take the hit when the desktop goes, the lack luster sales of new PC hardware vs mobile ( tablet etc etc ) is telling.
More than simple sales, the PC is where games (and in fact nearly ALL content) is actually created. Phones and tablets are fine for consuming content, but horrible for *creating* content. It's an open platform where people can generally do whatever they want with their hardware, and it's the most powerful computing device a consumer can generally purchase.
Smartphones and tablets are relatively new devices. As soon as the market is saturated and the technology matures, sales will drop off sharply, and you'll hear pundits moaning about the "demise" of those platforms as well. In fact, that's already happening with tablets, and I predict you'll start seeing the same thing with smartphones in another four or five years, maybe even sooner. Fewer and fewer people will be willing to purchase new phones every year or two in perpetuity.
Phones and tablets are much better consumer-level devices than PCs ever were. PCs are just moving into a new and arguably better niche as the most powerful line of computers for people who need or want to do more than a mobile device allows. The reason PC sales have dropped off considerably is that a) the worldwide market has been largely saturated, and b) computers have ridiculously powerful hardware for what most of them are required to do, so they don't need to be replaced nearly as often as they used to be.
Yep, I don't disagree with you. When I talked about optimizations, I was of course only talking about case 1. Anything above that certainly requires human-level work, and typically a substantial effort and deeper knowledge of the compiler and platform.
I wonder if the compiler does a better job if const is properly used? It's meant as a compiler hint, so that the compiler can be more aggressive because it knows there are supposed to be no side effects in the functions.
Also, I'd have a serious talk with a programmer who wrote crap like that in the first place.;-)
You have to consider that compilers are also going to perform a wide variety of micro-optimizations that humans simply couldn't do on a massive scale, over millions of lines of code. No one would argue that a compiler can radically restructure your algorithms during optimization, because it doesn't know which side-effects are acceptable and which are not. So, yes, human programmers still need to be aware of how to structure code for best results on a given platform.
Of course, you can always find specific examples to highlight where optimizing compilers fail badly, and then build examples to highlight that deficiency. I took a quick look at that video, and to be honest, it seems a bit contrived, although interesting enough that I may watch it in full later. Thanks for the link.
I'm not trying to slam C. You can do just about anything in C - that's one of it's strengths. I'm just pointing out that it's not the *optimal* choice for certain types of tasks, in my opinion. C has advantages in it's relative simplicity, portability, and power. Moreover, it works very well as a "least common denominator" language, in that nearly every other language can easily interop with it because of it's stable ABI. This is why nearly every OS and many widely-used libraries are written in pure C.
That being said, it's very easy to make simple mistakes in C that can cause significant security or stability issues. The notion that you simply need to be "competent" in C to avoid making critical mistakes is a fallacy. ALL programmers make mistakes, as we're only human. There's really no getting around the fact that the language is inherently dangerous.
One of C++'s strength is that it allows you to create zero-cost or near-zero-cost abstractions that prevent the programmer from making those mistakes. C simply doesn't have those same mechanisms. Of course, this comes at the cost of language complexity.
There's a reason we have a wide variety of languages available - they all have different strengths and weaknesses. As for anyone believes a single language to be the end-all and be-all, I'd submit they simply don't have enough experience in other languages to make that judgement.
Which part of what I wrote in particular are you calling "wrong"? The 1963 date? Yeah, I should have said "was used in combat in Vietnam", as the Air Force was indeed first with it's order. I had forgotten about that.
It's true that LeMay had a early hand in that mess. McNamara had some blame by forcing the Army adoption before the weapon was ready, and the Army Ordinance board had some blame for actively trying to sabotage the weapon, because they didn't want to give up the M-14.
Because McNamara was ultimately the one who made the final decision, I guess I tend to place the lion's share of the blame on him. Moreover, once reports came back about failures in the field, McNamara didn't listen to them, believing it was more lies from the Army, when soldiers were actually dying because of those failures. And of course, since the Army ordinance dept wanted the weapon to fail, they didn't push for necessary improvements like they should have. As such, it took a very long time for those issues to be corrected.
It was a rather complex and sordid affair, and there's a lot of blame to be spread around. The point I was trying to make, though, is that it's fairly silly to try to blame Nixon in 1969. I imagine you'll at least agree with me on that point.
Well, that places all of the major players on the side of Vulkan. So long DX12 and Microsoft lock-in.
Nintendo has historically used a customized version of OpenGL for their APIs, as has Sony. So, no one should be surprised to see them take part in this development effort, because these are hardware manufacturers developing their own platforms.
However, every major cross-platform developer or publisher was ALSO likely involved in or closely following the development of DirectX 12. That is, cross-platform developer don't "pick a side" in API wars. These developers have already structured their engine to be largely platform independent, including the renderer. My own little game engine supports DX9, DX11 and OpenGL 4.3. While it's not trivial to do, it's not terribly difficult either, as there are a lot of fundamental similarities between those APIs.
I'm betting that DX12 and Khronos will have many similarities as well. Future game engines will be based on the intersection of features between these two APIs, just like what has happened with previous versions. As far as I've heard, they're both largely rewrites, with similar goals: minimal driver interference, low level APIs used to communicate efficiently communicate with modern shader-based hardware. As such, it stands to reason that Khronos will use similar approaches to accessing the same hardware that DX12 needs to access.
It doesn't look like Windows 10 will flop - Steam HW survey shows it as a very rapidly growing market share of OSes - already at 17%. According to Steam, Windows in total is just under 96%, OS X at a bit over 3%, and Linux is under 1%. Note that these are gaming machines, not general purpose machines, but that's relevant for this discussion.
I really wish OS X and Linux had more inroads in the desktop. I really, really do, but it's a fantasy at this point to think that a new graphics API will somehow break Microsoft's death grip on the desktop.
Just to remind potential programmers. Lean C before you learn any other programming language, otherwise you will not understand why your code's performance is terrible.
It may not be apparent even then. Java looks an awful lot like C++ at the code level. So... what's different? Java (and other managed languages like C#) have a bunch of neat features like reflection and automatic memory management, which inherently comes at the cost of runtime efficiency. Simply learning C or C++ won't point out exactly why those languages are so much faster than managed languages. You can write nearly the same code in C++, Java, and C#, and you'll see C++ win performance benchmarks - at least in all but the most contrived examples.
Among the more significant differences are that C++ compilers are extremely good at optimizing, and C++ code generally compiles down to better cache-coherent structures than other languages. The difference is in the language itself, which adheres to a zero-cost principle, in that you don't pay for features you don't use. A lot of C++ abstractions are eliminated *entirely* at runtime, and are only used to protect the code's integrity during the compilation phase. We were told for years that native-equivalent performance was just around the corner or even already here, and it just never really happened outside of small, contrived benchmarks.
I don't think it's necessary to always learn C or C++ first, although I do think it's worthwhile to learn it at some point, simply because there's a lot of it out there. I'm primarily a C++ programmer myself, but I tend to be a bit more pragmatic about language preference. Use the language that's right for the job. For example, C is a *horrible* choice if you're writing a simple application that needs to do a bunch of string processing. In many cases, high performance isn't even a consideration, rather than correctness, security, and development speed.
Nixon committed a war crime in 1969 when he made it the standard rifle for the U.S. Army. He should have been put in prison for that.
The weapon first entered service in 1963 in Vietnam. You should be blaming McNamara, in Kennedy's administration, who ramrodded the damned thing through before it was properly field-ready. There were a number of issues - lack of chromed barrel, change in powder type, no cleaning kits, etc - which decreased it's efficiency and reliability in the field. It was in those early years between 1963 and 1969 that the most issues were reported.
By 1967, the weapon was significantly improved with the M16A1 variant, and by 1969, when the weapon was standardized, it was a good, reliable weapon, according to field reports. Because of earlier problems, though, a lot of servicemen continued to be wary of the weapon.
You can blame Nixon for a lot of things, but the M-16 debacle wasn't one of them.
The tainted version of Xcode was downloaded from a server in China that developers may have used because it allowed for faster downloads than using Apple's U.S. servers, Olson said.
Really? Really?!?
From the context in the article, it obviously sounds like these were Chinese developers. You click on the Apple app store, and Xcode downloads for free. I'm not sure how it could be easier - if speed was the issue, just update overnight. I can't figure out what the exact angle is, but it just seems too strange for legitimate developers to "innocently" make such a boneheaded mistake.
Or, maybe Chinese developers are so used to just downloading everything illegally that they didn't think twice about this.
The entire reason we want these things as plugins is so that I don't have to have them installed if I don't use them. Turning executable code a plugin does NOT make it insecure. The only thing a plug-in does is to make that code *optional* for each user. You want a minimal default attack surface, and adding built-in extras broadens that surface unnecessarily.
The reason Flash, Java, and Acrobat Reader plugins are insecure is because they were written long before internet security was a thing. Even today we're seeing new zero-day exploits in Flash that give arbitrary data user-level access. Why does anyone believe that the Skype codebase won't be subject to the same sort of attacks and vulnerabilities once it becomes part of the browser?
Please don't run executable code inside my document viewer.
kthxbye
A built in Skype client? Sweet! Now when a vulnerability is found in this or the Object RTC API implementation, everyone using the Edge browser will be vulnerable by default, and without a way of disabling it.
Building extra crap like this directly into the browser is a horrible idea. People were rightly upset when Firefox tried to pull that nonsense, and MS should be discouraged from going down that road as well. They should focus on building a robust plugin framework (just use Chrome's, and you'll get a big jump on creating an ecosystem), and then they can create a Skype plugin that will work on nearly every major browser out there.
Leave it to Microsoft. They strip all the cruft out of their old browser, then immediately start adding new cruft.
I suppose it makes more sense to be more precise in a company that actually makes paper boxes, but in general, it's still just pissing against the wind. You can be technically correct, but it doesn't matter, as 99.99% of the population will still incorrectly call corrugated fiberboard "cardboard" (especially "cardboard boxes"). Over time, as usage approaches critical mass, the old "incorrect" definition will always become the new "correct" definition. Then, there will be a historical footnote explaining the discrepancy. That's how language works.
A simple list, even one in electronic form, is not really a personal assistant, is it? I think the term "personal assistant" implies the ability to actively do things for you, like answer questions, collecting information, etc.
So, was the Wright Flyer not a real airplane because it could only travel very slowly over short distances? By that logic, the first "real" airplane would perhaps be the first operational jet-powered aircraft, like the Messerschmidt ME 262. Or maybe we'd choose the first all-metal monoplane, like the Junkers J 1?
I'm pretty sure most people agree on the basic definition of a "submarine" (a watercraft capable of independent operation underwater.), and even much earlier and more primitive vehicles quality by that definition.
tl;dr, it's a sales opportunity tracking ticket in Salesforce. Which is probably why he was using that lingo at a Salesforce conference. Presumably Cortana would have had access to his Salesforce accounts somehow. Or, more likely, a fake account with humorous "at-risk" customers like Apple and Google or something.
Ah, got it. That makes a *lot* more sense now. Thanks for the explanation.
My bet is that no car manufacturer wants to deal with having to design a charging station standard which requires people to hook it up, step away, AND have a method for ensuring that there is zero possibility of someone within the area.
Yeah, we should stick to something safer, like highly flammable liquids with explosive vapor clouds.
I grew up with a Honda Civic and an old Ford van in my family. As a youngster, whenever I looked under the hood, I marveled that people used to be able to work on cars themselves. I eventually got a chance to peek under the hood of some older car from the 60's (I forget the make/model), and I finally understood. Wow, cars engines were a LOT simpler back then, and what's more, the engine compartment wasn't nearly so cluttered. There was actually enough room to get in and work on things, and you could clearly see all the critical components of the engine and figure out how they worked for the most part.
Early computers were a bit like this as well. Think about how simple and minimalist a command-line interface (when that's ALL you had) was compared to the layers and layers of abstraction you have in the OS today. There's no doubt both the hardware and software is vastly more powerful today, but I'd imagine it's actually quite a bit harder for a student today to get a real grasp on what the computer is actually doing at a fundamental level. There's simply a hell of a lot more to learn, so programmers are necessarily becoming specialists.
I don't see this as a bad thing, because it simply means computers are reaching an appropriate level of maturity as devices intended for use by lay-persons, rather than exclusively by and for specialists. We "specialists" occasionally grumble about attempts to "dumb down" computers, but by and large, I think it's a good thing that computing is now ubiquitous, as it's added a tremendous amount of convenience to everyone's lives. And besides, the broader that market is, the more opportunity we have to earn a living writing software for the benefit of the masses.
The trend is actually reversing in some ways. Many kids are no longer interested in tinkering with PCs - which used to be a near requirement just to get them to work. They just see them as appliances now, about as interesting or exciting as their refrigerator, except for what it can DO for them. And it's often easier and more convenient for them to simply use their iPad.
So, no, I just don't see a world in which everyone is a programmer. There will certainly be a lot MORE programmers than ever, but it will still be viewed as something of a black art by the rest of the population. It's no different than an auto mechanic in that regard. The average person nowadays opens the hood of their cars and their eyes glaze over. They have no idea how to fix anything in there, and they don't want to know. There are people who do that for a living, and it's far more efficient to simply pay someone else to fix it.
Seriously, can you imagine an average person wanting to program something for themselves to scratch some itch, or do you think they'll just find a $5 app to take care of it for them? The second scenario sounds a hell of a lot more likely to me.
Slashdot Mirror
Yeah, I shouldn't have described it like that - my bad (see retraction above). It's been a while since I worked on PS games, and I think I remembered them as a little more OpenGL-like than they were. The PS2 was nothing like OpenGL, while the PS3 native libs were vaguely similar, but certainly not OpenGL in any sense.
I shipped PS2, PS3, Gamecube, Xbox, and Xbox 360 titles, but I've been out of consoles after that (PC only for quite a few years), so I'll defer to your knowledge on current-gen APIs. The PS2 was certainly not very similar to OpenGL (very low-level stuff), but I remember the PS3's libgcm being somewhat similar to earlier OpenGL versions, although the SPUs made it much more challenging, and the focus on the command buffer was a bit different. Still, you could more or less substitute many of the basic function calls, and terminology was certainly closer to OpenGL than DirectX. The Gamecube was much more similar to OpenGL than Sony's libraries from what I recall, and much easier to use.
I suppose it's still a bit of a misnomer, because console APIs have always allowed much more direct access to hardware, since there's less of a need for layers of abstraction (as the underlying hardware doesn't really change). As such, I think you're correct in that "inspired by OpenGL" is probably more accurate than "customized OpenGL", and probably much more appropriate in the case of Nintendo's consoles. So, correction noted.
I still dont know why the desktop is and ever was a battle ground, Linux / Android has won the Mobile space. M$ can take the hit when the desktop goes, the lack luster sales of new PC hardware vs mobile ( tablet etc etc ) is telling.
More than simple sales, the PC is where games (and in fact nearly ALL content) is actually created. Phones and tablets are fine for consuming content, but horrible for *creating* content. It's an open platform where people can generally do whatever they want with their hardware, and it's the most powerful computing device a consumer can generally purchase.
Smartphones and tablets are relatively new devices. As soon as the market is saturated and the technology matures, sales will drop off sharply, and you'll hear pundits moaning about the "demise" of those platforms as well. In fact, that's already happening with tablets, and I predict you'll start seeing the same thing with smartphones in another four or five years, maybe even sooner. Fewer and fewer people will be willing to purchase new phones every year or two in perpetuity.
Phones and tablets are much better consumer-level devices than PCs ever were. PCs are just moving into a new and arguably better niche as the most powerful line of computers for people who need or want to do more than a mobile device allows. The reason PC sales have dropped off considerably is that a) the worldwide market has been largely saturated, and b) computers have ridiculously powerful hardware for what most of them are required to do, so they don't need to be replaced nearly as often as they used to be.
Yep, I don't disagree with you. When I talked about optimizations, I was of course only talking about case 1. Anything above that certainly requires human-level work, and typically a substantial effort and deeper knowledge of the compiler and platform.
I wonder if the compiler does a better job if const is properly used? It's meant as a compiler hint, so that the compiler can be more aggressive because it knows there are supposed to be no side effects in the functions.
Also, I'd have a serious talk with a programmer who wrote crap like that in the first place. ;-)
You have to consider that compilers are also going to perform a wide variety of micro-optimizations that humans simply couldn't do on a massive scale, over millions of lines of code. No one would argue that a compiler can radically restructure your algorithms during optimization, because it doesn't know which side-effects are acceptable and which are not. So, yes, human programmers still need to be aware of how to structure code for best results on a given platform.
Of course, you can always find specific examples to highlight where optimizing compilers fail badly, and then build examples to highlight that deficiency. I took a quick look at that video, and to be honest, it seems a bit contrived, although interesting enough that I may watch it in full later. Thanks for the link.
I'm not trying to slam C. You can do just about anything in C - that's one of it's strengths. I'm just pointing out that it's not the *optimal* choice for certain types of tasks, in my opinion. C has advantages in it's relative simplicity, portability, and power. Moreover, it works very well as a "least common denominator" language, in that nearly every other language can easily interop with it because of it's stable ABI. This is why nearly every OS and many widely-used libraries are written in pure C.
That being said, it's very easy to make simple mistakes in C that can cause significant security or stability issues. The notion that you simply need to be "competent" in C to avoid making critical mistakes is a fallacy. ALL programmers make mistakes, as we're only human. There's really no getting around the fact that the language is inherently dangerous.
One of C++'s strength is that it allows you to create zero-cost or near-zero-cost abstractions that prevent the programmer from making those mistakes. C simply doesn't have those same mechanisms. Of course, this comes at the cost of language complexity.
There's a reason we have a wide variety of languages available - they all have different strengths and weaknesses. As for anyone believes a single language to be the end-all and be-all, I'd submit they simply don't have enough experience in other languages to make that judgement.
Which part of what I wrote in particular are you calling "wrong"? The 1963 date? Yeah, I should have said "was used in combat in Vietnam", as the Air Force was indeed first with it's order. I had forgotten about that.
It's true that LeMay had a early hand in that mess. McNamara had some blame by forcing the Army adoption before the weapon was ready, and the Army Ordinance board had some blame for actively trying to sabotage the weapon, because they didn't want to give up the M-14.
Because McNamara was ultimately the one who made the final decision, I guess I tend to place the lion's share of the blame on him. Moreover, once reports came back about failures in the field, McNamara didn't listen to them, believing it was more lies from the Army, when soldiers were actually dying because of those failures. And of course, since the Army ordinance dept wanted the weapon to fail, they didn't push for necessary improvements like they should have. As such, it took a very long time for those issues to be corrected.
It was a rather complex and sordid affair, and there's a lot of blame to be spread around. The point I was trying to make, though, is that it's fairly silly to try to blame Nixon in 1969. I imagine you'll at least agree with me on that point.
Well, that places all of the major players on the side of Vulkan. So long DX12 and Microsoft lock-in.
Nintendo has historically used a customized version of OpenGL for their APIs, as has Sony. So, no one should be surprised to see them take part in this development effort, because these are hardware manufacturers developing their own platforms.
However, every major cross-platform developer or publisher was ALSO likely involved in or closely following the development of DirectX 12. That is, cross-platform developer don't "pick a side" in API wars. These developers have already structured their engine to be largely platform independent, including the renderer. My own little game engine supports DX9, DX11 and OpenGL 4.3. While it's not trivial to do, it's not terribly difficult either, as there are a lot of fundamental similarities between those APIs.
I'm betting that DX12 and Khronos will have many similarities as well. Future game engines will be based on the intersection of features between these two APIs, just like what has happened with previous versions. As far as I've heard, they're both largely rewrites, with similar goals: minimal driver interference, low level APIs used to communicate efficiently communicate with modern shader-based hardware. As such, it stands to reason that Khronos will use similar approaches to accessing the same hardware that DX12 needs to access.
It doesn't look like Windows 10 will flop - Steam HW survey shows it as a very rapidly growing market share of OSes - already at 17%. According to Steam, Windows in total is just under 96%, OS X at a bit over 3%, and Linux is under 1%. Note that these are gaming machines, not general purpose machines, but that's relevant for this discussion.
I really wish OS X and Linux had more inroads in the desktop. I really, really do, but it's a fantasy at this point to think that a new graphics API will somehow break Microsoft's death grip on the desktop.
Just to remind potential programmers. Lean C before you learn any other programming language, otherwise you will not understand why your code's performance is terrible.
It may not be apparent even then. Java looks an awful lot like C++ at the code level. So... what's different? Java (and other managed languages like C#) have a bunch of neat features like reflection and automatic memory management, which inherently comes at the cost of runtime efficiency. Simply learning C or C++ won't point out exactly why those languages are so much faster than managed languages. You can write nearly the same code in C++, Java, and C#, and you'll see C++ win performance benchmarks - at least in all but the most contrived examples.
Among the more significant differences are that C++ compilers are extremely good at optimizing, and C++ code generally compiles down to better cache-coherent structures than other languages. The difference is in the language itself, which adheres to a zero-cost principle, in that you don't pay for features you don't use. A lot of C++ abstractions are eliminated *entirely* at runtime, and are only used to protect the code's integrity during the compilation phase. We were told for years that native-equivalent performance was just around the corner or even already here, and it just never really happened outside of small, contrived benchmarks.
I don't think it's necessary to always learn C or C++ first, although I do think it's worthwhile to learn it at some point, simply because there's a lot of it out there. I'm primarily a C++ programmer myself, but I tend to be a bit more pragmatic about language preference. Use the language that's right for the job. For example, C is a *horrible* choice if you're writing a simple application that needs to do a bunch of string processing. In many cases, high performance isn't even a consideration, rather than correctness, security, and development speed.
Nixon committed a war crime in 1969 when he made it the standard rifle for the U.S. Army. He should have been put in prison for that.
The weapon first entered service in 1963 in Vietnam. You should be blaming McNamara, in Kennedy's administration, who ramrodded the damned thing through before it was properly field-ready. There were a number of issues - lack of chromed barrel, change in powder type, no cleaning kits, etc - which decreased it's efficiency and reliability in the field. It was in those early years between 1963 and 1969 that the most issues were reported.
By 1967, the weapon was significantly improved with the M16A1 variant, and by 1969, when the weapon was standardized, it was a good, reliable weapon, according to field reports. Because of earlier problems, though, a lot of servicemen continued to be wary of the weapon.
You can blame Nixon for a lot of things, but the M-16 debacle wasn't one of them.
Tortoise? What's that?
From the article:
The tainted version of Xcode was downloaded from a server in China that developers may have used because it allowed for faster downloads than using Apple's U.S. servers, Olson said.
Really? Really?!?
From the context in the article, it obviously sounds like these were Chinese developers. You click on the Apple app store, and Xcode downloads for free. I'm not sure how it could be easier - if speed was the issue, just update overnight. I can't figure out what the exact angle is, but it just seems too strange for legitimate developers to "innocently" make such a boneheaded mistake.
Or, maybe Chinese developers are so used to just downloading everything illegally that they didn't think twice about this.
The entire reason we want these things as plugins is so that I don't have to have them installed if I don't use them. Turning executable code a plugin does NOT make it insecure. The only thing a plug-in does is to make that code *optional* for each user. You want a minimal default attack surface, and adding built-in extras broadens that surface unnecessarily.
The reason Flash, Java, and Acrobat Reader plugins are insecure is because they were written long before internet security was a thing. Even today we're seeing new zero-day exploits in Flash that give arbitrary data user-level access. Why does anyone believe that the Skype codebase won't be subject to the same sort of attacks and vulnerabilities once it becomes part of the browser?
Please don't run executable code inside my document viewer.
kthxbye
A built in Skype client? Sweet! Now when a vulnerability is found in this or the Object RTC API implementation, everyone using the Edge browser will be vulnerable by default, and without a way of disabling it.
Building extra crap like this directly into the browser is a horrible idea. People were rightly upset when Firefox tried to pull that nonsense, and MS should be discouraged from going down that road as well. They should focus on building a robust plugin framework (just use Chrome's, and you'll get a big jump on creating an ecosystem), and then they can create a Skype plugin that will work on nearly every major browser out there.
Leave it to Microsoft. They strip all the cruft out of their old browser, then immediately start adding new cruft.
Chartered flights aren't subject to the same security regulations as normal passenger airlines.
I suppose it makes more sense to be more precise in a company that actually makes paper boxes, but in general, it's still just pissing against the wind. You can be technically correct, but it doesn't matter, as 99.99% of the population will still incorrectly call corrugated fiberboard "cardboard" (especially "cardboard boxes"). Over time, as usage approaches critical mass, the old "incorrect" definition will always become the new "correct" definition. Then, there will be a historical footnote explaining the discrepancy. That's how language works.
Feel free to argue with the Oxford Dictionary about what's proper English and what's not. Moreover, this use of 'gift' as a verb, while not always in vogue, has historic roots from at least the 17th century .
A simple list, even one in electronic form, is not really a personal assistant, is it? I think the term "personal assistant" implies the ability to actively do things for you, like answer questions, collecting information, etc.
So, was the Wright Flyer not a real airplane because it could only travel very slowly over short distances? By that logic, the first "real" airplane would perhaps be the first operational jet-powered aircraft, like the Messerschmidt ME 262. Or maybe we'd choose the first all-metal monoplane, like the Junkers J 1?
I'm pretty sure most people agree on the basic definition of a "submarine" (a watercraft capable of independent operation underwater.), and even much earlier and more primitive vehicles quality by that definition.
tl;dr, it's a sales opportunity tracking ticket in Salesforce. Which is probably why he was using that lingo at a Salesforce conference. Presumably Cortana would have had access to his Salesforce accounts somehow. Or, more likely, a fake account with humorous "at-risk" customers like Apple and Google or something.
Ah, got it. That makes a *lot* more sense now. Thanks for the explanation.
This isn't the first time faulty speech recognition has embarrassed Microsoft during a live demo. Anyone remember the last time this happened?
To be fair to Cortana, how exactly do you respond to "Show me my most at-risk opportunities"? What does that even mean? Who talks like that?
The basis of the suit is "I like free money." For the lawyers, it's "vacation home."
My bet is that no car manufacturer wants to deal with having to design a charging station standard which requires people to hook it up, step away, AND have a method for ensuring that there is zero possibility of someone within the area.
Yeah, we should stick to something safer, like highly flammable liquids with explosive vapor clouds.
In part because cars were more straightforward
I grew up with a Honda Civic and an old Ford van in my family. As a youngster, whenever I looked under the hood, I marveled that people used to be able to work on cars themselves. I eventually got a chance to peek under the hood of some older car from the 60's (I forget the make/model), and I finally understood. Wow, cars engines were a LOT simpler back then, and what's more, the engine compartment wasn't nearly so cluttered. There was actually enough room to get in and work on things, and you could clearly see all the critical components of the engine and figure out how they worked for the most part.
Early computers were a bit like this as well. Think about how simple and minimalist a command-line interface (when that's ALL you had) was compared to the layers and layers of abstraction you have in the OS today. There's no doubt both the hardware and software is vastly more powerful today, but I'd imagine it's actually quite a bit harder for a student today to get a real grasp on what the computer is actually doing at a fundamental level. There's simply a hell of a lot more to learn, so programmers are necessarily becoming specialists.
I don't see this as a bad thing, because it simply means computers are reaching an appropriate level of maturity as devices intended for use by lay-persons, rather than exclusively by and for specialists. We "specialists" occasionally grumble about attempts to "dumb down" computers, but by and large, I think it's a good thing that computing is now ubiquitous, as it's added a tremendous amount of convenience to everyone's lives. And besides, the broader that market is, the more opportunity we have to earn a living writing software for the benefit of the masses.
The trend is actually reversing in some ways. Many kids are no longer interested in tinkering with PCs - which used to be a near requirement just to get them to work. They just see them as appliances now, about as interesting or exciting as their refrigerator, except for what it can DO for them. And it's often easier and more convenient for them to simply use their iPad.
So, no, I just don't see a world in which everyone is a programmer. There will certainly be a lot MORE programmers than ever, but it will still be viewed as something of a black art by the rest of the population. It's no different than an auto mechanic in that regard. The average person nowadays opens the hood of their cars and their eyes glaze over. They have no idea how to fix anything in there, and they don't want to know. There are people who do that for a living, and it's far more efficient to simply pay someone else to fix it.
Seriously, can you imagine an average person wanting to program something for themselves to scratch some itch, or do you think they'll just find a $5 app to take care of it for them? The second scenario sounds a hell of a lot more likely to me.