Contributors program/lang-es

  Esta página está supervisada por el equipo de OLPC.

This is an on-going translation

The currency of this article or section may be limited by out-of-date information. There may be relevant discussion on its talk page

Programa de Desarrolladores OLPC

Presentaciones y Manejo de Expectativas

Existe una diferencial importante entre un sistema OLPC y una laptop convencional de hace aproximadamente cinco años; esa es, nuestro sistema de software de base es mucho más capaz que el de aquel entonces. El ambiente Linux ahora tiene capacidad de internacionalización para scripts que no eran posibles entonces, un rendering de mayor calidad, y lo mejor de todo, un amplio espectro de aplicaciones.

There is a major difference between the OLPC system and a conventional laptop of approximately five years ago; that is, our base system software is much more capable than it was then. The Linux environment now supports internationalization capability for scripts that were out of our reach then, and much higher quality rendering and, best of all, a much wider range of applications.

Esto no ha sido sin un costo, sin embargo: la "Ley" de Moore nos ha permitido ser descuidados, tanto en el uso de memoria como de CPU; esto nos hace tomar difíciles decisiones al momento de mantener la "huella" (footprint) del software en niveles aceptables. La laptop OLPC tiene solo 512 MiB de almacenamiento (Flash), y probablemente su limitación más importante, 128 MiB de RAM, y un procesador mono-núcleo. En el último año más o menos, la comunidad se ha vuelto mas sensible a estos temas, y el trabajo esta bien encaminado para poner un límite a este "sobre-peso" y aspectos de rendimiento en general. Lo chico es hermoso (y usualmente más rápido!)

This has come somewhat at a cost, however: Moore's "Law" has allowed us to become sloppy, both in memory usage and CPU usage; this tends to force us to make some tough choices to keep the "footprint" of the software acceptable. The OLPC laptop have only 512 MB of storage (Flash), and probably the most serious limitation, 128 MB of RAM, and a single-core processor. Over the last year or so, the community has become much more sensitive to these issues, and work is well underway toward reigning in this "bloat" and performance work in general. Small is beautiful (and usually faster!).

Nuestras elecciones en la tecnología de base han sido conjugadas con la habilidad del software de lograr su máximo rendimiento a nivel global en cuanto a la "experiencia de usuario". Esto dictó nuestra elección por GTK+ y Pango (con Cairo como graficador de base), dado que la habilidad de Pango para manejar scripts complejos es la más avanzada de las tecnologías libres. Otras herramientas pueden ser usadas: pero tienen el costo de memoria y flash, y actualmente, en su habilidad para que el software basado en ellos pueda ser adaptado a lenguajes locales necesaria, que incluyen tanto Tailandés como Arábigo. El incluir otras herramientas como parte estándar de nuestro sistema de base es por lo tanto problematica, y la experiencia en sistemas embarcados demuestra que la inclusión de múltiples alternativas muy probablemente impacte negativamente en la experiencia del usuario.

Our base technology choices have been predicated on the ability of the software to achieve the best overall worldwide "user experience". This drove our choice of GTK+ and Pango (with Cairo as the graphical underpinnings), since Pango's abilities in complex scripts are currently most advanced of free software technologies. Other 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.

Sistemas BTest

Hemos pasado por dos (de tres) versiones (builds) del sistema OLPC completo, para "BTest".

Típicamente hay uno o dos versiones internas del sistema andtes de realizar un prueba beta externa, con lo cual nuestro BTest-1 es en realidad una prueba beta de la electrónica, al mismo tiempo que una prueba alfa para la nueva pantalla, el touchpad, el diseño industrial, y el teclado; esto es más temprano que en el ciclo de desarrollo de sistemas normal, y por lo tanto más burdo.

We have had the two builds (of three builds) of full OLPC laptops built, for "BTest". There is typically one or two builds of systems internally before an external beta test, so our BTest-1 is really beta test for the electronics, while alpha test for the new screen, touch pad, industrial design, and keyboard; this is earlier in the development cycle than systems are usually made available, and is correspondingly rougher.

El hardware BTest-2 continúa con sus pruebas beta para la electrónica, pruebas beta para la nueva pantalla (esta vez con un difusor que la mejora aún más) y el touchpad. El diseño industrial ha sido levemente mejorado sobre el BTest-1; la mayor parte de las lecciones del BTest-1 sobre mejoras mecánicas no pudieron ser incorporadas a tiempo para la BTest-2 y por lo tanto el BTest-3 será marcadamente más resistente que el BTest-1 o BTest-2.

The BTest-2 hardware is continuing beta test for the electronics, beta test of the new screen (this time with a diffuser improving it futher) and touch pad. The industrial design is only somewhat improved from BTest-1; most of the learning from BTest-1 on mechanical improvements could not be incorporated in time for BTest-2 and so BTest-3 will be significantly more rugged than BTest-1 or BTest-2.

El foco para el programa de desarrolladores de las máquinas BTest-1 será el desarrollo de software en proyectos relacionados con la GUI que necesitan entender la pantalla, el touchpad, y/o la cámara en el sistema, así como también las pruebas sobre la red inalámbrica, que han sido más complicadas de realizar anteriormente dada las incomodidades de las placas peladas.

The focus for the developer program BTest-1 machines will be software development on GUI related projects that need to understand the screen, the touch pad, and/or the camera in the system, along with wireless testing, which has been difficult to do sooner due to the cumbersome nature of bare PC boards.

El foco para las BTest-2 es comenzar con las pruebas de la red de malla, y trabajar también sobre el suspender/resumir, aunque al momento de esto, no funciona, aunque el trabajo de base esta finalizado.

BTest-2's focus will start the process of testing the mesh network, and we are also working on suspend/resume, though as of this writing, suspend/resume is not yet running, though the preparatory work is now complete.

Las máquinas también estan siendo asignadas para los países de lanzamiento y no se incluyen en este programa, que tiene como objetivo a la comunidad libre y open-source ya sean individuos u organizaciones de investigación a las que les interese contribuir a las metas de la OLPC.

Machine are also being allocated to launch countries and do not come under this program, which is aimed at individual free and open-source developers or research organizations interested in contributing to furthering OLPC's goals.

Lo que la OLPC Espera de los Usuarios BTest

Lean las Notas de Lanzamiento!

La versión BTest-1 ya ha sido distribuída: las Notas de Lanzamiento BTest-1 detallan el estado de las máquinas de dicha versión.

La versión BTest-2 comenzó su distribución el 12 de Febrero. Las Notas de Lanzamiento BTest-2 detallan el estado de las máquinas de la segunda versión.

El software correrá tanto en las BTest-1, BTest-2 y las placas ATest; por favor lean las Notas de Lanzamiento del Software OLPC.

The BTest-1 build has been distributed: the BTest-1 Release Notes describes the state of the first build of machines.

The BTest-2 build is starting distribution as of February 12. The BTest-2 Release Notes describes the state of the second build of machines.

The software will run on BTest-1, BTest-2 and the ATest boards; please read the OLPC Software Release Notes.

Reporte de Bugs y Errores

Noten que nuestro proceso es uno completamente abierto: en un programa "convencional" de pruebas beta de un producto, se les hubiera solicitado la firma de un acuerdo de confidencialidad, y la no divulgación de cualquier problema que puedan haber tenido, o siquiera saber que problemas han tenido otros probadores beta puedan estar teniendo. Usualmente, una prueba beta del hardware se realiza mucho despues en el programa tras haber hecho extensas pruebas que lo han sido realizadas aca.

Estas pruebas beta tempranas del hardware significan una mayor probabilidad de problemas en el hardware que una prueba beta posterior o una versión de producción. El diseño recien esta pasando pruebas de estrés bajo situaciones de altas temperaturas, frio, vibraciones, impacto, y humedad así como otras pruebas más.

Note that our process is a fully open one: in a "conventional" beta test program for a product, you would have been asked to sign a non-disclosure agreement, and not disclose any of the problems you might have, or even be aware of problems other beta testers might be having. Usually, such a hardware beta test is done later in the program after more extensive testing has been done than has been done here. This early beta test hardware means a much higher probability of hardware problems than later beta test or production hardware. The design is just now undergoing stress testing at elevated temperature, cold, vibration, shock, and humidity as well as many other tests.

Los componentes pueden estar bien en el papel, pero no necesariamente en la práctica, ya sea por defectos en el diseño de los componentes o en su uso. Las pruebas beta son usadas también para probar diferentes componentes de los fabricantes. Siempre que sea posible, en los productos de alto volúmen, los componentes son de múltiples proveedores (multiple-sourced), y cada tipo de parte nominal de diferentes fabricantes son probados en su compatibilidad. Esto es para asegurarse un aprovisionamiento estable, aún en el caso en el que un dado fabricante tenga problemas de entregas, y así disponer de alternativas. Ejemplos en nuestro hardware incluyen al proveedor de la cámara, memoria RAM, placas (PCB&mdash-printed circuit board), para nombrar algunos. En las placas ATest, por ejemplo, descubrimos varios componentes que no queremos usar en producción, y cabe suponer casos similares durante el BTest. El diseño de un componente puede ser nuevo, y tener sus propios problemas de diseño y fabricación a resolver (ej: el problema con el área de escritura que notamos abajo). Pueden haber errores en el ensamble. Puede haber errores en el diseño o selección de componentes. Una partida en particular de componentes puede ser defectuosa. El propósito de las pruebas beta, particularmente para productos de gran volumen, es descubrir estos problemas, mucho antes de la producción en masa, analizar las fallas completamente, y entendiendo la raíz o causa original de la falla, ser capaces de eliminar o prevenir dicho problema en las unidades de producción. Si se encuentran con algun problema de hardware, la OLPC puede pedirles que retornen la máquina para un rápido análisis de la falla; haremos lo posible para remplazarla lo más rápido posible.

Components that are fine on paper, may not work well in practice, either by defects in the design of the components or in their use. Beta testing is also used to test different manufacturer's components. Whenever possible in high volume products, components are "multiple-sourced", and the same nominal kind of part from different manufacturers tested for compatibility. This is to ensure steady supply, even if a particular manufacturer later starts having manufacturing problems, alternatives will be available. Examples in our hardware include camera supplier, RAM supplier, PCB supplier, to name just a few. On the ATest boards, for example, we discovered several components that we do not want to use in production, and we can expect similar issues during BTest. A component's design may be new, and have its own design or manufacturing problems to be resolved (e.g. the writing pad problem we note below). Errors can be made in assembly. Errors can be made in design or component selection. A particular lot of components may be defective. The purpose of beta test, particularly for a high volume product, is to discover these problems, long before volume production, analyze the failures completely, and, by understanding the root cause of each failure, be able to eliminate or prevent these problems in the production units. If you have a hardware problem, OLPC may ask you to return the machine quickly for failure analysis; we will do our best to get you a replacement promptly.

Esperamos que ingresen rápidamente cualquier problema que encuentren con el hardware o software en nuestro sistema de rastreo de errores, con el fin que los problemas puedan ser rastreados y resueltos. Por favor, incluyan la version del firmware que estan usando—visible en la segunda linea cuando se enciende la maquina: ej: "OpenFirmware CL1 QA62 Q2A"; el QA62 is la version de firmware—el build del sistema operativo—visible al final del proceso de booteo—y el número de serie de su máquina—que se encuentra debajo de la batería; ya que eso nos permitirá analizar el problema y resolverlo.

Si bien el registro por duplicado de errores y bugs es casi inevitable, el buscar y revisar previamente la posibilidad de que ya haya sido registrado no ayudará enormemente. Los problemas no pueden ser resueltos si no sabemos de ellos, o que tan frecuentemente saltan; si encuentra un problema claramente el duplicado de otro, es útil saber que tan frecuente es que ocurre, o cualquier otro detalle extra. Agregue dicha información a los reportes de errores. Preferimos que erren de más en el reporte de errores, y no por menos. Un patrón puede surgir entre los reportes o comentarios de un error, o quizás tengamos una mejor idea de que tan severo es el problema y esto nos permite poner prioridades para su resolución. Los errores son buenos (Bugs are good). El error es mucho más fácil de arreglar ahora que después.

We expect that you will quickly enter new hardware and software problems you encounter into our bug tracking system, so that the problems can be tracked and resolved. Please include the firmware version you are using -- displayed at power on time on the second line: e.g. "OpenFirmware CL1 QA62 Q2A"; the QA62 is the firmware version--the operating system build number--which is displayed at the end of the boot process--and the serial number of your machine--found under the battery; this will help us analyze your problem and resolve it. While duplicate bug entries are inevitable, searching to see if the problem has already been reported will be very helpful to us. Problems cannot be fixed if we don't know what you encounter, or how often they are encountered; if you find clearly the same problem as some one else, it is still helpful to know how often it is occurring, or any additional details you know. Add such information to the bug reports. Err by too much reporting, rather than too little. A pattern may emerge among the reports or comments on a bug, or we may have a much better idea how severe a problem is and be able to better prioritize its resolution. Bugs are good. Each bug is much easier to fix now than later.

Hardware

Guía de Usuarios para el hardware

Modo eLibro
EBook Configuration

Vista inferior
Bottom View

Estan usando un sistema bajo pruebas, mucho antes de cuando se tendría la oportunidad de usar un producto comercial "normal". Esto es para permitir las pruebas tanto de hardware como de software desde un principio, dado que nuestro sistema es significativamente diferente a las laptops convencionales (ej: la pantalla, administración de energía, durabilidad), y será usado en ambientes muy diferentes. Se podrá ver "tras bambalinas" (y ser parte) del proceso que los fabricantes de sistemas les ocultan: lo bueno, lo malo y lo feo del proceso de debuggeo del hardware y software.

La imagen a la derecha ubica la mayoría de las características de la máquina. Para abrir la máquina se debe primero destrabar las antenas (girándolas) y despues abrirla.

Para rotar la pantalla y transformarla a modo eLibro (eBook), la pantalla debe estar a 90 grados en su posición vertical. Solo puede girar en una de las dos direcciones hasta el punto en el cual la pantalla puede nuevamente bajarse sobre el teclado.

La batería se encuentra en la parte inferior, debajo de la pantalla y teclado, y se libera usando dos trabas deslizantes como se puede observar en la imagen inferior. También se puede ver la ranura para la SD calaramente. Nota: el plástico tendrá una textura en versiones posteriores de modo tal que la superficie no sea tan brillante.

You are using a system during test, well before when you would have the opportunity to use a "normal" commercial product. This is to allow both hardware and software testing to start, since our system is significantly different than conventional laptops (e.g. the screen, power management, ruggedness), and will be used in very different environments. You will see "behind the curtain" (and be part of) the process that computer system manufacturers hide from you: the good, the bad, and the ugly process of hardware and software debug.

The picture on the right locates most of the features of the machine. To open the machine you must first unlatch the antennae and then lift it open.

To rotate the screen to transform to ebook mode, the screen must be in the 90% upright position. It can only rotate one of two directions to the point where the screen can again be closed down over the keyboard.

The battery pack is located under the screen underneath the keyboard, and is released by two slide latches as seen in the lower thumbnail. You can also see the SD slot clearly. Note: the plastic will be textured in later builds so the surface of the machine will not be shiny.

Tipos de Placas ATest

Tenemos aproximadamente unas 500 placas "ATest" de desarrollo armadas, con el fin de impulsar rápidamente desarrollos en la comunidad libre y open-source así como lo países iniciales. Las cantidades de esta generación de placas es limitada ya que no disponemos de las facilidades de pruebas de producción. Estas son placas peladas. En este momento todavía disponemos de un número limitado de ellas, y probablemente tendremos más a medida que los sistemas BTest las remplacen.

La especificación de hardware esta terminada.

Hay varios tipos de placas ATest:

• 30 Pre ATest PCBs, que han sido armadas y distribuídas.
• 20 ATest PCBs, que han sido armadas y distribuídas.
• 485 ATest PCBs, que han sido armadas y distribuídas por medio de Brightstar. Estas pueden ser diferenciadas de las primeras 50 porque tienen un código de barras con el número de serie en ellas.

We've had approximately "ATest" 500 developer boards built, to jump start serious development in the free- and open-source software community and the initial deployment countries. Quantities of this generation of boards is limited as we do not have production test fixtures. Note that these are bare printed-circuit boards. At this time, we still have a limited number of boards available, and some more may become available as BTest systems replace many uses of ATest boards.

The hardware specification of these boards is set.

There are a number of ATest board types in the wild:

• 30 Pre A-Test PCB, which have been built and distributed.
• 20 A-Test PCB's, which have been built and distributed.
• 485 A-Test PCB's, which have been built and are being distributed through Brightstar. These can be distinguished from the first 50 boards in that they have serial-number barcodes on them.

Estas placas no tienen chips DCON y en su lugar tienen un conector VGA estándar como el de cualquier computadora de escritorio o laptop. Esperamos que las placas de producción tengan contactos para un conector VGA pero no el conector en si. Adicionalmente, las placas Pre-ATest tienen conectores mini-pci; en las placas ATest, estos conectores mini-pci han sido eliminados; los contactos permanecen y probablemente sean incluídos en las placas de producción.

Las placas ATest incluyen un socket para el chip de ROM para el desarrollo de la BIOS; este socket no se encontrará en la versión de producción. El socket se encuentra vacío; la BIOS esta almacenada en el chip flash serial que se conecta por medio del controlador embarcado. El proceso para actualizar el flash serial bajo Linux no se encuentra disponible y por el momento involucra bootear DOS y actualizar el chip de flash usando un utilitario de Quanta. Salvo que se encuentren directamente involucrado en el desarrollo de la BIOS, debe mantenerse alejado de las actualizaciones de la BIOS hasta que sea anunciado por las personas responsables de la OLPC o trabajando en su nombre.

Por el momento, todo el hardware se considera en funcionamiento (habiendo sido probado), pero no todos los pilotos (drivers) bajo Linux. El piloto de la inalámbrica está siendo totalmente rediseñado.

Ver: Notas sobre el uso de la placas de desarrollador OLPC

These boards lack DCON chips and instead come with the standard VGA connector you'd find on the back of a desktop or laptop computer. We expect that production boards may ship with pads for VGA connectors, but not the connector itself. Additionally, the Pre-A-Test boards have populated mini-pci connectors; on the A-Test boards, these mini-pci connectors have been left off; the pads are included and will probably be included on production boards.

The A-Test boards include a socketed ROM chip for BIOS development; this socket will not be on production boards. The sockets are empty; the BIOS is stored in the serial flash chip that is interfaced via the embedded controller. The process for updating the serial flash under Linux is not yet available and at the moment involves booting DOS and updating the flash chip using a utility from Quanta. Unless you are directly involved in BIOS development, you should stear clear of BIOS updates unless and until instructed by responsible people working on behalf of OLPC.

At this time, the hardware is all believed to work (having been tested), but not all drivers are working properly under Linux. The wireless driver is being completely revamped at the moment.

See: Notes on using the OLPC developer boards.

No esperen

1. Monitor o pantalla plana
2. disco, DVD, CD o discos-USB
3. teclado o ratón
4. concentradores (hubs) USB con alimentación que pueden ser requeridos por algunos periféricos
5. adaptadores Ethernet USB
6. otros dispositivos de entrada

Esperamos que sean capaces de procurarse de ellos localmente.

1. Monitor or flat panel
2. disk, DVD, CD or USB drives
3. keyboard or mice
4. powered USB hubs that may be needed for use with some peripherals
5. USB ethernet adaptors
6. other input devices

We expect you have or can acquire these locally.

Expectativas para la Máquinas BTest

Por favor léan cuidadosamente las Notas de Lanzamiento BTest-1 o las Notas de Lanzamiento BTest-2 y las Notas de demostración.

Si recibe una/s máquina/s BTest, espere recibir también:

1. uno o más sistemas BTest, con teclados localizados de haberlos
2. un adaptador de corriente para cada máquina (en la medida de lo posible y nuestra habilidad con la bola de cristal)
3. una batería para cada máquina
4. alguna versión del software cargado ya sea en fábrica o por la OLPC: piense en realizar una actualización a la última versión a su llegada. El proceso ha sido simplificado en extremo con la Imagen de Reinstalación Automática.

Please carefully read the BTest-1 Release Notes or BTest-2 Release Notes and the BTest-1 Demo Notes.

If you get a BTest machine(s), expect to get (a) box(s) with:

1. one or more BTest systems, with localized keyboards if available
2. one AC power adapter for each machine (to the extent possible by our logistics and crystal ball gazing) which will have the right plug type for your country if available
3. one battery pack for each machine
4. factory or OLPC pre-load of some version of the software: you should plan to immediately update the software to a current version upon arrival. This has been made extremely easy with the Autoreinstallation image.

Expectativas para Placas ATest

1. una placa 'pelada' ATest OLPC, en su bolsa anti-estática protectora, con advertencia sobre estática, y un número de serie tanto en la caja como la placa.
2. un adaptador de corriente (enchufes planos EE.UU.), capacidad de 15 Watts.
3. un adaptador RS-232 DE-9 macho para uso de consola serial y debuggeo.
4. una bolsita plástica con pies separadores para la placa, junto a un diagrama mostrando donde deben ser insertados.
5. un par de antenas 802.11, que deben ser conectadas a la placa antes de su uso.

Expect to receive (a) box(s) with:

1. one bare OLPC A-Test board, in a static protective bag, with static warning, with serial number both on the box and on the board.
2. one power supply brick (U.S. plugs), 15-Watt capacity. Note that Sony power bricks should also work fine, and that if you can find the connector (the Sony appears compatible) you can use many different DC voltages.
3. RS-232 cable adapter to DE-9 male connector for serial console use and debugging
4. a small plastic bag with standoffs for the board, along with a diagram showing where they should be inserted
5. one pair of 802.11 antennae, which will need to be connected to the board before use.

Hosting de Proyectos

Si su interés es principalmente el desarrollo a nivel de sistema o codificación de aplicaciones, entonces únase a alguno de los proyectos en nuestro Wiki de Desarrollo. Disponemos de mucha mas flexibilidad, ancho de banda y CPU que las alternativas como SourceForge, y su proyecto no se encontrará sepultado entre los miles de otros proyectos totalmente irrelevantes a la OLPC. Si su proyecto tiene aspectos que se relacionan con la OLPC, pero es principalmente parte de algún otro proyecto (ej: GTK+, X11), estaremos contentos de proveer recursos relacionados mas limitados, tales como rastreo de bugs (bug-tracking) y nuestro wiki.

If your interest is primarily on doing some systems level or on applications level coding, then join one of the projects on our Hosting Wiki.

We have much more flexibility, bandwidth and CPU available than alternatives like SourceForge, and your project won't be as lost among thousands of other projects unrelated to OLPC. If your project has aspects related to OLPC, but is primarily part of some other project (e.g. GTK+, X11), we're also happy to provide more limited OLPC

related facilities, such as bug tracking and our wiki.

Cronograma del Hardware

En esta primera generación de placas, a la cual llamamos placas ATest, el hardware es completamente funcional con la excepción que el video es VGA, en vez de utilizar la pantalla plana con el chip DCON de los sistemas BTest.

Las máquinas embaladas BTest-1 fueron armadas en Noviembre 2006. Los sitemas BTest-1 son totalmente funcionales, pero usan una Altera FPGA en lugar del CaFE ASIC que esta presente en versiones posteriores, para la interfaz la memoria flash NAND, cámara, y SD. Este FPGA tiene un rendimiento inferior y un mayor consumo que el del CaFE ASIC. Otra versión (BTest-2) fue hecha a fines de Enero 2007 usando CaFE ASIC. La tercera version (BTest-3), en mayor volúmen, saldrá durante el otoño del sur (primavera del norte). Esta última versión BTest es el primer punto donde se las pruebas con chicos comienza a tener sentido, a medida que el software madure.

In this first generation of boards, which we call A-Test boards, the hardware is fully functional except that video is VGA out, rather than using a flat panel with the DCON chip which appears in the BTest systems. Packaged BTest-1 machines were built in late November. The BTest-1 systems are fully functional, but use an Altera FPGA in place of the CaFE ASIC which is present in later builds, for NAND flash, camera, and SD interfaces. This FPGA has lower performance and consumes much more power than the CaFE ASIC does. Another build (BTest-2) occurred in late January using the completed CaFE ASIC. The third BTest-3 build, in larger quantities, will sometime in the spring. This final BTest build is the first point where working with children starts to make sense, as the software matures.

Metas

Nuestras metas variarán a medida que el hardware madure. Para los sistemas BTest necesitamos la mayor colaboración en:

• administración de energía en los pilotos de dispositivos (device driver pilots): para nosotros cada joule cuenta, y un simple "oh, tenemos la mayor parte del chip apagada, quizas" no basta. Queremos saber exactamente que cada posibilidad de ahorro de energía ha sido realizada, y que el suspender/resumir sea ultra-estable y espeluznantemente rápido.
• suspender/resumir rápido: debemos ir más allá del acutal estado del arte como fue discutido en la cumbre de administración de energía.
• operación modal: si ciertas aplicaciones estan a pantalla completa, el sistema debe automáticamente suspenderse/resumirse cuando este 'libre' (idle) más allá de cierto tiempo breve.
• manejo de velocidad de pantalla variable: (alias: cambio de modo al paso), nuevamente, ahorrar energía.
• inalámbrica: estaremos usando una malla de red. La experimentación en serio de este área se impone, sacudir a los pilotos (drivers) y obtener experiencia de su comportamiento bajo varias condiciones (ej: áreas rurales con bajos niveles de ruido, areas metropolitanas congestionadas). Comprendemos que para realizar pruebas en serio, varias placas son necesarias. Por favor, sean realistas en sus expectactivas: dos placas no son relevantes; doscientas no pueden ser entregadas.
• optimizaciones del compilador: si eres un genio de compiladores, tenemos entendido que el Geode carece de un back-end scheduler lo cual limita su rendimiento, particularmente en punto flotante. Nos encantaría ver algún trabajo en este área que beneficiaría a todos.
• operación sin tic: existen parches fuera del árbol para ser integrados en Linux que le permitirían funcionar sin tics periódicos; hemos estado experimentando, y si bien nuestro ritmo de tics es uno de los más bajos observados en un sistema Linux, puede y debería descender aún más. Nada en el sistema debería ser poleado (polled)!
• interacción entre administración de energía y la interfaz: las aplicaciones necesitan estar al tanto de su consumo energético y requerimientos, e informar al sistema de ello mejor.
• el OOM (memoria insuficiente—out of memory) es naive, para decirlo suavemente.
• optimización de Sugar: si bien el ambiente de Sugar será mucho mas rápido tan pronto como usemos el Python 2.5 reconstruido, se requiere trabajo, particularmente en el arranque de Python.
• Sugarización de aplicaciones: hay muchas aplicaciones que con un mínimo de esfuerzo se puede lograr que funcionen correctamente en Sugar para los chicos. Los invitamos a elegir una y ayudar.
• pantalla remota: hemos empezado a trabajar en un proyector de bajo costo. El facilitar el uso de aplicaciones remotamente es un plus. Existen varias formas (y dificultades) para hacerlo, con lo cual hay técnicas inmediatas, así como también formas mucho mas sofisticadas para hacer evolucionar el "estado del arte del X Window System", dependiendo de tus habilidades y preferencias.
• aplicaciones educativas de cualquier tipo
• herramientas de servidor para las escuelas y soporte de las laptops

Estamos seguros que sos más brillante que nosotros y has visto lo que nos falta en la lista...

Our goals will vary as the hardware matures. For the BTest systems we need the most help on:

• power management in the device drivers: for us, every joule matters, and a simplistic "oh, we mostly have most of a chip turned off, maybe" isn't good enough. We want to know that every possible power savings has been realized, and that suspend/resume is rock solid and blindingly fast.
• fast suspend/resume: We must go beyond the current state of the art as discussed at the power management summit.
• modal operation: if certain applications are full screen, the system should automatically suspend and resume whenver idle for more than a short period.
• variable speed display driving: (aka: mode change on the fly), again, to save power.
• wireless: we will be deploying mesh networking. Serious experimentation in this area is in order, to shake down the drivers and to gain experience in its behavior in differing conditions (e.g. rural areas with low noise characteristics; busy metropolitan areas). We understand that to do serious tests, more than a single board will be needed. Please be realistic in your expectations: two boards is not interesting; two hundred boards can't be provided.
• compiler optimization: if you are a compiler wizard, we understand that the Geode lacks a specific back end code scheduler, which limits performance, particularly FP performance. We'd love to see work go on in this area which would help everyone.
• tickless operation: there are patches out of tree about to be integrated into Linux that allows Linux to function without periodic tics; we've been experimenting, and while our tick rate is probably the lowest yet observed on a Linux system, it can and should go further. Nothing in the system should poll!
• power management desktop interaction: applications need to be better aware of their power usage and requirements, and communicate this better to the system.
• The OOM (out of memory) killer is naive, to say the least.
• Sugar optimization: While the Sugar environment will get substantially faster as soon as we deploy a rebuilt Python 2.5, further work, particularly on python startup, is in order.
• Sugarizing applications: There are many applications that with minimal work can be made to work well in the Sugar environment for young children. We encourage you to pick one and help out.
• Remote display: we have begun work on a low cost projector. Making it easy to remote applications is well worthwhile. There are a number of ways (and difficulties) of doing this, so there are immediate techniques available, along with much more sophisticated ways of advancing the "state of the X Window System art", depending on your inclinations and abilities.
• Educational applications of all sorts.
• Server based tools for schools and support of the laptops.

We're sure you are brighter than we are and have seen what we're missing in the above list.

Se puede contribuir un muchas áreas donde no se necesita del hardware. Por ejemplo:

• uso de memoria: muchas aplicaciones y herramientas desperdician y/o pierden memoria. Arreglar esto ayudará a todos y es mucho mas fácil en sistemas convencionales.
• optimización de rendimiento: el arreglar el uso de memoria usualmente resulta en código más rápido.
• adaptación de herramientas: la resolución efectiva de la pantalla cambia según si se está en modo color o blanco y negro. Las herramientas y aplicaciones necesitan adaptarse, y los temas que funcionen correctamente.
• Interfaz: la mayor parte del trabajo sobre la interfaz puede ser llevado a cabo en Linux convencionales. Pero nuestro sistema también dispone de un modo eLibro (eBook), con cuatro botones direccionales y el enter. Aplicaciones claves deberán ser actualizadas para trabajar correctamente en este entorno (ej: evince, navegador). Probar el comportamiento de las aplicaciones en escala de grises y realizar los cambios necesarios sería muy útil.
• aplicaciones: no falta decir más. El ambiente "Sugar" bajo desarrollo puede correr en computadoras convencionales, y muchas aplicaciones deberían ser simplificadas y optimizadas para nuestros sistemas. Nuestra principal audiencia son los chicos pequeños en vez de los escolares mayores que han sido los usuarios principales de computadoras
• soporte para IPv6, servicios de descubrimiento, que son muy importantes para nosotros.
• Seguridad: SELinux u otras tecnicas pueden ser formas de protegernos contra Ataques-Día-0; al ser un enorme ecosistema de máquinas similares, es algo para pensar seriamente.

Daremos preferencias a propuestas de hardware que requieran acceso a hardware OLPC para avanzar; pedidos BTest deberían necesitar mobilidad del sistema y enfocarse en la GUI y aplicaciones que requieran las nuevas pantallas.

You can contribute in many areas which do not require hardware. For example:

• memory usage: many applications and toolkits waste and/or leak memory. Fixing these will help everyone and most easily done on conventional systems.
• performance optimization: fixing memory usage will usually result in faster code.
• toolkit adaptation: the display's effective resolution will change from grayscale to color mode and back. Toolkits and applications need to be able to adapt, and themes that work well in both modes verified.
• UI: most of the user interface work can be done today on conventional Linux desktops. But our system will also have an e-book mode, with dual 4-direction keys and enter. Key applications will need updating to work well in this environment (e.g. evince, web browser). Testing application's behavior under grayscale conditions and making whatever changes are needed would be helpful.
• Applications: goes without saying. The "Sugar" environment under development can be run on conventional desktops, and many applications should be simplified and optimized for our systems. Our primary audience are younger children, rather than the middle and high school students that have been the primary child users of computers.
• IPv6 support, and service discovery, which are very important to us.
• Security: SELinux or other techniques may be a way to protect against Day 0 attacks; as a large ecosystem of similar machines, it is something worth seriously worrying about.

We will give preference for hardware to proposals that require access to the OLPC hardware to make progress; BTest requests should either require mobile use of the systems and focused on GUI and applications where access to our new screen is needed.

Cualificaciones

Estamos buscando personas capaces e interesadas en ayudar al desarrollo. Los requisitos necesarios dependerán enormemente de las áreas donde se desee trabajar: por ejemplo, la gente que trabaja en BIOS y booteo debe ser "amiga de los electrones", y no asustarse de JTAG o debuggeos similares.

La mayor parte del desarrollo de pilotos (drivers) involucra las habilidades normales de debuggeo de pilotos, aunque el tema de administración de energía puede ser más desafiante que la media.

El desarrollo del sistemas de ventanas requiere experiencia con X, y así sucesivamente.

We're looking for people able and interested in helping in development. The qualifications needed depend strongly upon where you are interested in working: for example, people working on BIOS/boot paths should be seriously "friends of the electrons", and not scared of JTAG and similar kinds of debugging.

Most driver work takes normal driver debugging skills, though getting power management right can be more challenging than most driver development.

Window system development requires X experience, and so on; applications, experience in developing those or similar applications, and so on.

Como contribuir

dev.laptop.org

La OLPC tiene un ambiente de desarrollo para soportar (host) proyectos de desarrollo tanto de software como de contenido. En la medida de lo posible, los invitamos a desarrollar upstream en los proyectos originales. Sin embargo, algunos proyectos son específicos a la OLPC, o necesitan de modo temporal recursos de desarrollo mientras son adaptados a nuestros sistemas. Un ejemplo es el Linux kernel tree donde mantenemos código OLPC antes de que este listo para ser incorporado al kernel central de Linux. Esto nos permite compartir nuestro trabajo en varios aspectos del kernel de Linux, al mismo tiempo que seguimos bastante de cerca al de Linus, con el objetivo de ayudar en el upstream del código.

Estamos dispuestos a proveer gustosamente recursos de hosting en este sistema a aquellos con necesidades relacionadas con la OLPC.

OLPC runs a development environment for hosting software and content development projects. As much as possible, we encourage you to do your development upstream in the original projects. However, some projects are OLPC specific, or need temporary development resources while being staged for our systems. An example is the Linux kernel tree where we maintain OLPC code before it is ready to submit to the main Linux kernel. This lets us easily share work on various aspects of the Linux kernel, while tracking Linus' tree reasonably closely, to aid in upstream submission of code. We are happy to provide hosting resources on this system to those with OLPC related needs.

Sistemas de Administración de Código Fuente

Dado que tanto el kernel como el X Window System utilizan git como su administrador de código fuente, y nosotros trabajamos sobre ambos, git es nuestra elección para SCM (Source Code Management). Pueden ver los árboles git en dev.laptop.org.

El kernel Fedora es mantenido en ese proyecto. Para BTest-1 estamos usando un kernel del árbol olpc-2.6 en vez del kernel Fedora. Esto puede cambiar en un futuro.

RPMs fuente para la mayoría de las versiones específicas para la OLPC también están disponibles de RedHat.

Since both the kernel and the X Window System use git as their development source code management systems, and we work on both, git is our SCM of choice. You can see the git trees hosted at dev.laptop.org.

The Fedora kernel is maintained at that project. For BTest-1 we are using a kernel from the olpc-2.6 tree, rather than a Fedora kernel. This may change at some future date.

Source RPMs for most OLPC-specific versions of code are also available from RedHat.

Sistema de Monitoreo de Bugs y Errores

La OLPC mantiene un sistema de rastreo de errores llamado trac, que también posee su wiki (aunque desaconsejamos su uso como tal). Para usarlo, es necesario crear una cuenta propia. Se pueden realizar consultas sobre bugs y errores pendientes (o cerrados).

OLPC maintains a bug tracking system called trac, which is also a wiki (though we discourage use of it as a wiki). To use it, you need to create an account for yourself. You can query it for open (or closed) bugs.

Wiki

Este Wiki público esta disponible para el escribir sobre cualquier idea o esfuerzos relacionados con el proyecto; o para categorizar y desarrollar contenido para las laptops. Algunas páginas (visiblemente marcadas) son mantenidas por el equipo principal de la OLPC. Preferimos este wiki al de Trac para los articulos.

The main public OLPC wiki is available for use to write about any ideas or efforts related to the project; or to categorize and develop content for the laptops. Some pages (prominently marked) are maintained by the core OLPC team. We prefer this wiki to the Trac wiki for most writing.

Direcciones de Organizaciones Claves

La OLPC depende de una serie de tecnologías claves y proyectos, incluyendo:

OLPC depends on a number of key technologies and projects, including:

• Gnome
• Matchbox
• GTK+ toolkit, Pango Text Layout Library
• Cairo Graphics Library
• X Window System
• Linux Kernel
• Gecko Rendering Engine of the Mozilla Foundation
• AbiWord word processor
• eToys

Contactos

Mail

Para contactarnos via e-mail, ver contactos.

Para el correo de superficie, envie a:

One Laptop per Child

P.O. Box 425087

Cambridge, MA 02142

Estados Unidos

For e-mail contacts, see Contact OLPC.

Snail mail please sent to:

One Laptop per Child

P.O. Box 425087

Cambridge, MA 02142

USA

Chat IRC

Principalmente usamos la mensajeria instantanea IRC, que puede ser encontrada en irc.freenode.net en los canales #olpc y #sugar.

We primarily use IRC instant messaging, and can be found on irc.freenode.net, #OLPC and #sugar channels.

Instalación de Software

Al Recibirla

Nota: cuando reciba por primera vez un sistema, haga inmediatamente una actualización a la versión acutal, tal como esta documentado bajo la seccion de NAND Flash y Re-instalación de la BIOS más abajo.

La BIOS (LinuxBIOS + OpenFirmware como booteador), Linux en sí mismo, y el software OLPC son instalados en los sistemas BTest en la fábrica; sin embargo, su intención es para realizar pruebas en el sistema y realizar prácticas para su uso final. En el tiempo en que le damos a Quanta el sistema para su fabricación y el arribo a sus manos, un número importante de errores y bugs habrán sido corregidos o eliminados.

Note: when you first receive the system, please immediately update the system to current software, as documented below in the NAND Flash and BIOS Re-installation section. The BIOS (LinuxBIOS + OpenFirmware as bootloader), Linux itself, and the OLPC software stack were installed at the factory on the BTest systems; however, this is intended as testing of the systems and practice for later rather than for serious use. In the time since we gave the system to Quanta for manufacturing until you receive a system, a number of key bugs have been fixed, and other problems resolved.

Actualización del Sistema

Cuando reciba el sistema, y ocasionalmente de ahí en más durante las pruebas beta, el software y/o el firmware (BIOS), pueden necesitar ser actualizados. Esperamos que durante la distribución el agregado de software y contenido local o un remplazo completo del software instalado en fábrica sea algo normal.

When you receive the systems, and occasionally afterwards during beta test, the software and/or firmware (BIOS), may need to be upgraded. We expect that during deployment addition of local software and content or total replacement of the factory installed software will be normal.

Como actualizar la imagen del SO en un Sistema BTest

Re-instalación de la BIOS y NAND Flash

Siga las instrucciones en imagen de auto-reinstalación; esto facilita enormemente la actualizacion de varias máquinas, tan fácil como insertar una llave USB y rebootear el sistema.

(Un resumen del procedimiento se detalla a continuación. Actualizar el Sistema Operativo en la flash NAND consta en tres pasos:

1. Descargar un archivo zip
2. Des-zippear sus contenidos, creando un directorio llamado "boot" en la llave USB o disco.
3. Enchufar la llave o disco USB y rebootear.

Los scripts Forth usados por el Open Firmware actualizan la BIOS SPI flash de booteo, corregir un error en los datos de manufactura, e instalan una imagen sobre la flash NAND, sin necesidad de intervenir. Ha sido simplificado lo más posible).

Follow the autoreinstallation image directions; this makes updating many machines very easy, as easy as inserting a USB key and rebooting the system.

(A summary of the procedure is outlined below. Upgrading the OS on NAND flash is now a three step process:

1. Download a zip file;
2. Unzip the contents, creating a directory named "boot" on a flash key or disk drive;
3. Plug in the USB flash key or USB disk and reboot.

The Forth scripts used by Open Firmware will update the SPI BIOS bootflash, fix the manufacturing data error, and installs an image onto NAND flash, without further intervention. It is has been made as simple as possible.)

Como Instalar Linux en la Flash o Disco

(Las instrucciones detallas se encuentran aquí: imagenes del SO).

El primer paso es obtener un disco USV, instalar una imagen del SO al disco, y bootear la laptop del disco USB. Aca se encuentran las instrucciones para instalar una imagen del SO en un disco USB. Una vez que la laptop haya booteado del disco USB, la imagen que se encuentran en la laptop puede ser actualizada (esto solo se recomienda cuando se esta actualizanto un viejo sistema ATest corriendo sobre una BIOS vieja). Aca se encuentran las instrucciones para actualizar la imagen del SO interna.

Actualizaciones manuales de la BIOS y el firmware de la inalámbrica deberían ocurrir de forma automática cuando se utiliza una nueva versión de la imagen del SO.

(Detailed instructions are here: Build_images.)

The first step is to obtain a USB disk, install an OS image to the disk, and boot the laptop off of the USB disk. Instructions for installing an OS image to the USB disk can be found here. Once the laptop has booted off the USB disk, the image that's on the laptop itself can be upgraded (this is only recommended when upgrading an old ATest system running an old BIOS). Instructions for upgrading the internal OS image can be found here.

Manual updates to the BIOS and wireless firmware should happen automatically when using a new OS image.

Como inscribirse

Por favor envien un mail a developer at laptop dot org con la siguiente información:

1. Name
   / Nombre
2. Email address
   / Correo electrónico
3. Employer (if any), University/College
   / Empleador (si se aplica), Universidad, Centro
4. Shipping address and instructions
   / Dirección de envío e instrucciones
   1. name,
      / nombre
   2. address, (cannot be a post office box)
      / dirección (no puede ser una casilla de correo postal)
   3. city,
      / ciudad
   4. postal code,
      / código postal
   5. country,
      / país
   6. telephone number, (yes, we really need this for the shipping companies)
      / número telefónico (si, realmente necesitamos esto para las compañias de envio)
   7. any special instructions
      / cualquier instrucción particular
5. Description of your plans for the machine(s). Concrete proposals with defined outcomes are much more likely to result in a system than "it would be cool to play with these and demo them all over for you".
   / Una descripción del plan de utilización de la/s máquina/s. Propuestas concretas con resultados definidos son mucho más probables de resultar en un sistema que "estaría bueno jugar con una de estas y hacer demos para Uds."
6. Quantity of machines desired
   / Cantidad de máquinas deseadas
7. Description of your experience, both with hardware and software
   / Descripción experiencia personal, tanto en hardware como software

Suponiendo que el pedido es aprobado, un mensaje de correo será enviado con la información del envío, o un lo siento. Cabe destacar que ciertos pedidos son mas viables y aplicables más tarde en el proyecto, cuando dispongamos de más máquinas.

Please send mail to the developer at laptop dot org email alias with the following information:

1. Name
2. Email address
3. Employer (if any), University/College
4. Shipping address and instructions
   1. name,
   2. address, (cannot be a post office box)
   3. city,
   4. postal code,
   5. country,
   6. telephone number, (yes, we really need this for the shipping companies)
   7. any special instructions
5. Description of your plans for the machine(s). Concrete proposals with defined outcomes are much more likely to result in a system than "it would be cool to play with these and demo them all over for you".
6. Quantity of machines desired
7. Description of your experience, both with hardware and software

Presuming your request is approved, a mail message will be sent to you with shipping information, or a regret. Note that some requests may be more feasible and applicable later in the project, when we more machines available.

Máquinas en desuso

Si en algún momento dejan de tener tiempo para contribuir al esfuerzo de la OLPC, por favor sean tan amables de retornar su sistema o placas para su redistribución.

If you no longer have time to contribute to the OLPC effort, please be so kind as to return your system or board for redistribution.