Developers/Issues/lang-es: Difference between revisions
No edit summary |
|||
| (11 intermediate revisions by 3 users not shown) | |||
| Line 1: | Line 1: | ||
{{Developers}} |
{{Developers}} |
||
[[Developers/Stack| |
[[Developers/Stack/lang-es|Previo]] [[Developers/Projects/lang-es|Siguiente]] |
||
Esta página intenta apuntarte a las diferencias mas grandes al programar para una [[Hardware|OLPC-XO]], y programar en una maquina de escritorio tradicional. Las recomendaciones que encontrarás son útiles aun para otros sistemas, pero en la XO, las limitantes de recursos, y disponibilidad de drivers hacen a las cosas "útiles" se conviertan en "criticas". |
|||
This page tries to point out the major differences between coding for the [[Hardware|OLPC-XO]], and coding for traditional desktops. Most of the advice here is useful even for other systems, but on the XO, resource limitations and diverse deployment can make "useful" turn "critical". |
|||
= Uso de memorias y procesadores = |
= Uso de memorias y procesadores = |
||
Fundamentalmente el hardware de la OLPC-XO el cual es nuestra plataforma meta y tiene solo 1024MB de almacenamiento en (FLASH), y 256 MB en RAM en un procesador de un solo nucleo. Esto requiere que el desarrollador deba poner mucha atención a la "huella" de memoria que deja la aplicación. Los desarolladores quizás necesiten ajustar su ideas y tomar decisiones fuertes para mantener el sistema dentro de un consumo conservador. |
|||
Fundamentally, the OLPC-XO hardware which is our primary target platform has only 1024 MB of storage (Flash), and 256 MB of RAM on a single-core processor. This requires developers to pay much more attention to the memory "footprint" of applications. Developers may need to adjust attitudes and make tough choices to keep the system within this footprint. |
|||
Mientras laptops incrementan en poder y en tamaño a traves de la historia, ver [http://en.wikipedia.org/wiki/Moore%27s_law Ley de Moore], el proyecto de OLPC ha optado por un hardware conservador y una distribución amplia. La comunidad Linux se ha vuelto mucho mas sensible a problemas como "inflación", ha provisto capacidades de internacionalizacion para scripts, y una mejor calidad de procesamiento en una mas grande cantidad de aplicaciones. |
|||
Lo bello es pequeño (y usualmente mas rápido) para todos. |
|||
Small is beautiful (and usually faster) for everyone. |
|||
= Localización = |
= Localización = |
||
El proyecto OLPC se esta implementando una gran cantidad de paises, cada uno con culturas e idiomas unicos. Para que sea accesible a los niños de estos paises, debemos internacionalizar y localizar nuestro software para cada país. Independientemente de que stack de actividades se trabaje, tu proyecto necesitará ser localizado en potencialmente ''cientos'' de idiomas. |
|||
The OLPC project is deploying in a large number of countries, each of which has unique cultures and languages. To be accessible to the children in these countries we have to internationalize and localize our software for each country. Regardless of which Activity stack you are working on, your project will need to be localized into potentially ''hundreds'' of languages. |
|||
Nuestra tecnología base ha sido predicada en la habilidad de que el software alcance la mejor experiencia de usuario a nivel ''mundial''. Este requisito nos ha empujado a usar GTK+ y Pango (con Cairo como base gráfica) como nuestro sistema GUI predeterminado. La habilidad de Pango en scripts complejos son actualmente la forma mas avanzada en tecnologías de software abiertas. |
|||
Otros toolkits de desarrollo pueden ser usados, pero traen un mayor costo de memoria y huella en el flash, y hoy, en la abilidad del software basado en estas para localizar a los diferentes scripts que nos enfrentamos inmediatamente,el cual incluye ambos Thai y Arabigo. Incluyendo otros toolkits como parte estándar de nuestro sistema base es problemático, una experiencia en empotrar sistemas nos muestra que incluir múltiples toolkits causará seguramente un impacto negativo en la experiencia de uso. |
|||
El resumen rápido de como preparar tu proyecto para la internacionalización de: |
|||
The quick summary of how to prepare your project for internationalization is to: |
|||
* recuerda siempre que necesitaras internacionalizar, así que evita hacer presunciones sobre cultura en tu actividad |
|||
* always remember that you will need to internationalize, so avoid building assumptions of culture into the activity |
|||
* |
* usa [[Gettext|gettext]] para tus cadenas de interfaz, icono y otras |
||
* usa texto unicódigo para renderear los elementos de interfaz gráfica |
|||
* use Unicode text for rendering and GUI elements |
|||
Si haces esto como código, el trabajo de internacionalización no será completado, pero debe ser razonable y directo y no requerirá mucho ajuste. |
|||
If you do that as you code, the job of internationalizing won't be finished, but it should be reasonably straightforward and won't require a lot of retrofitting. |
|||
Ver: [[Localization|Localización]] para documentación extensiva de como localizar tu actividad |
|||
Ver: [http://downloads.egenix.com/python/LSM2005-Developing-Unicode-aware-applications-in-Python.pdf Desarrollando aplicaciones sensibles a unicodigo desde Python] (PDF), 31-diapositivas presentación y como trabajar en unicódigo |
|||
Ver: [[Gettext]] y su [http://www.gnu.org/software/gettext documentación] |
|||
Tips: Puedes crear una traducción falsa con mucho texto conteniendo caracteres no ASCII. Es común hacer esto en Cyrillic (ruso) y caracteres Griegos que estan formados de forma similar a los caracteres en Inglés. ¿El texto se rendera? hay elementos gráficos muy pequeños? algunos caracteres Asia orientales necesitan una altura extra junto con algunos caracteres doble acentuados usados en Europa Oriental. Los scripts de derecha a Izquierda como los Arabes necesitan ser considerados. |
|||
Tip: You can create a fake translation with lengthy text containing non-ASCII characters. It is common to do this with Cyrillic (Russian) and Greek characters that are shaped similar to English characters. Does the text get rendered? Are any graphical elements too small? East-Asian characters may need extra height, along with some of the double-accented characters used in Eastern Europe. Right-to-left scripts like Arabic should also be considered. |
|||
= Procesador = |
= Procesador = |
||
Sugar puede correr en todos los equipos, la meta es que corra en |
Sugar puede correr en todos los equipos, la meta es que OLPC corra en computadoras muy baratas y particularmente la [[Hardware|OLPC-XO]]. De esta forma necesitas enfocar tus proyectos a estos tipos de hardware. Los CPUs de las máquinas es apenas el equivalente de un procesador Athlon a 500MHz Athlon processor de principios de este siglo. Esto también incluye el juego de istrucción y desempeño. |
||
= Eficiencia = |
= Eficiencia = |
||
Muchos OLPC-XOs tendrán que ser recargados por manivelas o necesitarán durar largos períodos de tiempo entre re cargas. Por lo que cada erg de energía es preciado. |
|||
Many OLPC-XOs will have to be hand-cranked or will need to last long periods between recharges. Every erg of energy is precious. |
|||
Nuestro enfoque en el ahorro de energía requiere la habilidad de poner en suspensión completamente a la máquina cuando no está haciendo algo. Si tu actividad esta constantemente haciendo procesos irrelevantes, la máquina no podrá ponerse en suspensión de manera total. |
|||
Our power-saving approach requires the ability to put the entire machine to sleep when it's not doing anything. If your activity is constantly doing silly things the machine may not be able to go to sleep at all. |
|||
Desactiva las operaciones de tus actividades tan pronto te sea posible (por ejemplo, tan pronto como determines que no necesitas hacer mas cálculos). Evita las operaciones GUI que son "solo para mostrar" y aquellas que no mejoren una experiencia educativa.Intenta que los cálculos o de renderear en respuesta a eventos, no hagas un render de 30fps si tus datos cambian cada 10 o 20 minutos. |
|||
Disable your activity's operations as soon as possible (i.e. as soon as you determine that you are not needing to do any more calculation). Avoid GUI operations that are "just for show"; those which don't improve the educational experience. Try only to calculate or render in response to events, don't render 30fps if your data only changes once every 10-20 minutes. |
|||
Intenta que tu actividad no esté activa constantemente o que "despierte" de manera frecuente, la laptop ha sido diseñada para "dormirse" tan pronto como le sea posible y posiblemente tu loop de actividad pueda evitar que la laptop se duerma. Usa interfaces a sincrónicas como "[http://docs.python.org/lib/module-select.html select]" o "INotify" en lugar de "polling" constantemente para los cambios. |
|||
Leer el artículo de Dave Jones [http://lwn.net/Articles/192214/ "Why Userspace Sucks"] Ve que muchos de los problemas particulares identificados ya están siendo resueltos, queremos evitar cometer errores similares. |
|||
Considera re escribir secciones clave que alenten tu lenguaje de alto nivel en lenguajes de bajo nivel y código más eficiente. Mejorar el rendimiento de tu código en un factor de diez puede permitir a la máquina ir a "dormir" 3 o 4 veces más a menudo. |
|||
Consider rewriting key sections of slow code in your high-level languages in lower-level and more efficient code. Improving the performance of your code by a factor of ten may let the machine go to sleep 3 or 4 times as often. |
|||
= Modularidad es buena = |
= La Modularidad es buena = |
||
Partiendo la funcionalidad de tus aplicaciones en algo mas modular y plugins que se puedan cargar puede causar mejor uso de memoria o almacenamiento. |
|||
Breaking out the functionality of your application into separately-loadable plugins or modules can allow for substantial memory and/or storage savings. |
|||
Por ejemplo, el soporte de GAIM a cualquier protocolo de Mensajería, pero solo anticiparemos los 3 mas comunes. Dejando así los plugins no tan necesarios nos permite rescatar memoria y almacenamiento. |
|||
For example, GAIM supports just about every IM protocol in existence, but we can only anticipate 3 being common. Leaving off the unneeded plugins saves both memory and flash-storage footprint. |
|||
Para el desarrollo en Python, no importes modulos al inicio. En vez de eso importalos cuando el código lo requiera, y después descarga el modulo para liberar la memoria. Esto requiere de trabajo con ihooks y imp soporte la función unload() por ahora, solo usa una función de muestra en tu código. |
|||
For Python development, don't import modules at the top. Instead, import them just where they are needed in the code and then unload the module. This will require some work with ihooks and imp to support unload() but for now, just use a dummy function in your code. |
|||
De ser posible, implementa componentes opcionales como un modulo separado de Python y borra los archivos .pyc cuando el usuario escoja no usar esa opción. Elimina los objetos cuando estos ya no sirva usando del. |
|||
If possible, implement optional components as a separate Python module and delete the .pyc file when a user chooses not to use that option. Remove objects when they are no longer needed using del. |
|||
= Fugas de memoria = |
= Fugas de memoria = |
||
Una OLPC-XO solo tiene 256MB de memoria. |
|||
Normalmente cuando un programas en un lenguaje de alto nivel lenguajes garbage-collected como Python, Javascript o Smalltalk no tienes que preocuparte por la recolección de basura. En el desarrollo con lenguajes de bajo nivel, incluyendo las extensiones de lenguaje de alto nivel, necesitas estar mas en guardia. |
|||
Es una buena idea revisar fugas de memoria de manera regular durante el proceso de desarrollo. Prueba el tamaño de memoria (ver [[Memory leak testing]] que tiene instrucciones) cada minuto y grafícalo. Si el aumento es lento y gradual, entonces tienes una fuga. un programa normal se incrementa rápidamente al principio y permanece perfectamente plano o decrece y crece repetidamente. |
|||
It is a good idea to check for memory leaks at least a few times during the development process. Sample the memory size (see [[Memory leak testing]] for instructions) every minute and graph it. If there is a slowly increasing size, then you have a leak. A normal program will increase rapidly at the beginning and then remain perfectly flat or shrink and grow repeatedly. |
|||
¡¡Recuerda que cada fuga, aún la mas pequeña, cuenta!! |
|||
Remember that every leak, however small, counts! |
|||
= Almacenamiento = |
= Almacenamiento = |
||
La OLPC-XO tiene 1GB de almacenamiento usando una compresión [[JFFS2]], de nivelación del desgaste del sistema de archivos. la compresión JFFS2 tiende a proveer un radio de 2:1 para texto y datos típicos sin compresión extra para datos ya comprimidos. |
|||
Es posible que al instalar JFFS2 en una máquina Linux sientas que necesitas un método eficiente y preciso de medición de almacenamiento. Esto no es prácticamente necesario para intentar mantener el tamaño bajo y usar los tamaños enzipados como un estimado del requerimiento de almacenamiento de los JFFS2. |
|||
It is possible to install JFFS2 on a Linux machine should you feel you need particularly precise measurements of your storage usage. This likely isn't practically necessary, try to keep the size down and use the zip-compressed size as an approximate estimate of the JFFS2 storage requirement. |
|||
En los archivos de escritura de los sistema flash el desempeño es generalmente lento, mientras que los accesos aleatorios son de hecho muy buenos. El desempeño es glacial si el sistema de ficheros tiene poco espacio y tiene que borrar constantemente bloques liberados antes de escribir (el JFFS2 intenta hacer esto en un segundo plano, pero si no puede...). |
|||
On flash file-systems write performance is generally slow, while random access is actually very good. Performance is glacial if the file system is low on space and has to continually erase freed blocks before writing (JFFS2 attempts to do this in the background, but if it can't....). |
|||
Los programas que constantemente escriben en el sistema de archivos sin necesidad son anti-sociales, desgastan la nivelación ayuda a la longevidad de flash, pero tiene límites, y la escritura quema la alimentación. |
|||
Programs that continually write to the file system without need are anti-social; wear levelling helps flash longevity, but it has limits, and writing burns power. |
|||
Las asignaciones de permisos de escritura de archivos (a través de la llamada al sistema mmap) pueden no ser compatibles. |
|||
Writable file mappings (via the mmap system call) may not be supported. |
|||
= Pantalla = |
= Pantalla = |
||
La OLPC XO tiene doble modo de pantalla, una que tiene una gran resolucion en modo blanco y negro. Cada aplicacion debe ser programada para ser usada en este modo y sus gráficas, muchas de estas son materia de escoger el modo de colores con diferentes luminosidades y altos contrastes. |
|||
The OLPC-XO has a dual-mode screen that has a high-resolution black and white mode. Every application should be coded to be usable in black and white graphics mode, mostly this is a matter of choosing display colours with different luminance values and high contrast. |
|||
La resolución efectiva en modo de colores es mas o menos menor que una en escala en grises, aun cuando el frame buffer siempre sera en alta resolución. Si tu aplicación no honra las fuentes y su ajuste al vuelo, o los contores de las fuentes cambian su pixelación, tu aplicacion no será capaz de degradarse elegantemente y requerira de ajustes manuales para ser usado. Por favor ten en cuenta esto y arreglalo. |
|||
The effective resolution in color mode is somewhat lower than in grayscale, even though the frame buffer will always be in high resolution. If your application does not honor the font resolution change-on-the-fly mechanisms, or hardwires fonts by pixel size, your application won't be able to switch modes gracefully and may require manual intervention to be usable. Please fix. |
|||
El hardware de la OLPC-XO soporta la combinación alfa (composición Porter-Duff), así que esperamos eventualmente soportar esto tambien, pero de momento ''not'' existe este soporte. |
|||
La XO de la OLPC aun no cuenta con hardware 3D. OpenGL se puede usar, pero no esta incluido por defacto (esto inflara el tamaño de tus actividades considerablemente) y no tendrá ningún soporte de hardware. En teoría tu puedes considerar los motores MMX y Enhaced 3DNow! para proveer soporte 3D de forma modulada, pero esto es solo una teoría. |
|||
= Redes = |
= Redes = |
||
No debes confiarte únicamente en la conexión a Internet, aunque sea rápida o estable. La latencia en conexiones satelitales puede ser extremadamente mala, así que mensajes al servidor pueden dejar tu actividad inservibles para los niños en el campo, aunque se vea perfectamente bien en otro lugar. |
|||
You should not rely on having an Internet connection, let alone a fast or reliable one. Latency on satellite-uplink connections can be extremely bad, so lots of round-trip messages to a server may make your activity unusable for children in the field, even though it seems to work perfectly everywhere else. |
|||
Las redes inalámbricas de la OLPC permite la redificación entre pares, sin conexión a Internet. Normalmente esto se implementaría mediante una red mesh o matriz fuera de la escuela, pero una escuela sin conexión a internet trabajaría de una manera similar. |
|||
The OLPC wireless network allows peer-to-peer networking with no Internet access. Normally this would be via a mesh network for OLPC-XOs away from school, but disconnected access-point configurations (i.e. a school with no active Internet uplink) will work in the same way. |
|||
[[Avahi]] |
[[Avahi]] y [[Telepathy]]-provee redes locales descubiertas por las aplicaciones aun cuando no hay una conexión activa a Internet. Intenta hacer tu creatividad usualmente en el vinculo local. |
||
= Seguridad = |
= Seguridad = |
||
Tu código deberá trabajar dentro del sistema de seguridad [[OLPC Bitfrost]]. Aunque el usuario es muy transparente, de la perspectiva del desarrollador Bitforst es una forma intrusiva de asegurar la aplicación. Esto es por diseño. Para trabajar dentro de Bitfrost tu estaras comunmente pensando en las ramificaciones en cuanto a seguridad de lo que estés haciendo. |
|||
Your code will have to work within the [[OLPC Bitfrost]] security system. While to the user it is quite transparent, from the developer's perspective Bitfrost is a rather intrusive approach to security. This is by design. To work within Bitfrost you will often need to consider the security ramifications of what you are doing. |
|||
Considera cuidadosamente si tienes ciertos tipos de operación, si tu vas a necesitar marcar tu actividad con un bit especial de seguridad. Algunos de esos permisos son, por defacto, mutuamente exclusivos. Si necesitas esas funcionalidades mutuamente exclusivas, deberás implementar una actividad firmada, o una autorización explicita pue rl niño que ejecture la aplciación en su laptop. |
|||
Consider carefully whether you need certain types of operation, if you do you will need to flag your activity with a special security "bit". Some such permissions are, by default, mutually exclusive. If you need those mutually exclusive functions, you will require either an officially signed activity, or an explicit authorization by each child to be run on their security-enabled laptop. |
|||
Se te invita a leer la documentación de [[OLPC Bitfrost]] para completamente comprender los principios principales y sus enfoques. |
|||
You are encouraged to read [[OLPC Bitfrost]] to fully understand the underlying principles and approaches. |
|||
== Resumen de restricciones == |
== Resumen de restricciones == |
||
Las mayores restricciones al trabajar con Bitfrost son: |
|||
* |
* acceso a las redes -- boolean control flag bit, if not set, no network access is possible |
||
** rate-limited by default |
** rate-limited by default |
||
** filtering restrictions available to protect against corruption (i.e. you can firewall your activity, in a sense) |
** filtering restrictions available to protect against corruption (i.e. you can firewall your activity, in a sense) |
||
| Line 127: | Line 128: | ||
** if you are considering tutorials or similar tools that "run" another activity for the user, you need to consider this. |
** if you are considering tutorials or similar tools that "run" another activity for the user, you need to consider this. |
||
Especificando banderas: |
|||
Specifying Flags: |
|||
Especificando filtros de red: |
|||
Specifying Network Filters: |
|||
== Procedimiento de registro de actividades == |
== Procedimiento de registro de actividades == |
||
[[Developers/Stack|Previous]] [[Developers/Projects|Next]] |
[[Developers/Stack/lang-es|Previous]] [[Developers/Projects/lang-es|Next]] |
||
[[Category:Developers]] |
[[Category:Developers]] |
||
Latest revision as of 04:16, 9 July 2011
Esta página intenta apuntarte a las diferencias mas grandes al programar para una OLPC-XO, y programar en una maquina de escritorio tradicional. Las recomendaciones que encontrarás son útiles aun para otros sistemas, pero en la XO, las limitantes de recursos, y disponibilidad de drivers hacen a las cosas "útiles" se conviertan en "criticas".
Uso de memorias y procesadores
Fundamentalmente el hardware de la OLPC-XO el cual es nuestra plataforma meta y tiene solo 1024MB de almacenamiento en (FLASH), y 256 MB en RAM en un procesador de un solo nucleo. Esto requiere que el desarrollador deba poner mucha atención a la "huella" de memoria que deja la aplicación. Los desarolladores quizás necesiten ajustar su ideas y tomar decisiones fuertes para mantener el sistema dentro de un consumo conservador.
Mientras laptops incrementan en poder y en tamaño a traves de la historia, ver Ley de Moore, el proyecto de OLPC ha optado por un hardware conservador y una distribución amplia. La comunidad Linux se ha vuelto mucho mas sensible a problemas como "inflación", ha provisto capacidades de internacionalizacion para scripts, y una mejor calidad de procesamiento en una mas grande cantidad de aplicaciones.
Lo bello es pequeño (y usualmente mas rápido) para todos.
Localización
El proyecto OLPC se esta implementando una gran cantidad de paises, cada uno con culturas e idiomas unicos. Para que sea accesible a los niños de estos paises, debemos internacionalizar y localizar nuestro software para cada país. Independientemente de que stack de actividades se trabaje, tu proyecto necesitará ser localizado en potencialmente cientos de idiomas.
Nuestra tecnología base ha sido predicada en la habilidad de que el software alcance la mejor experiencia de usuario a nivel mundial. Este requisito nos ha empujado a usar GTK+ y Pango (con Cairo como base gráfica) como nuestro sistema GUI predeterminado. La habilidad de Pango en scripts complejos son actualmente la forma mas avanzada en tecnologías de software abiertas.
Otros toolkits de desarrollo pueden ser usados, pero traen un mayor costo de memoria y huella en el flash, y hoy, en la abilidad del software basado en estas para localizar a los diferentes scripts que nos enfrentamos inmediatamente,el cual incluye ambos Thai y Arabigo. Incluyendo otros toolkits como parte estándar de nuestro sistema base es problemático, una experiencia en empotrar sistemas nos muestra que incluir múltiples toolkits causará seguramente un impacto negativo en la experiencia de uso.
El resumen rápido de como preparar tu proyecto para la internacionalización de:
- recuerda siempre que necesitaras internacionalizar, así que evita hacer presunciones sobre cultura en tu actividad
- usa gettext para tus cadenas de interfaz, icono y otras
- usa texto unicódigo para renderear los elementos de interfaz gráfica
Si haces esto como código, el trabajo de internacionalización no será completado, pero debe ser razonable y directo y no requerirá mucho ajuste.
Ver: Localización para documentación extensiva de como localizar tu actividad Ver: Desarrollando aplicaciones sensibles a unicodigo desde Python (PDF), 31-diapositivas presentación y como trabajar en unicódigo Ver: Gettext y su documentación Tips: Puedes crear una traducción falsa con mucho texto conteniendo caracteres no ASCII. Es común hacer esto en Cyrillic (ruso) y caracteres Griegos que estan formados de forma similar a los caracteres en Inglés. ¿El texto se rendera? hay elementos gráficos muy pequeños? algunos caracteres Asia orientales necesitan una altura extra junto con algunos caracteres doble acentuados usados en Europa Oriental. Los scripts de derecha a Izquierda como los Arabes necesitan ser considerados.
Procesador
Sugar puede correr en todos los equipos, la meta es que OLPC corra en computadoras muy baratas y particularmente la OLPC-XO. De esta forma necesitas enfocar tus proyectos a estos tipos de hardware. Los CPUs de las máquinas es apenas el equivalente de un procesador Athlon a 500MHz Athlon processor de principios de este siglo. Esto también incluye el juego de istrucción y desempeño.
Eficiencia
Muchos OLPC-XOs tendrán que ser recargados por manivelas o necesitarán durar largos períodos de tiempo entre re cargas. Por lo que cada erg de energía es preciado.
Nuestro enfoque en el ahorro de energía requiere la habilidad de poner en suspensión completamente a la máquina cuando no está haciendo algo. Si tu actividad esta constantemente haciendo procesos irrelevantes, la máquina no podrá ponerse en suspensión de manera total.
Desactiva las operaciones de tus actividades tan pronto te sea posible (por ejemplo, tan pronto como determines que no necesitas hacer mas cálculos). Evita las operaciones GUI que son "solo para mostrar" y aquellas que no mejoren una experiencia educativa.Intenta que los cálculos o de renderear en respuesta a eventos, no hagas un render de 30fps si tus datos cambian cada 10 o 20 minutos.
Intenta que tu actividad no esté activa constantemente o que "despierte" de manera frecuente, la laptop ha sido diseñada para "dormirse" tan pronto como le sea posible y posiblemente tu loop de actividad pueda evitar que la laptop se duerma. Usa interfaces a sincrónicas como "select" o "INotify" en lugar de "polling" constantemente para los cambios.
Leer el artículo de Dave Jones "Why Userspace Sucks" Ve que muchos de los problemas particulares identificados ya están siendo resueltos, queremos evitar cometer errores similares.
Considera re escribir secciones clave que alenten tu lenguaje de alto nivel en lenguajes de bajo nivel y código más eficiente. Mejorar el rendimiento de tu código en un factor de diez puede permitir a la máquina ir a "dormir" 3 o 4 veces más a menudo.
La Modularidad es buena
Partiendo la funcionalidad de tus aplicaciones en algo mas modular y plugins que se puedan cargar puede causar mejor uso de memoria o almacenamiento.
Por ejemplo, el soporte de GAIM a cualquier protocolo de Mensajería, pero solo anticiparemos los 3 mas comunes. Dejando así los plugins no tan necesarios nos permite rescatar memoria y almacenamiento.
Para el desarrollo en Python, no importes modulos al inicio. En vez de eso importalos cuando el código lo requiera, y después descarga el modulo para liberar la memoria. Esto requiere de trabajo con ihooks y imp soporte la función unload() por ahora, solo usa una función de muestra en tu código.
De ser posible, implementa componentes opcionales como un modulo separado de Python y borra los archivos .pyc cuando el usuario escoja no usar esa opción. Elimina los objetos cuando estos ya no sirva usando del.
Fugas de memoria
Una OLPC-XO solo tiene 256MB de memoria.
Normalmente cuando un programas en un lenguaje de alto nivel lenguajes garbage-collected como Python, Javascript o Smalltalk no tienes que preocuparte por la recolección de basura. En el desarrollo con lenguajes de bajo nivel, incluyendo las extensiones de lenguaje de alto nivel, necesitas estar mas en guardia.
Es una buena idea revisar fugas de memoria de manera regular durante el proceso de desarrollo. Prueba el tamaño de memoria (ver Memory leak testing que tiene instrucciones) cada minuto y grafícalo. Si el aumento es lento y gradual, entonces tienes una fuga. un programa normal se incrementa rápidamente al principio y permanece perfectamente plano o decrece y crece repetidamente.
¡¡Recuerda que cada fuga, aún la mas pequeña, cuenta!!
Almacenamiento
La OLPC-XO tiene 1GB de almacenamiento usando una compresión JFFS2, de nivelación del desgaste del sistema de archivos. la compresión JFFS2 tiende a proveer un radio de 2:1 para texto y datos típicos sin compresión extra para datos ya comprimidos.
Es posible que al instalar JFFS2 en una máquina Linux sientas que necesitas un método eficiente y preciso de medición de almacenamiento. Esto no es prácticamente necesario para intentar mantener el tamaño bajo y usar los tamaños enzipados como un estimado del requerimiento de almacenamiento de los JFFS2.
En los archivos de escritura de los sistema flash el desempeño es generalmente lento, mientras que los accesos aleatorios son de hecho muy buenos. El desempeño es glacial si el sistema de ficheros tiene poco espacio y tiene que borrar constantemente bloques liberados antes de escribir (el JFFS2 intenta hacer esto en un segundo plano, pero si no puede...).
Los programas que constantemente escriben en el sistema de archivos sin necesidad son anti-sociales, desgastan la nivelación ayuda a la longevidad de flash, pero tiene límites, y la escritura quema la alimentación.
Las asignaciones de permisos de escritura de archivos (a través de la llamada al sistema mmap) pueden no ser compatibles.
Pantalla
La OLPC XO tiene doble modo de pantalla, una que tiene una gran resolucion en modo blanco y negro. Cada aplicacion debe ser programada para ser usada en este modo y sus gráficas, muchas de estas son materia de escoger el modo de colores con diferentes luminosidades y altos contrastes.
La resolución efectiva en modo de colores es mas o menos menor que una en escala en grises, aun cuando el frame buffer siempre sera en alta resolución. Si tu aplicación no honra las fuentes y su ajuste al vuelo, o los contores de las fuentes cambian su pixelación, tu aplicacion no será capaz de degradarse elegantemente y requerira de ajustes manuales para ser usado. Por favor ten en cuenta esto y arreglalo.
El hardware de la OLPC-XO soporta la combinación alfa (composición Porter-Duff), así que esperamos eventualmente soportar esto tambien, pero de momento not existe este soporte.
La XO de la OLPC aun no cuenta con hardware 3D. OpenGL se puede usar, pero no esta incluido por defacto (esto inflara el tamaño de tus actividades considerablemente) y no tendrá ningún soporte de hardware. En teoría tu puedes considerar los motores MMX y Enhaced 3DNow! para proveer soporte 3D de forma modulada, pero esto es solo una teoría.
Redes
No debes confiarte únicamente en la conexión a Internet, aunque sea rápida o estable. La latencia en conexiones satelitales puede ser extremadamente mala, así que mensajes al servidor pueden dejar tu actividad inservibles para los niños en el campo, aunque se vea perfectamente bien en otro lugar.
Las redes inalámbricas de la OLPC permite la redificación entre pares, sin conexión a Internet. Normalmente esto se implementaría mediante una red mesh o matriz fuera de la escuela, pero una escuela sin conexión a internet trabajaría de una manera similar.
Avahi y Telepathy-provee redes locales descubiertas por las aplicaciones aun cuando no hay una conexión activa a Internet. Intenta hacer tu creatividad usualmente en el vinculo local.
Seguridad
Tu código deberá trabajar dentro del sistema de seguridad OLPC Bitfrost. Aunque el usuario es muy transparente, de la perspectiva del desarrollador Bitforst es una forma intrusiva de asegurar la aplicación. Esto es por diseño. Para trabajar dentro de Bitfrost tu estaras comunmente pensando en las ramificaciones en cuanto a seguridad de lo que estés haciendo.
Considera cuidadosamente si tienes ciertos tipos de operación, si tu vas a necesitar marcar tu actividad con un bit especial de seguridad. Algunos de esos permisos son, por defacto, mutuamente exclusivos. Si necesitas esas funcionalidades mutuamente exclusivas, deberás implementar una actividad firmada, o una autorización explicita pue rl niño que ejecture la aplciación en su laptop.
Se te invita a leer la documentación de OLPC Bitfrost para completamente comprender los principios principales y sus enfoques.
Resumen de restricciones
Las mayores restricciones al trabajar con Bitfrost son:
- acceso a las redes -- boolean control flag bit, if not set, no network access is possible
- rate-limited by default
- filtering restrictions available to protect against corruption (i.e. you can firewall your activity, in a sense)
- file access -- by default you will have no data-file access without explicit selection by the user
- store all user data within the Journal
- unrestricted file access for a file-type -- by default not available if network access is available (to prevent automated uploading of e.g. all of a child's documents to an attacker), if you need both, you need to be signed/explicitly-enabled
- constrain all file-writing to be only within the ${SUGAR_ACTIVITY_ROOT} (available as an environmental variable passed to your Activity instance)
- file writes -- rate-limited by default to prevent flash storage exhaustion (if you are planning to stream video to flash storage, you likely need to consider this!)
- camera/microphone access -- special flag to be allowed to ask for access, 30 minute timed access after which re-request required
- background sound -- flag, allows for playing sounds when not the foreground activity
- background CPU -- flag, allows for using more than a small fixed percentage of CPU while not foreground
- synthetic X events -- flag, allows you to generate synthetic X events (mouse and keyboard, for instance) and send them to other Activities
- if you are considering tutorials or similar tools that "run" another activity for the user, you need to consider this.
Especificando banderas:
Especificando filtros de red: