Feature roadmap/Page of all features that target 9.1.0

• XO release 8.2 contains a list of packages (some forked and some not). For must 9.1.0 we must update all packages to their Fedora 10 versions and re-apply XO specific changes, as needed, to the new Fedora 10 package.
• Every package should also be included upstream. If that has not been completed in time for this release, every package must at a minimum have a plan for how it will get included upstream. This must include at a minimum an e-mail exchange with the package.
• Must measure the NAND and memory usage vs 8.2. Any significant (not precisely defined as >1%) change in memory or NAND space in comparison to 8.2, must be reviewed.
• Must not include any Fedora 9 or earlier packages (unless they haven't changed).
• Should create tools to manage forked packages better. To start with: a notification tool to let us know if a new upstream release has occurred for a package we have forked. (Scott suggestion). See also thread by Scott at: http://lists.laptop.org/pipermail/devel/2008-October/020411.html

koji latest-pkg dist-olpc4 --all

Overview. This feature is designed to address the persistent requests to run more applications. An alternative approach would be the "easy sugarization" feature above. This implementation is currently preferred because it also helps us get all the XO software "upstream". That would bring in more developers and add flexibility for XO users.

• Only needs to run Fedora applications which fit in the available NAND space, memory and CPU.
• Must run as well on the XO as they would on any other computer 433Mhz 256 MB RAM.
• Must allow switching between a Fedora 10 based spin with a conventional desktop manager and XO running Sugar, and back.
• Must fit on the XO NAND along with the Sugar based XO image with enough space left (exact amount tbd) for user data.
• Must/should? allow this on all XOs shipping with XO release 9.1.0. That is, an XO which ships with Sugar
• Must support camera, microphone, speakers, wifi 802.11 A/B/G, touchpad, Keyboard, USB interfaces, and SD interface.
• Does not need to make it easy to share files between Fedora and Sugar.
• Must not need a developer key to switch to Fedora implementation.
• Must fully support Yum.
• Must come with nnnn applications on default install (will be chosen and will be a very minimal set).
• Must boot as fast as Sugar.
• Must support upgrading the Fedora version and the Sugar version in 9.2.0 and future releases.
• Must not keep two copies of any files or libraries. Any file which is exactly the same on both Sugar and Fedora images should be used by both and should not take twice the space.

• Open issue about Security. How do we protect security and still make Fedora + "standard" window manager available? GS

• Must leave at least 200MBs free when Fedora + Desktop and Sugar are available. (GS test of new query system, not copied to feature roadmap source yet)

Sizes of recent window manager images:
[ ] awesome.dat 18-Nov-2008 02:41 334M
[ ] awesome.img 18-Nov-2008 02:40 224K
[ ] base.dat 18-Nov-2008 02:55 157M
[ ] base.img 18-Nov-2008 02:55 105K
[ ] gnome.dat 18-Nov-2008 03:24 436M
[ ] gnome.img 18-Nov-2008 03:23 293K
[ ] kde.dat 18-Nov-2008 03:58 536M
[ ] kde.img 18-Nov-2008 03:57 360K
[ ] lxde.dat 18-Nov-2008 04:20 220M
[ ] lxde.img 18-Nov-2008 04:20 147K
[ ] sugar.dat 18-Nov-2008 10:14 357M
[ ] sugar.img 18-Nov-2008 10:13 239K

One possible solution. From this thread: http://lists.laptop.org/pipermail/devel/2008-December/021904.html

• yum groupinstall "GNOME Desktop Environment"
  

I gave this a try with latest Joyride (2592), and get a couple of depsolving problems. Maybe one of the RPM ninjas on fedora-olpc-list could take a look at how we could resolve these? Alternatively, maybe we should be hand-picking the list of packages to add, since I see some deps in there we don't want, e.g.:

--> Processing Dependency: texlive = 2007-35.fc10 for package: kpathsea
--> Processing Dependency: httpd >= 2.2.0 for package: gnome-user-share

Possibly useful tool for building Fedora images: https://fedoraproject.org/wiki/Features/ApplianceTools

Kickstart file from Peter for Fedora 9: http://pbrobinson.fedorapeople.org/olpc/

• Must support Right to left (RTL) in all Sugar GUI elements.
• Must support Right to left in Write
• Must include at least two good Arabic fonts
• Must support shaping in Write and in Sugar.

Test cases:

(and at a short notice), since it is much more flexible and powerful than what we have been using till now (XKB).

• Must completely support Simplified Chinese, Nepali and Amharic.
• User experience for keyboard layout switching should not change

• Modification of relevant startup and configuration scripts for SCIM support
  • Patches in olpc-utils ensure that SCIM starts up automatically in the relevant locales
  • A separate script pre-configures SCIM, based on the mfg-data. This also ensures that SCIM recognises the XO's language switching key as the trigger to change layouts
• Language/script specific stuff
  • Proper handling of Amharic characters (<trac>8494</trac>) requires implementation of a new Amharic input method (in progress)
  • Simplified Chinese:
    • The following Fedora packages provide support for the Chinese requirement:
      • scim-pinyin
      • scim-fcitx (To be verified with the team in China)
  • Nepali support is implemented by the following Fedora package
    • m17n-contrib-nepali

• Should include translations of the following languages
  • Uyghur
  • Simplified Chinese
  • add more...
• Should have a minimum of >80 percent translation of sugar and >80 percent translations for the top 10 activities chosen by the deployment or country.

1. Power save (here after called idle suspend) should default on but the user also the option to not use it.
2. When you turn the radio off the in the network control panel it must cut off all power to the wireless chip.
3. Must rewrite the documentation on power and explain it to Frances so that she understands how to use it. (add link to existing documentation).
4. Should offer a full featured set of power options in GUI. Not critical but nice to have.
5. Idle suspend must dim the screen after 1 minute of the user not touching the keyboard or touchpad. Then after an additional 2 minutes it must change the screen completely off. Must allow setting of those values in the control panel. The only exceptions are that when the audio device is playing, when olpc-update is running.
6. Must turn the screen back on in less than 1 second after the user touches the keyboard or touchpad.
7. Idle suspend must turn the CPU off.
8. Must allow activities to override the idle suspend mode above. That is to not suspend even if the time has passed.
9. Must not lose your network connection, activity state, sugar GUI elements and collaboration (e.g. start a chat, let the XO suspsend then otehr chat person chats, that new chat text should show on the suspended XO without turning on the screen) after waking from idle suspend. Must not crash. Multicast, ARP, mDNS, the Presence Service, and collaboration must all work in the presence of autosuspend.
10. Should not turn the screen on unless the user interacts with the keyboard.
11. Wireless chip must respond to ARP requests when in Idle Suspend mode.
12. Screen must not flicker on resume.
13. Should allow users to disable the mesh: reduces power consumption of the WiFi chip, allows the WiFi chip to enter power-save mode, and most importantly, allows lid-closed suspend to totally power off the WiFi chip. <trac>6995</trac>
14. Should put the EC into deep sleep when in a lid-closed suspend. This will cut its power from about 60ma to about 20ma (check with rsmith), which would further increase the duration of a lid-closed suspend before the battery drains.
15. (* not likely to make 9.1 with current resources *) Should improve cpu idle detection. Currently we can't auto-suspend very often (only after >1 minute of no user interaction) because suspend is so heavy-handed. The cpuidle infrastructure in the kernel should be able to tell us when it's safe to suspend because no process wants access to the CPU for the next few seconds. Most of the pieces are there.
16. "Lid close" behavior will be unchanged from the 8.2.0 release; on closing the lid, the screen and wifi (if connected to an access point) should turn off, and should turn themselves back on when the lid is reopened.
17. There should be a way to enter the "lid close" sleep above using the power button; exact details are with User:pgf, who is working on the quick-power-button-press menu.

• Other related bugs found by GS on review of trac: <trac>7922</trac> and <trac>7954</trac>

<trac>9145</trac> -- Disabling the radio in control panel should power-down WiFi chip
<trac>8948</trac> -- "Turn off the wireless radio" checkbox is confusing
<trac>8424</trac> -- Sugar control panel's Network > Wireless Radio checkbox does nothing if Power > Extreme power management checked
<trac>8062</trac> -- Need a default to leave RF turned off on reboot
(8062 reminds us that as we evolve the power settings, there needs to remain one that keeps the radio off and survives reboots.)
<trac>7047</trac> -- Suspend turns radio on even if it was forced off
<trac>6995</trac> -- Mesh icon in Frame should allow Mesh to be turned off
(If mesh is off and access point is off -- and we don't support ad-hoc mode -- then the radio should be powered down, too. This would mean our interface was so intuitive that it didn't need a control-panel item to turn off the radio.)

Requirement 3 possibly addressed by edits to existing documentation:
Longer battery life and Suspend and resume.

Requirement 4 addressed by:
<trac>2765</trac> -- Need to turn off DCON after some time in idle suspend
<trac>4606</trac>

Requirement 5 addressed by:
<trac>9054</trac> -- Speed up USB resume (kernel)
<trac>7981</trac> -- EC mask setting is inefficient
<trac>8916</trac> -- Extreme Power Management doesn't unload USB for fast resumes
<trac>7384</trac> -- Manually enabled USB-disabling Power Management

Requirement 9 addressed by:
<trac>6818</trac> -- Make the multicast wakeup filter work with collaboration (Ricardo Carrano?)
<trac>7458</trac> -- Intermittent lockup on WOL

Requirement 11 addressed by:
<trac>3732</trac> -- ARP broadcasts don't wake auto-suspended laptops

Requirement 12 addressed by:
<trac>8893</trac> -- DCON flicker on resume (kernel regression; perhaps Deepak, Andres, Mitch, or Adam Jackson?)
<trac>7958</trac> -- DCON shows totally wrong image during suspend, with lots of colored noise. (Seems rare, whereas #8893 is 100% reliable, so we should go for #8893 first and get to #7953 if it still exists and we have time.)
Other:

• <trac>9055</trac> -- Create 9.1 test plans for automatic power management

• There's still a major Python bug that causes multi-threaded pyGTK2 programs to poll uselessly once a second (<trac>4680</trac>, <trac>4677</trac>). Much work was done to close it, but there is still a small sprint required to get it done. This not only reduces power use directly, but also allows the system to suspend because it doesn't appear that activities need to do some work soon.

• We have a bug if we enter suspend while audio is playing: <trac>6201</trac>. This should be fixed either with the correct kernel fix, or by refusing to suspend while the audio device is open.

Background on power draw including a break down watts used in different modes:

• XO Power Draw#The Numbers
• Per-Activity Power Usage

Significant technical actions (as suggested by John/Gnu) that could reduce the laptop's power draw:

• not to Greg - move to collaboration.
• Reduce packet traffic during sharing -- particularly multicast traffic, which loads many machines (and wakes them up from autosuspend). This will require diagnosis and improvement of the presence and collaboration protocols. Some work was done on this, after the high packet traffic melted the WiFi bandwidth in early deployments (e.g. turn on 30 laptops in the mesh, none of them can usefully get anything done), but our main response was to tell later deployments "Don't use the mesh, use access points" -- a significant reversal that we should keep working to fix.

Owners for each subrequirement as follows: Requirements 1 - 5, 7, 8, 10, owned by CJB. 6 by CJB, 9 and 11 networking team (Ricardo?), 12 Mitch and Deepak Product manger Greg, QA Joe.

http://it.jeita.or.jp/mobile/e/index.html

• The power button is currently underutilized. It should allow either shutdown or suspend of the laptop, with the help of an on-screen dialog or menu.
• Make sure that the clean power button shutdown in 9.1 works from the Sugar nickname

Summary of that thread:

Currently it is much easier to "crash" the laptop (by holding the power button down) than it is to shut it down cleanly. while journalled filesystems can recover from this on the next boot, application writes in progress might not.

Pushing the power button on the laptop should present a menu or dialog allowing shutdown. as a strawman UI, the pushing the button should result in a simple dialog that looks like:

       The laptop will suspend in 5 seconds.
          Shutdown, Suspend Now, Cancel

Or, perhaps more simply:

       The laptop will suspend in 5 seconds
       Push the power button again to shutdown.

It's probably important that existing behavior (i.e., pushing the button causes a suspend) not be interfered with too much. not using extra keys, nor needing the mouse, is also desirable.

This will need to interact with lid-close in a sensible manner. namely:

• Closing the lid (and therefore suspending) while the 5-second delay is still pending should not cause unexpected behavior when the laptop reawakens, and
• Closing the lid after a shutdown has commenced should not interrupt or halt the progress of the shutdown.

Ideally, power button "menu" should work indepently of sugar (so that it behaves correctly with other window managers), and even independently of X11, so that it works when the user is at a console prompt.

Ideally, if Sugar is running, the first press (which brings up the prompt) would in parallel cause the foreground activity to save its state (as if it was going into the background), speeding up either the subsequent suspend, or the subsequent shutdown.

• After a key has been generated for a country, must not require them to contact OLPC for any further information to make the signed image.
• Can allow deployments to sign with their own key or with a key delegated from us.

• Must allow activation of XOs via wireless AP connection to a School Server
• Must work with all APs which the XO can work with. In particular, must work with open, WEP, WPA and WPAv2 APs.
• Should allow activation of many receiver XOs from a source XO. That is, the same as above but with the "server" being an XO.
• Must allow addition of activation keys to the Activation Server via USB.
• Should allow addition of activation keys to the Activation Server via network access.
• Should make it possible for the deployment to perform all activation tasks without OLPC intervention.

• See also image customization feature.

The controlling idea is that when an XO is stolen it will stop working after a time (activation lease time) unless it contacts a re-leasing server (usually a School Server). For example, if an XO is stolen and taken away from its school server, after the expiration of the lease time it will no longer boot up. If the XO is stolen but still comes within range of its school server, it can still be prevented from booting if the XO information (probably serial number) has been added to a black list on the XS.

• If the laptop is stolen, and doesn't contact its local school server within some period time (activation lease time) the XO will no longer boot. This state is known as passive-kill.
• Si se roba el XO y el XO no se contacta a su servidor (XS) local de la escuela dentro de una cierta hora del perío (tiempo del arriendo) el XO va a encender (boot). Este estado se conoce como muerte-pasiva.

• When the XO boots up and contacts the XS, its lease time is extended. e.g. if the activation lease time is 30 days and it starts on November 1, then the XO boots up on November 20 and contacts the XS, it will continue functioning without contacting the XS until December 20. This state is known as activated.
• Cuando el XO arranca y entra en contacto con el XS, su tiempo del arriendo es extendido. e.g. si el tiempo del arriendo de la activaciós 30 dí y comienza el 1 de noviembre, despuéel XO arranca el 20 de noviembre y entra en contacto con el XS, écontinuaráuncionando sin entrar en contacto con el XS hasta el 20 de diciembre. Este estado se conoce como activado

• Optionally as set by the administrator, if an XO is deactivated and tries to boot up when in the vicinity of its controlling school server, then it will boot unless it has been added to a blacklist. The blacklist is a list of XOs (by serial number?) which has been entered in to the school server by its administrator. That is, the activation lease time will be automatically extended whenever the XO contacts its controlling XS, unless it has been entered in the black list. Laptops that request their new lease from the XS and find themselves in the blacklist get into a state known as active-kill.
• Opcionalmente como fija por el administrador, si un XO se desactiva e intenta boot cuando esta en la vecindad de su servidor de la escuela que controla, despuéboot a menos que se haya agregado a una lista negra. La lista negra es una lista de XOs (por número de serie?) cuáha sido entrado adentro al servidor de la escuela por su administrador. Es decir, el tiempo del arriendo de la activacióeráutomácamente cuando el XO entra en contacto con su XS que controla, a menos que no se haya inscrito en la lista negra. Laptops que contactan el XS y se encuentran en la lista negra entran en un estado llamado muerte-activa.

• Must allow setting of the activation lease time by the deployment lead (user interface required). That is, they can set it for 90 days or whatever they want. The granularity should be at 24 hours and be from 1 day to never expire. Must allow setting this once for a recurring interval (e.g. XO leases expire every 60 days).
• Debe permitir el ajuste del tiempo del arriendo de la activacióor del despliegue (interfaz utilizador requerido). Es decir, pueden fijarlo por 90 dí o lo que quieren. La granulosidad debe ser en 24 horas y ser a partir de 1 dínunca a expirar. Debe permitir el fijar de esto una vez para un intervalo el repetirse (e.g. los arriendos de XO expiran cada 60 dí).

• Must not be possible for the user to set the date on the laptop to keep it within the lease period or to force it to outside the lease management. This might mean you cannot change the date or there is no root access, or it might mean an alternate time source is used.
• Necesidad no ser posible para que el usuario fije la fecha en el ordenador portál para guardarlo dentro del período del arriendo o para forzarlo fuera de la gerencia del arriendo. Esto pudo significar usted no puede cambiar la fecha o no hay acceso a root, o puede ser que signifique que una fuente alterna del tiempo estátilizada.

Note: XO-1 hardware is limited to 1 RTC clock so we cannot really do this.

• Must support the same as described above but allow the server which determines the activation to be across the Internet. The lease management server can be in a data center managed by the deployment or on a server managed by OLPC.
• Soporte los mismos requerimientos mencionados en el ultimo punto pero permita la activacion contra un servidor conectado a Internet. El servidor puede estar en un centro de datos manejado por NOC local o en un servidor manejado por OLPC.

• Must support the same requirement as described above but allow the reset of the activation to be done via USB key. That is, when an XO's lease expires, it must be booted with the USB key containing a special code. This can be done before it expires to extend the lease.
• Soporte el mismo requisito como se describe anteriormente pero permita que el reajuste de la activación sea hecho vía llave del USB. Es decir, cuando el arriendo de un XO se expira, ése debe boot con la llave del USB que contiene un código especial. Esto puede ser hecha antes de que expire para extender el arriendo.

• Should support the ability for an XS to continuously generate new leases every nnn time as set by the user (e.g. every 2 weeks). This will allow an XS to be placed in a school and then it does not need Internet access or anyone from outside the school to continuously update the lease times.

• Should support a GUI accessible from the XO which is password protected and encrypted (aka no passwords in the clear across the network/wireless). This GUI will allow a user in the school to enter an XO by serial number or better by name and have that XO added to the blacklist (see above, essentially its lease is not renewed).

See also write up on "Actual security requirements": User:Mstone/Commentaries/Security_1 and
Server side "Blueprint" at: http://wiki.laptop.org/go/XS_Blueprints:Lease_and_update_server

• Firmware Key and Signature Formats#Version 2
• http://dev.laptop.org/~cscott/joyride-api/bitfrost.leases.crypto-module.html
• http://lists.laptop.org/pipermail/security/2008-June/000441.html

• Must allow upgrade of new XO Software via the Software Control Panel
• Must allow install from OLPC server using build name (same as olpc-update script but now in GUI)
• Must allow configuration (including setting default via the Image Customization feature) of a School Server or another server or a USB stick as the source of the image.
• Must allow setting of "latest" image when choosing what to download. e.g. on the School Server there should be a directory where you can place the "latest image". Then the XO user should be able to get the "latest image" off the school server without specifying the build number.

When imaging a new laptop or upgrading a laptop we must allow the deployment to create a custom image. This special image will allow XOs to be re-imaged via USB or over a network (via olpc-update to internet, via olpc-update to XS, via Quicker Imaging feature above). The customized image must allow configuration of the following items. These should be settable when creating a new image or when upgrading unless otherwise noted.

The ideal solution would allow a deployments to load a source XO with the OS, add anything they want to it (e.g. RPMs, activities, other content, language packs, scripts, changed configuration files, etc.) then the "click a button" and output a signed image which is a full copy of that XO (need to document anything which does not get copied exactly, e.g. factory data, user name, other?). This signed image can then be installed via any of the available mechanisms.

Cuando haciendo un imagen nuevo para el XO o haciendo una actualizacion del Software debe permitir que el despliegue cree una imagen de encargo. Esta imagen especial permitiráue XOs sea puesto víel USB o sobre una red (víla olpc-update del Internet, víla olpc-update de un XS, o via Quicker Imaging definido arriba). La imagen modificada para requisitos particulares debe permitir la configuracióe los puntos siguientes. Étos deben ser configurable al crear una nueva imagen o al aumentar a menos que se indicare en forma diferente.

• Must allow re-image of an XO or update of an XO from 8.2(767) and preferably 70x as well.

• Must allow install or upgrade via olpc-update to internet, via olpc-update to XS, via NAND Blaster, via USB stick.

• When installing a custom image, must not require any user interaction with the keyboard. Can require holding down a game key on startup.
• Al instalar una imagen de encargo, no debe requerir cualquier interaccióel usuario con el teclado. Puede requerir el mantenimiento de una llave del juego en arranque.

• Must allow setting the language
• Debe permitir el fijar de la lengua

• Must allow inclusion of the activities and content bundles chosen by the deployment.
• Debe permitir la inclusióe las actividades y el contenido líelegido por el despliegue.

• Must allow installing a language pack
• Debe permitir el instalar de un paquete de la lengua

• Must allow configuring the keyboard for a language
• Debe permitir el configurar del teclado para una lengua

• Must allow installing an RPM (Ethiopia)
• Debe permitir el instalar de una RPM (Etiopí

• Must allow setting Time, Date Timezone
• Debe permitir deinicion del tiempo y Timezone

• Must allow setting of all elements of the sugar-control panel, CLI and GUI versions.
• Debe permitir el ajuste de todos los elementos del panel del azúcontrol, de las versiones del CLI y del GUI.

• Must work with activated XOs and non-activated XOs. In the non-activated case must activate them so the XO is ready for use in the school when done.
• Debe trabajar con XOs activado y XOs no activado. En el caso no activado debe activarlos asíue el XO es pronto para usar en la escuela cuando estáecho.

• Must no require more than one reboot.
• No debe requirer mas que on "reboot"

• Should turn off when its done or show "success" screen then one key stroke and shutdown.

• Must allow changing startup picture by copying an image to the XO.
• Debe permitir el cambiar del cuadro de lanzamiento copiando una imagen al XO.

• Must not require that deployments request a new signed build from OLPC. This can be addressed by allowing them to sign their own builds or by allowing all the customizations listed to be made on a signed build without requiring that it be re-signed. We can require that this feature is only available to specially designated users.
• Necesidad no requerir que los despliegues pidan una nueva estructura firmada de OLPC. Esto puede ser tratada permitiendo que firmen sus propias estructuras o permitiendo todos los arreglos para requisitos particulares enumerados para ser hecho en una estructura firmada sin requerir que re-signed. Podemos requerir que esta caracteríica estéolamente disponible para los usuarios especialmente señdos.

See also:

• <trac>7878</trac>
• <trac>6689</trac>
• <trac>6432</trac>

The following two points need redefinition and clarification:

• Must work with activated XOs and non-activated XOs. In the non-activated case must activate them so the XO is ready for use in the school when done. (rewrite to cover pre-activated and lease feature disabled cases).
• When imaging in a warehouse must activate the laptop

• Note, follow up on issues with open firmware.

• http://lists.laptop.org/pipermail/devel/2008-July/016417.html

re: the ideal solution paragraph above:

I don't feel this is a realistic aim. A lot of files are initialized on first boot which need to be customized per-XO. For a redistributable XO image, all of these changes would have to be undone at image generation time. While it is possible to produce a specification of these changes by taking an unmodified unbooted image and "diff" it against a booted-but-otherwise-untouched XO nand image, this is a bit of a hack and would be a pain to maintain in the long run (our system and its building blocks are constantly changing).

Michael Stone had a good writeup on the differences he detected in a Nepal build that had been made in this way, even after they thought they had cleaned it up. Can anyone find the link?

And here's my suggestion for improving customisation: We already have the technology to insert RPMs into a build, because the released builds are made up of RPMs and not much more! So let's fix up pilgrim or puritan to be more available for use by deployments, perhaps setting up a koji-style build server of some kind hosted at 1CC (to avoid the deployments having to set up a build box). As for other customisations, the current method (customization key) works fine for the limited customisations that it allows, so that simply needs to be expanded.

-DanielDrake 20:15, 17 December 2008 (UTC)

• Must allow XOs to pass their identity to the XS so that the XS recognizes them without the need for them to login.
• Must allow passing the identity to the XS with which the XO is registered. Should allow passing it to any XS. Should allow passing it to any Web server with the right server side code implemented.
• Does not require passing XO identity to more than one server at a time (not taking in to consideration and "load balancing like downstream replicating of data which is transparent to the XO).
• Does not require passing the XO identity to other XOs.
• Must pass that info in Browse in such a way that the XS HTTP server can recognize and extract the info for use in CGI scripting.
• Must work with the back and restore feature so an XO and only the relevant XO "automatically" see and restore their own backed up files.
• Does not need to support passing identity via any activities aside from Browse.
• May allow passing of XO identity to other web server or services aside from the XS but the XS is the primary must have server. If identity is passed to other non-XS server the XO identity must be encrypted and unique so that other browsers or devices can't "spoof" and appear to be the XO.
• Must allow the user to turn off or turn on this feature. When off the XO will not pass its identity.
• Must maintain its identity after upgrade or downgrade.

Server side requirements:

• Must allow an override on the XS which allows it to see a new XO and associate it with a previously seen XO (covers the case where an XO breaks and the user wants to restore the data to a new XO).
• Must allow the XS to move the identity DB and any associations (e.g. which files where back up from which XOs) to a new XS or to share it with another secure XS.

• Must start the cursor on the right and move to the left as characters are typed in Sugar, write and other activities.

Workflow example for the network case above:

1. XOs leave the factory with an older image (e.g. 8.2.1) which includes this OFW code.
2. A custom image based on the same or a later release including activities, content, language and maybe other customizations is prepared and loaded on the XS.
3. An AP is setup and wired to the server.
4. The XOs are turned on, as many as they have power jacks for. On boot up we can require that they hold down some special keys (game keys).
5. Release the keys and the XOs find the AP and start listening on preconfigured multicast broadcast address.
6. The XS broadcasts on the preconfigured address and each XO starts receiving.
7. In case of errors which are more than what can be recovered by error correction the XOs, pick up again on the second broadcast or third or up to ... n (where is configurable or they just turn t he server off).
8. When the XO has a complete image it notifies by putting a special image on the screen.
9. On next reboot of the XO its running the new image. Subsequent boots do not do this multicast listening unless configured specifically by the user.

Some open issues to be addressed by the design proposal:

• Do we pre-configure an ESSID and multicast addresses and hard code those in the factory?
• Can we get it down to no intervention of hold down games keys only?
• What happens if you turn on "too many" XOs? Can we just let them turn on as many as they want and we'll fill them in some order or should we

limit it to set # of XOs at a time? Can we scale it by using more "channels" or more APs?

• Any other security points?