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 installations. -Rusty _______________________________________________ Openmoko community mailing list community@lists.openmoko.org http://lists.openmoko.org/mailman/listinfo/community
