Developers/Issues/lang-es
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".
Contents
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 conservaor 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
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.
Our base technology choices have been predicated on the ability of the software to achieve the best overall worldwide "user experience". This requirement drove our choice of GTK+ and Pango (with Cairo as the graphical underpinnings) as our primary GUI system. Pango's abilities in complex scripts are currently the most advanced of free software technologies.
Other development toolkits can be used: but they come at a cost in memory and flash footprint, and today, in the ability of software based on them to be localized to many of the scripts we face immediately, which include both Thai and Arabic. Including other toolkits as a standard part of our base system is therefore problematic, and experience on embedded systems show that including multiple toolkits would almost certainly cause the overall experience to suffer.
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. 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
Sugar puede correr en todos los equipos, la meta es que corra en OLPC While Sugar can run on almost any computer, the target of the OLPC project is to run on extremely inexpensive machines, and particularly the OLPC-XO. As such, you need to target your projects to the constraints of the hardware. The CPU in the machines is the rough equivalent of a 500MHz Athlon processor from the turn of the century. This includes instruction set and performance.
Eficiencia
Many OLPC-XOs will have to be hand-cranked or will need to last long periods between recharges. Every erg of energy is precious.
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.
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.
Try not to have your activity running constantly or waking frequently, the laptop is intended to "go to sleep" as quickly and often as possible, and your activity's trivial loop may prevent that sleeping. Use asynchronous interfaces such as "select" or "INotify" rather than "polling" constantly for changes.
See: Dave Jones' paper "Why Userspace Sucks" Note that most of the particular problems identified are already being worked on, we want to avoid making similar mistakes!
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
Breaking out the functionality of your application into separately-loadable plugins or modules can allow for substantial memory and/or storage savings.
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.
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.
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
An OLPC-XO only has 256MB of memory.
Normally when programming in high-level garbage-collected languages such as Python, Javascript or Smalltalk you normally do not need to worry about garbage collection. In lower-level language development, including extensions for high-level languages you need to be more on your guard.
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.
Remember that every leak, however small, counts!
Almacenamiento
An OLPC-XO has 1GB of storage using a JFFS2 compressing, wear-leveling file-system. JFFS2 compression tends to provide about 2:1 compression for text and typical data, with no extra compression on already compressed data.
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.
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....).
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.
Writable file mappings (via the mmap system call) may not be supported.
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 apoyarte unicamente en una 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 inalambricas 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 trabajaria 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:
