Sunday
May112008

Why Dell will not bounce back

Why Dell will not bounce back: "Bottom line is this: the only innovations worth making are the ones involving product ideas and product design. I mean, Duh. Right? It's pretty obvious. What's amazing to me is how few companies actually seem to realize it. To sustain an edge in any market you must make better products than your competitors, consistently, over and over and over again. Just making the same products as everyone else but taking a little friction out of the system can give you an advantage, but only a temporary one."

(Via The Secret Diary of Steve Jobs.)

Bingo. And combined with the current move to virtualisation, I think that all the major PC and Server builders out there are in for a very rough ride in the next 5-10 years. As others have mentioned, the current commodity PC is a race to the bottom, but nobody's mentioned what happens when you hit the bottom.

The other missing piece of this equation is loyalty. If price is the only major differentiator, then there's no reason for me to be a repeat customer. If you offer me something that nobody else is able to offer, then I have a reason to become a repeat customer.

Wednesday
May072008

Why Apple's iPhone is like a 1981 IBM PC - page 2 - at ZDNet.co.uk

Why Apple's iPhone is like a 1981 IBM PC - page 2 - at ZDNet.co.uk: "Perhaps the best arguments against Apple allowing background tasks are that they take up too much airtime, draining the battery, and that there's no way for them to communicate to the user when they need attention. If either of these two things were a given for background tasks, then Apple would have a point. But they're not, and it doesn't."

(Via ZDNet.)

Not a bad article, regarding Apple's decision to limit access to iPhone developers to userland applications without background tasking. I agree that at the OS layer there's not really any terribly good reason not to allow it as the kernel of OS X is more than up to the task.

However, but I don't think he's really invested a lot of time looking at the impact that radio communications have on battery life in a pocket-sized device.

The article mentions the battery only once in passing. First off, anything you're likely to do in the background would be looking up information somewhere over the network. For the moment I can't think of any background tasks that are limited to local data that have much value. If there's a need to alert the user, you can always interact with calendar and use its resources for meeting alerts etc. So by default you're going to be using the radio (bluetooth, wifi or Edge or eventually 3G) a lot.

If you think that doesn't have an impact on battery life, take an iPhone and set the Mail application to Auto check every 15 minutes. For fun, turn off Wifi and use the cell network exclusively. Then set it to Manual and see how much time you get out of your battery. I notice that on days where I have very heavy usage of Edge, I can sometimes drain the battery before getting back home at the end of the day. Constant network activity would practically guarantee that I wouldn't make it through the day.

Apple's doing two things here - first off, it's minimizing the risk. Not to the platform as a technical issue, but to its reputation. If people start installing apps left and right and then discover that their iPhone can't get through the day there will be a serious negative reaction.

Secondly, Apple's approach to new markets is to deliver what it promises, but still leaving some room to expand in order to keep up the buzz. We complained for a year that there were no 3rd party apps and it kept everyone talking about the iPhone. Now we'll be getting applications to play with and talk about and complain about the lack of background processing.

It's all about managing expectations, and we have very different expectations from a portable computer and something that looks like a phone. Imagine that your phone only got 3 hours of use out of a charge. We expect this from a computer, but I expect that, at worst, I should be able to go the entire day with an iPhone without worrying about running out of battery. While the iPhone is technically a computer in terms of it's OS architecture, it's a very special purpose computer with a very specific usage pattern and form factor that has to be respected.

I fully expect that Apple will release a background task API specific to the iPhone sometime in the next 18 months that will abstract much of the management of these activities and will be able to regroup queued demands from multiple applications in order to send them together rather than as a constant flow. Until battery technology gets a lot better this is always going to be an issue.

Tuesday
Apr292008

iPhone chat to use Jabber?

Found in multiple articles

Well duh.

If you look at the specs for OS X Server and your current iChat client, you’ll discover that Jabber is built-into both and when you use OS X Server to manage your accounts you get a secure end-to-end enterprise chat solution. See iChat Server at Apple.

For more details on how to extend your iChat Server out to external services such as Google Talk, see the OS X Server Wiki.

Tuesday
Apr292008

Canadian cell carrier Rogers announces iPhone deal

Macworld | Canadian cell carrier Rogers announces iPhone deal: "Canadian cell service provider Rogers Communications will be bringing its users the iPhone, according to a statement. ‘We’re thrilled to announced that we have a deal with Apple to bring the iPhone to Canada later this year,’ said Ted Rogers, President and CEO of Rogers Communications. ‘We can’t tell you any more about it right now, but stay tuned.’"

(Via MacWorld.)

Now the only question is just how badly Rogers intends to screw their customers on the data plan. I can only hope that Apple has negotiated some kind of reasonably priced unlimited data plan instead of the usual pillaging that Rogers prefers.
Monday
Apr282008

Fibre Channel to Software iSCSI Failover Failures

Fibre Channel to Software iSCSI Failover Failures: "Based on these results, I’m inclined to say that one of two things is true. Either: I did something very, very wrong; or ESX isn’t quite right to support automatic failover between FC and software iSCSI. Has anyone else tried this, or am I the only one? If you have tried it, did it work? If so, what steps did you have to take—if any—to make it work properly?"
(Via blog.scottlowe.org.)

Are you using a NetApp for the SAN or something else? I've been able to do this quite happily using Datacore's SANMelody storage virtualisation product. While I didn't test it under high stress loads, it worked just fine under regular production loads of 10-15 VMs running.

In my configuration I allocated the iSCSI Initiators and the FC WWNs to the same ESX Server object in the interface and it seemed to be fine with that.

Edited to add: Side note - I did these tests a while ago using ESX 3.0.1.  I haven't tested this against ESX 3.5.

Edited to add: Boy, re-reading my comment about FC WWNs made me realize just how easy it is to Good Morning Vietnam acronym speak.  That made sense to what, about 1% of the population?