Creating Meego Products in a Different Way and Faster - How to Change the Device Creation

Creating MeeGo products in a different way and faster - How to change the device creation

Pasi Nieminen CEO [email protected] +358 40 737 3907 www.nomovok.com

1 The Questions That I Try Answer Today

 How to make product faster & better in MeeGo world

 How/why to change the UX creation - QML?

 MeeGo for ARM, where is it now?

 Where to find companies to work on MeeGo?

2 About Us

 We create products build on Open Source technologies #1 MeeGo company

 Pioneer in Embedded Open Source Pioneer in commercial utilization of Open Source in embedded devices. Since 2001, more than 400 OSS deployment project delivered

 Employs 110 OSS experts globally 400 more in ZCOCO.net for deep Linux expertize

 Locations 3 Currently serving businesses in Japan, Germany, France, US, Finland and Korea. Insider's View to MeeGo - Where Are We Now?

4 Current MeeGo Deployment Status

 Currently FULL build & integration pipeline working

 Currently MeeGo-dev + QT4.7 + NOMOVOK Steel Rat UX running on STE U8500 / Freescale i.mx51 / Renesas AP4 (All ARMv7 optimized) / IA

 See our demo @ demo area, and NOMOVOK staff

5 Forget C++ & Native QT apps - Go for QML

6 MeeGo Apps – Faster

 QT4.7 enables QML apps

 Declarative UI

 XML + JS

 3x faster app creation to QT native apps

 Performance almost equal to native QT apps, in future much faster (declarative GUI => GPU)

7 QML – hello world

import Qt 4.7

Rectangle { id: page width: 500; height: 200 color: "lightgray"

Text {

id: helloText8 text: "Hello world!" y: 30 anchors.horizontalCenter: page.horizontalCenter font.pointSize: 24; font.bold: true } } QML - demo

9 Moving to Native Build Process from Cross compilation -Ready To Deploy Today

10 MeeGo Builds – a new way

 No cross compilation anymore, pure native builds

 No toolchain problems

 No manual patching / no branching

 Faster new versions

 Completely new way to build embedded products, and integrate to community versions

11 Build environment is the same as the target environment, including Building for Target HW operating system and hardware architecture

Native Cross-compilation

Build environment is completely different from the target environment. Build tools are On Target HW Emulated modified not to see/rely on the actual environment. Example: Maemo (ARM) app built in Ubuntu on x86 PC using Scratchbox Build environment is the Build environment is the same as the target actual target environment, environment, but emulated as virtual machine including real hardware. on another environment. Example: Maemo app built Example: Ubuntu ARM app built in Windows PC, in Maemo device with ARM. using a Virtual Machine emulating ARM. Ubuntu installed as the OS of this Virtual Machine.

12 Benefits of Native Build Systems

 Native on Target  Native on Emulated Target

1. Build tools (compilers etc.) 1. No changes needed to environment or tools originally designed, and are still Build tools work as they do on native developed, for this as target. 2. Use of actual environment information 2. Get the actual environment 3. No limit to the performance of the VM host machine information from running system 4. Allow building in host desktop machines in multiple OS's 3. Always access to the latest tools and features for the environment 5. OS only limited by the virtualization SW support 4. No performance hit from extra 6. Most packages can be built in emulated environment computing layers 7. Success rate in tested packages: ~85-95% of Ubuntu packages built without modifications (Handhelds Mojo CELF2008: ~15000 packages)

Yes, there are some cons:

- Not all, i.e. smaller, devices have Yes, there are some cons: sufficient performance to be High performance hit due to the Virtual Machine emulation feasible build devices layer

- Builds require significant computing Not all packages can be built unmodified with emulator power 13 Native build or modifications needed NOMOVOK Linux Build Service

 Hosted Linux binaries build service  Optimized binaries

Customers to drop in source codes and Means more performance with less power consumption and smaller memory footprint NOMOVOK process takes care of native (e.g. ARM kernel 20% improvement in build to deliver binary packages performance).

 Native builds – less problems  Common components

No tool and patching problems with cross Use of common components and technologies compilation build systems allows easy, secure access and use as part of the development process. No vendor lock  Optimized target architecture and the Linux ups, open process. distribution  Secure Native build can support a long list of target Each customer gets an own, separate and hardwares. Optimization of the build complete service – no shared functionalities environment for each customer a core part of service

 Focus on essential

Support your product easily, make SW variants easily. Make sure you keep you Linux as close to OSS community versions as possible, let us help you14 not to fork. NOMOVOK MeeGo Build Service

Build Environments Customer Source Project_1 Binaries Project_1 MeeGo x.x- ARM yy Project_2

Project_2 MeeGo x.x- ARM zz Project_3

Project_3 MeeGo x.x- ARM zz

15 Utilize Global MeeGo Supply Chain Easily - Network of MeeGo Companies - Easy Way To Utilize

16 ZCOCO.net Ease Device Creation

 How to find best companies in MeeGo?

 How to ramp up MeeGo creation?

 Learn how to utilize community

 Stop compromising, get right people

 ZCOCO – a community of MeeGo companies

17 Unique Contractual Model

 One contract, many suppliers

 One local contact - always

 Best suppliers in OSS / MeeGo

 No profit on profit

どうもありがとうございます。 Thank you!

For more information, please contact:

Pasi Nieminen CEO

[email protected] +358 40 737 3907