TSA's job is to prevent passengers from bringing weapons onto the airplane. They have some successes and notable failures in doing this.
No, the TSA's job is to stop terrorists from hijacking planes, not to keep guns off planes. If half the passengers had guns, the terrorists wouldn't try hijacking a plane. And that's the fundamental problem with the TSA, their focus is on passengers as threats, rather than on the threat to the passengers. That's like saying locks are to keep you from opening a door. No, the lock is to protect what's behind the door, the door and lock are just one mechanism of providing protection.
What you're saying is that it's okay that the TSA might fail every now and again because the passengers will spot the malicious person and prevent him from performing his dastardly task.
No, I'm saying it's impossible for the TSA to succeed at that task. Therefore, they need to focus on how to minimize the risk with minimal invasiveness and impact. That's off topic, see my blog posts for more info. Here's the most relevant one to this discussion.
But if you want to go with this analogy, Android would be a better secure environment than iOS. Android has various tools that smart people can use to find malicious software So, to carry this into your analogy, using Android is like flying on airplane with a group of passengers who understand security and can spot the evildoer and warn others. iOS is like flying on an airplane where everybody says, "Oh, they made it through the TSA checkpoint. They must be okay."
No. Those tools are as useless to a typical Android user as a brake adjustment tool is to a typical car driver. It has nothing to do with the user's attitude, 95+% of users don't have enough knowledge to adequately identify risks in software, therefore, users are safer when a team of trained people vet all the software before users can access it.
If all Android software had to be vetted by a team of trusted experts using those tools before it could be downloaded and installed on a user's phone, then it would be a safer (not more secure) environment. Since all iOS apps are vetted, it's much harder for malicious software to get through. In either case, some malicious software will get through, but more will (and has) gotten through to the Android stores. The fact that Apple vets all the software on the iOS App Store reduces the chances of malware getting through, therefore, iOS users are safer from malware (again, not to be confused with being more secure).
Even though Android users may technically have access to check out the software they're loading, they don't have the knowledge or skill to do so. They don't even know that they have the tools available or what to look for, much less how to evaluate anything the tools might show them. That the tools are available is completely useless to 95+% of Android users because they don't have the knowledge to do anything useful with the tool. And most of those don't know or care that those tools are available, they just want a phone that works.
Having the tools available is only useful to those with the knowledge of how to effectively use the tools and evaluate the results (i.e. the user must know the tools exist, know how to use them, know how to interpret the output to identify potential risks, AND understand enough about security to evaluate any potential risks identified). The tools are only useful to the 1% who understand enough about security to vet a program in the first place.
First, clearly you didn't read my reply to the previous commenter who used the "false sense of security" fallacy. Actually, the "false sense of security" argument can be many fallacies, linked below:
Appeal to belief. e.g. Many people claim it gives a false sense of security, therefore, it must. Show that it actually has that effect before you use it as your premise. A hypothetical premise only gives a hypothetical result.
Begging the question. e.g. Giving people "false sense of security" makes them less safe assumes that they have the knowledge and ability to do something useful to mitigate the risk AND that they would do something different if they didn't have that "false sense of security. However 95+% don't have that knowledge, and evidence is that most don't change their behavior even after they've been informed of the risks. The assumption is false, therefore, the conclusion is fallacious.
Composition. e.g. Because I/we/technical users possess the knowledge and ability to recognize security risks, all users would behave the way I/we would. Your/Our behavior (or theoretical behavior) does not represent what most users will actually do.
Ignoring a common cause. e.g. Users are careless when they think they're safe, therefore, they are careless because they think they're safe. In fact, most users are either always careful, or always careless, regardless of whether they think they're safe.
Flawed analogy. Forget that the TSA is searching for weapons when they need to be watching for suspicious behavior. Forget that they're irradiating passengers and groping others for their illusion of security.
The fundamental problem with the analogy is that air passengers know to watch for weapons, suspicious behavior, etc. In fact, passengers are the only ones who have actually caught any attempts at terrorism in the last 10 years, not the TSA. Passengers can still do something to detect and stop an attacker on a plane. Software users don't know what to look for, what is suspicious behavior, where to look for it, or how to stop it if they could detect it. And given the nature of software, that all of the "work" is hidden from the user, there is very little a user CAN look for, and if if the do detect something, it's probably too late.
They're two totally different environments, requiring two different approaches to safety.
Which makes absolutely no difference to the 95+% users who don't know enough about security to make such an evaluation. No matter how many times users get burned, if they don't understand security, most of them will make the same mistake next time simply because they don't know how to evaluate an app for security. And for those who do know about security, it doesn't stop them from exercising caution. Therefore, the "false sense of security" actually makes no difference.
It's not more secure (Charlie Miller keeps demonstrating that), but for the typical user (who doesn't know enough about security to judge an app), having a vetting/approval process such Apple's is still offers a safer environment than running completely unvetted apps (such as on the Android stores).
And the ISPs would also need full access to the digital source for all their copyrighted media. I mean, how can they look for copies if they don't have unencrypted source to all the copyrighted material? Hashes are completely insufficient because those would be defeated by simply changing one byte and/or of the data. With full, unencrypted source media, then the ISP could compare all new media files uploaded to see it it's a close match to the source and flag those that are close for manual review.
See, a nice technological solution to a behavioral/legal issue. Of course, it would cost a fortune, would be pretty easy to bypass, someone at an ISP would accidentally release the unencrypted source, and the rights holders would never go for it, but it makes as much sense as anything the MAFIAA has suggested.
So now you're saying that even though you explicitly said they could differentiate their device by running a different UI like they do now, you just know that they won't.
Go back and read my comment again. If Android provided a good standard UI, most would not replace it. A UI is a WHOLE lot of work, especially when you have to maintain compatibility with third party apps. They would spend their efforts on making better hardware and/or proprietary apps and/or lower cost. This is no change from my initial statement.
Except that this is not about a derivative work because running Sense on top of Android does not create a derivative work, just like running LiteStep on Windows does not create a derivative work.
Replacing the UI is a major change, it is a derivative work. But if you go back to my original comment, I specifically stated... an OEM felt they had a way to improve it, they would be free to do so to differentiate their product.... Google could add restrictions that state: If an OEM customizes it, they have to be able to meet/exceed those same standards (which could include performance, responsiveness, and compatibility benchmarks) in order to use the Android name. Nowhere in there did I say they can't replace the UI, or otherwise customize it, said most wouldn't. I also said is that Google could set standards they have to meet to be able to use the Android name.
So, we're right back to my initial statements.
If you want some precedent on trademark usage, here's one. In that case, MS settled because of issues with their claim to "Windows", but the fact that it was allowed to proceed as far as it was when "Lindows" wasn't even using MS's trademark, but a very similar name gives some indication of how much control over a trademark usage the owner really has (within their market/business). Perhaps an even better case is Apple Corps v Apple Computer, they were in completely different businesses and the names weren't the same, but Apple Computer still paid Apple Corps (multiple times) to use the name. These cases strongly suggest Google can certainly impose the restrictions I suggested on "Android".
If it had a good, usable, UI standard, but an OEM felt they had a way to improve it, they would be free to do so to differentiate their product.
It doesn't take a genius to figure out that if OEMs change the UI then it becomes non-standard.
But if the default UI didn't suck, they wouldn't all need to change it, and most wouldn't.
Google owns the Android trademark. They can place restrictions on it's use as they see fit. That they haven't restricted it as I suggested is part of the problem.
They cannot stop an OEM from stating that their device runs Android, that's not how trademarks work, there is no legal method for them to do such a thing.
Yes, they can. If I own the trademark, you can't use it without my permission unless you're making a reference to my product. If that product is OSS, and you've modified it, then it's no longer my product (it's a derivative), so the only way you can use my trademarked name is with my permission. If I set terms under which you may and may not use my trademark, then you can use it only when you comply with the terms. That's exactly how trademark works.
Go back and reread my earlier post. I didn't ignore that at all. First you argue with my premise, then when your own comments demonstrate my premise is valid, you assert I'm ignoring something I stated in my premise.
Google owns the Android trademark. They can place restrictions on it's use as they see fit. That they haven't restricted it as I suggested is part of the problem.
That's what they do, and that's part of what causes the problem. HTC's Android isn't the same as Samsung's Android even though there is a standard UI on vanilla Android. OEMs want - or rather need - to differentiate so of course they will make changes if the OS is free software.
Clearly, they don't, or they wouldn't have the problems they have.
Actually, Android can to all of that, and still allow customization. If it had a good, usable, UI standard, but an OEM felt they had a way to improve it, they would be free to do so to differentiate their product. Likewise, you can specify a minimum level of hardware that delivers an "acceptable" user experience with the standard package. One of the things the license gives you access to is the use of the Android name. Licenses can impose restrictions, even on OSS. Google could add restrictions that state: If an OEM customizes it, they have to be able to meet/exceed those same standards (which could include performance, responsiveness, and compatibility benchmarks) in order to use the Android name. If they don't meet those, they can either use the OS, but they can't claim Android compatibility. That gives OEMs a strong incentive to meet the specifications, but they're free to forego them if they think it's worth the trade-off, and Android as a platform isn't harmed by that OEM's choice.
What you call a design failure is usually just a feature nerds care about and typical users don't. That's what most commenters on here completely fail to understand, and that's why the iPod, iPhone, and iPad have outsold ever competitor no matter what the nerds have called failures.
That doesn't mean those products haven't had design issues or missing features, it just means that your definition of a failure is skewed by your opinion of what a device can/should do.
As for just getting stuff done, that's exactly what Apple products make it easy for the typical user to do, get stuff done WITHOUT having the think like a programmer or engineer. And most programmers and engineers refuse to even consider that adapting a device/UI to the user is far more valuable and marketable than features that users can't figure out how to use because they're not interested in learning to think like an engineer or programmer just to play their music, make a phone call, or surf the web, or check email.
That might be interesting, if OK didn't have a history of M5+ quakes about every 60 years, 1887, 1952, and now 2011. I'm not saying fracking isn't possibly related, there is evidence from other areas that fracking may induce some seismic activity, but this one is more likely just periodic movement.
And the reason they've shipped phones with too little RAM/CPU and poor quality screens is essentially that consumers often demand crap. It's kind of a general problem, not limited to cell phones, that people want stuff but they don't want to pay for quality. That's why we have McDonalds restaurants all over the place and Best Buys filled with eMachines computers.
Consumers don't demand crap. Consumers largely shop on price. Retailers (and in the US, wireless carriers) buy devices to hit certain price points that they can advertise. Consumers don't have access to information to compare the devices, so put the blame where it belongs, with the sellers who are willing to sell crap because they know people will buy it and then blame the manufacturer (rather than the company who knowingly or carelessly sold them a piece of crap to make a profit).
I've worked in retail computer stores. I've talked customers out of buying products that I didn't think they would be happy with (e.g. products with poor build quality or a high return rate). Customer satisfaction creates repeat customers. Quality, value, usability, and customer service create customer satisfaction. Price is rarely the top consideration, it's just the one that sellers focus on because it's easier to sell on price than to actually provide information and service to the customer.
Android itself seems to have been fundamentally fucked as Google has spent the last 3 years reinventing the wheel that had already been built, quite well, in regular Linux platforms.
And how many successful (non-Android) Linux phones are there? An OS alone does not make a device. A server OS does not automatically make a good desktop, or vice-verse. A desktop OS does not automatically make a good mobile device OS. Switching from a keyboard to a keyboard+mouse/stylus to a single touch touch-screen to a multi-touch touch-screen requires redesigning the UI and/or APIs. Screen size, RAM, CPU, and GPU all affect what the UI can do while still being responsive enough. You can blame Google, but it's the hardware vendors that didn't offer (or were slow to offer) newer versions of Android for the first generation of Android phones. The hardware vendors had to select or develop a UI, because Android didn't have a sufficient UI, and most of them did a poor job of it (as I would expect, if they were that good at OS/UI development, they would probably have their own OS rather than Android).
Some should be showing off new features that Apple doesn't have like the new face unlock feature in Android 4.0.
Yeah, when there are phones shipping with Android 4.0 and front facing cameras that can use the features. Marketing features that aren't yet available to the end users is a REALLY bad idea.
Others should highlight their restrictive model: picture the old Mac vs. PC ads, but with the iPhone checking with Apple before denying the user's request to install an app of their choice.
This would probably backfire, how many trojans and programs that send your info back to the developer's server have been found in the Android marketplace? Lots. Apple would almost certainly use that in a counter-attack ad.
Market your strengths, but be careful of those that also have an underlying weakness/vulnerability, it will come back to bite you.
Android needs more standardization. A standard UI, a minimum resolution, and a minimum hardware set. One of the things Apple has done very effectively is manage the user experience. MS Windows and Android have allowed manufacturers to put out devices with too little RAM, CPU, and/or poor quality screens, keyboards, touch-screens and it hurts the reputation of the platform. When a user buys a bad Windows or Android device, they're as likely to blame the OS as they are the hardware manufacturer. Failing to understand and address that is a marketing failure on the part of the OS vendor.
News-Service.com responded correct. If they're going to make laws/rulings that make it impractical, just completely do away with the service and let the users, politicians, rights abusers and courts work it out. If it pisses of enough users, the politicians will get involved. But News-Service.com doesn't have to spend a ton of money (and raise prices) to stay out of trouble. And of course, the rights holders will be inconvenienced by this in ways they haven't even thought of yet.
Slashdot Mirror
I'm not sure I see the flaw.
TSA's job is to prevent passengers from bringing weapons onto the airplane. They have some successes and notable failures in doing this.
No, the TSA's job is to stop terrorists from hijacking planes, not to keep guns off planes. If half the passengers had guns, the terrorists wouldn't try hijacking a plane. And that's the fundamental problem with the TSA, their focus is on passengers as threats, rather than on the threat to the passengers. That's like saying locks are to keep you from opening a door. No, the lock is to protect what's behind the door, the door and lock are just one mechanism of providing protection.
What you're saying is that it's okay that the TSA might fail every now and again because the passengers will spot the malicious person and prevent him from performing his dastardly task.
No, I'm saying it's impossible for the TSA to succeed at that task. Therefore, they need to focus on how to minimize the risk with minimal invasiveness and impact. That's off topic, see my blog posts for more info. Here's the most relevant one to this discussion.
But if you want to go with this analogy, Android would be a better secure environment than iOS. Android has various tools that smart people can use to find malicious software So, to carry this into your analogy, using Android is like flying on airplane with a group of passengers who understand security and can spot the evildoer and warn others. iOS is like flying on an airplane where everybody says, "Oh, they made it through the TSA checkpoint. They must be okay."
No. Those tools are as useless to a typical Android user as a brake adjustment tool is to a typical car driver. It has nothing to do with the user's attitude, 95+% of users don't have enough knowledge to adequately identify risks in software, therefore, users are safer when a team of trained people vet all the software before users can access it.
If all Android software had to be vetted by a team of trusted experts using those tools before it could be downloaded and installed on a user's phone, then it would be a safer (not more secure) environment. Since all iOS apps are vetted, it's much harder for malicious software to get through. In either case, some malicious software will get through, but more will (and has) gotten through to the Android stores. The fact that Apple vets all the software on the iOS App Store reduces the chances of malware getting through, therefore, iOS users are safer from malware (again, not to be confused with being more secure).
Even though Android users may technically have access to check out the software they're loading, they don't have the knowledge or skill to do so. They don't even know that they have the tools available or what to look for, much less how to evaluate anything the tools might show them. That the tools are available is completely useless to 95+% of Android users because they don't have the knowledge to do anything useful with the tool. And most of those don't know or care that those tools are available, they just want a phone that works.
Having the tools available is only useful to those with the knowledge of how to effectively use the tools and evaluate the results (i.e. the user must know the tools exist, know how to use them, know how to interpret the output to identify potential risks, AND understand enough about security to evaluate any potential risks identified). The tools are only useful to the 1% who understand enough about security to vet a program in the first place.
First, clearly you didn't read my reply to the previous commenter who used the "false sense of security" fallacy. Actually, the "false sense of security" argument can be many fallacies, linked below:
Appeal to belief. e.g. Many people claim it gives a false sense of security, therefore, it must. Show that it actually has that effect before you use it as your premise. A hypothetical premise only gives a hypothetical result.
Begging the question. e.g. Giving people "false sense of security" makes them less safe assumes that they have the knowledge and ability to do something useful to mitigate the risk AND that they would do something different if they didn't have that "false sense of security. However 95+% don't have that knowledge, and evidence is that most don't change their behavior even after they've been informed of the risks. The assumption is false, therefore, the conclusion is fallacious.
Composition. e.g. Because I/we/technical users possess the knowledge and ability to recognize security risks, all users would behave the way I/we would. Your/Our behavior (or theoretical behavior) does not represent what most users will actually do.
Ignoring a common cause. e.g. Users are careless when they think they're safe, therefore, they are careless because they think they're safe. In fact, most users are either always careful, or always careless, regardless of whether they think they're safe.
Flawed analogy. Forget that the TSA is searching for weapons when they need to be watching for suspicious behavior. Forget that they're irradiating passengers and groping others for their illusion of security.
The fundamental problem with the analogy is that air passengers know to watch for weapons, suspicious behavior, etc. In fact, passengers are the only ones who have actually caught any attempts at terrorism in the last 10 years, not the TSA. Passengers can still do something to detect and stop an attacker on a plane. Software users don't know what to look for, what is suspicious behavior, where to look for it, or how to stop it if they could detect it. And given the nature of software, that all of the "work" is hidden from the user, there is very little a user CAN look for, and if if the do detect something, it's probably too late.
They're two totally different environments, requiring two different approaches to safety.
Which makes absolutely no difference to the 95+% users who don't know enough about security to make such an evaluation. No matter how many times users get burned, if they don't understand security, most of them will make the same mistake next time simply because they don't know how to evaluate an app for security. And for those who do know about security, it doesn't stop them from exercising caution. Therefore, the "false sense of security" actually makes no difference.
It's not more secure (Charlie Miller keeps demonstrating that), but for the typical user (who doesn't know enough about security to judge an app), having a vetting/approval process such Apple's is still offers a safer environment than running completely unvetted apps (such as on the Android stores).
Save 15% or more on your tape purchases, while knowing you're secure.
And the ISPs would also need full access to the digital source for all their copyrighted media. I mean, how can they look for copies if they don't have unencrypted source to all the copyrighted material? Hashes are completely insufficient because those would be defeated by simply changing one byte and/or of the data. With full, unencrypted source media, then the ISP could compare all new media files uploaded to see it it's a close match to the source and flag those that are close for manual review.
See, a nice technological solution to a behavioral/legal issue. Of course, it would cost a fortune, would be pretty easy to bypass, someone at an ISP would accidentally release the unencrypted source, and the rights holders would never go for it, but it makes as much sense as anything the MAFIAA has suggested.
DMCAA - Digital Mafia Collection Agency Act.
There are none so blind as those who will not see.
Done wasting my time trying to explain it to you.
So now you're saying that even though you explicitly said they could differentiate their device by running a different UI like they do now, you just know that they won't.
Go back and read my comment again. If Android provided a good standard UI, most would not replace it. A UI is a WHOLE lot of work, especially when you have to maintain compatibility with third party apps. They would spend their efforts on making better hardware and/or proprietary apps and/or lower cost. This is no change from my initial statement.
Except that this is not about a derivative work because running Sense on top of Android does not create a derivative work, just like running LiteStep on Windows does not create a derivative work.
Replacing the UI is a major change, it is a derivative work. But if you go back to my original comment, I specifically stated ... an OEM felt they had a way to improve it, they would be free to do so to differentiate their product.... Google could add restrictions that state: If an OEM customizes it, they have to be able to meet/exceed those same standards (which could include performance, responsiveness, and compatibility benchmarks) in order to use the Android name. Nowhere in there did I say they can't replace the UI, or otherwise customize it, said most wouldn't. I also said is that Google could set standards they have to meet to be able to use the Android name.
So, we're right back to my initial statements.
If you want some precedent on trademark usage, here's one. In that case, MS settled because of issues with their claim to "Windows", but the fact that it was allowed to proceed as far as it was when "Lindows" wasn't even using MS's trademark, but a very similar name gives some indication of how much control over a trademark usage the owner really has (within their market/business). Perhaps an even better case is Apple Corps v Apple Computer, they were in completely different businesses and the names weren't the same, but Apple Computer still paid Apple Corps (multiple times) to use the name. These cases strongly suggest Google can certainly impose the restrictions I suggested on "Android".
If it had a good, usable, UI standard, but an OEM felt they had a way to improve it, they would be free to do so to differentiate their product.
It doesn't take a genius to figure out that if OEMs change the UI then it becomes non-standard.
But if the default UI didn't suck, they wouldn't all need to change it, and most wouldn't.
Google owns the Android trademark. They can place restrictions on it's use as they see fit. That they haven't restricted it as I suggested is part of the problem.
They cannot stop an OEM from stating that their device runs Android, that's not how trademarks work, there is no legal method for them to do such a thing.
Yes, they can. If I own the trademark, you can't use it without my permission unless you're making a reference to my product. If that product is OSS, and you've modified it, then it's no longer my product (it's a derivative), so the only way you can use my trademarked name is with my permission. If I set terms under which you may and may not use my trademark, then you can use it only when you comply with the terms. That's exactly how trademark works.
IANAL.
Go back and reread my earlier post. I didn't ignore that at all. First you argue with my premise, then when your own comments demonstrate my premise is valid, you assert I'm ignoring something I stated in my premise.
Google owns the Android trademark. They can place restrictions on it's use as they see fit. That they haven't restricted it as I suggested is part of the problem.
Because the vanilla UI SUCKS. Which just demonstrates my initial assertion.
That's what they do, and that's part of what causes the problem. HTC's Android isn't the same as Samsung's Android even though there is a standard UI on vanilla Android. OEMs want - or rather need - to differentiate so of course they will make changes if the OS is free software.
Clearly, they don't, or they wouldn't have the problems they have.
Actually, Android can to all of that, and still allow customization. If it had a good, usable, UI standard, but an OEM felt they had a way to improve it, they would be free to do so to differentiate their product. Likewise, you can specify a minimum level of hardware that delivers an "acceptable" user experience with the standard package. One of the things the license gives you access to is the use of the Android name. Licenses can impose restrictions, even on OSS. Google could add restrictions that state: If an OEM customizes it, they have to be able to meet/exceed those same standards (which could include performance, responsiveness, and compatibility benchmarks) in order to use the Android name. If they don't meet those, they can either use the OS, but they can't claim Android compatibility. That gives OEMs a strong incentive to meet the specifications, but they're free to forego them if they think it's worth the trade-off, and Android as a platform isn't harmed by that OEM's choice.
What you call a design failure is usually just a feature nerds care about and typical users don't. That's what most commenters on here completely fail to understand, and that's why the iPod, iPhone, and iPad have outsold ever competitor no matter what the nerds have called failures.
That doesn't mean those products haven't had design issues or missing features, it just means that your definition of a failure is skewed by your opinion of what a device can/should do.
As for just getting stuff done, that's exactly what Apple products make it easy for the typical user to do, get stuff done WITHOUT having the think like a programmer or engineer. And most programmers and engineers refuse to even consider that adapting a device/UI to the user is far more valuable and marketable than features that users can't figure out how to use because they're not interested in learning to think like an engineer or programmer just to play their music, make a phone call, or surf the web, or check email.
Trouble comprehending the topic of your own post?
Strongest ever recorded in Oklahoma.
That might be interesting, if OK didn't have a history of M5+ quakes about every 60 years, 1887, 1952, and now 2011. I'm not saying fracking isn't possibly related, there is evidence from other areas that fracking may induce some seismic activity, but this one is more likely just periodic movement.
Wrong. OK has a history of M5+ quakes about avery 60 years. 1887, 1952 and now 2011.
And the reason they've shipped phones with too little RAM/CPU and poor quality screens is essentially that consumers often demand crap. It's kind of a general problem, not limited to cell phones, that people want stuff but they don't want to pay for quality. That's why we have McDonalds restaurants all over the place and Best Buys filled with eMachines computers.
Consumers don't demand crap. Consumers largely shop on price. Retailers (and in the US, wireless carriers) buy devices to hit certain price points that they can advertise. Consumers don't have access to information to compare the devices, so put the blame where it belongs, with the sellers who are willing to sell crap because they know people will buy it and then blame the manufacturer (rather than the company who knowingly or carelessly sold them a piece of crap to make a profit).
I've worked in retail computer stores. I've talked customers out of buying products that I didn't think they would be happy with (e.g. products with poor build quality or a high return rate). Customer satisfaction creates repeat customers. Quality, value, usability, and customer service create customer satisfaction. Price is rarely the top consideration, it's just the one that sellers focus on because it's easier to sell on price than to actually provide information and service to the customer.
Android itself seems to have been fundamentally fucked as Google has spent the last 3 years reinventing the wheel that had already been built, quite well, in regular Linux platforms.
And how many successful (non-Android) Linux phones are there? An OS alone does not make a device. A server OS does not automatically make a good desktop, or vice-verse. A desktop OS does not automatically make a good mobile device OS. Switching from a keyboard to a keyboard+mouse/stylus to a single touch touch-screen to a multi-touch touch-screen requires redesigning the UI and/or APIs. Screen size, RAM, CPU, and GPU all affect what the UI can do while still being responsive enough. You can blame Google, but it's the hardware vendors that didn't offer (or were slow to offer) newer versions of Android for the first generation of Android phones. The hardware vendors had to select or develop a UI, because Android didn't have a sufficient UI, and most of them did a poor job of it (as I would expect, if they were that good at OS/UI development, they would probably have their own OS rather than Android).
Some should be showing off new features that Apple doesn't have like the new face unlock feature in Android 4.0.
Yeah, when there are phones shipping with Android 4.0 and front facing cameras that can use the features. Marketing features that aren't yet available to the end users is a REALLY bad idea.
Others should highlight their restrictive model: picture the old Mac vs. PC ads, but with the iPhone checking with Apple before denying the user's request to install an app of their choice.
This would probably backfire, how many trojans and programs that send your info back to the developer's server have been found in the Android marketplace? Lots. Apple would almost certainly use that in a counter-attack ad.
Market your strengths, but be careful of those that also have an underlying weakness/vulnerability, it will come back to bite you.
Android needs more standardization. A standard UI, a minimum resolution, and a minimum hardware set. One of the things Apple has done very effectively is manage the user experience. MS Windows and Android have allowed manufacturers to put out devices with too little RAM, CPU, and/or poor quality screens, keyboards, touch-screens and it hurts the reputation of the platform. When a user buys a bad Windows or Android device, they're as likely to blame the OS as they are the hardware manufacturer. Failing to understand and address that is a marketing failure on the part of the OS vendor.
Market what you can do with that extra storage, not that is has extra storage. "7500 songs or 20 hours of movies". Market benefits, not specs.
...real programmers don't ask for help, unlike those wimpy JS hacks and C# pretenders.
News-Service.com responded correct. If they're going to make laws/rulings that make it impractical, just completely do away with the service and let the users, politicians, rights abusers and courts work it out. If it pisses of enough users, the politicians will get involved. But News-Service.com doesn't have to spend a ton of money (and raise prices) to stay out of trouble. And of course, the rights holders will be inconvenienced by this in ways they haven't even thought of yet.