Tamerlin

Of that I'm a bit skeptical. For one thing, this sort of idea was fairly common about the G4 processors, even though Apple was by far the smallest purchaser of G4 processors -- Ericsson, Cisco, and Nortel were shipping routers using G4's in tens of thousands while Apple was still taking pre-orders in some cases.

Another thing to consider is that Samsung is among the world's largest semiconductor manufacturing companies. They fabricate and sell enough semiconductor products to make even Intel's volume look comparatively small. Even with the iVolumes that Apple produces, it's hard to imagine that even they could be a dominant consumer by volume.

IMO were it not for the Oracle acquisition, it would be a matter of time until Java were fully open sourced, but with Oracle in charge now I suspect that it's not going to happen.

They priced their hardware competitively, and it was good hardware, but in all of their price comparisons they ignored the reality of what the competition was offering in order to make it appear that Apple was offering the better value, which it was not.

For example on the Big Mac that they deployed to VA tech, they sold the university the computers, and compared that price to Dell's. Dell's price however included the computers, network hardware, network installation, building lease, power infrastructure buildout, on-site support, and upgrades.

That's the real reason that Apple hasn't made significant headway into corporate markets; it's not a technical limitation on the hardware or software, it's been support.

IT groups I've spoken to found Apple support to be pretty frustrating to work with, because they had no idea as to how to handle support calls involving non-trivial numbers of machines. (They were fine with a single machine at a time per customer, but when you tell them "here are the 40 serial numbers for computers that you've recalled for a replacement battery" they fell flat on their face.)

In most applications I've been stuck on, the tests ended up being an impediment to development -- because the design was poor. The tests helped to reveal dependencies, so people who were working on bits of code could easily identify what dependencies they had to fix when they made changes, but that also served to underscore how badly coupled the various components were.

I guess the moral is that too many mediocre wannabe agilistas try to use testing to cover up bad design.

(Him: Wait, how will you swap those two entries? You can't just move them back and forth. Me: using the "swap" function that I described immediately after you described the problem?)

Look at how much of the rest of IBM's revenues come from services related to mainframes. A significant part of IBM's service and support revenue is tied directly to IBM's mainframes -- a bit like Microsoft's Office, which isn't a core product, but it's tied to Windows, and it's part of what makes Windows profitable.

What differentiates IBM's mainframes from the few remaining competitors (there are only something like 10 companies in the world in that space) are advantages that Windows has no analog for -- Windows' biggest advantage right now is, comically, Windows (i.e. market share).

I recall reading an article, IIRC in CineFX, about the Godzilla model in Gozilla 2000 (the Devlin and Emmerich film). The textures for their Godzilla model alone were something like 900 MB.

Honestly I wouldn't be surprised if Pixar introduced a renderfarm hosted in Azure.

Although the amount of data is very large, you don't general end up taking the bandwidth hit all at once. If you have your renderfarm set up on Azure, you could set up a plugin for your animation software, e.g. Maya, that uploads the assets for the scene you're working on and renders it on an Azure virtual machine configured with multiple processors, then download the rendered image data. One you upload the assets once, you will rarely if ever have to upload the whole lot of them again if the render management software is smart enough to keep track of which files you've modified since the last time you rendered. So you've modified a mesh but none of its textures, it only needs to upload the mesh in order to re-render.

It's hardly trivial, and for the larger shops like WETA Digital that are creating massive, virtual sets with massive, virtual armies modeled and rendered with Massive (couldn't resist :)), they can afford an in-house renderfarm -- and the costs will favor it.

For a smaller shop, that might not be so easy, BUT there are shops that are pulling off some pretty amazing animations without buying the pricey software... outfitting a renderfarm with Photorealistic RenderMan or Mental Ray or Final Render licenses can get quite expensive -- when last I checked, it was something like $2000 or $2500 per machine for a Mental Ray rendernode license. PhotoRealistic RenderMan was in the same price range.

For a character animator, there's an IK rig which, depending on the character, can be quite complicated, and IK involves a lot of math. Then there's the mesh deformation and blended IK/FK. And then things like hair and cloth simulation. And texture rendering. Doing that on a cloud would have latencies that would make it excruciating to work with.

Compositing would be just as bad; the amount of data involved is larger, and as you add layers and masks, filters that affect those layers and masks, you can pretty much throw any hope of interactivity out the window. Now imagine trying to paint out safety wires over a cloud...

Digital art requires a LOT more computing power than creating software.

Try playing a first person shooter on a laggy network, you'll get a sense for how frustrating and counter-productive what you're suggesting would end up being, though I suspect that it's because you're vastly underestimating how much goes on in digital artists' tools more than anything else.

Not only was I not passionate about that, but since it was the first time I'd encountered code with lower quality and even more antiquated technology than what I'd found in government contracting, I was truly contemptuous about what I was doing.

If you get stuck with work that doesn't require ANY of the skills that the interviewers grill you for, it's hard to care about your job, let alone be passionate about it.

Not to imply that I think it's likely, but Sony DOES have something that Apple might benefit from: manufacturing. Don't forget, Sony makes quite a few semiconductor products -- including, for example, the sensors in Nikon's digital SLRs.

Overall though, I agree with the prevailing opinion, that it's pretty unlikely.

No, this is precisely why almost most people are not doing it: they don't want to work hard and keep at something that isn't easy for them.

There is only one route to guaranteed failure: don't try.

"Most of us are not physically capable of understanding certain things that others do understand, are able to work at, etc. I happen to be one of those people who can't understand."

That attitude is precisely why you can't.

True, in Intel's core market (high-end server, desktop and laptop CPUs), Intel is nigh unassailable. No other semiconductor manufacturer in the world can afford to keep up to date with semiconductor manufacturing R&D on their own any longer.

The handheld isn't part of Intel's core market though, and the MacBook Air doesn't quite fit, either.

CPU margins are quite small now, outside of high end parts. That's less true for graphics processors right now. That's probably why Intel's going after the graphics market, but Intel doesn't have much expertise in that area, and it

Also, as graphics processors becoming more general-purpose, the CPU will gradually become less critical to application performance...

That assertion presupposes that Apple will give up the professional content creation market entirely. If they've killed off Shake and curtailed developement on Final Cut Pro, then I'g guess that your theory has some merit.

The reason? The upcoming 2.5 GHz ARM core will most likely be performance competitive with today's x86, but by the time it comes to market, we'll most likely be looking at a Sandy Bridge refresh, and even the first Sandy Bridge processors will most likely smoke the best that ARM can throw at it.

The ARM will almost certainly continue to dominate the low-power markets though. I don't see a high likelihood of x86 making it there. I'd even go out on a limb and suggest that if Intel wanted to compete head-to-head with ARM, their best bet would be a low-power Itanium, since it's not saddled with x86 hardware any more, and therefore requires considerably less logic to match x86 performance with the same manufacturing technology.

How much cool new stuff as Microsoft Research dreamed up that got snuffed out when the management got wind of it but didn't think that it was worth productizing?

IBM had the same problem -- an amazing think tank, laden with talent (probably all of IBM's worthwhile talent), churning out amazing R&D projects... very few of which ever went beyond prototypes. Like IBM's PDA, for example...

... which was true, but it was for the money; Microsoft stock options were making people rich.

The proof?

The year that MS stock values dropped for the first time, MS started having trouble hiring people.

They treat their own developers a LOT better than they used to, in fact almost as well as Google does.

But it's hard to live that Microserf thing down... partly because that sweatshop method, replacing process with extra hours, leads to terrible, bug-ridden code.

What irks me more than people irrationally disliking Microsoft is people who spout about how bad Microsoft's code is, and how asinine their processes are, while making exactly the same mistakes that even Microsoft learned from and has been fixing.

That's completely nonsensical. Microsoft didn't act anti-competitively to become big, they did it AFTER becoming big. You can't abuse power you don't have, and when Microsoft won the OS contract with IBM, it was a tiny company, and Apple was by comparison huge.

Microsoft got big by taking advantage of the fact that the guy that wrote DOS didn't think it was worth anything, so he was happy with the $50k (or whatever) that Bill gave him for it, and IBM didn't think that the PC market would go anywhere, so they didn't think anything of giving MS money for every PC sold.

When Bill started licensing DOS to every company that wanted to make a PC, Microsoft became big.

THAT is how Microsoft acquired the power to abuse that they then proceeded to abuse.

AFAIK Oracle still charges license fees for Oracle per core, while Microsoft charges per socket. The result is a HUGE price disparity... and the less expensive product is also the one that's far easier to deploy and maintain, and has vastly superior tools for developing and optimizing code.

Honestly, I don't see how Apple would be on Oracle's radar at all, since they serve such vastly different markets.

Apple might not make money directly with its compiler, but for its 3rd party developers to be stuck with a mediocre compiler is definitely a disadvantage for Apple.

Hypothetical: The hardware under the hood is identical to that of a Dell. Compare an application written for both, but the one running on the Dell uses Intel's highly optimized compiler while Apple uses one that's not tuned for any particular platform, and therefore performs somewhat poorly on x86.

Result: Apple has a 20% performance deficit.

Now say that application is Photorealistic RenderMan or Cinema4D or Modo.

That 20% performance deficit, that has nothing to do with the hardware, just created a significant cost disadvantage for a mac user -- to implement a renderfarm, the mac adds either 20% in rendering time, or 20% in extra hardware costs to offset the rendering time (which ends up costing more still in logistics).

Result? Apple would lose a potentially non-trivial sale.

Having an optimized in-house compiler would probably also help to improve OpenGL performance on the mac -- because odds are the entire OS is compiled with the same compiler...

Though it may not be a significant direct revenue generator, having a good compiler would probably still be very beneficial for Apple AND its customers, not to mention developers.