Dudas para la nueva version de FDOM
|
|
David Samblas Martinez
|
Hola como he dicho en mi anterior post, a la que tenga un hueco,
quiero volver a ponerme con a crear una nueva release de FDOM, pero me surgen ciertas dudas de como atacarla y quisiera consultarlo con vosotros, en petit comite, ahora mismo no podria manejar el ruido y las expectativas si lo hiciera en la Internacional. *1.-Basada en solo en guion (Fdomizer/Kustomizer) ,mixta Openembedded+guion de primer arranque/mantenimiento, Openembededded pura? Los tres enfoques tienen ventajas y desventajas, **Solo guion ***Ventajas-> Mas facil, mas Rapido, puedo llegar a hacerlo yo solo, facilmente maleable ***Desventajas-> Dificilmente mantenible si la base cambia,que lo hacen y mucho, (gracias a $Deity) , gestion de licencias manual **mixta Las aplicaciones se instalarian directemente desde Openembbeded y las que tuvieran el codigo fuente accesible desde opkg.org ***Ventajas-> Bien planteada puede llegar a actualizarse via opkg update/upgrade y estar en sincronia con la distro base, scripts para pulir detallitos y workarounds a mi ignorancia en Openembedded, esos scripts puedo llegar a hacerlo yo solo, la disponibidad del codigo fuente estaria mas o menos asegurada y se puede facilmente hacer un mirror de las fuentes utilizadas. ***Desventajas-> Se debe tener mucho cuidado con los scripts para que no rompan nada cuando se hace un upgrade y si lo hacen que sea facilmente restaurado con otro script de mantenimiento pero la mas gorda es que no puedo hacerlo solo, ya lo he demostrado en varios intentos fallidos con esta aproximacion, mas detelles mas abajo **Openembedded pura ***Ventajas-> Las actualizaciones y el mantenimiento se harian solo a traves de opkg, sin ayuda de scripts auxiliares. ***Desventajas-> Un paquete no puede(no se) mover/alterar archivos de otro paquete dentro del rootfs en tiempo de creacion del mismo, lo que imposibilita por ejemplo el mover los iconos del escritorio a directorios para hacer categorias (FDsubmenu/SortOM), hacer bakcup de los archivos de configuracion originales... etc Y al igual que la opcion anterior no puedo hacerlo solo **Ayuda, please En lo que seguro necesitaria ayuda, y me refiero a que alguien se ensucie las manos conmigo es en: ***Montar un entorno saneado de OpenEmbedded Es decir, sigue estos pasos, bajate estos ficheros de configuracion y compilara seguro, al menos con la distribucion base, no me importa si tengo que instalar otro SO que no sea Ubuntu 8.10, puede ser parte de los pasos iniciales necesarios, lo que ya seria una filigrana, y esta idea me la has dado tu Jose luis, es tener un Live CD instalable con este entorno saneado. ***Montar un csv/svn/git para el overlay y los scripts y un howto de como realizar un ciclo de cambios en el csv/svn/git Descargate/sincroniza asi, modifica/añade el archivo asa, prueba que funcione asi, sube los cambios asa, nunca supe como realizar el ultimo paso y siempre acababa en en un full upload, seria ideal que ademas este sevidor pudiera hacer una compilacion diaria ***Un servidor apara alojar el resultado (kernel, rootfs(tar y jffs2), ficheros fuente, livecd, que aguante el tiron de las descargas, lo ideal seria que sincronizara con el del csv/svn/git una vez al dia con el resutado Y por pedir que no quede *** Un tracker para los bugs/mejoras, aunque esto creo que me lo puedo apañar yo solito, un cable seria de agradecer. la opciones basada en Openembedded sin esa ayuda, es volver a darme contra el muro de mi ignoracia, y no creais, suelo estamparme contra el por placer, varias veces, pero cuando no consigo hacer ni que se resquebraje un tocho despues de n intentos la diversion empieza a convertirse en un improductivo dolor de cabeza Y otra duda existencial 2.-Distribucion base SHR o OM2009? Como ya sabeis la filosofia de FDOM es si funciona y mola para adentro asi que es facilmente aplicable a cualquier distro base, *SHR(testing algun dia stable) **Pros->Funciona como un tiro!, ya tiene incorporado de serie un monton de aplicaciones, incluyendo un bonito sistema de configuracion y es lo que mas se aceraca a un telefono de uso diario. **Contras->Me gusta mas paroli, no se como la comunidad SHR se tomaria un fork "a la" FDOM, tengo la sospecha que al tener mas cosas instaladas de serie sera mas facil romper cosas. *OM2009(FDOM estara basada en la stable release pero para empezar se podrian usar las RC) **Pros->Openmoko esta encantada con que se creen forks a partir de su distro. es mas creo que es una distribucion pensada para hacer forks, me gusta paroli, no lo puedo evitar. **Contras->Mas movimientos y cambios que en la stable(ups perdon testing) de SHR, mas cosas por hacer a nivel de configuracion. Bueno, estas son basicamentes mis dudas antes de tan siquiera empezar, necesito vuestra opinion y sabiduria y esta vez desde el pricipio Un saludo y gracias por compartir mis cabilaciones de -- David Reyes Samblas Martinez http://www.tuxbrain.com Open ultraportable & embedded solutions Openmoko, Openpandora, GP2X the Wiz, Letux 400, Arduino Hey, watch out!!! There's a linux in your pocket!!! _______________________________________________ Local-openmoko-spain mailing list [hidden email] http://lists.projects.openmoko.org/mailman/listinfo/local-openmoko-spain |
||||||||||||||||
Davide
|
On Monday 27 April 2009 11:11:18 David Reyes Samblas Martinez wrote:
> **Contras->Me gusta mas paroli, no se como la comunidad SHR se tomaria > un fork "a la" FDOM, tengo la sospecha que al tener mas cosas > instaladas de serie sera mas facil romper cosas. Pues yo opino igual... Qué sentido tiene hacer un fork de SHR? No sería mejor concentrar nuestros esfuerzos en SHR, incluso integrando paroli como opción? Está bien tener la distro "oficial" (OM), está muy bien tener Debian, y está mejor incluso tener una distro "comunitaria" (SHR). Pero no le veo sentido a otra más (reinventar la rueda), si no va a aportar nada nuevo... Si optas por seguir con FDOM (la usé en su día, y mucho!), yo voto por un script a lo "kustomizer" sobre SHR (de momento está mucho más madura que OM2009), que no deje de ser SHR, pero que instale cosillas "necesarias" que la imagen "a pelo" no trae, y que, al menos yo, instalo una y otra vez cada vez que flasheo :) Facilitar la vida al usuario de a pie, vamos. Pero es mi sólo opinión, claro :) _______________________________________________ Local-openmoko-spain mailing list [hidden email] http://lists.projects.openmoko.org/mailman/listinfo/local-openmoko-spain |
||||||||||||||||
jluis
|
In reply to this post
by David Samblas Martinez
El Monday, 27 de April de 2009 11:11:18 David Reyes Samblas Martinez va
escriure: > Hola como he dicho en mi anterior post, a la que tenga un hueco, > quiero volver a ponerme con a crear una nueva release de FDOM, pero me > surgen ciertas dudas de como atacarla y quisiera consultarlo con > vosotros, en petit comite, ahora mismo no podria manejar el ruido y > las expectativas si lo hiciera en la Internacional. Tu lo has pedido >;-) > *1.-Basada en solo en guion (Fdomizer/Kustomizer) ,mixta > Openembedded+guion de primer arranque/mantenimiento, Openembededded > pura? Si quieres generar una imagen para distribuir la que mas ventajas representa es la version mixta pero pensando en migrarla a OE. >... > **Openembedded pura > ***Ventajas-> > Las actualizaciones y el mantenimiento se harian solo a traves de > opkg, sin ayuda de scripts auxiliares. > ***Desventajas-> > Un paquete no puede(no se) mover/alterar archivos de otro paquete > dentro del rootfs en tiempo de creacion del mismo, lo que imposibilita > por ejemplo el mover los iconos del escritorio a directorios para > hacer categorias (FDsubmenu/SortOM), hacer bakcup de los archivos de > configuracion originales... etc No entiendo para que quieres realizar eso en tiempo de creacion de paquete lo suyo es hacero antes o despues de la instalcion del paquete y el sistema de paquetes lo permite. > Y al igual que la opcion anterior no puedo hacerlo solo > > **Ayuda, please > En lo que seguro necesitaria ayuda, y me refiero a que alguien se > ensucie las manos conmigo es en: > ***Montar un entorno saneado de OpenEmbedded > Es decir, sigue estos pasos, bajate estos ficheros de configuracion y > compilara seguro, al menos con la distribucion base, no me importa si > tengo que instalar otro SO que no sea Ubuntu 8.10, puede ser parte de > los pasos iniciales necesarios, lo que ya seria una filigrana, y esta > idea me la has dado tu Jose luis, es tener un Live CD instalable con > este entorno saneado. Puedes contar comigo pero no se si tendre tiempo para escribir howtos. Mi live que permite realizar el make en el neo y distribur la compilacion en i386, esta casi hecho (tan solo me falta que me configure correctamente el cdc_ether i el how-to) >..... > > 2.-Distribucion base SHR o OM2009? > Como ya sabeis la filosofia de FDOM es si funciona y mola para adentro > asi que es facilmente aplicable a cualquier distro base, > *SHR(testing algun dia stable) No has de tener problemas SHR. Segun que paquetes quiras instalar si estan en OE puedes pedir a los de SHR que compilen el paquete. Las diferencias (a lo burro) de uso del framework en SHR y FSO se limitan a que SHR tiene midleware extra y tras la conferencia esa que van a realizar este mes que viene seguro que convergeran mas ( paroli tambien puede correr en SHR) _______________________________________________ Local-openmoko-spain mailing list [hidden email] http://lists.projects.openmoko.org/mailman/listinfo/local-openmoko-spain |
||||||||||||||||
Rafael Campos
|
Hola a tod@s,
2009/4/27 Jose Luis Perez Diez <[hidden email]>: > El Monday, 27 de April de 2009 11:11:18 David Reyes Samblas Martinez va > escriure: >> Hola como he dicho en mi anterior post, a la que tenga un hueco, >> quiero volver a ponerme con a crear una nueva release de FDOM, pero me >> surgen ciertas dudas de como atacarla y quisiera consultarlo con >> vosotros, en petit comite, ahora mismo no podria manejar el ruido y >> las expectativas si lo hiciera en la Internacional. > > Tu lo has pedido >;-) > >> *1.-Basada en solo en guion (Fdomizer/Kustomizer) ,mixta >> Openembedded+guion de primer arranque/mantenimiento, Openembededded >> pura? > > Si quieres generar una imagen para distribuir la que mas ventajas representa > es la version mixta pero pensando en migrarla a OE. Yo aqui tambien opino como Jose Luis, el mejor punto de entrada es empezar con una mixta, y poco a poco, migrarlo todo a OE. > >>... >> **Openembedded pura >> ***Ventajas-> >> Las actualizaciones y el mantenimiento se harian solo a traves de >> opkg, sin ayuda de scripts auxiliares. >> ***Desventajas-> >> Un paquete no puede(no se) mover/alterar archivos de otro paquete >> dentro del rootfs en tiempo de creacion del mismo, lo que imposibilita >> por ejemplo el mover los iconos del escritorio a directorios para >> hacer categorias (FDsubmenu/SortOM), hacer bakcup de los archivos de >> configuracion originales... etc > > No entiendo para que quieres realizar eso en tiempo de creacion de paquete lo > suyo es hacero antes o despues de la instalcion del paquete y el sistema de > paquetes lo permite. > >> Y al igual que la opcion anterior no puedo hacerlo solo >> >> **Ayuda, please >> En lo que seguro necesitaria ayuda, y me refiero a que alguien se >> ensucie las manos conmigo es en: >> ***Montar un entorno saneado de OpenEmbedded >> Es decir, sigue estos pasos, bajate estos ficheros de configuracion y >> compilara seguro, al menos con la distribucion base, no me importa si >> tengo que instalar otro SO que no sea Ubuntu 8.10, puede ser parte de >> los pasos iniciales necesarios, lo que ya seria una filigrana, y esta >> idea me la has dado tu Jose luis, es tener un Live CD instalable con >> este entorno saneado. > > Puedes contar comigo pero no se si tendre tiempo para escribir howtos. Mi live > que permite realizar el make en el neo y distribur la compilacion en i386, > esta casi hecho (tan solo me falta que me configure correctamente el > cdc_ether i el how-to) > desde la beta, 9.04 y no he tenido problemas para compilar en OE (ya se resolvieron la mayoria de ellos). >>..... >> >> 2.-Distribucion base SHR o OM2009? >> Como ya sabeis la filosofia de FDOM es si funciona y mola para adentro >> asi que es facilmente aplicable a cualquier distro base, >> *SHR(testing algun dia stable) > > No has de tener problemas SHR. > > Segun que paquetes quiras instalar si estan en OE puedes pedir a los de SHR > que compilen el paquete. > > Las diferencias (a lo burro) de uso del framework en SHR y FSO se limitan a > que SHR tiene midleware extra y tras la conferencia esa que van a realizar > este mes que viene seguro que convergeran mas ( paroli tambien puede correr > en SHR) Yo no lo veo como un fork, lo veo como un addon. En definitiva, la base es OM (200x.x) y sobre ella, las aplicaciones SHR. y FDOM lo que haria seria meter todos o casi todos los paquetes disponibles. Lo unico que puede fallar, con SHR es alguna dependencia, pero eso podria ayudar a detectar dependencias perdidas en SHR/FSO o OM 200x. Para mi SHR es una distro usable sobre FSO, mientras que FSO esta más centrado en desarrollar y madurar el framework, soportando más dispositivos, mas configuraciones, otros modems, telefonos, ... > > > > _______________________________________________ > Local-openmoko-spain mailing list > [hidden email] > http://lists.projects.openmoko.org/mailman/listinfo/local-openmoko-spain > Te hecharé una mano en lo que los buzz fixes me lo permitan ;) Porque siempre hay tiempo para compilar o re-compilar Saludos. -- ___________ Rafael Campos o0 Methril 0o http://openblog.methril.net/ _______________________________________________ Local-openmoko-spain mailing list [hidden email] http://lists.projects.openmoko.org/mailman/listinfo/local-openmoko-spain |
||||||||||||||||
Miguel Angel Calderón
|
2009/4/27 Rafael Campos <[hidden email]>
Buenas, Me gusta la idea de David, sería una buena manera de empezar a familiarizarse con los entresijos de una distribución para el Neo y así poder colaborar más. Veo que vosotros teneis más claro el tema del punto de partida, pero mi opinión sería la empezar con Om2009 o una testing de OE e ir añadiendo los programas y utilidades de configuración que veamos y nos gusten. Yo también prefiero el look de Paroli y estaría bien tener sobre esa base nuevas aplicaciones... Al fin y al cabo SHR parece que tiene suficiente empujón del grupo de desarrollo como para que nos pongamos nosotros a modificarla. Yo agradecería mucho unas indicaciones de como empezar... luego yo ya trastearía mirando y haciendo pruebas. En cuanto llegue mi Neo podría empezar a probar cosillas. Por cierto, por si alguien no lo ha visto, hay una nueva versión de Hackable1 que se puede descargar. Si quereis ver un video de esta distro en acción lo teneis aquí [1]. El principal desarrollador, Marcus Bauer, padre del programa TangoGPS, ha hecho el video y dice que él ya usa el Neo con esta distro como daily "phone". [1] http://www.youtube.com/watch?v=Izww_4Z421g -- Un saludo -- There is no spoon _______________________________________________ Local-openmoko-spain mailing list [hidden email] http://lists.projects.openmoko.org/mailman/listinfo/local-openmoko-spain |
||||||||||||||||
| Free Embeddable Forum Powered by Nabble | Help |
