Has the guy actually made any modifications to it?
When I need to install a non-supported app on my Google TV, I just download the app on my rooted phone and email it to myself.
That's it, most tablet apps run fine on my Google TV even if their manifest says it does not support it (and my Google TV itself is not rooted, it doesn't have to be since it's just receiving the apk). Now the usability of those non-GoogleTV apps may not be that great, but that's another story. My point is that nothing on the TV itself prevents the installation of anything if the user bypasses Google Play.
Ideally they'd release a test suite, and anything that passes the test suite may be called OpenStack, while anything that fails may not. That would be a simple, objective criterion.
If they did truly value their reputation among developers, they'd just release a standard test suite that everybody would fail initially.
Using a test-driven approach would make sense in this case.
It's because no one uses the Google+ sign-in yet. Google has barely started phasing out the normal Google sign-in in favor of their Google+ sign-in.
Two key innovations introduced by the new Google+ sign-in over its predecessor, the plain Google sign-in. It's no longer compatible with an open standard like OpenID, it now uses its own proprietary standard. Plus, it exports everything plus the kitchen sink when signing-in into a web site (assuming you give it the permission to).
Still, I prefer the Google+ sign-in because it actually gives me granular control over which circles can see what I'm sharing without having to spam the rest of my acquaintances with content they don't want to see. Criticize Google all you want, but even when they do evil, they seem to be doing it better than other companies.
Now unable to leave the country, unable to vote in most places, unable to own a firearm....
Unable to own a firearm.
Wouldn't that be a good thing? The guy is 19 years old, not 12. He should have been old enough to know better the first time around with the airplane. And he should have been old enough to know better the second time around when the police helicopter immediately showed up after that.
And what about leaving the country? Did he get himself on a no-fly list because of this? Since when can felons not leave the country? As far as I'm aware, only incarcerated felons and felons on parole can not leave the country. With him, his sentence is 30 months, he'll be lucky if he's given parole since that will cut down that 30 months incarceration drastically, but as far I'm aware that hasn't been decided yet.
Thank you for contacting Kobo Writing Life. There is a known error on the WHSmith website that is showing DRM-Free books as DRM ePubs. They’re working on fixing this issue when they update their website in May. Even though your books appear as DRM ePub’s, any customers that want to purchase your book from WHSmith are directed to our site to make the purchase. On our site your book is correctly listed as DRM-Free. I’m sorry for the inconvenience that this may cause and hope that this has clarified things for you. Sincerely, The Kobo Team
Can't wait until next spring. I'm pretty sure that's when this will get the axe.
You're wrong. It already got the ax last summer (July 2012) when that service was called Google Notebook (or Google Notes). Google Notebook could already be shared between all your devices, and it wasn't just limited to the latest release of Android either.
Why did you make this transition?
We loved working on Notebook, but sometimes we have to make the hard decision to focus more of our efforts on products and technologies that will yield the most benefit to users in the long run. With all the great innovations and improvements to Google Docs in the last few years, we think it’s a great replacement for Notebook. http://www.google.com/googlenotebook/faq.html
Personally, I just like PushBullet. It doesn't have all the functionality Google Notebook used to have, nor will it ever have half the functionality Keep will have (since it's really designed to push things to your devices, not really push things both ways). But I really like it. It's simple. It's elegant. And it just does the things I need it to do.
And no, I don't know those PushBullet guys. I have no affiliation with them.
This document underscores just how little our military and political leaders understand about this new theatre of war. They're drafting up treaties without even knowing where the borders are yet.
Don't worry. It's not like the US/NATO adheres to the real Geneva Convention.
Even its own Constitution, the US makes a mockery of it by ignoring the clear language the Founding Fathers used to describe who it pertained to.
The guy is asking the wrong question. He should be asking questions like "How can I maximize profits?" or "How can people find out about my utility?" not "What is a reasonable way to deter piracy?". One doesn't necessarily follow from the other.
In any case, coming back to his original question. Perhaps his utility could help his customers deter the piracy of the graphics they create with it (may be some kind of self-signing/watermarking/registration system for their own graphics). A customer who tries to protect his own assets will probably not want to try doing it with a pirated copy of the software. It would be too high a risk that whoever pirated that software also crippled/modified the functionality that would deter piracy of the images as well.
I linked to that article because it detailed the process of how Microsoft automatically recompiled WP7 apps to WP8. If my point wasn't possible, how come there were 100K apps at launch automatically without even the final SDK coming out?
Take a look at this suggested fix/workaround:
If an app that targets Windows Phone OS 7.1 is deployed to a phone that is running Windows Phone 8, or you create a new app that targets Windows Phone 8 and that app uses the photo chooser task, if your app iterates over the contents of isolated storage and you want to skip over directories created by the system, skip over “PlatformData” and “Shared”.
This type of fix is worded in such a way as it can be applied using either the WP7 sdk, or the WP8 sdk.
They would have said so if this fix/workaround could only work using the WP8 sdk-only. Their automatic recompiling on the cloud must keep on running every time a current WP7 application gets updated I would think. Either that, or may be they issued a pre-release of their sdk to existing developers. In either case, as a developer on a different platform, I don't consider this to be strange at all.
So the onus is on you to show that there were lots of problems with the migration, and you failed to come up with even one reference.
"Lots of" is not a precise enough number for me. I've already shown you 20+ far-reaching problems not dealt automatically specifically mentioned by Microsoft in its own documentation, but you've chosen to believe that those problems are not wide-reaching enough to affect most WP7 apps running on WP8.
Perhaps, I could even find you 20+ documented references of actual apps having had problems with the automatic migration, but again I'm sure that such a number won't be enough for you. So why should I keep on wasting my time?
I've already told you what my WP7 developers friends have told me. You've chosen not to believe me. You've chosen to believe that I must have spoken to someone else (if I'm telling you the truth at all). And that's fine. Let's just end it at that. I accept the limitation that I can not prove everything I know to be correct. Also, I accept the limitation that I can not prove everything that my WP7 developer friends have told me about their work. And the burden is on you to believe me, or not believe me.
Making you believe me is not my call anymore. And I'm beginning to think it never even was to begin with. Take care.
My original point was that Microsoft claimed it was going to be so much better than Android for developers because it was going to handle fragmentation the right way (not like Google).
When did they do that?
At pretty much every developer tech evangelist event sponsored by Microsoft that I've been to that tried to attract developers from other platforms (at least three, may be more, Microsoft did sponsor lots of so-called "cross-platform" events so as to attract developers from other platforms). I'm sure I could find a written quote, but I'm tired being the one who's doing all the researching and the careful reading -- when you're obviously doing none of that yourself.
So from where did the 100K+ apps appear in the WP8 marketplace at launch? Magic? The developers did not have to lift a finger to do that.
Magic? I don't believe in real magic.
Stage magic, or clever marketing, that's the kind of magic they've used. Magic which uses smoke and mirrors to obfuscate the real underlying situation.
Like I've said already, many of those WP7 developers did have to modify their code. Microsoft created all kinds of incentives for it. And the ones who didn't bother just suffered a new influx of negative reviews from users with WP8 phones and therefore less visibility in the app store.
"do you really think the 100,000 app compiler trick is going to work?"
The article you're quoting is from before the WP8 launch casting doubts on the process i.e from June 2012. WP8 came out in October.
Yes, that article doesn't make my entire point. I never claimed otherwise. It only makes part of my point, that recompiling an app doesn't necessarily mean running an application.
And I did have to quote it for you, you're the one who linked to it originally, claiming that it somehow supported *your* point when it very clearly doubted that your point was even possible at all.
And I'm the one who pointed out to you that all the 5 articles you linked to were from before the WP8 launch (including the article quoted above), thereby nullifying them as evidence for your point, and now you're the one who has the gall to point out the same thing to me? Even quoting the dates and highlighting the "before" in bold as if you were the one suddenly trying to educating me on the matter when I didn't even make half the claim you made? Seriously?!
That's misleading at best and outright false at worst. Microsoft has compiled 100,000+ WP7 apps in the cloud so that they work for WP8. So from the perspective of a WP7 dev, the apps run unmodified from their end and they don't have to put any effort towards modifying their app. They DO NOT have to worry about the 35+ "breaking changes" that you quote.
Yes, they do have to worry about that. You were actually just too lazy to read the rest of the linked Microsoft documentation (or the rest of my other very lengthy posts where I do all the cutting and pasting, and the highlighting in bold for you).
And no, saying that you can recompile something doesn't mean that it's going to run as well as it did before, or even run at all.
Again, how different is a WP7 dev's situation with WP8 coming with the Android dev's situation with a new version coming?
My original point was that Microsoft claimed it was going to be so much better than Android for developers because it was going to handle fragmentation the right way (not like Google).
And what does Microsoft do?
On almost day 1, it turns around, and actually does it much-much worse than Google, thereby burning most of its early adopter developers. And please don't just take my word for it, ask your friends who actually developed for Windows Phone 7.x. If one of them is willing to speak up here to share what happened, I'm actually willing to completely shut up about it.
I know what I'm saying actually runs contrary to what Microsoft does normally on the Desktop. In the past, Microsoft has done extremely well maintaining backward compatibility whenever it could. This time, they did try, but they just ended up upsetting their WP7 developer base.
Don't you even read the articles you link to? The 5 articles you linked to all predate the migration, and besides, the last article you selected makes even this point:
[...]
Do you really want a third party compiling your app?
How can you be sure it will work?
A brand new compiler, running in the cloud, compiling 100,000 apps and doing the job correctly - first time?
And without even a public beta of the compiler?
This is beginning to sound like real magic not just stage magic.
The chances of creating a compiler that can do this job correctly are small. Even if the compiler is 100% perfect at its task, things still don't always work.
Consider if any app has a process that is based on any timing loop or delay. As the resulting code runs at a very different speed, even if the compiler was 100% perfect there would still be apps that didn't work as originally designed.
You also have to ask why is this a cloud compiler?
The best reason I can think of is that by making it in the "cloud" they can avoid having to make it available to anyone else.
That is, not only will you not have to be involved it is absolutely impossible for you to be involved.
That is, Microsoft will not be putting this tool into your hands.
So why exactly is Microsoft taking on this very difficult task just to make your apps go a bit faster?
The most likely reason is that Microsoft is taking a very different route to getting WP7 apps running under WP8 than simply bundling Silverlight and XNA subsystems. The compiler is most likely not only doing the job not only of speeding up WP7 apps but making them into WP8 apps.
This is potentially and even more difficult task than just creating a simple compiler.
Microsoft haven't said that this is what the compiler does but suppose it j
Your earlier assertion was that WP7 won't run on WP8, not that WP8 apps won't run on WP7.
Just to be clear, I said that WP7 [apps] won't run [unmodified] on WP8. Yes, that's correct. I still stand by the original gist of that claim.
With Android, you just keep the target SDK number the same, and you don't have to change a thing. Let me highlight in bold some of the phrases you missed in the Android documentation you linked to:
Content providers are no longer exported by default. That is, the default value for the android:exported attribute is now “false". If it’s important that other apps be able to access your content provider, you must now explicitly set android:exported="true". This change takes effect only if you set either android:targetSdkVersion or android:minSdkVersion to 17 or higher. Otherwise, the default value is still “true" even when running on Android 4.2 and higher.
Compared to previous versions of Android, user location results may be less accurate if your app requests the ACCESS_COARSE_LOCATION permission but does not request the ACCESS_FINE_LOCATION permission. To meet the privacy expectations of users when your app requests permission for coarse location (and not fine location), the system will not provide a user location estimate that’s more accurate than a city block.
Some device settings defined by Settings.System are now read-only. If your app attempts to write changes to settings defined in Settings.System that have moved to Settings.Global, the write operation will silently fail when running on Android 4.2 and higher. Even if your value for android:targetSdkVersion and android:minSdkVersion is lower than 17, your app is not able to modify the settings that have moved to Settings.Global when running on Android 4.2 and higher.
If your app uses WebView, Android 4.2 adds an additional layer of security so you can more safely bind JavaScript to your Android code. If you set your targetSdkVersion to 17 or higher, you must now add the @JavascriptInterface annotation to any method that you want available to your JavaScript (the method must also be public). If you do not provide the annotation, the method is not accessible by a web page in your WebView when running on Android 4.2 or higher. If you set the targetSdkVersion to 16 or lower, the annotation is not required, but we recommend that you update your target version and add the annotation for additional security.
The first and last paragraphs go away, since they're not relevant to a developer who won't change the target SDK. So what are we left with? Only the second and third paragraph. Now, let's read those remaining paragraphs a little more carefully once again.
Compared to previous versions of Android, user location results may be less accurate if your app requests the ACCESS_COARSE_LOCATION permission but does not request the ACCESS_FINE_LOCATION permission. To meet the privacy expectations of users when your app requests permission for coarse location (and not fine location), the system will not provide a user location estimate that’s more accurate than a city block.
What does this mean less accuracy? Are the apps that access that permission COARSE_LOCATION (but not fine location) going to crash? No. Are they going to blank out the screen? No. Are they going to block the UI thread? No.
Now I could see how an app that currently accesses FINE_LOCATION could crash and could act really weird, but the documentation clearly states that only the applications that access the COARSE_LOCATION, but not FINE_LOCATION will be affected. How does this change break something exactly? Why do you call it a "breaking change" when it actually doesn't break anything?
Some device settings defined by Settings.System are now read-only. If
Yes, you just need to install the apk yourself. One way to get to the official apk is to root the phone that originally downloaded the apk with (although, there are other ways that don't involve rooting at all).
I've done that a couple of times for my Google TV. Most Android tablet apps will work ok on Google TV, it's just that many developers just don't bother to check since the Google TV marketshare is still so small.
Do you ever wonder why an app that has the cumulative average rating of 4.5+ stars (may be more) has so many bad reviews recently? And don't you wonder why there is so much disparity between the good reviews and the negative reviews.
The MS app store doesn't tell you which version of the Windows Phone each review is based on, but may be you could take a guess at what's causing the new influx of negative reviews among all the five stars reviews this app currently enjoys?
Buggy in wp8 l920. Lots of errors by Mark 3/18/2013 Constant error messages. Never seems to get fixed. by Michal 3/18/2013 Bags with connection, but it is nice app. Update pls by Jain 3/18/2013 Good app.. Never had any problem. But lacks many features as compared to other platforms. by TAHMINA 3/18/2013 Broken - errors all the time by Alessandro 3/17/2013 Quite complete and usable, a must have for me! by User 3/16/2013 Good app, but please add a feature so we can see sent emails. Thanks. by User 3/15/2013 Not as good as the google or apple versions by User 3/15/2013 Too many oops something went wrong errors... by Gerald 3/15/2013 Doesn't load properly on Nokia 930 Windows 8 phone by Abdulrehman 3/15/2013 Many bugs- errors out freqly by chrissy 3/15/2013 Login fails immediately, doesn't wait for async call to data auth service.:( by Michael 3/14/2013 Fix this garbage app!! Can't believe you published linkedin on windows phone like this. by User 3/14/2013 Nunca me corrio by Ramkumar 3/13/2013 Doesn't work 90% of the time. Failed to load data with error messages.
Those negative reviews coming from the "wp8 l920" user and the "Nokia 930 Windows phone 8" user are interesting, aren't they? Personally, I wouldn't be surprised if the only negative reviews this app was attracting were only from the WP8 users, and the only glowing reviews were coming from the WP7 users. It's too bad I can't prove this without the shadow of a doubt. Someone like you would never believe such a guess on my part.
And what breaking change between WP7 and WP8 could possibly trigger this "Doesn't work 90% of the time. Failed to load data with error messages"? I did promise you I'd look into that. Let's see. I would guess those two changes:
Change When your app makes an SSL request to a web service or web site, apps that target Windows Phone 8 contact the issuer of the site's certificate for the security certificate revocation list. This additional network request in Windows Phone 8 apps increases the time required for the SSL request. If the certificate revocation list is not received in a timely manner, the SSL request may time out, especially over a slow or unreliable network connection.
Impact/Workaround Make sure that your app handles the possibility of a timeout and retries the request or continues without the requested data.
Change In Windows Phone 8, the background transfer service will transfer on the following data networks while the app is in the foreground. In Windows Phone OS 7.0, transfers do not occur on these data networks, regardless of whether the app is running in the foreground. 2G, EDGE, Standard, GPRS In Windows Phone 8, transfers won’t proceed on these networks while the app is not in the foreground. This limitation is shared by the HttpWebRequest object, so performing your own transfer doesn’t provide any advantages over using background transfers. On networks that are 3G and higher, background transfers will proceed on both Windows Phone 8 or Windows Phone OS 7.1, regardless of whether the app is running in the foreground, assuming all other conditions are met. Background transfers will occur in W
Know I'll get modded down for going against Slashdot groupthink. But what is the argument suggesting? "It all happened on a computer, it shouldn't be prosecuted?" Stealing private information and releasing in publicly isn't just obviously illegal, it caused grief for 114,000 people.
He didn't release it publicly. He released it to a news site (which did the responsible thing).
Fact: WP8 was WP7 compatibility with only a few minor differences, and more than 10000 WP7 ran unmodified on WP8, and you said "all existing third party applications"
A "few minor differences"? That's not a fact. That's a claim made my Microsoft on its own site.
I'll tell you what. You pick a third party application that you like and you tell me its name. You just pick one. That's it. And I'll tell you how that application would have broken if it had been ported unmodified from WP7 to WP8.
Does this sound fair? You can even help yourself with the table I showed you earlier, listing the so-called "few" minor differences between WP7 and WP8 (that do not get automatically resolved by Quirks-mode).
Android is completely backwards-compatible, so an application you wrote for Android 1.0 or 1.6 will still work on Android 3.x or Android 4.2 (without any changes).
That's odd, because I keep encountering apps that worked on older devices that claim they won't work on my Android 4.2 devices. Maybe that's a certification issue rather than a real compatibility problem, but it shows that upgrading isn't 100% perfect.
I doubt it's a certification issue (unless it's from third party framework). As developers, we were told very early on by Google to make our certificates expire in 99 years, or 120 years (I forget what was the number exactly).
My guess would be that it's the use of an undocumented api that might have been the issue. For instance, before Google gave us the ability to customize our screen locks with widgets, some of the more clever developers found undocumented ways to embed widgets on our screen locks. Or another example would be Ad Blocker, which was recently banned from Google Play (since Google is becoming more evil and controlling now unfortunately). That app too must have been using undocumented features, that could easily break with a new version of Android (especially now that the app has become big enough to get onto Google's radar).
That being said, I'm an Android developer, and I've also personally used at least 100+ different Android applications in the last three to four years on a variety of Android phones, I've never actually experienced this issue you described, and this is the first time I'm actually hearing someone describing this issue.
And please, speak to any of your developer friends who developed on Windows Phone 7. You're obviously not going to take my word for it. I assume you're just going to think that I cherry-picked the information I wanted from the Microsoft web site.
Er, that likely means they'll be on WP9. How long will Google update Android 3.x or even 4.0?
Trololol samzenpuss, trololol.
I agree that the summary is click-baiting us.
But on a related-note, the first jump Microsoft made from Windows Phone 7.5/7.8 to Windows Phone 8 broke compatibility for all existing third party applications. That move really upset the early developers on that platform (especially when they had been told that MS was going to be different and was not going to be fragmented).
With Android, this just does not happen. Android is completely backwards-compatible, so an application you wrote for Android 1.0 or 1.6 will still work on Android 3.x or Android 4.2 (without any changes).
In the meantime, take your GPS into Tunisia and let me know how that goes. I won't visit you in Tunisian prison.
Oh yes of course, I'm not disputing that those laws exist, or that they're enforced on individuals on a regular basis. And even thought, I sounded quite certain in my allegations, I'm only just 90% certain that it is some kind of official retaliation, and not some kind of corrupt official looking for bribe money, or some tin-foil hat wearing official going off on a personal crusade against gps units.
Those multinationals have planned for the consequences, and we shouldn't cry for them.
I don't think anyone is crying for them.
And yes, part of such a contingency plan for US conglomerates could also mean to have a number of powerful US lobbyists and powerful US politicians already on their corporate payroll (or the politicians wives, or their close relatives, or their close friends). Trying to manipulate politicians can sometimes be the cheaper way to go.
The loss that Coke realizes in all of this is more than you or I will make in years, but less than they make in a day.
Personally, I couldn't care less either way, but I doubt that the conglomerate itself sees it that way.
It takes time to build market-share and establish yourself as a category leader in any market. Anything that happens today commercially in China could have far reaching consequences into the future, when China's market is considered exponentially more valuable than it is now.
It could also have an immediate impact on current shareholders and current share prices, since the price of a share often includes the potential growth of a company's future market.
If you do a lot of travelling, you will find that GPS laws are different everywhere.
This has nothing to do with GPS. After the US accused China of cyber attacks, it just retaliated against the biggest US conglomerates they could go after.
China did something similar to Carrefour after the French President officially received the Dali Lama. Of course, everybody knows that Carrefour had nothing to do with the Dali Lama's visit, but that wasn't the point. The point was to put the French chain store under siege everywhere it was located in China, so that the French corporation and the related French unions would in turn put the screws to the French President.
Also, it doesn't hurt that a corporation like Coca Cola (and other corporations in the same category) couldn't care less about cyber attacks against US-based technology companies or US-based media companies, but care deeply about being in China's market. So by targeting such companies and accusing them of espionage (a pretty serious allegation if you ask me), they're effectively pitting the lobbyists of those major consumer goods companies against the lobbyists of the major technology/media companies.
Slashdot Mirror
Has the guy actually made any modifications to it?
When I need to install a non-supported app on my Google TV, I just download the app on my rooted phone and email it to myself.
That's it, most tablet apps run fine on my Google TV even if their manifest says it does not support it (and my Google TV itself is not rooted, it doesn't have to be since it's just receiving the apk). Now the usability of those non-GoogleTV apps may not be that great, but that's another story. My point is that nothing on the TV itself prevents the installation of anything if the user bypasses Google Play.
Ideally they'd release a test suite, and anything that passes the test suite may be called OpenStack, while anything that fails may not. That would be a simple, objective criterion.
If they did truly value their reputation among developers, they'd just release a standard test suite that everybody would fail initially.
Using a test-driven approach would make sense in this case.
It's because no one uses the Google+ sign-in yet. Google has barely started phasing out the normal Google sign-in in favor of their Google+ sign-in.
Two key innovations introduced by the new Google+ sign-in over its predecessor, the plain Google sign-in. It's no longer compatible with an open standard like OpenID, it now uses its own proprietary standard. Plus, it exports everything plus the kitchen sink when signing-in into a web site (assuming you give it the permission to).
Still, I prefer the Google+ sign-in because it actually gives me granular control over which circles can see what I'm sharing without having to spam the rest of my acquaintances with content they don't want to see. Criticize Google all you want, but even when they do evil, they seem to be doing it better than other companies.
Now unable to leave the country, unable to vote in most places, unable to own a firearm....
Unable to own a firearm.
Wouldn't that be a good thing? The guy is 19 years old, not 12. He should have been old enough to know better the first time around with the airplane. And he should have been old enough to know better the second time around when the police helicopter immediately showed up after that.
And what about leaving the country? Did he get himself on a no-fly list because of this? Since when can felons not leave the country? As far as I'm aware, only incarcerated felons and felons on parole can not leave the country. With him, his sentence is 30 months, he'll be lucky if he's given parole since that will cut down that 30 months incarceration drastically, but as far I'm aware that hasn't been decided yet.
Actually, I know one guy who would have behaved the same way she did, or even worst.
Zealouts on crusades can be found just about anywhere.
His blog has been updated. It was just a mistake.
Thank you for contacting Kobo Writing Life.
There is a known error on the WHSmith website that is showing DRM-Free books as DRM ePubs. They’re working on fixing this issue when they update their website in May.
Even though your books appear as DRM ePub’s, any customers that want to purchase your book from WHSmith are directed to our site to make the purchase. On our site your book is correctly listed as DRM-Free.
I’m sorry for the inconvenience that this may cause and hope that this has clarified things for you.
Sincerely,
The Kobo Team
I guess Cory Doctorow made the mistake of using a Creative Commons license.
Next time, he should just release his books under GPL3.
Can't wait until next spring. I'm pretty sure that's when this will get the axe.
You're wrong. It already got the ax last summer (July 2012) when that service was called Google Notebook (or Google Notes). Google Notebook could already be shared between all your devices, and it wasn't just limited to the latest release of Android either.
Why did you make this transition?
We loved working on Notebook, but sometimes we have to make the hard decision to focus more of our efforts on products and technologies that will yield the most benefit to users in the long run. With all the great innovations and improvements to Google Docs in the last few years, we think it’s a great replacement for Notebook. http://www.google.com/googlenotebook/faq.html
Personally, I just like PushBullet. It doesn't have all the functionality Google Notebook used to have, nor will it ever have half the functionality Keep will have (since it's really designed to push things to your devices, not really push things both ways). But I really like it. It's simple. It's elegant. And it just does the things I need it to do.
And no, I don't know those PushBullet guys. I have no affiliation with them.
This document underscores just how little our military and political leaders understand about this new theatre of war. They're drafting up treaties without even knowing where the borders are yet.
Don't worry. It's not like the US/NATO adheres to the real Geneva Convention.
Even its own Constitution, the US makes a mockery of it by ignoring the clear language the Founding Fathers used to describe who it pertained to.
How do you know?
The guy is asking the wrong question. He should be asking questions like "How can I maximize profits?" or "How can people find out about my utility?" not "What is a reasonable way to deter piracy?". One doesn't necessarily follow from the other.
In any case, coming back to his original question. Perhaps his utility could help his customers deter the piracy of the graphics they create with it (may be some kind of self-signing/watermarking/registration system for their own graphics). A customer who tries to protect his own assets will probably not want to try doing it with a pirated copy of the software. It would be too high a risk that whoever pirated that software also crippled/modified the functionality that would deter piracy of the images as well.
Of course it is assumed that google makes it's money by mining the documents, so I would not necessarily use it for business applications.
If you're a business and if you decided to actually pay for the service, Google Drive can actually get pretty expensive.
They'd be crazy to mine that information. It would be the equivalent of Amazon trying to sell books and kitchen appliances to its AWS cloud customers.
I linked to that article because it detailed the process of how Microsoft automatically recompiled WP7 apps to WP8.
If my point wasn't possible, how come there were 100K apps at launch automatically without even the final SDK coming out?
Take a look at this suggested fix/workaround:
If an app that targets Windows Phone OS 7.1 is deployed to a phone that is running Windows Phone 8, or you create a new app that targets Windows Phone 8 and that app uses the photo chooser task, if your app iterates over the contents of isolated storage and you want to skip over directories created by the system, skip over “PlatformData” and “Shared”.
This type of fix is worded in such a way as it can be applied using either the WP7 sdk, or the WP8 sdk.
They would have said so if this fix/workaround could only work using the WP8 sdk-only. Their automatic recompiling on the cloud must keep on running every time a current WP7 application gets updated I would think. Either that, or may be they issued a pre-release of their sdk to existing developers. In either case, as a developer on a different platform, I don't consider this to be strange at all.
So the onus is on you to show that there were lots of problems with the migration, and you failed to come up with even one reference.
"Lots of" is not a precise enough number for me. I've already shown you 20+ far-reaching problems not dealt automatically specifically mentioned by Microsoft in its own documentation, but you've chosen to believe that those problems are not wide-reaching enough to affect most WP7 apps running on WP8.
Perhaps, I could even find you 20+ documented references of actual apps having had problems with the automatic migration, but again I'm sure that such a number won't be enough for you. So why should I keep on wasting my time?
I've already told you what my WP7 developers friends have told me. You've chosen not to believe me. You've chosen to believe that I must have spoken to someone else (if I'm telling you the truth at all). And that's fine. Let's just end it at that. I accept the limitation that I can not prove everything I know to be correct. Also, I accept the limitation that I can not prove everything that my WP7 developer friends have told me about their work. And the burden is on you to believe me, or not believe me.
Making you believe me is not my call anymore. And I'm beginning to think it never even was to begin with. Take care.
My original point was that Microsoft claimed it was going to be so much better than Android for developers because it was going to handle fragmentation the right way (not like Google).
When did they do that?
At pretty much every developer tech evangelist event sponsored by Microsoft that I've been to that tried to attract developers from other platforms (at least three, may be more, Microsoft did sponsor lots of so-called "cross-platform" events so as to attract developers from other platforms). I'm sure I could find a written quote, but I'm tired being the one who's doing all the researching and the careful reading -- when you're obviously doing none of that yourself.
So from where did the 100K+ apps appear in the WP8 marketplace at launch? Magic? The developers did not have to lift a finger to do that.
Magic? I don't believe in real magic.
Stage magic, or clever marketing, that's the kind of magic they've used. Magic which uses smoke and mirrors to obfuscate the real underlying situation.
Like I've said already, many of those WP7 developers did have to modify their code. Microsoft created all kinds of incentives for it. And the ones who didn't bother just suffered a new influx of negative reviews from users with WP8 phones and therefore less visibility in the app store.
"do you really think the 100,000 app compiler trick is going to work?"
The article you're quoting is from before the WP8 launch casting doubts on the process i.e from June 2012. WP8 came out in October.
Yes, that article doesn't make my entire point. I never claimed otherwise. It only makes part of my point, that recompiling an app doesn't necessarily mean running an application.
And I did have to quote it for you, you're the one who linked to it originally, claiming that it somehow supported *your* point when it very clearly doubted that your point was even possible at all.
And I'm the one who pointed out to you that all the 5 articles you linked to were from before the WP8 launch (including the article quoted above), thereby nullifying them as evidence for your point, and now you're the one who has the gall to point out the same thing to me? Even quoting the dates and highlighting the "before" in bold as if you were the one suddenly trying to educating me on the matter when I didn't even make half the claim you made? Seriously?!
That's misleading at best and outright false at worst. Microsoft has compiled 100,000+ WP7 apps in the cloud so that they work for WP8. So from the perspective of a WP7 dev, the apps run unmodified from their end and they don't have to put any effort towards modifying their app. They DO NOT have to worry about the 35+ "breaking changes" that you quote.
Yes, they do have to worry about that. You were actually just too lazy to read the rest of the linked Microsoft documentation (or the rest of my other very lengthy posts where I do all the cutting and pasting, and the highlighting in bold for you).
And no, saying that you can recompile something doesn't mean that it's going to run as well as it did before, or even run at all.
Again, how different is a WP7 dev's situation with WP8 coming with the Android dev's situation with a new version coming?
My original point was that Microsoft claimed it was going to be so much better than Android for developers because it was going to handle fragmentation the right way (not like Google).
And what does Microsoft do?
On almost day 1, it turns around, and actually does it much-much worse than Google, thereby burning most of its early adopter developers. And please don't just take my word for it, ask your friends who actually developed for Windows Phone 7.x. If one of them is willing to speak up here to share what happened, I'm actually willing to completely shut up about it.
I know what I'm saying actually runs contrary to what Microsoft does normally on the Desktop. In the past, Microsoft has done extremely well maintaining backward compatibility whenever it could. This time, they did try, but they just ended up upsetting their WP7 developer base.
http://www.i-programmer.info/professional-programmer/i-programmer/4402-the-astonishing-tale-of-wp8-compiling-100000-apps.html
Don't you even read the articles you link to? The 5 articles you linked to all predate the migration, and besides, the last article you selected makes even this point:
[...]
Do you really want a third party compiling your app?
How can you be sure it will work?
A brand new compiler, running in the cloud, compiling 100,000 apps and doing the job correctly - first time?
And without even a public beta of the compiler?
This is beginning to sound like real magic not just stage magic.
The chances of creating a compiler that can do this job correctly are small. Even if the compiler is 100% perfect at its task, things still don't always work.
Consider if any app has a process that is based on any timing loop or delay. As the resulting code runs at a very different speed, even if the compiler was 100% perfect there would still be apps that didn't work as originally designed.
You also have to ask why is this a cloud compiler?
The best reason I can think of is that by making it in the "cloud" they can avoid having to make it available to anyone else.
That is, not only will you not have to be involved it is absolutely impossible for you to be involved.
That is, Microsoft will not be putting this tool into your hands.
So why exactly is Microsoft taking on this very difficult task just to make your apps go a bit faster?
The most likely reason is that Microsoft is taking a very different route to getting WP7 apps running under WP8 than simply bundling Silverlight and XNA subsystems. The compiler is most likely not only doing the job not only of speeding up WP7 apps but making them into WP8 apps.
This is potentially and even more difficult task than just creating a simple compiler.
Microsoft haven't said that this is what the compiler does but suppose it j
Your earlier assertion was that WP7 won't run on WP8, not that WP8 apps won't run on WP7.
Just to be clear, I said that WP7 [apps] won't run [unmodified] on WP8. Yes, that's correct. I still stand by the original gist of that claim.
With Android, you just keep the target SDK number the same, and you don't have to change a thing. Let me highlight in bold some of the phrases you missed in the Android documentation you linked to:
Content providers are no longer exported by default. That is, the default value
for the android:exported attribute is now “false". If it’s important that other apps be
able to access your content provider, you must now explicitly set android:exported="true".
This change takes effect only if you set either android:targetSdkVersion or android:minSdkVersion
to 17 or higher. Otherwise, the default value is still “true" even when running on Android 4.2 and higher.
Compared to previous versions of Android, user location results may be less accurate
if your app requests the ACCESS_COARSE_LOCATION permission but
does not request the ACCESS_FINE_LOCATION permission.
To meet the privacy expectations of users when your app requests permission for
coarse location (and not fine location), the system will not provide a user location estimate
that’s more accurate than a city block.
Some device settings defined by Settings.System are now
read-only. If your app attempts to write changes to settings defined in
Settings.System that have moved to Settings.Global,
the write operation will silently fail when running on Android 4.2 and higher.
Even if your value for android:targetSdkVersion and android:minSdkVersion
is lower than 17, your app is not able to modify the settings that have
moved to Settings.Global when running on Android 4.2 and higher.
If your app uses WebView, Android 4.2 adds an additional layer of
security so you can more safely bind JavaScript to your Android code.
If you set your targetSdkVersion to 17 or higher, you must now add
the @JavascriptInterface annotation to any method that you want available
to your JavaScript (the method must also be public). If you do not provide the
annotation, the method is not accessible by a web page in your WebView
when running on Android 4.2 or higher. If you set the targetSdkVersion
to 16 or lower, the annotation is not required, but we recommend that you
update your target version and add the annotation for additional security.
The first and last paragraphs go away, since they're not relevant to a developer who won't change the target SDK. So what are we left with? Only the second and third paragraph. Now, let's read those remaining paragraphs a little more carefully once again.
Compared to previous versions of Android, user location results may be less accurate
if your app requests the ACCESS_COARSE_LOCATION permission but
does not request the ACCESS_FINE_LOCATION permission.
To meet the privacy expectations of users when your app requests permission for
coarse location (and not fine location), the system will not provide a user location estimate
that’s more accurate than a city block.
What does this mean less accuracy? Are the apps that access that permission COARSE_LOCATION (but not fine location) going to crash? No. Are they going to blank out the screen? No. Are they going to block the UI thread? No.
Now I could see how an app that currently accesses FINE_LOCATION could crash and could act really weird, but the documentation clearly states that only the applications that access the COARSE_LOCATION, but not FINE_LOCATION will be affected. How does this change break something exactly? Why do you call it a "breaking change" when it actually doesn't break anything?
Some device settings defined by Settings.System are now
read-only. If
Yes, you just need to install the apk yourself. One way to get to the official apk is to root the phone that originally downloaded the apk with (although, there are other ways that don't involve rooting at all).
I've done that a couple of times for my Google TV. Most Android tablet apps will work ok on Google TV, it's just that many developers just don't bother to check since the Google TV marketshare is still so small.
LinkedIn, that's a great example! Thank you!
Do you ever wonder why an app that has the cumulative average rating of 4.5+ stars (may be more) has so many bad reviews recently? And don't you wonder why there is so much disparity between the good reviews and the negative reviews.
The MS app store doesn't tell you which version of the Windows Phone each review is based on, but may be you could take a guess at what's causing the new influx of negative reviews among all the five stars reviews this app currently enjoys?
Buggy in wp8 l920. Lots of errors :(
by Mark
3/18/2013
Constant error messages. Never seems to get fixed.
by Michal
3/18/2013
Bags with connection, but it is nice app. Update pls
by Jain
3/18/2013
Good app.. Never had any problem. But lacks many features as compared to other platforms.
by TAHMINA
3/18/2013
Broken - errors all the time
by Alessandro
3/17/2013
Quite complete and usable, a must have for me!
by User
3/16/2013
Good app, but please add a feature so we can see sent emails. Thanks.
by User
3/15/2013
Not as good as the google or apple versions
by User
3/15/2013
Too many oops something went wrong errors...
by Gerald
3/15/2013
Doesn't load properly on Nokia 930 Windows 8 phone
by Abdulrehman
3/15/2013
Many bugs- errors out freqly
by chrissy
3/15/2013
Login fails immediately, doesn't wait for async call to data auth service.
by Michael
3/14/2013
Fix this garbage app!! Can't believe you published linkedin on windows phone like this.
by User
3/14/2013
Nunca me corrio
by Ramkumar
3/13/2013
Doesn't work 90% of the time. Failed to load data with error messages.
Those negative reviews coming from the "wp8 l920" user and the "Nokia 930 Windows phone 8" user are interesting, aren't they? Personally, I wouldn't be surprised if the only negative reviews this app was attracting were only from the WP8 users, and the only glowing reviews were coming from the WP7 users. It's too bad I can't prove this without the shadow of a doubt. Someone like you would never believe such a guess on my part.
And what breaking change between WP7 and WP8 could possibly trigger this "Doesn't work 90% of the time. Failed to load data with error messages"? I did promise you I'd look into that. Let's see. I would guess those two changes:
Change
When your app makes an SSL request to a web service or web site, apps that target Windows Phone 8 contact the issuer of the site's certificate for the security certificate revocation list. This additional network request in Windows Phone 8 apps increases the time required for the SSL request. If the certificate revocation list is not received in a timely manner, the SSL request may time out, especially over a slow or unreliable network connection.
Impact/Workaround
Make sure that your app handles the possibility of a timeout and retries the request or continues without the requested data.
Change
In Windows Phone 8, the background transfer service will transfer on the following data networks while the app is in the foreground. In Windows Phone OS 7.0, transfers do not occur on these data networks, regardless of whether the app is running in the foreground.
2G, EDGE, Standard, GPRS
In Windows Phone 8, transfers won’t proceed on these networks while the app is not in the foreground. This limitation is shared by the HttpWebRequest object, so performing your own transfer doesn’t provide any advantages over using background transfers. On networks that are 3G and higher, background transfers will proceed on both Windows Phone 8 or Windows Phone OS 7.1, regardless of whether the app is running in the foreground, assuming all other conditions are met.
Background transfers will occur in W
Know I'll get modded down for going against Slashdot groupthink. But what is the argument suggesting? "It all happened on a computer, it shouldn't be prosecuted?" Stealing private information and releasing in publicly isn't just obviously illegal, it caused grief for 114,000 people.
He didn't release it publicly. He released it to a news site (which did the responsible thing).
It didn't cause grief to anyone, but AT&T.
Fact: WP8 was WP7 compatibility with only a few minor differences, and more than 10000 WP7 ran unmodified on WP8, and you said "all existing third party applications"
A "few minor differences"? That's not a fact. That's a claim made my Microsoft on its own site.
I'll tell you what. You pick a third party application that you like and you tell me its name. You just pick one. That's it. And I'll tell you how that application would have broken if it had been ported unmodified from WP7 to WP8.
Does this sound fair? You can even help yourself with the table I showed you earlier, listing the so-called "few" minor differences between WP7 and WP8 (that do not get automatically resolved by Quirks-mode).
That's odd, because I keep encountering apps that worked on older devices that claim they won't work on my Android 4.2 devices. Maybe that's a certification issue rather than a real compatibility problem, but it shows that upgrading isn't 100% perfect.
I doubt it's a certification issue (unless it's from third party framework). As developers, we were told very early on by Google to make our certificates expire in 99 years, or 120 years (I forget what was the number exactly).
My guess would be that it's the use of an undocumented api that might have been the issue. For instance, before Google gave us the ability to customize our screen locks with widgets, some of the more clever developers found undocumented ways to embed widgets on our screen locks. Or another example would be Ad Blocker, which was recently banned from Google Play (since Google is becoming more evil and controlling now unfortunately). That app too must have been using undocumented features, that could easily break with a new version of Android (especially now that the app has become big enough to get onto Google's radar).
That being said, I'm an Android developer, and I've also personally used at least 100+ different Android applications in the last three to four years on a variety of Android phones, I've never actually experienced this issue you described, and this is the first time I'm actually hearing someone describing this issue.
From where do Slashdotters get their information? From only other Slashdot posts filled with lies and misinformation?
Here is the official table of "breaking changes in core Windows Phone features" for Windows Phone 8 from Microsoft itself.
And please, speak to any of your developer friends who developed on Windows Phone 7. You're obviously not going to take my word for it. I assume you're just going to think that I cherry-picked the information I wanted from the Microsoft web site.
Er, that likely means they'll be on WP9. How long will Google update Android 3.x or even 4.0?
Trololol samzenpuss, trololol.
I agree that the summary is click-baiting us.
But on a related-note, the first jump Microsoft made from Windows Phone 7.5/7.8 to Windows Phone 8 broke compatibility for all existing third party applications. That move really upset the early developers on that platform (especially when they had been told that MS was going to be different and was not going to be fragmented).
With Android, this just does not happen. Android is completely backwards-compatible, so an application you wrote for Android 1.0 or 1.6 will still work on Android 3.x or Android 4.2 (without any changes).
In the meantime, take your GPS into Tunisia and let me know how that goes. I won't visit you in Tunisian prison.
Oh yes of course, I'm not disputing that those laws exist, or that they're enforced on individuals on a regular basis. And even thought, I sounded quite certain in my allegations, I'm only just 90% certain that it is some kind of official retaliation, and not some kind of corrupt official looking for bribe money, or some tin-foil hat wearing official going off on a personal crusade against gps units.
Those multinationals have planned for the consequences, and we shouldn't cry for them.
I don't think anyone is crying for them.
And yes, part of such a contingency plan for US conglomerates could also mean to have a number of powerful US lobbyists and powerful US politicians already on their corporate payroll (or the politicians wives, or their close relatives, or their close friends). Trying to manipulate politicians can sometimes be the cheaper way to go.
The loss that Coke realizes in all of this is more than you or I will make in years, but less than they make in a day.
Personally, I couldn't care less either way, but I doubt that the conglomerate itself sees it that way.
It takes time to build market-share and establish yourself as a category leader in any market. Anything that happens today commercially in China could have far reaching consequences into the future, when China's market is considered exponentially more valuable than it is now.
It could also have an immediate impact on current shareholders and current share prices, since the price of a share often includes the potential growth of a company's future market.
If you do a lot of travelling, you will find that GPS laws are different everywhere.
This has nothing to do with GPS. After the US accused China of cyber attacks, it just retaliated against the biggest US conglomerates they could go after.
China did something similar to Carrefour after the French President officially received the Dali Lama. Of course, everybody knows that Carrefour had nothing to do with the Dali Lama's visit, but that wasn't the point. The point was to put the French chain store under siege everywhere it was located in China, so that the French corporation and the related French unions would in turn put the screws to the French President.
Also, it doesn't hurt that a corporation like Coca Cola (and other corporations in the same category) couldn't care less about cyber attacks against US-based technology companies or US-based media companies, but care deeply about being in China's market. So by targeting such companies and accusing them of espionage (a pretty serious allegation if you ask me), they're effectively pitting the lobbyists of those major consumer goods companies against the lobbyists of the major technology/media companies.