Everything and the Mobile Software Universe…

[Thomas Menguy is looking at why Nokia and Intel are more and more collaborating lately]

After the ofono initiative (Telephony Stack coming from Nokia, integrated in Intel new OS, Moblin, and Nokia one, Maemo) and Intel licensing the Nokia HSPA/3G modem IP , the honeymoon seems in good shape!

The Intel and Nokia effort includes collaboration in several open source mobile Linux software projects. Intel will also acquire a Nokia HSPA/3G modem IP license for use in future products

Intel/Nokia Press release

Nokia has been in trouble recently:

• Market share and revenues are eroding , down to 35% for smartphone marketshare, first loss for 10 years
• Lost lackluster as technology provider (at east in the consumer space)
• Is looking to reinvent itself (again) as a service provider and a full vertical player… but OVI is, as of now, underwhelmig

Intel  seems to be doing really well right now but:

• It is still missing the ball in the embedded space (netbook are only a fraction of it)
• Atom is selling well … but at a low price : higher end centrino platform has been cannibalized, so revenue is suffering
• Still completely tied to MS Windows for software: Netbook were not selling at all when they were Linux based, market took off when WinXP has been put on it. It can be seen as a strength … but MS has failed in the device space, for years, so Intel x86 advantage is alleviated by all the new embedded OS for whom the ARM processor is THE choice leading to the next point …
• …Qualcomm is now the Intel archrival, with cutting edge Wireless, HUGE IP bag and full system integration (and, as Intel, a ton of cash).
• Is looking to reinvent itself (windriver deal) as a system provider more than a chip (CPU, discrete component) one.

Nokia is moving fast to become a vertical player, from services to devices

• it is now organized in a by platform silos: S40  / S60 / Maemo
• putting strength in its software and integration
• Lots of acquisitions around OVI and services.

As a Software guy I can’t retain myself to comment about this S60 ditching in favor of Maemo : Symbain is a robust OS, with cutting edge wireless capabilities. Where it is really poor is around it’s programming model (way too much over engineered) … and it’s user experience (UX) (S60 is just very dated and poorly conceived, no homogeneity nor UX guidelines)….
Do you really think that changing the low level OS will change anything? Linux is no better than Symbian kernel, just more hype around it, the UX layer has to be done from scratch by Nokia … Hum sounds the same as S60 no?
Will have to wait and see but Qt is still not in Maemo: N900 is GTK based…really old tech…and as difficult to program as S60.

Nokia is trying to be Google (or an Apple/Google hybrid), and, as Google, has an issue with deployment of its own services on a wide range of devices, what can be the solution?

Is it Maemo? I don’t think so: If yes Nokia will have to deploy it like Android…they have failed in the past with S60. Maemo won’t be the only Nokia Platform for a long time : They  need to commonalize efforts between their 3 platforms (Maemo,S60,S40)
They have Qt:

• Ported to S60 to replace its programming model and allows a better UX framework and developers friendliness
• Maemo 6 : at last, Qt based and Maemo 5 gets its Qt shot also
• But the real missing one, the one Nokia sells hundreds millions every year : where is Qt and deployment solution for S40 ???? This would be the real killer one with bilion of platforms deployed in a few years …

Intel is also moving vertically, trying to sell systems instead of chipsets and get out of the MS Windows locked-in: Here comes Moblin, a new OS … with, for now, no traction from OEMs (Who are too in love with Android, but it may change because an OEM doesn’t like to be locked in by a software platform, look at Samsung Bada for example…).

Really a big driving OEM is missing to finish this system vision, to help Intel grow its expertize in the area…And after all why not Nokia?

What would be the incentive for Nokia?:

• If Intel delivers (and it is a big IF) , so if their HW embedded platform is head and shoulders above the competition (Moorestown and its successors), Nokia will have a big differentiator before the competition, IF the software is optimized on it
• This is were I really see a merge between Maemo and Moblin (I bet on this one ) so Nokia will cut dev costs again, with its hardware partner
• Adding Intel as its supplier, Nokia will have a real multi supplier strategy, so less risk (cost and supply)

I really think we should look at those two closely in the following months….

What do you think?

This DevX article: Get to Know uSTL: A Lightweight STL for Symbian describing a symbian STL (C++ Standard Template Library, the C++ “toolbox” with lists, vector, string utils, etc.) less crippled that the standard one, really reminded me of this eternal debat.

Recently we have worked on some memory optimization for our product, the part running on the PC. It was using way too much memory compared to what information was effectively loaded.

The data model is XML, and we are creating our objects with SAX parsing of this model… and many things were stored in STL string, and some stream where used….surprise STL string where using 128 bytes preallocating data…so for a 4 bytes string you use …. 128 bytes! stream memory use were growing exponentially!

So we played brut force and quickly reimplemented a class string based on good old char *, and a stream tuned for our use…and guess what: mem usage was divided by 10, and it was really faster.

Conclusion of this story: if you want to go serious, you have to master and well understand all the objects you use heavily: It may sound obvious, but many many time programmers take too many things for granted, especially on the PC world ….you know why Windows is now using way too much RAM …but in the PC camp Moore Law helped a lot to deal with RAM/CPU power explosion…

It is not to say that STL is a bad library (ok, not so intuitive to use, but it is another story), but those kind of services are ok for prototyping, or “normal” application, not for intensive ones. The difference between this two kind of applications is blurry, and coding something faster prevails way too often, heading to crippled apps.

Now look at the mobile phone space, here the Moore Law is not bringing a lot of RAM/CPU, it is “only” bringing down the chipset cost…but the vast majority of mobile phones are still running on CPU with less that 10 MIPS and 256 or 512kB of RAM, BUT feature sets are still growing and growing….

So obviously your applications, services, HAVE to use less RAM and less CPU each time, hum we are really NOT in a PC world.

To achieve that you can:

1. Continue to code as close as possible to the bar metal (uhm silicium), using low level C code, assembly, few OS services.
2. Use a Mobile Phone coding framework, taylored for the embedded space (this one is itself made using the previous point mode of programming), with a native programming language (C/C++)
3. Use a Higher Level OS with a native programming language (C/C++) (Palm, WinCE, Symbian)
4. Choose an “interpreted framework” like Java or .NET (see the Mono effort in this respect)
   
5. Go for scripting. (like OpenLaszlo, Ruby On Rails, Digital Airways, etc)

Of course the more abstract you go the more RAM/CPU you loose, but the more developper productivity you get … if you stick too closely to the PC world mantra. BUT if it doesn’t fit in your target …. it won’t fit , and you loosed a lot more that productivity, you loosed your market.

A high Level OS is simply not a choice: try to fit WinCE in a 10 MIPS machine … it is already not snappy on a 400MHz ARM 926 … (same for Symbian and in less extent Palm)

So things have to be more balanced, and as the zen approach told us “the middle way” may be the solution.

I strongly believe that a mix of very high level services for UI, with a good interconnection with low level services for control, algorithm and modelling part of the application is the way to go:

1. You let the graphists/designers quickly design your UI
2. You code the algorithm, controls, threading model, network in C/C++ with low level or very low resource consumming APIs
3. You let the framework dealing with interactions between applications and resource access sharing.

The last point is crucial, else you end up with a big mess, with unmaintenable and non evolutive code cause all the services will have to know each others, definitively a big mistake. The first one has to be there cause clearly the UI is, in this market, defined in specifications by UI specialists, and it can greatly improve the time to market to let them “design to manufacture” with some powerfull tools to create UI, like user friendly RAD, or even better like Flash Lite SDK, or Digital Airways But those high level solutions are not enough cause they lack the second point: the logic of your app have to be done in a scripting language, which is clearly not tuned nor designed to do that: UI and Logic HAS TO BE more clearly separated to use the best tools to do the job.
Java also doesn’t fulfill those needs … SavaJE is not everywhere, no phone with full Java UI…(I won’t go also in the Java mess around standardization, check this techtype entry about internationalization ): It is not good for UI (only a programmer can do a UI), and so so for application core (CPU and RAM, plus missing APIs).

For sure, as said at TomSoft we need Mobile Developement Simplification(and yes widget standardization can help), but the traditional vision of “one model” fits all seems clearly not relevant for our industry, and more innovative frameworks have to emerge to trully allow the explosion we are all waiting around mobile services (see this entry about skype failure to deliver…).

What do you think?

Update: Taken from the Adobe Flash Lite 2.1, here are some RAM/CPU for flash …

Ok, we are far from the “Ultra Low Cost”/”Low Cost” segment but not by a 10 factor (except for CPU), so suing only some part of flash for a phone UI is not out of question ….

Update 2: Good read at “C. Enrique Ortiz Mobility Weblog” about the C language, and why it is still, and will stay, usefull. Anyway for me C++ is also a “low level” language as it is compiled and you are dealing yourself with pointers …