5 posts • joined 22 May 2009
This is beginning...
... to smell like DNF.
How dumb is that?
It's been very clear that transportationa ccounts for more emissions than meat production.
However, this in no way changes the fact that meat production causes more emissions than production of vegetable foods.
This article is the equivalent of buying a SUV because air transport causes more emissions than car transport. "Obviously" the SUV is fine as long as you don't fly.
There's mutt you insensitive clod. Oh, wait, that insult was used on another website, not this. Goes to show I'm gettin gold.
There is currently no formal way to delcare dependencies between apps. I'm working on that, as I find the time for it, and Google is aware that some improvement would be useful here.
As someone who develops for both iPhone and Android, I think the whole fragmentation issue is way overblown. If a new Android OS comes out, things may break. Then I'm stuck as long as Google does not update the SDK to include the new version. Then I test the app, tweak one or two lines, and things work again (usually). Pushing the fixed version to the market is a matter of a few minutes. It would be great if the SDK was updated the day a new Android version hits the streets, better yet if that happend a week or so in advance. But that's really all the improvement that's required, IMO.
Contrast that to Apple: yes, they let developers preview new versions of the iPhone OS. But most people just leave it at that, and don't consider what it involves: first, I've seen behaviour change between the preview and the release version, meaning that when the new version hit the streets, I had to go back and fix things YET AGAIN. I'd rather do that only once. Second, pushing a new version of an app to the Store can take weeks, with Apple's review process. So there's almost guaranteed to be a period of several weeks in which my app won't work (assuming anything breaks at all, but that's also the assumption with Android's updates, right?).
Last, Apple immediately proceeds to deprecate any previous OS versions, which anally violates any iPod touch users you might have, because they won't be able to use your newly fixed version (your app depends on an OS version, not on APIs being present). You may think that's not a problem, after all it's only a few bugfixes, but the likelihood is that you'll develop new features on top of that. For Apple, it's a great situation, because iPod touch users who really want to use an app will be forced to upgrade their OS, which costs them money. For developers who may lose customers over this, and consumers who may lose apps over this, it's a stinking pile of excrement.
You have a similar problem with all OSes when they ship new features that you want to use, of course, but then it's a feature-driven thing. You can support older versions as long as you don't want to use the new features on Android. At least when you drop support for users of an older OS version, you can give them a reason why.
Rise of the Machines
Reads like part of the plot for the third Terminator movie. Skynet is about to become active.
- Just TWO climate committee MPs contradict IPCC: The two with SCIENCE degrees
- 14 antivirus apps found to have security problems
- Feature Scotland's BIG question: Will independence cost me my broadband?
- Apple winks at parents: C'mon, get your kid a tweaked Macbook Pro
- FTC to mobile carriers: If you could stop text scammers being jerks that'd be just great