What could be done to improve the OM development process?
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
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