Monday 21 July 2008, 6:28 AM
Consumerisation - an ugly name with a beautiful future
By any standards, consumerisation - or consumerization, if you're in the US - is an unlovely word. Even if you haven't come across it before, you'll know what it describes: the adoption by the enterprise of consumer technology. By rights, it belongs to Apple - the Apple II was bought by individuals who put it on their desks at work to the considerable annoyance of the high priests of the data centres, just like the iPhone 3G is being plumbed into corporate Exchange services as fast as the early adopters can type their server URIs into that annoying little virtual keyboard. And indeed for Apple, there is only upside to the process,
For other vendors, however, the trend is worrying. How do you design technology that satisfies the complex requirements of the enterprise while competing at consumer levels of cool usefulness? On Dialogue Box, the video show I co-present with Charles McLellan, we have a segment called the Axis of Awesome where we chart enterprise IT according to how useful it is - and how cool it feels. We started that as a bit of a joke: I'm beginning to realise that it's rather more than that.
But that's nothing compared to the problems the process presents to IT professionals within the organisation. It's hard enough to maintain security, compliance and reliability standards when you define and implement everything from the keyboard to the database: when your users are collaborating via Google Docs on their HSPDA-dongled Eees, you have as much chance of keeping them in line as the Salvation Army has of closing down the pubs.
You can't beat them so join in. The days of the enterprise IT department ruling by diktat are over as are the days of users being passive consumers. So start treating users as part of the solution: they know what they're doing, so listen to what they say. Stop saying "We don't support that, so you're on your own"; start saying "Show me what you're up to, and let's see if we can help".
This has many benefits, not least that you'll know what's really going on and can head off dangerous practices by guidance rather than have them appear on your radar at the same time as they appear in the headlines of the MD's Financial Times. Conversely, you'll spot genuinely useful innovations early and often: your organisation suddenly becomes full of enthusiastic, engaged IT evaluators generating tons of real-life data on which planners can feast.
You'll also find yourself sorting out problems by creating new models of use and innovative solutions to new problems. In terms of equipping yourself and your team with the skills necessary to thrive in the future - possibly even creating the next big thing in enterprise IT - this is a golden opportunity.
There are huge implications in this level of cultural change it's a genuine shift in the landscape that will leave no relationship untouched. The winners, as always, will be those who are best at throwing away old assumptions and seeing things anew. Find those people within your organisation. Become one yourself. It's an awesome prospect.
Thursday 17 July 2008, 10:42 AM
Intel's cache problems, what they mean and how to solve them
If you want to get really intimate with hardware, there's nothing like low-level, high-performance coding to remove all barriers between your mind and the silicon. One result, aside from the difficulties it creates during dinner party small talk, is that you get to find out how stuff actually works which can be very different to how the chip companies tell it.
Take a look at this blog entry. It's from a chap who's on the team for x264, an open source video encoder library. This is a fascinating area: you have to deal with a lot of real-world data very quickly, and modern processors have large amounts of support available if you're got the chops to handle vector mathematics.
But all is not as it seems. In particular, he reports that Intel has a consistent and rather painful problem with its on-processor caches one that AMD has managed to avoid.
A cache works by making a copy of a large chunk of external, slow memory that it can then feed quickly to the processor in smaller chunks as required. As it's far more efficient to do one large read externally than lots of little ones, this speeds things up enormously.
The size of the large chunk is called a line; Intel, as is common, has 32 or 64 byte lines. If the processor wants to read one byte from memory, the cache intercepts it, does a 32 or 64 byte read for the area containing that byte, passes the one byte back and then expects to fulfil further reads from the same area without bothering the slow main memory.
As you may expect, an awful lot of work goes into designing the cache systems to optimise speed under lots of circumstances. One particular problem is a cacheline split that's where the processor asks for memory that overlaps the end of one line and the beginning of the other. The cache has to do two long reads to fulfil one processor request bad news.
In most systems, this never happens. Data is always aligned with the beginning of a 32- or 64-byte boundary; processors, compilers, memory architecture and software alike has rules to keep it that way. Some processors even crash if you try anything else.
But with video encoding, you can't stick to that rule. A lot of modern compression works by following patterns as they move across the screen, using various mathematical methods to spot where something's moved to and then just encoding that movement as a vector. Because objects can be anywhere on screen and thus in display memory you have to be able to scoop stuff up with no restrictions connected with the underlying memory architecture. Quite often, you'll just have to read across cache lines, because that's where the real world has put your data.
On AMD, you get a small penalty. On Intel, you get a huge penalty equivalent to having to go to the next level of cache and move all the data in anew, no matter whether a real read is needed or not. Sometimes, it's far worse. Even when you factor in all the times that there's no split, the average speed of important functions is halved.
Exactly why this happens, nobody (outside Intel) knows. It has the savour of a clever shortcut that saved a lot of gates or neatly fixed some particular problem: the downside would have been recognised, but judged unlikely to happen and unimportant when it did. Hardware engineering is full of this kind of thinking: squeezing the best functionality out of a circuit against deadline and other limitations means having to decide in advance what's going to matter in the real world. Combine that with fallible human foresight and ever more systemic complexity, and it's rather surprising that chip sets work as well as they do. It's easier to understand that drivers, especially those written by third parties, are often late, buggy or poor performers..
What can be done? Look at the way the x264 developer blog works: solid engineering information shared and explained. In the case of the Intel cacheline problem, four possible workarounds are discussed in some detail: it's open source, so made to be passed around. It often takes a lot of blood and tears to find out what's going wrong in these cases and the instinct can be to hoard what is so expensively bought. Yet when it's shared, its value increases: community amplifies knowledge.
The next step is to spread the awareness of sharing back to the chip manufacturers. It may seem instinctively right to keep secret the details of mishaps and architectural quirks, but they'll be found out anyway. Instead of being thought obstructive, why not get the kudos for honesty and community spirit? That goes a lot further than marketing budget ever can in the minds of users: it'll get your products working better, sooner, and it makes you an attractive place to work when you're out hiring the good guys.
After all, there's nothing smarter than making your mistakes work for you.
Wednesday 16 July 2008, 1:47 AM
Two takes on reality
Today was my first one on the job, and enormous fun. I can recommend being editor as a way to stimulate the little grey cells - I blinked at around five o'clock and realised that the day had passed in a blur of emails, ad-hoc meetings, stories, questions and answers. Getting bored - not an option.
A pal from outside the company suggested that I blog about the reality of becoming an editor for the first time. Very tempting: it only happens at best once per lifetime, and the things I'm learning -- or at least being exposed to, in short order -- are an education and a half. The complexities of the job look extraordinarily different inside from out, and that's after one day inside when the out was being a journalist constantly working for years at a very detailed level with my own editors. Lord alone knows how it looks to people in the real world.
But blogging all that is not an option. We have to keep some secrets from each other, dear reader, or where's the mystery? After striking out all the commercial stuff, the personnel bits, the what-if discussions where we chew over ideas in unpublishable ways, the times I pop off to the loo to shoot up with crystal meth -- well, make a double espresso with our single most vital employee benefit, the free real coffee machine -- there'd be nothing left but my navel-gazing. Which would be dead dull.
There are moments to be shared. One of today's highlights was a quote collected during the construction of the story about the European Commission's ongoing programme of injecting a bit of sanity into mobile phone roaming charges. We called a number of operators to get their take on developments, mostly because it's just good journalism to get points of view from everyone in a story but a little bit because it's often a really good way to illustrate just how disconnected organisations can become from reality.
So take this, delivered by a professional on behalf of Vodafone: "We don't hear a great call from our customers for regulation or intervention for what is already a competitive market in terms of price, SMS prices have already been falling [and] there are plenty of other commodities in the world where prices are rising."
This is all undoubtedly true. I can't remember offhand the last time I suggested regulation to a telco which had just landed me with a very large bill for very little service. The price of SMSs has indeed been going down, in general, while the cost of oil, bread and eggs has been going up. But to imply that either was in some way an answer to the complaints of the European Commission - that mobile phone companies are grotesquely overcharging for roaming, with profit margins almost impossible to calculate without major developments in theoretical mathematics - is as farcical as a five year old caught raiding the biscuit jar excusing himself by saying Aunty Maude once gave a Hob-Nob to the vicar.
Vodafone doesn't agree. Either it truly believes that data transmission costs should be index-linked to the spot price of Brent sweet light crude, or it thinks that we'll believe whatever it says. Either option reflects badly on the relationship the company has with reality: lest Voda think I'm picking on it, it is far from alone.
But the sheer pleasure of having a lump of attributable inanity delivered, gift-wrapped and ready to serve, and to see it presented with all the trimmings to a waiting world -- ah, that's why it's worth doing the job.
That and the coffee. Oh, and the magic that the whole thing works.
Monday 14 July 2008, 4:31 PM
I for one welcome our new overlor... oh, hold on, that's me
Bit of a change of plan here at Goodwins Central. After getting on for more than a decade and a half doing basically the same job of technology editor albeit for four different publications and five different owners the company and I have had a mutual rush of blood to our heads. I'm delighted to say that I'm now the editor of ZDNet.co.uk.
These are exceptionally interesting times in what has always been an exceptionally interesting job. In the good old days, editors pontificated from the safety of paper and monthly deadlines. Now, we're having to use exactly the same systems as we're writing about our success depends on innovative adoption and adaptation of new technology, and an ability to react to events as they happen. We have video, blogs, entire communities of people who don't sit on the editorial desks but have lots to say about the industry and the way we cover it. Keep it coming.
But there are some constants. Like any enterprise, ZDNet UK depends utterly on its team and its management, and I'm surrounded by outrageously talented, hard-working people at every level. . We've got some of the best informed and most critical readers on the planet, many of you making the trip with us since the days of PC Magazine (One Hundred 486 PCs Tested! What were we thinking?). And it's not as if we're going to run out of things to write about.
So stick with us. We've got a few ideas for what happens next. I'm sure you do, too.
Forward in all directions!
Monday 14 July 2008, 7:51 AM
I want my Enterprise 2.0
It's taken a while, but I'm beginning to get the hang of Enterprise 2.0. The job's not made any easier by the usual parlously low signal to noise ratio; as with any fashionable, badly-defined idea there's enough marketing balderdash to perturb the orbit of Jupiter. And the good stuff is buried underneath.
I know what Enterprise 2.0 should be about. It should be about sharing not just data, but views onto that data. At the moment, too many of us are stuck in a world of email attachments, shared drives and cluttered desktops ideas about as advanced as the horse and cart. Collaboration takes place between tiny silos of information: the best we can hope for is something like Google Docs, a word processor that knows about more than one user but not much more than that.
Which is a shocking waste of information. When I'm working on an enterprise project, I need to know when documents change and I'd like to know when they're read. I want to keep track of anything and everything connected with the project, with an emphasis on areas that are personally important. The computers more accurately, the network can know all of this; it mediates all access and can analyse connections and actions until the bovines return to base.
But it doesn't. Even if it did, there's little tradition of presenting complex information in a way that recognises the last ten years of technology and what we've created. It only takes a few minutes' thought to come up with any number of desktop visualisation techniques that could reveal what's going on in a glance: we have graphics hardware as standard that can render huge amounts of information differentated by shape, colour, brightness, animation. So why are files represented by bitmapped icons as static and information-free as Egyptian hieroglyphics?
All these ideas should be as easy to string together in a collaborative environment as blocks of Lego; building up an accurate model of the work of the company as naturally as sketching an idea on a piece of paper. They should be deployable by individuals, spreading between workers and groups because people want to use them not dependant on IT departments buying thousands of seats and unleashing huge changes asynchronous with demand. They use ideas that are commonplace elsewhere, and build on open interfaces that we've had for years.
Where are they?

