Talk:Maemo Reconstructed

(New page: Add your proposals here --~~~~)
m
 
(16 intermediate revisions not shown)
Line 1: Line 1:
 +
Add your proposals here (remember to sign the proposal with your username, use ---- plus four tildes. If you'd like to discuss the proposals in real-time, try #maemo on irc.freenode.net (IRC) --[[User:stskeeps|stskeeps]] 20:21, 3 November 2008 (UTC)
-
Add your proposals here --[[User:stskeeps|stskeeps]] 20:21, 3 November 2008 (UTC)
+
===Build tools===
 +
Do we get a modern gcc-4.3 and boost-dev? Reason is that for esp. C++ code, g++-4.x can compile template code to much smaller code than g++-3.4. This is more true for shared objects. With boost spirit and mpl, one can create amazing small binaries. (proposal by koos)
 +
 
 +
* I don't see why it shouldn't be possible to get proper modern compilers, provided they work properly for ARM and such. The point of Maemo "R" is to focus more on the hildonization of apps and on working on adjustments to libraries/services to make them more sane in terms of power saving (which is also a big thing in green computing, just see PowerTOP and such). It is a problem when typical libraries that apps use like boost-dev are not up to date, because of platform particularities - and this problem is rooted in the base system. ---[[User:stskeeps|stskeeps]] 19:37, 4 November 2008 (UTC)
 +
 
 +
===Xorg===
 +
Will xcb be part of Fremantle? Lenny already based its Xlib on xcb. (proposal by koos)
 +
 
 +
* Well, this discussion may not be about Fremantle, but about a future Maemo OS that I have no idea which codename it would have if it was accepted ;) But, based on your proposal. XCB, from xcb.freedesktop.org: The X protocol C-language Binding (XCB) is a replacement for Xlib featuring a small footprint, latency hiding, direct access to the protocol, improved threading support, and extensibility. I believe this would obviously be a good part of a mobile platform, if it does not conflict with applications and that it is not CPU intensive, and instead helps on CPU usage and memory usage. ---[[User:stskeeps|stskeeps]] 19:27, 4 November 2008 (UTC)
 +
 
 +
=== Busybox vs dash+coreutils and such ===
 +
 
 +
If you check what Busybox provides on the device:
 +
$ dpkg -s busybox|grep Provides|tr ',' '\n'
 +
 
 +
You should compare Busybox footprint against following Debian
 +
packages: findutils, gzip, hostname, ifupdown, module-init-tools, net-tools, procps, sed, tar, coreutils, grep, mount, login, debianutils, util-linux, vim-tiny, mawk, mktemp, bsdutils, sysvinit-utils, iputils-ping, psmisc, time
 +
 
 +
---Eero Tamminen in an e-mail to maemo-developers, Wed, 05 Nov 2008 11:23:01 +0200
 +
 
 +
* I've added the following change to the proposal, https://wiki.maemo.org/index.php?title=Maemo_Reconstructed&diff=8546&oldid=8540 , but even if it does raise the numbers a bit, the footprint is not -huge-, compared to let's say, an mp3 in the jffs2 fs. My argument still stands I'd say - is 3.5m so important to spare that it justifies the problems that arise from the choice of busybox? Next step is performance and memory usage I guess.. ---[[User:stskeeps|stskeeps]] 10:41, 5 November 2008 (UTC)
 +
 
 +
There is something more - even as ordinary users or script writers, the busybox tools often miss something important.  GnuTar and the other compression tools often have to be there along side.  Loop device support is NOT in busybox so to use it you must get a special mount command.  There is a lot of functionality which often needs to be added even in non developer situations.  Busybox should be stretched to add some of the missing things available as options but simply using the full standard set of tools fixes these problems as well.
 +
:We are open to consider the inclusion of specific tools in Busybox. Please open an enhancement request in bugs.maemo.org for each tool including the reasoning why. -- Quim Gil
 +
 
 +
 
 +
There are many docs, themes, icons, pictures, fonts, and other things which may not be used, so is the footprint really a problem?  How large would it really be?  If space is that tight could the internal flash be set to have a second partition with support for unix like things such as symlinks and not appear as a USB device to when attached to a PC?  Or have some way to create this in a system such that it would override busybox (maybe modify busybox such that if X exists, busybox execs X instead of its internal applet code such that it would never conflict with installing the real application, or maybe just let the symlink be removed and have busybox during init or signal recreate any links for applications which go missing).  Turn either-or into both-and.
 +
 
 +
=== A package that builds in Scratchbox should also build on a tablet ===
 +
 
 +
Debian packages in general aren't buildable with Busybox, so
 +
above would be pending on this: https://bugs.maemo.org/show_bug.cgi?id=2896
 +
 
 +
And on modified build-essentials metapackage that brings in the suitable
 +
GNU tools I guess.
 +
 
 +
---Eero Tamminen in an e-mail to maemo-developers, Wed, 05 Nov 2008 11:23:01 +0200
 +
 
 +
=== Kernels should be a bit richer and modules should be available ===
 +
 
 +
For example, Mac partition support cannot be added as a module.  Same with core dumps, but I think that is on by default.  For boot speed the default kernel should have things built in instead of modules, but there should be a full /lib/modules with modprobe and depmod which can be populated with modules as needed but have the module load support transparent (e.g. USB host, attaching a CD player, or HFS+ mac formatted iPod, coda or fuse for webdav, usbserial, other usb gadgets...)

Latest revision as of 12:07, 10 September 2022

Add your proposals here (remember to sign the proposal with your username, use ---- plus four tildes. If you'd like to discuss the proposals in real-time, try #maemo on irc.freenode.net (IRC) --stskeeps 20:21, 3 November 2008 (UTC)

Contents

[edit] Build tools

Do we get a modern gcc-4.3 and boost-dev? Reason is that for esp. C++ code, g++-4.x can compile template code to much smaller code than g++-3.4. This is more true for shared objects. With boost spirit and mpl, one can create amazing small binaries. (proposal by koos)

  • I don't see why it shouldn't be possible to get proper modern compilers, provided they work properly for ARM and such. The point of Maemo "R" is to focus more on the hildonization of apps and on working on adjustments to libraries/services to make them more sane in terms of power saving (which is also a big thing in green computing, just see PowerTOP and such). It is a problem when typical libraries that apps use like boost-dev are not up to date, because of platform particularities - and this problem is rooted in the base system. ---stskeeps 19:37, 4 November 2008 (UTC)

[edit] Xorg

Will xcb be part of Fremantle? Lenny already based its Xlib on xcb. (proposal by koos)

  • Well, this discussion may not be about Fremantle, but about a future Maemo OS that I have no idea which codename it would have if it was accepted ;) But, based on your proposal. XCB, from xcb.freedesktop.org: The X protocol C-language Binding (XCB) is a replacement for Xlib featuring a small footprint, latency hiding, direct access to the protocol, improved threading support, and extensibility. I believe this would obviously be a good part of a mobile platform, if it does not conflict with applications and that it is not CPU intensive, and instead helps on CPU usage and memory usage. ---stskeeps 19:27, 4 November 2008 (UTC)

[edit] Busybox vs dash+coreutils and such

If you check what Busybox provides on the device: $ dpkg -s busybox|grep Provides|tr ',' '\n'

You should compare Busybox footprint against following Debian packages: findutils, gzip, hostname, ifupdown, module-init-tools, net-tools, procps, sed, tar, coreutils, grep, mount, login, debianutils, util-linux, vim-tiny, mawk, mktemp, bsdutils, sysvinit-utils, iputils-ping, psmisc, time

---Eero Tamminen in an e-mail to maemo-developers, Wed, 05 Nov 2008 11:23:01 +0200

  • I've added the following change to the proposal, https://wiki.maemo.org/index.php?title=Maemo_Reconstructed&diff=8546&oldid=8540 , but even if it does raise the numbers a bit, the footprint is not -huge-, compared to let's say, an mp3 in the jffs2 fs. My argument still stands I'd say - is 3.5m so important to spare that it justifies the problems that arise from the choice of busybox? Next step is performance and memory usage I guess.. ---stskeeps 10:41, 5 November 2008 (UTC)

There is something more - even as ordinary users or script writers, the busybox tools often miss something important. GnuTar and the other compression tools often have to be there along side. Loop device support is NOT in busybox so to use it you must get a special mount command. There is a lot of functionality which often needs to be added even in non developer situations. Busybox should be stretched to add some of the missing things available as options but simply using the full standard set of tools fixes these problems as well.

We are open to consider the inclusion of specific tools in Busybox. Please open an enhancement request in bugs.maemo.org for each tool including the reasoning why. -- Quim Gil


There are many docs, themes, icons, pictures, fonts, and other things which may not be used, so is the footprint really a problem? How large would it really be? If space is that tight could the internal flash be set to have a second partition with support for unix like things such as symlinks and not appear as a USB device to when attached to a PC? Or have some way to create this in a system such that it would override busybox (maybe modify busybox such that if X exists, busybox execs X instead of its internal applet code such that it would never conflict with installing the real application, or maybe just let the symlink be removed and have busybox during init or signal recreate any links for applications which go missing). Turn either-or into both-and.

[edit] A package that builds in Scratchbox should also build on a tablet

Debian packages in general aren't buildable with Busybox, so above would be pending on this: https://bugs.maemo.org/show_bug.cgi?id=2896

And on modified build-essentials metapackage that brings in the suitable GNU tools I guess.

---Eero Tamminen in an e-mail to maemo-developers, Wed, 05 Nov 2008 11:23:01 +0200

[edit] Kernels should be a bit richer and modules should be available

For example, Mac partition support cannot be added as a module. Same with core dumps, but I think that is on by default. For boot speed the default kernel should have things built in instead of modules, but there should be a full /lib/modules with modprobe and depmod which can be populated with modules as needed but have the module load support transparent (e.g. USB host, attaching a CD player, or HFS+ mac formatted iPod, coda or fuse for webdav, usbserial, other usb gadgets...)

Retrieved from "http://wiki.maemo.org/Talk:Maemo_Reconstructed"