Editing Maemo Reconstructed
Warning: You are not logged in.
Your IP address will be recorded in this page's edit history.
The edit can be undone.
Please check the comparison below to verify that this is what you want to do, and then save the changes below to finish undoing the edit.
Latest revision | Your text | ||
Line 1: | Line 1: | ||
- | |||
- | |||
Our goal is to bring together Nokia and community developers who have an interest in the Maemo platform and reach a vision of the future Maemo system architecture that's satisfying to both Nokia and the community. | Our goal is to bring together Nokia and community developers who have an interest in the Maemo platform and reach a vision of the future Maemo system architecture that's satisfying to both Nokia and the community. | ||
- | These are the low level ''technical'' system goals (use of booting process, busybox/coreutils, kernel features etc.), and not high level stuff like "Ogg support" or "open source everything". The process is called Maemo "Reconstructed" to indicate we can remix parts from and disassemble the current Maemo platform and augment it until we get a vision that would be fitting as the future of the Maemo platform. | + | These are the low level ''technical'' system goals (use of booting process, busybox/coreutils, kernel features etc.), and not high level stuff like "Ogg support", or "open source everything". The process is called Maemo "Reconstructed", as to indicate we can remix parts from and disassemble the current Maemo platform and augment it until we get a vision that would be fitting as the future of the Maemo platform. |
If you have anything to contribute that is constructive criticism, or alternate proposals for parts of the proposal, please add it to the [[Talk:Maemo Reconstructed|talk page]]. Again, this is not the place for discussion on high-level topics like A2DP support and finger-friendliness. These are low-level platform issues. If you want to shoot down part of the proposal, document your findings on why it is not possible or should not be done and discuss it on the talk page. | If you have anything to contribute that is constructive criticism, or alternate proposals for parts of the proposal, please add it to the [[Talk:Maemo Reconstructed|talk page]]. Again, this is not the place for discussion on high-level topics like A2DP support and finger-friendliness. These are low-level platform issues. If you want to shoot down part of the proposal, document your findings on why it is not possible or should not be done and discuss it on the talk page. | ||
Line 15: | Line 13: | ||
Thanks to Ryan Abel for proofreading and to other #maemo members for comments. | Thanks to Ryan Abel for proofreading and to other #maemo members for comments. | ||
- | |||
- | |||
== The Maemo "Reconstructed" platform == | == The Maemo "Reconstructed" platform == | ||
- | The | + | The purpose of Maemo "Reconstructed" is to make Maemo a general platform for tablet devices (including Nokia devices), to make it more developer-friendly, and to bring it into alignment with standard Linux distributions. It is also within the philosophy that the platform should be "hackable", a main selling point with open-source friendly hardware. |
We should stop seeing the tablets as strictly under-powered embedded systems, and see them for what they really are—powerful, power-efficient, economical handheld computers. Not simply hopped-up electronic calendars, but real computers that are capable of almost as much computing as a laptop. | We should stop seeing the tablets as strictly under-powered embedded systems, and see them for what they really are—powerful, power-efficient, economical handheld computers. Not simply hopped-up electronic calendars, but real computers that are capable of almost as much computing as a laptop. | ||
Line 28: | Line 24: | ||
There should exist scripts and documented methods for creating a Maemo "R" image that can be adapted to any setup or device. It should be easy to build your own jffs2 image. | There should exist scripts and documented methods for creating a Maemo "R" image that can be adapted to any setup or device. It should be easy to build your own jffs2 image. | ||
- | Development of the Maemo "R" platform (non-device-specific and non-vendor-specfic differentiation) should be done in the open, with public SCM, bugtrackers and | + | Development of the Maemo "R" platform (non-device-specific and non-vendor-specfic differentiation) should be done in the open, with public SCM, bugtrackers and blueprints. This way, developers can adjust their applications to later 'stable' releases and know what is coming regarding the Maemo API. |
- | One of the goals of the Maemo "R" platform is that it should be easy to port an existing desktop application by hildonizing it and adjusting to the form factor of a tablet, without having to deal with platform particularities like what features the busybox version of a tool uses or other factors. A secondary goal is to have a platform that is flexible enough to encourage experimentation and development for tablets. | + | One of the goals of the Maemo "R" platform is that it should be easy to port an existing desktop application by hildonizing it and adjusting to the form factor of a tablet, without having to deal with platform particularities like what features the busybox version of a tool uses, or other factors. A secondary goal is to have a platform that is flexible enough to encourage experimentation and development for tablets. |
== Kernel == | == Kernel == | ||
- | For the Maemo "R" platform specific kernels | + | For the Maemo "R" platform specific kernels does not matter, but it may be relevant to discuss certain features that would be nice to have for the platform to work correctly. |
== Boot process == | == Boot process == | ||
Line 87: | Line 83: | ||
** '''Advantages''': We now have a full ubuntu base system on our tablet. We've got Upstart for for free without any development. We have a base we can easily work with upstream on, as we base on typical packages. The mojo project also gets to have instant value to the Nokia/Maemo development and Nokia gets a return from the research investment in it. | ** '''Advantages''': We now have a full ubuntu base system on our tablet. We've got Upstart for for free without any development. We have a base we can easily work with upstream on, as we base on typical packages. The mojo project also gets to have instant value to the Nokia/Maemo development and Nokia gets a return from the research investment in it. | ||
** '''Discussion''': ''Is busybox really needed on a tablet''? In initfs, sure, but in the actual system? Having sane coreutils and bsdutils (and debconf) -really- helps porting. Now that dash exists, is there a reason for busybox as sh? This avoids any conflicts with coreutils, bsdutils etc if they are going to be used. | ** '''Discussion''': ''Is busybox really needed on a tablet''? In initfs, sure, but in the actual system? Having sane coreutils and bsdutils (and debconf) -really- helps porting. Now that dash exists, is there a reason for busybox as sh? This avoids any conflicts with coreutils, bsdutils etc if they are going to be used. | ||
- | *** | + | *** A simple (which may be unfair and inaccurate) experiment with dpkg-deb -x of procps, coreutils, util-linux, bsdutils into a path, and then mkjffs'ing it after stripping man pages, locales and info pages, 2.2mb flash, and with busybox getting same treatment, 300k flash. |
- | + | *** Is ''1.9mb'' flash so much to sacrifice for making porting for Maemo a matter of hildonization and platform-centric things, instead of hunting debconf, busybox incompatibilities and such for weird libraries you never heard of? | |
- | + | ||
- | *** Is '' | + | |
*** Are there any direct and noticable differences in performance that justifies the use of busybox, and do they justify the lessened ability of being able to port to Maemo without hassle? | *** Are there any direct and noticable differences in performance that justifies the use of busybox, and do they justify the lessened ability of being able to port to Maemo without hassle? | ||
- | |||
** '''Problems''': For some reason the mojo people decided to divert from Debian arch notation and call their ARM EL distribution arch type 'arm', not 'armel', which is in wide use with Maemo. | ** '''Problems''': For some reason the mojo people decided to divert from Debian arch notation and call their ARM EL distribution arch type 'arm', not 'armel', which is in wide use with Maemo. | ||
* '''Upstart''' | * '''Upstart''' | ||
Line 113: | Line 106: | ||
* '''Udev''' | * '''Udev''' | ||
** Part of Maemo platform already, and useful for desktop and embedded systems. | ** Part of Maemo platform already, and useful for desktop and embedded systems. | ||
- | * '''Ke-recv''' | + | * '''Ke-recv & Alarmd''' |
** Some daemon representing this (Kernel event handling + scripts, maybe OHM?) | ** Some daemon representing this (Kernel event handling + scripts, maybe OHM?) | ||
* '''GConf''' | * '''GConf''' | ||
Line 134: | Line 127: | ||
* '''Xorg''' | * '''Xorg''' | ||
** Part of Fremantle roadmap. | ** Part of Fremantle roadmap. | ||
- | ** Device-specific Xorg drivers (omap for N8x0's, other devices has other drivers, etc.). It should not be a requirement which Xorg driver is in use, but the capabilities of this. | + | ** Device-specific Xorg drivers (omap for N8x0's, other devices has other drivers, etc.). It should not be a requirement which Xorg driver is in use, but the capabilities of this. |
- | + | ||
* '''GStreamer''' | * '''GStreamer''' | ||
- | ** Part of Maemo platform as of now, ideal for codecs, include vendor-specific | + | ** Part of Maemo platform as of now, ideal for codecs, include vendor-specific propertiary ones. |
* '''PulseAudio''' | * '''PulseAudio''' | ||
** Part of [[Task:Maemo roadmap/Fremantle]]. Optional part of platform? What does Maemo really target of device types? | ** Part of [[Task:Maemo roadmap/Fremantle]]. Optional part of platform? What does Maemo really target of device types? | ||
Line 147: | Line 139: | ||
** The base graphical framework of Maemo. This GTK version should be Maemo 'GTK', but the following things should hold true for the Maemo GTK. | ** The base graphical framework of Maemo. This GTK version should be Maemo 'GTK', but the following things should hold true for the Maemo GTK. | ||
*** Maemo GTK is designed for power-saving low-freq devices. It is designed for touchscreens and with memory conservation in mind | *** Maemo GTK is designed for power-saving low-freq devices. It is designed for touchscreens and with memory conservation in mind | ||
- | *** It should not alter | + | *** It should not alter it's behaviour in such a way that a certain window manager or desktop environment is needed to run applications using this toolkit. If this change of behaviour is needed, the toolkit should detect the WM/DE and enable the behaviour if it's Hildon+Matchbox. |
*** It should not change upstream API (but may add or cause breakage that would make normal GTK applications not work with it. | *** It should not change upstream API (but may add or cause breakage that would make normal GTK applications not work with it. | ||
* '''GTKMM''' | * '''GTKMM''' | ||
Line 168: | Line 160: | ||
== SDK (developer kit for the platform) == | == SDK (developer kit for the platform) == | ||
- | The SDK is a basic part of developing for Maemo. | + | The SDK is a basic part of developing for Maemo. But there are occasional horror stories. Based on some of the stories about the SDK and other trends in the mobile device world, this is a vision of a proper SDK for Maemo "R". |
Maemo "R" SDK should be easy to install. It should be a matter of apt-get'ing a package or installing a VMware appliance for non-Linux users. It's alright for device-specific dev packages & emulator images to require a license to download, but the base Maemo "R" SDK should be easily installable and allow you to start developing for the base Maemo "R" platform immediately. You shouldn't have to go through hoops to get Scratchbox + Rootstrap + Generic Maemo device emulator image and such, - this attracts developers. | Maemo "R" SDK should be easy to install. It should be a matter of apt-get'ing a package or installing a VMware appliance for non-Linux users. It's alright for device-specific dev packages & emulator images to require a license to download, but the base Maemo "R" SDK should be easily installable and allow you to start developing for the base Maemo "R" platform immediately. You shouldn't have to go through hoops to get Scratchbox + Rootstrap + Generic Maemo device emulator image and such, - this attracts developers. | ||
- | |||
- | |||
- | |||
- | |||
- | |||
- | |||
Maemo "R" SDK, should consist of four parts: | Maemo "R" SDK, should consist of four parts: | ||
- | === Scratchbox | + | === Scratchbox (cross-compilation environment) === |
Build programs for another architecture/target than on the one compiling. | Build programs for another architecture/target than on the one compiling. | ||
Line 186: | Line 172: | ||
Packages for Maemo should not expect Scratchbox to be where they're compiled (There's been seen examples of this amongst Nokia code.). This increases portability of Maemo platform. A package that builds in Scratchbox should also build on a tablet. | Packages for Maemo should not expect Scratchbox to be where they're compiled (There's been seen examples of this amongst Nokia code.). This increases portability of Maemo platform. A package that builds in Scratchbox should also build on a tablet. | ||
- | + | ===Maemo "R" rootstrap === | |
- | + | Maemo base OS with libraries and dev packages to cross-compile any applications for Maemo "R", not to run them. | |
- | + | Cross-compiliation certainly speeds up compilation and allows a proper developer environment for developing for Maemo "R". "Not to run them" is meant as, CPU transparency is okay, but the rootstrap should not try to be a fullly deployed Maemo "R" system. The rootstrap shouldn't try to act as an tablet - we have the emulators for that. | |
- | + | A Maemo "R" rootstrap may have Nokia/device specific dev packages but developers should be encouraged to develop for the defined Maemo "R" platform. Nokia/other hardware vendors specific dev packages should strive towards non-device-specific standardization of the interfacing if possible (a BME dev package may not be relevant on other devices). | |
- | + | Maemo has great possibility to become a general platform for tablet like devices. The possibility of additional device platforms which also embrace the Maemo minimal base + build-essential + dev packages direction will cause every Maemo device to have additional applications as well when they appear for other devices. | |
- | + | === QEMU appliances included with target device(s) emulated === | |
- | + | The appliances would be shipped with a device-specific Maemo "R" installed on it. This is where built applications should be run, not inside the SDK (no Xephyr, not full hildon desktop, etc. in Scratchbox). These should be configured with sbrsh for cpu transparency from initial setup. N8x0 emulation is already seen (http://blog.haerwu.biz/2008/04/11/nokia-n800-emulation/). Qemu appliances will allow the user to instantly test how their applications work on the actual device or an emulated version. | |
- | + | ||
- | + | ||
- | + | ||
- | + | ||
- | + | ||
- | + | ||
- | + | ||
- | + | ||
- | + | ||
- | N8x0 emulation is already seen (http://blog.haerwu.biz/2008/04/11/nokia-n800-emulation/) | + | |
- | + | ||
- | + | ||
=== Deployment and debugging support scripts === | === Deployment and debugging support scripts === | ||
Line 217: | Line 191: | ||
Work could be done on easy deployment of developed packages (# sb-copy-to-tablet -i usb, -i emu, etc) or running in similar manner to sbrsh with NFS and the likes. | Work could be done on easy deployment of developed packages (# sb-copy-to-tablet -i usb, -i emu, etc) or running in similar manner to sbrsh with NFS and the likes. | ||
- | |||
- | |||
- | |||
- |
Learn more about Contributing to the wiki.