What could be done to improve the OM development process?

Russell Sears sears at cs.berkeley.edu
Wed Aug 13 23:06:22 CEST 2008

Mike Baroukh wrote:
>> Trust me, to avoid it, 
>> for a while I really considered shipping a console-image for the framework 
>> image, forcing people to ssh into to start getting familiar with the dbus 
>> services...

Why try to avoid it?  Isn't it the shortest path to a working phone?

If the framework's working, shouldn't all the other stuff be easy to 
write?  For me, FSO is the most stable image so far.  I don't care too 
much about how the GUI looks, at least at this stage of the game. 
(Though 2008.8 looks pretty cool!)

> hum ...
> personnaly, I use it.
> I couldn't get my GPRS work on ASU.
> It works immediatly with FSO and I could phone while GPRS is on.

Really?!?  How?  Is there a GUI somewhere, or did you edit the PPP 
scripts to enter your provider settings?

> So please, if you do this, build also the wm and allowing us to install 
> it ...

I think of FSO as a bear bones linux installation.  It doesn't too much, 
but it's rock-solid, and ready to have new software installed.  I just 
wish there was a unified repository for openmoko packages that held all 
packages written against FSO (ie: a superset of the stuff that comes 
with 2008.8 and FSO).

I couldn't get anywhere with the 2008.8, and am not a fan of qtopia's 
approach to some things.  However, I would like to use opkg to add some 
of SHR's software (and some 2007.2 software) to my FSO installation.

It looks like I'll have to repackage / recompile quite a few programs 
that I'm interested in, which is a shame.  (ie: the openmoko-mediaplayer 
ipk file I have wants pulseaudio for some reason...)

Perhaps there should be 'tasks' metapackages.  So, if you have FSO, but 
want to try out the SHR gui you just do this:

opkg install task-shr

Then, edit some .Xsession file to launch illume + qtopia. FSO with a 
2007.2 look and feel would be this:

opkg install matchbox

and edit your .Xsession to start matchbox instead of illume (and 
probably port the matchbox panel stuff to new apis...).

This approach has worked pretty well for debian over the years.  Though 
now they've got ubuntu, kubuntu, xubuntu, etc.  Instead of forking, OM 
and others could make images for different UIs.

Pre-FSO, I don't think it would have worked for openmoko, since the 
underlying software stacks varied (and evolved) so much.  But now, 
assuming everyone standardizes on FSO's middleware (which seems to be 
happening), getting it to work shouldn't be too bad.

Also, it would let users avoid regressions like the ones associated with 
moving from 2007.2 to [SHR|QTopia|2008.8|FSO], since they could choose 
which apps to run, and try out new software without losing their old 


More information about the community mailing list