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.

Ah, but the issue is going and buying, say, the new Xperia x10 (which is about to come out, months /after/ the Droid and Nexus One) and then discovering that some app which works on the Droid does not work on the x10, because while the Droid is on 2.0.1, the x10 is on a heavily-modified 1.6. To use your analogy, this is like someone going to go buy a new gaming computer, and then discovering your new system only has a DirectX 8.0 card in it.

Tech-saavy smartphone buyers will know to look at what version of the OS the phone comes with before purchase. However, part of what people are pushing for lately is smartphone adoption outside of the 'traditional' smartphone market. Most of the people I know who have iPhones are not people who previously had Blackberries or Windows Mobile phones; they had little Samsung candybar phones, or Motorola sliders, or whatever. These are not people who want to look at the tech specs of their phones before buying them; they just want a phone that does what it says on the tin, and where they don't have to worry about compatibility and conflict. To them, the Xperia x10 is a /newer/ phone, thus should /have the newer stuff/.

This is where the fragmentation will hurt Android adoption. Someone can go and say, 'well, a new iPhone just came out. It'll be fancier/newer/faster than last year's model, so it can do everything last year's could and then new stuff.' You cannot do that with Android; someone sees the Droid has Facebook integration in the address book, goes 'cool! I want that!' and goes out to buy some even-newer Android phone, only to discover they cannot do the things their friend's Droid could, because their phone is using an older version of Android. To the average consumer, this doesn't make sense; those are both Android phones, and theirs is NEWER! Shouldn't their phone do MORE, not LESS? Etc.

(And let's be honest, even the tech-saavy gadget-addicted folks get unhappy when they don't have the latest and greatest update for their system. You need only check the irate threads at Phandroid or on the Verizon forums about 'when is the Droid getting 2.1?' 'Screw the Droid, when is the Eris getting 2.x at all?' and so on. It makes them annoyed to see that the Droid was promptly supplanted by the Nexus One two months later, and then people who bought the Nexus One now have /that/ being supplanted by the Desire shortly thereafter, etc.)

Yes, but this isn't happening just one time.

Let's say now Microsoft decides they want to compete with Google by doing some project called Microsoft Libre. Now you have to opt-out on both Google and Microsoft Libre. And someone else decides to make The Pirate Bookstore, where you can download any current NYTimes bestseller for free, as long as the author hasn't explicitly opted out that one book... and now that's three sites. And hey, someone else seizes on that business model, and now there's four... six... twenty-three... two-hundred and twelve...

The problem is the precedent. If Google is the only person with this model, that's great. If /everyone/ goes by this model, and you must opt-out of every single use individually, it's much less reasonable. It's the difference between a Do Not Call list, and having to get yourself off of every single telemarketer's phone list individually.

Most of those I know who object to the current state of the settlement would be /equally/ happy if the Copyright office returned to requiring that the copyright be renewed every 10 years. Then they could just mail in /one/ letter every ten years while alive renewing the rights on their works, and they'd be happy with that.

But the objection that Ursula LeGuin (and others) have to the Google Books deal is nothing to do with the term of copyright or direct control. It's the fact that as part of this settlement Google has decided that 'unless you actually explicitly object, in writing, to our use of your work, you give us implied right to publish.' LeGuin and others are objecting to the idea that /during the term of copyright/ authors should have to 'opt out' of having their works made freely available online, rather than giving them the choice of 'opting in.' This isn't about length of copyright or anything else. But having this method be opt-out rather than opt-in puts authors in a bad spot, especially if they've sold electronic reproduction rights to an eBook publisher and then Google comes along and puts the book up for free because the author didn't opt-out quickly enough.

Many of the authors I know of who object to this are ones who /also/ give away free (or incredibly cheap) eBooks of their work when the work is no longer held by a particular publisher. LeGuin herself has DRM-free eBooks of her own older work available for about $1 each through several eBook sellers, and is actually quite against extensions of copyright. As the forward to the brief explanation of copyright law she has on her website, she refers to:

http://www.ursulakleguin.com/Copyright.html

The problem LeGuin and those signing her petition have is the blanket expectation that anything -- even books which may be under a current publishing contract with some publisher who has bought electronic rights -- is fair game unless the copyright holder explicitly opts that individual title out. I mean, let's be fair, we've all seen that opt-out methods are generally not popular with those they target. How many of us actually liked the logic of opt-out spam, where if you haven't contacted the people to say /not/ to send them spam, then they assume you've given implicit permission to send you spam e-mail?

Actually, that's not necessarily the marketer's dream. Kleenex and Xerox have also had headaches because when the name becomes that ubiquitous, you have some issues keeping the rights to it. If the courts decide that your name has become a generic word, then you're in trouble in terms of legal enforcement of your trademark. Xerox in particular has discouraged people from using 'xerox' as a verb, because they're concerned about losing the trademark. From their own website's company factbook, italic emphasis mine:

The Xerox Trademark
Xerox is a famous trademark and trade name. Xerox as a trademark is properly used only as a brand name to identify the company's products and services. The Xerox trademark should always be used as a proper adjective followed by the generic name of the product: e.g., Xerox printer. The Xerox trademark should never be used as a verb. The trade name Xerox is an abbreviation for the company's full legal name: Xerox Corporation.
XEROX is a registered trademark of Xerox Corporation.

Wikipedia has a little information on this, too: http://en.wikipedia.org/wiki/Xerox#Trademark

Usability.

Your average desktop user does not want to go, 'Oh, well, I'm running on Processor X, with distribution Y, patch Z. I guess that means I need /this/ tarball (or this subdirectory of the big tarball).' Fat binaries solve this problem.

If I am a Mac OS X developer, fat binaries mean I don't have to make a separate Intel download, or separate PowerPC download. No worries about Joe User downloading the PowerPC version, then complaining about performance (not realizing they're running a PowerPC binary in Rosetta on an Intel machine), or so on. I can just have one download on my website, and the loader handles finding the correct binary.

Similarly, I can bundle 32-bit and 64-bit binaries for a given architecture into the same binary, rather than having separate 32 and 64-bit downloads (as is common on Windows). Tech-literate users may well know whether their system is 32-bit or 64-bit, but if I sat my father down in front of a brand-new Windows 7 machine from Best Buy, I doubt he would know whether to pick a '32-bit' or '64-bit' download for an antivirus program on a given website. He would, instead, call me.

Now, some software solves this problem by having a tiny installer you download, which then goes out and pulls down the correct packages from the Internet after examining your machine. This is one solution, though not entirely ideal (it means in order to do any install, you need to have internet access). Some installers include the entire set of binaries, and just install the correct one; this is fine, as long as you have an installer, but can break down if you try to transplant the hard drive into a new machine. For instance, Joe User picks up that nice Windows 7 Home Premium machine he saw at Best Buy, and plugs his Windows Vista drive in to copy over applications, unaware his old computer was running Vista x64, while his new Windows 7 machine is 32-bit. Joe has some Problems now, when he tries to run some of his old installed software that was 64-bit only.

At any rate, there are plenty of solutions to this problem; fat binaries are just one. None are perfect and all have their tradeoffs; in the case of fat binaries, the main problem is disk space. Package management tools have their own problems. (RPM dependency hell any time you want to go outside of your distribution's available packages, for instance, and the 'screw this, I'm installing PHP from source' result some sysadmins turn to.)

From a server standpoint, fat binaries aren't necessarily the most useful solution (unless you're dealing with clustered machines with variant processors or configurations, but a shared filesystem between them), but from a *desktop user standpoint*, fat binaries may be friendlier than other options.

At any rate, my *personal* opinion is that from a general desktop end-user standpoint (as opposed to a sysadmin/techy standpoint), disk space is cheap but usability is priceless. And my experience is that fat binaries require less work on the part of the end user (though, admittedly, more work on the part of the developer; building Universal Mac OS X binaries of software outside of Xcode can be a hair-pulling experience at times and inspire fond thoughts of Windows installers that just pick the right binary based on a system check).

So whether you feel Linux benefits from fat binaries may well boil down to whether you feel Linux needs to target general, non-techy desktop users more or not. Your own opinions may well differ from mine; not everyone's criteria and priorities are identical, which is probably a good thing. Otherwise we'd have a pretty homogenous software community out there!

MissingSync for iPhone is basically an iSync plugin for the iPhone. ;)

Really, Mark/Space is the first place I check for any iSync plugin I need, as their Missing Sync line is pretty comprehensive. They've got a Palm Pre plugin -- which syncs out of iTunes without the USB hack, the approved way, so doesn't break -- and one for Blackberry, and one for Nokia, and so on. I used to use their Missing Sync for Palm, and then later Missing Sync for Windows Mobile, before I moved on to an iPhone and an Android handset. Android's about the only thing they DON'T have a sync plugin for, but another company's Spanning Sync -- an iSync plugin for Google contacts/calendar -- fills that niche too.

There's already a solution, in Missing Sync for Palm OS, which already handles synching to more recent Palm devices (Centro and Treo) much better than Apple's legacy support. I don't know anyone who has a Mac and a Treo and /doesn't/ already use Missing Sync anyway over Apple's grotty and outdated legacy Palm code. I would guess that Apple yanking Palm OS support from iSync and letting Missing Sync fill that particular slot in the Sync Services food chain is an acknowledgment of that fact.