When it senses that you need an oil change, it won't just tell you that--it'll use GPS and AdSense to try to tell you where to go.
That's not really a new feature, though. If you buy a Magellan GPS with the AAA TourBook you'll get the same "service":)
But only if you spend some time poking at the screen to ask for it. Xtifr's point was that the car could initiate this search when it realizes that you need an oil change, which isn't the same thing at all. Now, I'm not sure I'd want my car bugging me about getting the oil changed, much less randomly suggesting routes to service stations, but what he's suggesting is about the integration, not the lookup feature.
That's not my experience. I've had plenty of experience helping my kids with math, and I find that most of the time I can work out the answer in my head, or at the very least a good approximation, long before my kids can punch it into the calculator. I don't know how many times they've shown me their answer and I said "No, you must have made some mistake", and they respond "But I used the calculator!" My answer that their result looks too big, or too small, or odd when it ought to be even, or round when it ought to be fractional, or fractional when it ought to be round, or -- you get the idea -- consistently bugs them because I'm consistently right.
I always explain how I looked at it, but I still don't think any of them have got the knack of mentally pre-estimating answers before pounding the keyboard.
FWIW, for real-world stuff I typically use a calculator (or a computer) -- but if the answer is too far from my mental estimate, I double and triple check.
Umm, yeah, like there's no bias there. Find me a reputable source for those statements.
Java Apps Have the Most Flaws, Cobol the Least:
Complete red herring. That article isn't about security flaws in the JVM, it's about programmer errors in apps written in Java. It's also a really, really poorly done study.
Some "Food 4 Thought" in regards to your statement requoted here next
Nope. Try again. But see if you can find something *real* this time (you can't).
I SWEAR I'm not making this up: a manager once criticized my code as being too terse: "people have to read and understand it before they can modify it". He saw no irony in that statement.
Yeah? Well I recently got a peer review comment during the annual performance evaluation cycle that said "His code is some of the most straightforward, transparent and understandable I've seen."
Dude, I'm thinking about getting that quote framed and hanging it on the wall, I'm that proud of it. It helps that it's from a guy who's brilliant, writes beautifully elegant code himself, has nearly 30 years' experience at it and has given me a lot of tremendously insightful feedback in design reviews, but regardless fo the source, the statement itself is some of the highest praise I've ever received, IMO.
That's the standard that professional programmers should strive to reach, that their code is utterly straightforward, transparent and understandable, no matter how complex or tricky what they're implementing may be. It's a goal that will never actually be achieved, except for trivial code, but there's huge value in the effort. Conciseness aids understandability, but terseness hurts it.
It's simple - you add up the cost of outages (revenue and reputation), ops overhead (support staff and time lost using clunky UI's) and correcting mistakes caused by errors in the code, then you compare it against the cost of resolving the technical debt.
Hang on, buddy... that's already an overload for the sales/marketdroid single neuron... why should they care, as long as they get the commission? If the company goes busted, that's not their problem either... their CV will show how many zillions they made in sale, not their fault the company went under.
That's when you have to go over their head. If everyone up the chain thinks the same way, you should hack it in the quickest and easiest way you can and use the time you free up to work on your CV.
Keep in mind, though, that as you walk up the chain you may well run into a person who does understand what you're saying and looks at the company's situation and makes a rational, considered decision to take on the additional technical debt. Technical debt, just like financial debt, does make sense in many cases.
using flags instead of try/catch blocks for error handling
It was my understanding that, at least up until recently, try/catch blocks, and exceptions in general, were not well supported in C++, and did not work well. Has this changed in the long while since I looked, or was I just misunderstood?
No, you're right. I'd say the present state of affairs is that they're well-supported by major tools... but that the fundamental design of exception handling is fraught with subtle pitfalls, and as a result many (most?) C++ shops still avoid them.
One example is that there is basically no way to safely write a destructor that may throw an exception, but if your destructor does anything at all of substance (and RAII means many of them do), then you may not even know whether your code may throw. You can wrap it all in a try/catch... but what can you do in the catch? Swallowing the exception is a bad idea, obviously. Throwing will cause an abort() sometime, when your dtor is called during an exception handling stack unwind. Even in normal functions, writing C++ code that is actually exception-safe is not nearly as easy as it looks.
I like C++, warts and all it's still my favorite language, and I'd love to be able to use exceptions, but I can't.
Android 3 supports full disk encryption so all phones and tablets that get 3 or above will too. Apparently some phones running 2.3 support it too, such as the Droid.
Note that this requires locking your phone with a password, though, not a pattern. This is because the decryption key is derived from your password. This is good security design, but the unlock pattern can't really provide enough entropy so you have to use a password.
It also means that if you forget your password, you're screwed. That's because it's good security.
Yoda would more likely say "Make an operating system, a kernel does not."
There's a difference between Yoda-speak and German-speak. Yoda-speak is OSV (object subject verb; "a fine mess this is") or VOSv (verb, object, subject, helping verb; "help you I will"), in contrast with the SVO or SvVO order of English (and presumably of standard Galactic Basic). The "X does not Y make" pattern is SvOV, as commonly used in German and Dutch and occasionally in English until the early modern (17th century) period. It's an allusion to a Richard Lovelace poem.
The Moar You Know...:::*
You know, your excellent and informative (if off-topic) post just made me really nostalgic for the days when such were common on slashdot.
Like I really want anyone and their uncle to be running native code on my machine. We went to a sandbox model for a reason!
If this is active now, how do we shut it off?
It's not active by default, yet, and it is sandboxed. Native sandboxing is possible.
NaCl program is sandboxed, so even when you allowed it to run, it cannot do anything harmful.
I remember people saying that about Java.
And it's true. Early on there were some JVM bugs that allowed malicious apps to break out of the sandbox, but those have been fixed, and sandboxed Java code is sandboxed very effectively.
The ONLY reason they're not profitable is the ridiculous requirement that they fully fund 75 years worth of pensions within 10 years of 2006.
You honestly think that the 20% decline in the volume of first class mail over the last four years has nothing to do with it?
The reality is that statistic is just going to continue getting worse, too (or better, depending on your perspective). I'll bet that by 2020, first class mail volume will be no more than 10% of what it was in 2000. And first class mail is the primary revenue generator of the USPS. Even if dropping the pension requirements would get them in the black right now, they'd still be in the red in a few short years, because the biggest piece of their business is simply disappearing.
Lastly, Unionization is fully in-line with Libertarian ideology
Voluntary unionization, yes. But voluntary unions don't last; if the union is at all successful it begins to focus on perpetuating itself and its lock on the labor side of the bargaining table. In some cases scabs get beaten, maimed or killed. In other cases, the unions champion changes in the law that make non-union labor effectively illegal. Even when those extremes are avoided, intense peer pressure is applied to those who don't want to join the union.
The biggest problem with unions and collective bargaining, though, is hidden in your parenthetical comment "which does not need to be seniority based, and can be performance based". No, it can't be performance based, because that requires an objective way to measure performance. The normal employer/employee relationship has a lot of fuzziness that allows hard-to-quantify performance factors to be taken into account. But unions need to establish clear rules and structures that can be written into the collective bargaining agreement, at least if the agreement is going to do anything more than specify minimums. That's why so many collective agreements end up being purely seniority-based: because it's about the only thing that can be objectively measured.
When I was at IBM they admitted that they mostly used the patents to defend against lawsuits from other companies which were claiming infringement with their own patents.
Mmm, I think you misunderstood, or the presentation only addressed one sort of patents. IBM makes lots of money from licensing its patents. There is a difference, though, which is that the patents that IBM licenses (by and large, there may be exceptions) are "legitimate". They're real, serious advances in the art which are of real value to their licensees, and not something that any random engineer would come up with off the top of their head when faced with a similar problem. Most of the patents IBM licenses for big bucks are for things like lithography processes, techniques for increasing disk storage density... and this racetrack memory.
I no longer work for IBM, but I did spend 14 years there and while I have many (many!) other criticisms of the company, I think their approach to patents is a good one.
Almost all of Canon's DSLR cameras now take SD(HC) cards... even the 60D and 1D Mk4. Your viewpoint was valid 2 years ago, but then again 20 years ago, that would have been s/CF/Film/
Well, assuming photographers have bought a new camera in the last two years... My 50D and 5D only take CF -- and I should point out that the 60D is barely one year old. It looks like the 1D line has had SD as an option since the Mk3, though, which was released four years ago, so I guess I'm a little dated.
Mmm, yes, I was assuming there's a pool per tab. With Chrome, since each tab is a separate process, I'm pretty sure that's the case.
I don't think that's an insuperable problem, though. The attacker can just watch the requests that are supposed to saturate the pool coming into the server, and if they stop arriving he can assume the pool is full. At that point he knows how large the available pool is, factoring in other connections already established, and can "release" enough connections to allow the page loading process to get down to the interesting bit. Of course, the connections from other tabs aren't static, so there's going to be a little noise, but even the scripted version of the attack is noisy.
Mail needs to cost more, I'd say the need to jump to $1 minimum.
Which would just accelerate the move of most traditional mail traffic to e-mail and other Internet-based mechanisms.
There's been a lot of talk in the comments attached to this article about competition with UPS and FedEx, and about high pension costs the USPS has been stuck with, etc., but none of that is what's really slamming the USPS. What's really doing it is that first class letters are rapidly going away. Personal letters are almost a thing of the past already. Electronic bills have become almost universally available, and some companies have even begun charging a fee for paper delivery. The bread and butter of USPS deliveries is all going on-line.
We're approaching a point at which we're going to have to either accept that the postal service cannot operate without heavy subsidization, or else we're going to have to allow letter delivery to become a relatively high-priced service, not often used by most people. The latter option pretty much implies that Internet service will become a basic necessity for transacting the ordinary business of life.
Well, um, I have to admit that we are indeed given ice cream too. Ben & Jerry's "Fairly Nuts" is my current favorite, though their Chocolate Fudge Brownie is a close second. Luckily the freezer is on the floor above mine so I always walk up the stairs to work off the calories in advance. That works, right??
Slacker.
I have to walk across the street to the ice cream freezer. The beer keg is right next to my desk, though.
There's a limit to the number of resources they'll download in parallell; it would probably be necessary to saturate that first. In fact, filling up all of the available download slots might really help -- request a bunch of resources from a server that will respond to the connection request but not complete it. Then the attacker could start timing from the instant the server completes the pre-timing request, then stop when the server receives the post-timing request. Some similar methods could be used to measure typical RTT and jitter, to calibrate the timing and pre-determine the likely accuracy of the attack.
Now, if the browser uses a new download thread/socket pool for each domain, that wouldn't work. But I suspect there's a per-endpoint pool and a total pool, otherwise a web page could DOS the client by consuming all network sockets. The attacker might need a few servers to saturate each of the per-endpoint pools until the total pool is saturated.
Browsers could defeat this attack by randomizing resource download order.
Sandwich them between requests to a real server, which you control. Network latency jitter would make the attack less reliable, but I'll bet it would still work reasonably well. Better if you have a low-latency path to the target. ISPs could probably implement it with very high reliability.
They can't license their work as Free Software, because those license terms conflict with Apple's.
such ecosystems can legally and single handedly kill free software.
It can if iOS takes over the world. However, that doesn't appear to be happening. Android has already surpassed iOS as a phone OS, and we're finally getting some decent tablets, too. The current situation with iOS's near dominance is an aberration; just as was the case throughout the PC era, the winning platform will be the one which allows for competition among hardware vendors, and that's not an approach that fits Apple's business model.
My prediction is that Android's dominance will continue to grow and that iOS will be relegated to a highly-profitable niche, where Apple has historically lived. The bigger risk is Microsoft. If they move to a single platform across PCs and mobiles, then they might be in a position to leverage their PC platform dominance to challenge Android for the top mobile spot. Then if they go to a walled garden with anti-F/LOSS TOS, we could be in trouble. At this point, though, I'm skeptical that Microsoft will get a strong platform deployed fast enough to have any hope of ousting Android. Frankly, I think they're already too late. But they might manage to get a solid minority piece of the market, perhaps as large as Apple's.
I think a three-way battle on the software platform, plus a many-way battle on the hardware platform, will ultimately be very good for consumers. The three major players will all represent diverse approaches, too: Apple, controlled hardware & walled garden; Microsoft, open hardware & (maybe) walled garden; Google, open hardware & open software. By "open" in the previous sentence, I mean in the sense of a free market, not in the F/LOSS sense -- though a free market in software implies that F/LOSS software will be free to compete as well, and it does that pretty effectively. And, of course, Android itself is Free Software.
Tell that to the buyers of Motorola devices, who have to bend over backwards to bypass the restrictions they put in place on the handsets they sell. That's not innovation, that's contorting oneself to work around punitive restrictions, something you shouldn't need to do.
I think that will change now that Google is buying Motorola's mobile business. Google has promised to run Motorola as a separate business and not give them any advantages in terms of earlier access to Android, etc., but I'll be really surprised if Google doesn't require them to stop the lockdown crap.
Slashdot Mirror
When it senses that you need an oil change, it won't just tell you that--it'll use GPS and AdSense to try to tell you where to go.
That's not really a new feature, though. If you buy a Magellan GPS with the AAA TourBook you'll get the same "service" :)
But only if you spend some time poking at the screen to ask for it. Xtifr's point was that the car could initiate this search when it realizes that you need an oil change, which isn't the same thing at all. Now, I'm not sure I'd want my car bugging me about getting the oil changed, much less randomly suggesting routes to service stations, but what he's suggesting is about the integration, not the lookup feature.
In *most* cases, a calculator is more efficient
That's not my experience. I've had plenty of experience helping my kids with math, and I find that most of the time I can work out the answer in my head, or at the very least a good approximation, long before my kids can punch it into the calculator. I don't know how many times they've shown me their answer and I said "No, you must have made some mistake", and they respond "But I used the calculator!" My answer that their result looks too big, or too small, or odd when it ought to be even, or round when it ought to be fractional, or fractional when it ought to be round, or -- you get the idea -- consistently bugs them because I'm consistently right.
I always explain how I looked at it, but I still don't think any of them have got the knack of mentally pre-estimating answers before pounding the keyboard.
FWIW, for real-world stuff I typically use a calculator (or a computer) -- but if the answer is too far from my mental estimate, I double and triple check.
Java tops for hackers, warns Microsoft:
Umm, yeah, like there's no bias there. Find me a reputable source for those statements.
Java Apps Have the Most Flaws, Cobol the Least:
Complete red herring. That article isn't about security flaws in the JVM, it's about programmer errors in apps written in Java. It's also a really, really poorly done study.
Some "Food 4 Thought" in regards to your statement requoted here next
Nope. Try again. But see if you can find something *real* this time (you can't).
If you use RAII only to release memory, that's true. If you use it to release other resources, not so much.
I SWEAR I'm not making this up: a manager once criticized my code as being too terse: "people have to read and understand it before they can modify it". He saw no irony in that statement.
Yeah? Well I recently got a peer review comment during the annual performance evaluation cycle that said "His code is some of the most straightforward, transparent and understandable I've seen."
Dude, I'm thinking about getting that quote framed and hanging it on the wall, I'm that proud of it. It helps that it's from a guy who's brilliant, writes beautifully elegant code himself, has nearly 30 years' experience at it and has given me a lot of tremendously insightful feedback in design reviews, but regardless fo the source, the statement itself is some of the highest praise I've ever received, IMO.
That's the standard that professional programmers should strive to reach, that their code is utterly straightforward, transparent and understandable, no matter how complex or tricky what they're implementing may be. It's a goal that will never actually be achieved, except for trivial code, but there's huge value in the effort. Conciseness aids understandability, but terseness hurts it.
It's simple - you add up the cost of outages (revenue and reputation), ops overhead (support staff and time lost using clunky UI's) and correcting mistakes caused by errors in the code, then you compare it against the cost of resolving the technical debt.
Hang on, buddy... that's already an overload for the sales/marketdroid single neuron... why should they care, as long as they get the commission? If the company goes busted, that's not their problem either... their CV will show how many zillions they made in sale, not their fault the company went under.
That's when you have to go over their head. If everyone up the chain thinks the same way, you should hack it in the quickest and easiest way you can and use the time you free up to work on your CV.
Keep in mind, though, that as you walk up the chain you may well run into a person who does understand what you're saying and looks at the company's situation and makes a rational, considered decision to take on the additional technical debt. Technical debt, just like financial debt, does make sense in many cases.
using flags instead of try/catch blocks for error handling
It was my understanding that, at least up until recently, try/catch blocks, and exceptions in general, were not well supported in C++, and did not work well. Has this changed in the long while since I looked, or was I just misunderstood?
No, you're right. I'd say the present state of affairs is that they're well-supported by major tools... but that the fundamental design of exception handling is fraught with subtle pitfalls, and as a result many (most?) C++ shops still avoid them.
One example is that there is basically no way to safely write a destructor that may throw an exception, but if your destructor does anything at all of substance (and RAII means many of them do), then you may not even know whether your code may throw. You can wrap it all in a try/catch... but what can you do in the catch? Swallowing the exception is a bad idea, obviously. Throwing will cause an abort() sometime, when your dtor is called during an exception handling stack unwind. Even in normal functions, writing C++ code that is actually exception-safe is not nearly as easy as it looks.
I like C++, warts and all it's still my favorite language, and I'd love to be able to use exceptions, but I can't.
Well, I have never even seen any vulnerable Cobol web applications
Have you seen any COBOL web applications, period?
For that matter, how many COBOL applications even use those new-fangled relational databases? SQL injection isn't a problem if you don't have SQL.
Android 3 supports full disk encryption so all phones and tablets that get 3 or above will too. Apparently some phones running 2.3 support it too, such as the Droid.
Note that this requires locking your phone with a password, though, not a pattern. This is because the decryption key is derived from your password. This is good security design, but the unlock pattern can't really provide enough entropy so you have to use a password.
It also means that if you forget your password, you're screwed. That's because it's good security.
A kernel does not an operating system make.
Yoda, is that you?
Yoda would more likely say "Make an operating system, a kernel does not."
There's a difference between Yoda-speak and German-speak. Yoda-speak is OSV (object subject verb; "a fine mess this is") or VOSv (verb, object, subject, helping verb; "help you I will"), in contrast with the SVO or SvVO order of English (and presumably of standard Galactic Basic). The "X does not Y make" pattern is SvOV, as commonly used in German and Dutch and occasionally in English until the early modern (17th century) period. It's an allusion to a Richard Lovelace poem.
The Moar You Know ...:::*
You know, your excellent and informative (if off-topic) post just made me really nostalgic for the days when such were common on slashdot.
Like I really want anyone and their uncle to be running native code on my machine. We went to a sandbox model for a reason! If this is active now, how do we shut it off?
It's not active by default, yet, and it is sandboxed. Native sandboxing is possible.
NaCl program is sandboxed, so even when you allowed it to run, it cannot do anything harmful.
I remember people saying that about Java.
And it's true. Early on there were some JVM bugs that allowed malicious apps to break out of the sandbox, but those have been fixed, and sandboxed Java code is sandboxed very effectively.
The ONLY reason they're not profitable is the ridiculous requirement that they fully fund 75 years worth of pensions within 10 years of 2006.
You honestly think that the 20% decline in the volume of first class mail over the last four years has nothing to do with it?
The reality is that statistic is just going to continue getting worse, too (or better, depending on your perspective). I'll bet that by 2020, first class mail volume will be no more than 10% of what it was in 2000. And first class mail is the primary revenue generator of the USPS. Even if dropping the pension requirements would get them in the black right now, they'd still be in the red in a few short years, because the biggest piece of their business is simply disappearing.
Lastly, Unionization is fully in-line with Libertarian ideology
Voluntary unionization, yes. But voluntary unions don't last; if the union is at all successful it begins to focus on perpetuating itself and its lock on the labor side of the bargaining table. In some cases scabs get beaten, maimed or killed. In other cases, the unions champion changes in the law that make non-union labor effectively illegal. Even when those extremes are avoided, intense peer pressure is applied to those who don't want to join the union.
The biggest problem with unions and collective bargaining, though, is hidden in your parenthetical comment "which does not need to be seniority based, and can be performance based". No, it can't be performance based, because that requires an objective way to measure performance. The normal employer/employee relationship has a lot of fuzziness that allows hard-to-quantify performance factors to be taken into account. But unions need to establish clear rules and structures that can be written into the collective bargaining agreement, at least if the agreement is going to do anything more than specify minimums. That's why so many collective agreements end up being purely seniority-based: because it's about the only thing that can be objectively measured.
When I was at IBM they admitted that they mostly used the patents to defend against lawsuits from other companies which were claiming infringement with their own patents.
Mmm, I think you misunderstood, or the presentation only addressed one sort of patents. IBM makes lots of money from licensing its patents. There is a difference, though, which is that the patents that IBM licenses (by and large, there may be exceptions) are "legitimate". They're real, serious advances in the art which are of real value to their licensees, and not something that any random engineer would come up with off the top of their head when faced with a similar problem. Most of the patents IBM licenses for big bucks are for things like lithography processes, techniques for increasing disk storage density... and this racetrack memory.
I no longer work for IBM, but I did spend 14 years there and while I have many (many!) other criticisms of the company, I think their approach to patents is a good one.
Photographers need a high speed SDHC reader.
Photographers' cameras take CF, not SD.
Almost all of Canon's DSLR cameras now take SD(HC) cards... even the 60D and 1D Mk4. Your viewpoint was valid 2 years ago, but then again 20 years ago, that would have been s/CF/Film/
Well, assuming photographers have bought a new camera in the last two years... My 50D and 5D only take CF -- and I should point out that the 60D is barely one year old. It looks like the 1D line has had SD as an option since the Mk3, though, which was released four years ago, so I guess I'm a little dated.
Photographers need a high speed SDHC reader.
Photographers' cameras take CF, not SD.
This is someone that doesn't program, doesn't write long docs, is used to surfing a lot, and probably just does blog updates. A tablet is perfect.
As is a very small laptop/netbook -- which is essentially what the iPad becomes when placed in the ZaggFolio case.
Mmm, yes, I was assuming there's a pool per tab. With Chrome, since each tab is a separate process, I'm pretty sure that's the case.
I don't think that's an insuperable problem, though. The attacker can just watch the requests that are supposed to saturate the pool coming into the server, and if they stop arriving he can assume the pool is full. At that point he knows how large the available pool is, factoring in other connections already established, and can "release" enough connections to allow the page loading process to get down to the interesting bit. Of course, the connections from other tabs aren't static, so there's going to be a little noise, but even the scripted version of the attack is noisy.
Mail needs to cost more, I'd say the need to jump to $1 minimum.
Which would just accelerate the move of most traditional mail traffic to e-mail and other Internet-based mechanisms.
There's been a lot of talk in the comments attached to this article about competition with UPS and FedEx, and about high pension costs the USPS has been stuck with, etc., but none of that is what's really slamming the USPS. What's really doing it is that first class letters are rapidly going away. Personal letters are almost a thing of the past already. Electronic bills have become almost universally available, and some companies have even begun charging a fee for paper delivery. The bread and butter of USPS deliveries is all going on-line.
We're approaching a point at which we're going to have to either accept that the postal service cannot operate without heavy subsidization, or else we're going to have to allow letter delivery to become a relatively high-priced service, not often used by most people. The latter option pretty much implies that Internet service will become a basic necessity for transacting the ordinary business of life.
Well, um, I have to admit that we are indeed given ice cream too. Ben & Jerry's "Fairly Nuts" is my current favorite, though their Chocolate Fudge Brownie is a close second. Luckily the freezer is on the floor above mine so I always walk up the stairs to work off the calories in advance. That works, right??
Slacker.
I have to walk across the street to the ice cream freezer. The beer keg is right next to my desk, though.
There's a limit to the number of resources they'll download in parallell; it would probably be necessary to saturate that first. In fact, filling up all of the available download slots might really help -- request a bunch of resources from a server that will respond to the connection request but not complete it. Then the attacker could start timing from the instant the server completes the pre-timing request, then stop when the server receives the post-timing request. Some similar methods could be used to measure typical RTT and jitter, to calibrate the timing and pre-determine the likely accuracy of the attack.
Now, if the browser uses a new download thread/socket pool for each domain, that wouldn't work. But I suspect there's a per-endpoint pool and a total pool, otherwise a web page could DOS the client by consuming all network sockets. The attacker might need a few servers to saturate each of the per-endpoint pools until the total pool is saturated.
Browsers could defeat this attack by randomizing resource download order.
Sandwich them between requests to a real server, which you control. Network latency jitter would make the attack less reliable, but I'll bet it would still work reasonably well. Better if you have a low-latency path to the target. ISPs could probably implement it with very high reliability.
this term in their tos :
They can't license their work as Free Software, because those license terms conflict with Apple's.
such ecosystems can legally and single handedly kill free software.
It can if iOS takes over the world. However, that doesn't appear to be happening. Android has already surpassed iOS as a phone OS, and we're finally getting some decent tablets, too. The current situation with iOS's near dominance is an aberration; just as was the case throughout the PC era, the winning platform will be the one which allows for competition among hardware vendors, and that's not an approach that fits Apple's business model.
My prediction is that Android's dominance will continue to grow and that iOS will be relegated to a highly-profitable niche, where Apple has historically lived. The bigger risk is Microsoft. If they move to a single platform across PCs and mobiles, then they might be in a position to leverage their PC platform dominance to challenge Android for the top mobile spot. Then if they go to a walled garden with anti-F/LOSS TOS, we could be in trouble. At this point, though, I'm skeptical that Microsoft will get a strong platform deployed fast enough to have any hope of ousting Android. Frankly, I think they're already too late. But they might manage to get a solid minority piece of the market, perhaps as large as Apple's.
I think a three-way battle on the software platform, plus a many-way battle on the hardware platform, will ultimately be very good for consumers. The three major players will all represent diverse approaches, too: Apple, controlled hardware & walled garden; Microsoft, open hardware & (maybe) walled garden; Google, open hardware & open software. By "open" in the previous sentence, I mean in the sense of a free market, not in the F/LOSS sense -- though a free market in software implies that F/LOSS software will be free to compete as well, and it does that pretty effectively. And, of course, Android itself is Free Software.
Tell that to the buyers of Motorola devices, who have to bend over backwards to bypass the restrictions they put in place on the handsets they sell. That's not innovation, that's contorting oneself to work around punitive restrictions, something you shouldn't need to do.
I think that will change now that Google is buying Motorola's mobile business. Google has promised to run Motorola as a separate business and not give them any advantages in terms of earlier access to Android, etc., but I'll be really surprised if Google doesn't require them to stop the lockdown crap.