Now some of this is also the fault of the individual phone makers that have to verify that their apps and hardware will work with the new phone OS and then compile them into an update package. Still the problem remains; when people buy a phone they are often not aware of the version of OS that is on it (again this is not Google’s problem, but it IS a problem). We watched this in action at a Sprint store not that long ago where someone assumed that because they were buying an Android phone they were getting Ice Cream Sandwich. Unfortunately the phone only came with Android 2.4 and there was no update from Sprint for the phone.

It is this level of fragmentation in the available phone products that can (and does) hurt Google and their partners. We have seen people with an Android phone complain that they cannot do this or that so Android “sucks” in reality it is only the version of Android they are using that is the problem because those features were added in a later update. Google unfortunately cannot control much of this due to the open source nature of the OS. It really is up to the manufacturers to deal with updates and phone improvements. Unfortunately many of the most popular handset makers are busy spending money and time fighting Apple against patent violations and working to make “non-infringing changes” to their existing product that updates are often put on hold (which is part of what Apple wants).

So you end up with a new OS being launched while a roughly year old OS has not even made it out to all of the products that could support it. ICS was supposed to be the OS that brought the tablet and the phone into sync so that there would be less fragmentation. Instead we are getting excited about Jelly Bean before many have even had a taste of Ice Cream Sandwich.

Now while this might sound like a slam on Google and Android it is not intended as one (although it does work out well for that) instead what it illustrates is an issue that could and most likely will arise when ARM based processors a begin to surface in servers and other infrastructure systems. Even though Microsoft has extended Windows to ARM in the form of Windows RT it is unlikely at this stage that we will see Windows Server for ARM any time soon.

This means that you will be looking at Linux for ARM which is perfectly fine. As an operating system it is great, open source and has plenty of drivers and other items that will be available. Unfortunately you can run into trouble due to the way that Linux for ARM will most likely be developed. What you might have happen is that when you drop in a new piece of hardware for an update you will have to recompile the kernel on your OS to keep things happy. If the hardware was out and was included in the kernel of your OS when you installed it then Linux will pick it up right away, if not you can spend some time getting it ready just to drop in the new gear. It is a type of maintenance overhead that most forget about when looking into ARM as a server.

We saw this when we were running Linux on PPC hardware and added two additional network cards. The OS did not see them and we had to recompile the kernel to add support for the two NICs. You do not see this much with Linux on x86 as there is considerably more support for it than what we have seen for PPC and even ARM. This support will increase, but for now a lot of items will not work out of the box and will require either development from the manufacturer or a company to have an in-house tech that can compile the needed software for use on the Linux ARM Kernel.

Because of this we do not see ARM entering the enterprise market very soon. We do expect it to get there in the form of smaller servers; authentication, certificate services, load balancing and also possibly web servers, but considering that rack space is at a premium it is not likely that someone will want to drop in 4 or 5 1-2U ARM severs when they can virtualize 10-14 Windows servers in the same space.

Discuss this in our Forum