03.20.08
2 Unlimited
“Dual-use is a term often used in politics and diplomacy to refer to technology which can be used for both peaceful and military aims.”
I watched a very interesting talk by Bruce Schneier regarding Dual Use technolgies. It can be found here.
Obviously the internet is a great example of a dual use technology. Originally developed to de-centeralise military communications, it has found a place in the hands of civillians. To the point (as Bruce mentions), that the military basically has its own internal IP network which borrows from the lessons learnt on security in the public network.
A military worker, who plugs his work laptop in at home via VPNs, is vulnerable to virus which can spread into the internal military network. And as a result the commoditisation of software, or to put it another way – the net flow of civilian technology flowing back into the military is a new trend.
Military (and aviation) s/w has to have a high degree of quality in their construction and verification. A malfunctioning plane, or remote nuclear detonator can cost lives where as excel crashing (but allowing you to recover your data) is rarely critical.
The talk really got me thinking about the quality assurance problems that are presented to mobile handset manufacturers.
If avionic grade quality and security controls were applied to mobile software, then it’s likely that we would get one handset every two years from the major manufacturers.
That’s not to say that all phones are inherently flawed, it’s just that packing more and more features into a phone creates an environment which has more in common with desktop PC rather than world where mobiles come from – the signalling stack.
Mobile phone signalling stacks have to go through rigorous type approval, performance and network interoperability testing across several world regions. Although it’s hard to fully test the code paths in a signalling stack, code coverage of a ROM image can be assessed by hardware tracing the program counter. 3G Network simulators can be purchased for a quarter of a million pounds a piece and the software is verified for worst case latency and real time guarantees.
In other words, the characteristics of the signalling stacks are pretty much a known quality.
Many mobile phones in the last decade have built upon the real time OS used by the signalling stick by creating an application framework which sits in a lower priority thread.
This worked very well for simple phones – it was possible to have a snappy UI which handled the simple tasks such as dialling, address book and texting.
Since the UI ran in the same address space as the kernel, the characteristics of the UI had to be proven just like the rest of the stack.
One important aspect of real-time/embedded programming is that the memory requirements of an applications should be defined in advance. This means pre-allocating areas of memory for the applications so that they will always be able to run (no out of memory dialogs).
The result of taking signal stack mentality to apps was that limits were set across applications. A handset could have say 10 slots for incoming SMS messages and if the slots were filled up then the user would have to delete the messages to receive more (a waiting message alert indicated this).
By establishing limits, not only did the engineers have a spec to work to – but actually, users are more comfortable with limits than many people credited.
So while engineers can optimise the contacts database to 200 entries, allowing a 0.1 second search and open time, users get a better deal because they get snappier performing phones which seldom crashed.
The other interesting factor is that, when you have limits you can present very specific dialogs to the user. If you have run out of SMS slots, then the dialogs can say “delete some messages”.
On a smart phone, running out of space for SMS is often generalised as a “Low disk” notification where by the user can delete anything from a few contacts to a photo to free up enough disk space to receive a message (not all users are fluent enough in technology to realise that deleting a music track saves more space than a SMS).
Allowing apps to run in the background means that battery can be zapped, or starve another app of memory so that an application which worked ok this morning, fails in the afternoon.
Not only are smart phones technically very difficult to verify in terms of quality and performance, but the limitless applications makes it very hard to provide good information to the casual user.
I find it quite unfortunate that a lot of the techniques and idioms which made mobile phones so easy to use and reliable are starting to fade and their importance de-emphasised.
(It’s interesting that Apple have really applied consumer electronics dogmas very heavily to their iPods and iPhones and have received plenty of press coverage for their almost iconoclastic attitude to the “precious developers”.)