There's been a lot of commentary about the announcement this week that Nokia is dropping Symbian from their high-end devices and putting MeeGo into a sort of "experimental lab" status. Most of it has been pretty scathing, with those who'll even admit that something had to be done rather loudly (and often incoherently) talking up Android as having been the obvious choice.

I'm sure it'll be a great comfort to the Nokia CEO that some random blogger on the Internet thinks it isn't automatically the biggest disaster ever, but that's broadly my take on it.

Symbian needed a lot of work. Nokia put quite a lot of time and money into trying to get it up to par with the competition and still hasn't got there after several years. MeeGo is apparently not ready yet. Having shown that the company simply isn't capable of getting the software right, they had to do something.

The "buy Palm" ship sailed a year ago and they weren't on it. No point crying over that one.

So the options left were:

  1. Give up on high-end smartphones;

  2. Android with a really great overlay;

  3. Windows Phone 7.

So let's take a look at each, eh?

Giving up on the high-end wouldn't be completely crazy, but it'd be a huge admission of defeat. Nokia makes most of its money from the low-end feature phones where it pretty thoroughly dominates. They're good at building robust, reliable, cheap handsets. But there's an argument to be made that having the prestigious high-end stuff can help maintain the position at the low-end, a sort of "halo effect".

If they'd gone Android -- and apparently there were talks with Google a while back which didn't go anywhere -- then they'd have needed to differentiate, likely in the usual Android way by writing their own custom overlay and apps. If they can't do this in-house for Symbian what makes anyone think they could do it for Android?

And once you do this with Android you've got a support nightmare. Either you have to kill support for old models very quickly, or you're stuck having to port all your custom code, including QA and UAT, every time Google drops an update.

Google are not exactly forthcoming about roadmaps and typically pick a new partner for each release. If you're not the lucky company this time around you automatically start behind the curve, both for getting updates out for your existing models and releasing new ones.

It's a mess, in other words.

Windows Phone has the potential (and I have to stress that right now that's only potential) to be a happy medium between the control-freak single-vendor iOS approach where there's effectively one device available and if you don't like it then you can sod off, and the Android approach where there are many models and many varying interface designs, with the attendant update and fragmentation issues.

There's a single OS vendor and only one interface available. That OS vendor has committed to keeping control over updates, just like Apple, but there's room for differentiation on hardware. Within limits, anyway. You have to meet a minimum spec, and that minimum is right now pretty high-end.

There are a number of manufacturers producing WP7 devices, so you'd think it's a bad deal for Nokia, but the platform is new enough abd Nokia's hardware good enough that they might be able to stand out from the Android crowd if this "special relationship" talk manifests something real.

Doing nothing wasn't an option. None of the choices available were ideal. In an ideal world they'd have been able to get their act together with Symbian or MeeGo and there'd consequently be more competition in the high-end smartphone OS field. But Nokia has been dysfunctional for years, they couldn't do it, and in my view this was the least-bad option open to them.

Whether the end result will be obscurity in five years or the resurgence that the execs are clearly hoping for, that's unclear. And anyone who tells you they know is either lying or an idiot.
I'm a UNIX guy. Been doing Solaris and Linux commercially for well over a decade, and a bunch of other variants too. Always had a fair degree of contempt for Microsoft products, and anyone daft enough to try to run servers with them.

But the reality is that Sun^WOracle seems determined to shoot themselves in the foot, or at least to can the general-purpose-server side of the business in favour of database appliances. And while there's a fair bit of Linux work around, it sometimes pays to be flexible.

So I've been poking at Windows for server stuff. Specifically, Windows 2008 R2.

At home I've replaced the Debian system doing random house-server duties -- nothing heavy, nothing I couldn't live without -- with Win2k8R2 on the same machine. It's doing DNS, DHCP, and file service Just Fine and was significantly easier to get going than pretty much any UNIX. The DHCP client ties into the name server properly and it took almost no work to configure. This for someone who has never tried to do this stuff on Windows before.

The same machine has a second Win2k8R2 instance running inside Hyper-V for a sandbox. Again, complete doddle to set up. Much easier than virtualisation on Linux with Xen or KVM, and unlike ESXi it'll run on any random hardware with Windows drivers.

What I haven't done so far is build a Linux VM. I don't expect that would be particularly difficult, provided I stuck to the supported distributions (Red Hat derivatives and SuSE). And obviously I've not tried to do anything comparable to a full vSphere infrastructure.

At work I've built a couple of Win2k8R2 instances on opposite sides of our global WAN. Installed Active Directory Lightweight Directory Services (AD LDS) on both and got a multi-master replicating LDAP service going. This took... very little time. It's essentially just a matter of adding the LDS role to the base Windows installation, running the "New LDS instance" wizard, answering a few questions, then doing the same on the other box(es) but answering "replica" to the first question so it'll hook up to the original and establish replication.

Compared to doing the same with OpenLDAP or eTrust or iPlanet a few years ago it's incredibly easy. The tools provided for prodding at the directory are reasonable -- LDP provides both a tree-based browser and lots of debugging info -- and include all the command-line stuff you'd expect. And it'll tie into existing AD infrastructure via the userProxy object class so you can have your random application users authenticate against AD as required.

My sole complaint thus far is that it doesn't take schema files in the same format as everything else, it wants them as LDIF. A tool is however provided that'll do the conversion, and I merely need to sit down next week, go over nis.schema, and pull out the bits of it I need -- posixAccount, posixGroup, and whatever the netgroups object classes are.

There's a fair amount of arcanery involved in this stuff, but Microsoft seem to have done a good job of making it so that you don't need to be an expert to get the basics done. This is in stark contrast to your typical UNIX (or similar) vendor with moronic defaults and mandatory tweaking to make anything work.


Abort, Rephrase, Ignore?

October 2011

2 345678


RSS Atom

Most Popular Tags

Style Credit

Expand Cut Tags

No cut tags