New Linux distribution for PDA and embedded device

[amrein]

What could be a big mistake is to think that I\'m the only one wanting something here. If those discussions fail, it\'s all people whose agree with the idea whose will be disappointed (and not only me). I don\'t have a miracle solution under my hat that will prevent discussion, conflicts or clashes. What this thread is all about is build a community linux for our pda and not about a new amrein rom (More than this, this name doesn\'t sound good :[

To be clear and to enter in the real discussion:

We don\'t need to reinvent what is already available. Most components are already there. What is needed is a thought of the community and more important of the ROM builders about how they could work on the same base system. The same way Gnome and Kde share X11 and some other desktop rules, the same way we could build ipks+dependencies that match and could be installed on any new wacky rom.

What do a system need to work and be compatible with another:

1 _ same gnu libraries and tool-chain (we should agree on the ones to use, be able to patch them on a centralized site for everyone, construct common tool-chain and sdk, share documentation for shared components)
2 _ need to use the same or a compatible package format (deb and ipk are completely compatible as the last one is based on the first. Ipkg program haven\'t reached version 1.0 at the time of writing and still have bugs)
3 _ matching dependencies in packages is mandatory (with Debian compatibility, this open the wall Debian repository without the need of manually unpack or rebuild anything).
4 _ compatible init script and low level tools for hardware management (example: you want to beam an entry or you need to connect to your bluetooth gsm or you connect a new wifi card).

It\'s exactly what could be done on a PC running one distro on which you want to install a new package. It\'s also why we could found some compatibilities between Qtopia roms and derivative. Other example: it\'s like installing GPE Opie or Qtopia on top of Familiar.
Familiar or OE/OZ are already based on Debian. Debian is the base system and have all Open Source package of earth today (300 000?). For people whose have already play with Familiar and are asking “So why don\'t we use Familiar?”, they should have also noticed that its main problem is the build system: It\'s a mess. OE or pdaXrom build system have been the answer to this and have completely overtaken it.

To be able to use all components of Debian is very important because it\'s the best way to be able to install any existing open source software from its repository (as long as you have disk space). In this perspective, ipk packages are there to save space. They are some kind of \'deb light packages\' or \'pda specific packages\' built to fit in pda environment (320*240, 640*480, ram, flash, speed constraints...).

More than this, Debian give us build tools, cross-compilation, automated build and test tools, docs and rules:
Developer reference : http://www.debian.org/doc/developers-reference/
Debian Policy Manual : http://www.debian.org/doc/debian-policy/
Docs Index : http://www.debian.org/doc/

It\'s time for rom builders to talk about what they should do to standardise the base system and to prepare what will come. The packages list and dependencies that should be build for Debian compatibility is based on debootrap packages. The base system should be built with packages split (for example i18n, locales, man pages, low used components...). If you are agree, I\'m sure that people (and I\'m in) will help you about this also.

What is missing at present in pdaXrom and OE/OZ:
_ the ipkg dependency structure.
_ the share of the tool-chain, libraries
_ the share of the same init scripts.
_ the menu + icons + themes structure (same as on PC).

Debian uses an unique tool to build menu item for all windows manager and this tool should be used. At present, pdaXrom can\'t use Qtopia packages and Qtopia can\'t use pdaXrom packages. In the future, pdaXrom will certainly have a working qte/x11 library and Qtopia will have a working x/qt in rootless mode ( as it is more like a hack at present and is not really usable or convenient for a newbie).

So at present, most components are there and need to be polished. If you are part of the ROM builders, following the base system rules will give you the opportunity to be able to build something completely compatible with anything that already exist. If you want to use Qtopia tools and libraries or X11/QT/GTK tools and libraries, it won\'t prevent you from been able to run it on any rom. It approximatively what Mickey has tried to say differently several times: those projects need help. This time, whatever you do for them, your work will always be useful. This community project with its tools (sdk, docs, ...) is the best way to open your imagination to any working and useful project.


Note: no need to use one build system as long as the base package are identical and respect Debian dependencies (and future Rom builders agreement). I\'m sure that \'the build system\' could have been a louder clash.
Note 2: as a kennel for your dog, it can\'t be built if you don\'t want it. As I say, this could be a flop if a system like this doesn\'t interest the community.
Note 3: people like me whose are not Linux guru are waiting for general plans from leaders. As any plan when you have the choice, we will be happy to follow what we feel could be in our interest. Rom builders and web masters, it\'s up to you.

[kodiak25]

A real OZ/OE developer (not a wannabe like me) would have to weigh in here as to whether pdaXrom and OZ/OE can coexist somehow in a ROM image.  I would guess that X should be able to live on top of the Qt framework with a translation layer if OZ is the base.  The bigger question is the size of the ROM image.  5500\'s are kinda cramped for space.

Kodiak25

[padishah_emperor]

Amrein, thankyou for being more precise.  I\'m pretty ok with that, especially as a new Debian convert, yep, you\'ve persuaded me, as long as we don\'t shut out 5x00 users. If I can run Qtopia and X apps at once, I\'ll be happy, I\'m learning QT right now so I can pitch-in.

But can you persuade the developers?

[amrein]

Very good question. The big discussion is between pdaXrom, OE/OZ teams and other rom builders like tkROM team in fact.

The bigger problem is that every team could think that they are building THE rom that will completely grab user  attention and forget about user needs. Rom builders need to think about the advantage and disadvantage of a common base system before accepting this \'effort fusion\'.

Exemple:
_ pdaXrom team could think that they only need to provide one big ipgk (or several little packages definition) with all debian dependencies and add qte/x11+qtopia compatibility so they could be the one.
_ OE/OZ team could think that they just need to change a few dependency names into their build system and add x11/qt in rootless mode.

But no distribution compatibility. A lot of work on different sdk, different docs, different feeds, different script...

pdaXrom 1.0.5 is out. This make them to lead today. Will they concider this plan and speak with OE team before OE/OZ overtake them someday... and so one? I can\'t answer to this.

pdaXrom team, OE/OZ team, tkROM team, ... have you make your mind?

[lardman]

pdaXrom 1.0.5 is out. This make them to lead today. Will they concider this plan and speak with OE team before OE/OZ overtake them someday... and so one? I can\'t answer to this.

I think this is unfair. PdaXrom is a better X system quite true as the X libs haven\'t been completely merged into OZ/OE yet (but the X and GTK etc libs are in OE and ready to be massaged along) and therefore don\'t work. This is something which I was planning to look at - to give my 5500 (and from this the other machines too) the ability to run X ontop of the OZ base . That said OZ & Opie is a better Qtopia based system. Horses for courses.

It\'s time for rom builders to talk about what they should do to standardise the base system and to prepare what will come. The packages list and dependencies that should be build for Debian compatibility is based on debootrap packages. The base system should be built with packages split (for example i18n, locales, man pages, low used components...). If you are agree, I\'m sure that people (and I\'m in) will help you about this also.

My impression was that debian didn\'t have this kind of fine granularity in its packages - hence the not using .deb packages (as you get lotsa of extra stuff in them which people might not want filling up their precious space). This is mentioned in the link about ipkg which I posted.

Also note (from the same link - perhaps it\'s not true, I\'ve not dug too deeply into it) that the dpkg system, although the scripting is far better than that provided by ipkg (and I think ipkg is fine for everything I\'ve come across), it\'s very large as is the state info contained in the  .deb files. This is a big no-no IMHO. Not everyone can affort to allocate a couple of meg just to house the package installation database (and I for one wouldn\'t want to). Basically this means that .deb packages would have to be split up and remade (into ipks ;-) - so you\'ve gained nothing IMO.

_ the ipkg dependency structure.
_ the share of the tool-chain, libraries
_ the share of the same init scripts.
_ the menu + icons + themes structure (same as on PC).

I think both systems support dependencies, but different ones which is linked to your second point about sharing the tool-chain and libs. I do think that merging the libs is a good idea - not least because then I wouldn\'t have to make two different versions of every command line program I use (for X and for Opie). I think of all the things you\'ve said this makes the most sense. Unfortunately common toolchains is more difficult - OZ supports many different devices, pdaXrom only supports the C machines (and because of this uses a toolchain which produces ARM5 code). I suppose if we moved to shared libs then there could be two toolchains - ARM4 (for ipaq, 5000d, 5500, etc.) and ARM5 (5600, C machines, etc.), but this is still not ideal IMO. I wonder just how much of an improvement ARM5 is over ARM4? Anyone?

Menus, icons, themes? This is a mute point IMHO. Assuming that you run the same WM on pdaXrom and in Xqt (in Opie) then you\'ll get the same icons, themes, etc. I\'ve no idea how Qt/E apps will be able to run inside pdaXrom - unless it\'s through the fb emulator (which sounds slow to me) or by recompiling (this is probably not what you want, but sounds like the best idea to me). I think you have to weigh up easy of installation against speed of operation + ease of use + size of installation (& extras needed to run a given app - Xqt for example).
 
There\'s more to say but my coffee\'s getting cold and I\'m getting RSI.


Si

[amrein]

I don\'t know. Perhaps the language barrier... I don\'t know.

_ ipkg is the tool that replace dpkg and apt-get. Why do you want to install apt-get? You want  the busybox version perhaps? We don\'t need it but if you want it you will be able to install it. What is the problem? Freedom?

_ the granularity of Debian package is a work to do and not something that is just there to use without brain juice. See Debian documentation to see all default packages installed by debootrap. Here is a link to find how a long time ago someone has shrunk Debian to fit in less than 35Mo: http://staff.washington.edu/dushaw/psion/ (no, I\'m not trying to introduce any company here). His script remove files. What I have proposed is to split those packages instead of deleting files and to let user install what they need and applications to be able to follow dependencies. Hard? A few discussion and people knowing Debian are enough to achieve this (say... less than one week?).

_ why are you talking about megabyte taken by Debian packages? If you don\'t have the space, why do you want to install them? Won\'t you be able to use only ipk? There also, I don\'t understand the problem. You should just remember that if you want something that is not in ipk feeds, you can use the wall Debian repository because all dependencies will be met. If you want to avoid using Debian package, you will be able to use only ipk (the base system is only built with ipk packages).
All those packages for my device.... this scare me but excite me too.

Read again my posts and if you find something that contradict what I\'m saying now, please let me know so I can explain it differently.

_ as soon as QT embedded X11 layer is done, anything from Qtopia can be run on X11. There was a port in process that has never been finished because of lack of interest. Whatever happen, the base system is not concerned about this QT/Qtopia/X11 but only by the dependencies and the fact that any graphical environment could use package from another.

_ Themes, icons, desktop files... some of them need to be used by both graphical environment. Sharing menu entries for example. Of course, this is needed only if a compatibility layer is there (with QTE/X11 and X/Qt)

_ Yes, the armv4 armv5 cross-compilation issue is a problem. I didn\'t think about it before I downloaded pdaXrom sdk. I don\'t know if a binary compiled for armv5 could be run on armv4 without problem. Even if it runs slower, I will be happy if the standard application are compatible (certainly not the kernel). If an expert has an answer about this.. ?

Note: at present we have the 5000 and the 5500 with a Intel StrongARM (armv4). The SL-5600, SL-C700, SL-C750, SL-C760, SL-C860, SL-6000L, SL-6000W with a Intel XScale (armv5). Note also that the SL-5600 is the only one of the armv5 family with 320*480 screen. All other use the 640*480 hi resolution Sharp screen. I will be happy to know that armv5 optimised apps can be run on armv4 processor.

[lardman]

All this time I\'ve been assuming you wanted to use dpkg (you say merge ipkg and dpkg together which I assume means to use some of the backend of dpkg...). Is this the case? If not then ignore what I say here.

_ ipkg is the tool that replace dpkg and apt-get. Why do you want to install apt-get?

I don\'t, I\'m quite happy with ipkg, I presume you\'re referring to someone else\'s message here.

_ the granularity of Debian package is a work to do and not something that is just there to use without brain juice. See Debian documentation to see all default packages installed by debootrap. Here is a link to find how a long time ago someone has shrunk Debian to fit in less than 35Mo: http://staff.washington.edu/dushaw/psion/ (no, I\'m not trying to introduce any company here). His script remove files. What I have proposed is to split those packages instead of deleting files and to let user install what they need and applications to be able to follow dependencies. Hard? A few discussion and people knowing Debian are enough to achieve this (say... less than one week?).

Just as long as you accept that it won\'t be a universal pancea to just be able to install .debs (which I think can be done with ipkg now in any case), and that they will most probably require \'massaging\' to produce usefully small packages. My point was that if this is the case why not just produce .ipks of the packages in question as the work involved will be equivalent?

_ why are you talking about megabyte taken by Debian packages?

Not by the packages, but by the database which is the backend to the dpkg system - the bit which keeps track of which files have been installed where. To tell the truth this is second hand knowledge as I\'ve not got much direct experience of debian (other than playing with pocketworkstation and the ROM which I linked to on the last page). I quite agree that if a package is too big you don\'t install it, but if the database which keeps track of the installed packages is also huge this is a major issue IMHO.

_ as soon as QT embedded X11 layer is done, anything from Qtopia can be run on X11. There was a port in process that has never been finished because of lack of interest. Whatever happen, the base system is not concerned about this QT/Qtopia/X11 but only by the dependencies and the fact that any graphical environment could use package from another.

Agreed this will be nice, but even nicer would be to have native X for X based ROMs and native Qt/E for Opie/Qtopia ROMs - just seems that it will be faster and will have less overhead. I admit that this won\'t probably happen though for everything.

_ Themes, icons, desktop files... some of them need to be used by both graphical environment. Sharing menu entries for example. Of course, this is needed only if a compatibility layer is there (with QTE/X11 and X/Qt)

Agreed. This should be reasonably simple to fix - perhaps have a script called \'link-menus\' which makes symlinks etc.

_ Yes, the armv4 armv5 cross-compilation issue is a problem. I didn\'t think about it before I downloaded pdaXrom sdk. I don\'t know if a binary compiled for armv5 could be run on armv4 without problem. Even if it runs slower, I will be happy if the standard application are compatible (certainly not the kernel). If an expert has an answer about this.. ?

ARM5 instructions won\'t run on ARM4 hardware. Now it\'s possible that an ARM5 binary may be able to run on an ARM4 processor if it doesn\'t use any of the new instructions, I don\'t know what the new instructions are so I can\'t comment on the probability (but all the ones I\'ve tried haven\'t worked). It\'s also possible, so I\'ve read, to produce a kernel module (?) which will handle the unrecognised instructions and make the binary work though I don\'t think anyone has done this.


Si

[amrein]

Ok. If this \'Plan\' has interested rom builders, they would have already reply.
lardman, I won\'t reply to your post because your questions can find answers with some imagination and good sense. If you didn\'t want to imagine how to solve them, it\'s because you don\'t like the idea as the Rom builders.
A flop then.