Contractual, no, but there are practical considerations that make that difficult. The Android market gives you very little space to describe your app as it is; I doubt you could fit an entire compatibility list in there. And not many users will copy a link out of a marketplace description and open the Browser to see what a longer list of compatibility notes.

I think the problem is that most people are reading this as "apps are sending off the UDID" and going "eh, who cares" because the UDID doesn't have any real inherent useful meaning outside of iOS development provisioning. Even when they read that you can associate the UDID with a real name somehow (as in the Amazon and CBS apps), they still see UDID isn't really useful data. All you know is "this hexadecimal value -- which, for all practical purposes, may as well be random -- is Joe Public." If Amazon generated a blob of random binary data and used that to identify that device to the server instead of the UDID, but changed no other part of their protocol, you'd still be able to associate the random blob of data with Joe Public.

Where this becomes a privacy concern is that since multiple services take the shortcut of using the UDID as their tracking token, if you had, say, both Amazon's tracking data and CBS's tracking data, you could take Amazon's realname data and combine it with the CBS program's demographic data, and have a bigger, badder demographic database. Because they both use the UDID as their tracking token, there's a shared bit of data you can use to combine those sorts of tracking databases. But that's not really presented as the problem here, so most people just think "why should I care that the UDID is being sent? Thats no different than any other random data-tracking cookie."

In contrast, I think why people reacted more vehemently to the Android article was that the TaintDroid folks reported that Android apps were not merely using device identifiers as tracking tokens, but were also reporting back the actual phone number, or in some cases the IMSI. While I don't care much about my UDID being sent off as a tracking token -- it's not meaningful data in and of itself -- I am going to be a lot more disturbed if I find some app is sending my cellular subscriber data to a server without a damned good reason, regardless of what data they're tracking.

That said, the growing popularity of smartphones means that privacy and malware/trojan prevention on mobile platforms /is/ going to become more and more of a real concern, I think. There are already security suites available for them, like Android Firewall on Android, or FirewallIP on iOS; they all require rooting/jailbreaking to use, but they're there as an option. But because of how much computing people do on their mobile devices, I think eventually we're going to see -- of necessity -- these sort of privacy/security tools for mobile platforms becoming more common and mainstream, whether Apple and Google open up the platform to allow third-party security tools or whether they start providing a higher level of security themselves, /something/ is going to change in time.

In fairness, the Lord of the Rings films were basically just one single unbelievably long movie, which happened to be broken into thirds for semi-sane human consumption.

Ah, then we can truly share the experience of those ancient Roman LINVX admins. :P

janus:~% perl --version

This is perl, vV.XI.I built for iCCCLXXXVI-linvx-thread-multi
(With II registered patches, see perl -V for more detail)

It's not quite /that/ bad; they're in a specific area (along the fence line), and so not terribly intrusive for anything I'm likely to do. But they /are/ just on the inside of my fence line, instead of out in the little 'private lane' easement. (Which is, admittedly, mildly annoying if not a huge issue... they couldn't have put this all in a foot south of where they did?)

At any rate, my point is that due to subdivision, you can certainly have utilities laid out in such a way that construction or work on one house /can/ affect others. :)

Some years before I bought my house the majority of the property's back yard was subdivided up and sold off to build three townhomes, and the side yard turned into a small private access drive to get to those homes. As a result, their utility lines run through my property; their water meters are actually on my property, rather than theirs.

The house I rented before purchasing this was a townhome built in a similar situation, where an older property had been subdivided up.

So, yes, wiring/plumbing two properties through one /does/ happen, especially in situations of urban densification where land that was originally just one property gets subdivided up into multiple plots. If I went randomly digging around my yard, I could very well take out my neighbor's plumbing or natural gas. If I do anything (like building the fence I did recently) I have to make certain everything's done to code so that I don't take out the gas or water lines that run under the edge of my yard to the houses behind me.

I now see a bright side to the 'touchscreen devices can't support mouse movement and Javascript hover behavior' complaints about web development for Android, iPhone, iPad, WebOS etc.

The Tenth Doctor did face the Valeyard (...sort of) in the tie-in comics, in "The Forgotten" story arc. So they've at least had a nod to the Valeyard. Of course, that story arc was entirely about touching on all Doc's previous regenerations, so... :)

Well, not the Cybermen; the original Cybermen of our universe were evidently destroyed, though we have seen the head of an old Mondas Cyberman in one episode of the new series ('Dalek,' with the Ninth Doctor) so know they once existed. But Cybermen were recreated in an alternate universe ('Rise of the Cybermen'), and then came through to ours ('Army of Ghosts'), and evidently stuck around. Presumably the majority of Cybermen we've seen in the new series are those Cybus Systems ones.

Also, the fact that this is the immediate assumption of folks on the Internet nowadays is a little bit depressing.

Your quoting of Job's letter was a fairly obvious segue into what I had observed from personal experience -- namely, the issues that can arise when a third-party development tool becomes a critical component to a toolchain, and the first-party platform developer has to adapt. (Though anyone who had been in the Mac development world at that same time could probably have similarly observed this, albeit from the user side rather than the Metrowerks side.)

Are we really so jaded as a society that people believe only one person can ever have a specific thought, or only one person will ever have experience relevant to the topic at hand? Or have we reached the point where if any point has ever been made anywhere on the net, we have to Google it first and share a link to the closest match to our own thoughts?

On the other hand, I /am/ on Slashdot... ;P

Actually, I used to have to use Metrowerks CodeWarrior at my old job, when we were looking at using it as the IDE to target an embedded systems chip we were designing; they were already a leading IDE for embedded systems work, so we wanted to investigate possibilities there. I got sent to Austin to work with the Metrowerks folks there several times during 2002, before we decided to do our own toolset (and then failed completely and miserably, which is an entirely different story).

So I remember the PowerPlant headaches from having been /at/ the Metrowerks offices during those Dark Times, and overhearing a lot.

(However, reading Gruber's post, he's got a *much* more concise and readable summary of that situation from the general Apple community viewpoint than my write-up, so that's a good link to contribute to the discussion.)

This is important; Apple has already gone down this road once.

Metrowerks wrote a toolkit called PowerPlant. PowerPlant allowed you to develop rapidly and easily on the classic Mac OS. As such, this toolkit was very popular. Then two things happened: Metrowerks was bought by Motorola, and Apple tried to move to Mac OS X.

This did not go well.

PowerPlant was no longer a high priority for Metrowerks-in-Motorola, and so was updated slowly. This meant PowerPlant apps couldn't support things like Carbon Events, among other issues. Moreover, since PowerPlant wasn't building binaries that went to the expected libraries in the expected ways -- as things built with Apple's own tools did -- Apple had to move carefully to avoid breaking all of these existing apps. After all, if they made a change to the OS that broke PowerPlant apps, people weren't going to blame Metrowerks... they were going to blame Apple. It was an Apple update that broke things, right? In short, Apple became bound by a third-party developer's timeline and tools to determine what they could effectively do on their own OS. Moreover, app developers faced having to either rewrite their apps in pure Carbon (or Cocoa) or wait until Metrowerks would update PowerPlant, if they wanted access to new features.

(I strongly suspect that PowerPlant is the 'painful experience' Jobs is referring to in his open letter.)

If they came out with OS 5, and discovered it would break Flash apps, they'd have to go talk to Adobe and go 'okay, this needs to be fixed.' If Adobe can't fix it in their toolset... what does Apple do? Do they just release iPhone OS 5 and break the Flash apps? But people will complain that 'Apple broke my apps,' then. Do they wait for Adobe to fix things? That could take a while; Adobe's been promising Flash Player on Android for a while, to the point that the original 'early 2009' date has slipped to 'late 2010.' I can't imagine Apple wanting to wait on Adobe to update tools for a year or more before releasing their OS update, and if that seems extreme... you can find O'Reilly books on Carbon Events dating back to 2001, but PowerPlant didn't support Carbon Events until late 2004. This led to things like this developer topic.

Whether or not you agree with Apple's actions, given that history I can well see them wanting to avoid repeating that experience on the iPhone.

Sure, and you can develop for iPhone using open source tools; all of Apple's extensions to gcc or llvm are contributed back to the main distribution. And how ARMv6 or ARMv7 binaries work is certainly well documented in many places. You can (relatively) easily write a new tool that targets the iPhone or iPad from that information; MonoTouch, Unity, the Flash app packager and so on all did so, after all.

Open tools does not necessarily imply an open format.

And the code for compiling Flash logic into an ARMv6-binary .app bundle for the iPhone is NOT freely available from Adobe, last I checked... it was part of Flash CS5, which you had to pay for. So one could even argue that Apple's tools (gcc, llvm, clang) for generating iPhone binaries are more 'open' than Adobe's (Flash CS5). But that just gets into arguing semantics which, for purposes of this discussion, aren't really meaningful.

At heart, the issue people have isn't that the tools are 'open' or 'closed' (whatever the definition of those terms may be to a given person), but that Apple is saying 'only binaries generated with approved/blessed tools will be sold in our storefront.' I imagine even that wouldn't be a problem outside of a few grumbling folks, save that Apple is also the /only/ storefront outside of the jailbroken world. There's no 'allow installs from alternate markets' option like Android has. So Apple saying 'no go' effectively bans you from the majority of users who don't jailbreak (i.e., the majority of casual, non-techy users).

"...make it run OS X..."

Putting aside the debate over the closed/open nature of the iPad, I suspect this would be extremely popular with a small niche of users, and overall would be a colossal mistake on Apple's part.

Pretty much all previous tablet attempts that actually shipped have used desktop operating systems for the platform. Pretty much all previous attempts have failed. As someone who had the misfortune of using a Windows tablet for a while, I can tell you that desktop operating systems are clearly NOT MEANT for tablet use. Sure, you can cram touch or handwriting into them, just like someone can put on shoes that don't fit quite right. But the reality is that the experience will always feel sub-par; your feet will hurt with the ill-fitting shoes, and your computing experience will suffer using a desktop environment on a tablet machine. (This applies to OS X, too, if you look at the Axiom Modbook machines.) And I suspect Apple isn't interested in offering a sub-par experience, as previous tablets have. The iPad may be more limited than a 'full featured computer,' but (as someone who's tried this both ways) also feels MUCH more natural to use than a desktop operating system when you're dealing with touch on a tablet.

But moreover, you rightly make the point that 'the Xbox didn't need to act like a PC,' and (whether we like it or not) the iPad is not trying to be the same thing as a desktop PC either. The iPad is trying to be an appliance, like a television or a microwave; something you just use, and don't have to worry about all the things average folks don't want to have to worry about. The simple truth is that techies want their devices open, but average folks don't care. They just want it to work. Even Microsoft's realized this now, which is why the Windows Phone 7 platform is apparently not allowing native code to run (witness the cancellation of Fennec for Windows Mobile), and has an Apple-like app storefront you submit to through Microsoft so they can better control the experience and stability. And while we hacker sorts lament the loss of ability to muck freely with our devices (without having to 'root' or 'jailbreak' or whatever the terminology for your platform of choice is), the less technical sorts are going, "Oh! Now /I/ can use these shiny gadgets, too!"

Most people I handed my old Tablet PC to went "WTF?" and got frustrated. My aunt, who had given up entirely on computers after the hassles she had with her old PC, toyed with an iPad the other day and remarked in surprise, "I could use this and have e-mail again!" The difference is fairly dramatic. The Tablet PC was trying to be a desktop PC stuffed into a tablet, and gave a lot of power to the user but did not work optimally. The iPad is /not/ trying to be a desktop PC at all... and that gives Apple the freedom to throw out the existing usage paradigm entirely, rather than shoehorning the desktop into a touch device.

We can hope they extend the platform and make it more flexible and powerful, but I think we're more likely to see the mobile branch of OS X (iPhone, iPad) expanded out to get new capabilities than we are to see them "make it run OS X" as you suggest. Simply because the mobile branch's usage model is better suited to phone and tablet use than the desktop model is.

If the argument is 'the Android ecosystem is fragmented and incompatible, and this will hurt adoption,' I'm not certain that your point in any way addresses the core argument. The outdated OS on one phone (x10) may be Sony's fault rather than Google's, but that doesn't change the fact that the platform fragmentation is there. And the x10 is just one phone among many, from various providers.

The solution some have suggested is that Google should impose certain licensing terms, such as making a good-faith effort to bring a phone up-to-date within 3 months of release; having phones released while 2.1 is current, that are still running 1.6 and have no upgrade path? Whose fault that is doesn't really matter, in the end; no matter who is responsible, the situation hurts the platform.