Feature roadmap/Page of all features that target 9.1.0


Jump to: navigation, search

This page is simply a query that embeds the entire page of pages that have Target for 9.1 set to yes. They appear ordered by priority then feature area


Feature roadmap/Rebase on Fedora 10

Feature subcategory Category:Linux and OS
Requesters Ed
  • 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
Specification Run this command to see latest package status:

koji latest-pkg dist-olpc4 --all

Owners User:Gregorio
Priority 1
Helps deployability? yes
Target for 9.1? yes

Feature roadmap/Run Fedora applications on XO

Feature subcategory Category:Linux and OS
Requesters Ed, David

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)
Specification From post by David Lang, http://lists.laptop.org/pipermail/devel/2008-December/021548.html

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/

Owners User:Gregorio, User:PBRobinson, User:Erik
Priority 1
Helps deployability? yes
Target for 9.1? yes

Feature roadmap/Better Arabic Support

Feature subcategory Category:Localization
Requesters Dubai, Palestine, Lebanon refugee camps (Sabra and Shatilla)
  • 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.
Specification https://dev.laptop.org/ticket/6808

Test cases:

Owners User:Gregorio, User:Marc, User:Martin S
Priority 1
Helps deployability? yes
Target for 9.1? yes

Feature roadmap/SCIM

Feature subcategory Category:Localization
Requesters User:Sayamindu
Requirements * We need to migrate to SCIM for our input method needs. Our current input method (XKB with XIM) does not work with languages like Chinese, and there are enhancement requests from existing deployments (eg: <trac>8494</trac>) which can only be handled via SCIM. Having SCIM ready and integrated into our builds offer us the possibility to add support for almost any script relatively easily

(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
Specification * Conversion of all existing layouts to m17n db format , along with refinements and better support for modifiers whenever possible (<trac>6280</trac> (Postponed due to uncertainty wrt the future of SCIM, as detailed on this thread )
  • 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
Owners User:Sayamindu
Priority 1
Helps deployability? yes
Target for 9.1? yes

Feature roadmap/Translations

Feature subcategory Category:Localization
Requesters Mongolia, Rwanda, all
Requirements * Must include updated translations for as many currently supported languages as agreed by Localization list http://lists.laptop.org/listinfo/localization
  • 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.
Specification * List languages and links to their Pootle file here.
Owners User:Sayamindu, User:Gregorio
Priority 1
Helps deployability? yes
Target for 9.1? yes

Feature roadmap/Improved battery life

Feature subcategory Category:Power management
Requesters User:Kimquirk, User:Carla, User:Gnu, Ethiopia, User:Juliano
Requirements Background information: a list of UI actions which may affect power usage: Requirements#Power Management Requirements Our job is to increase battery life in as many modes as possible. For a test plan for these features written back at the 703 release, see Tests/Suspend_Resume.

  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>
Specification Requirement 2 addressed by:

<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

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.)

  • <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:

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.

Owners User:Joe, User:Gregorio, User:Cjb, User:Wmb@firmworks.com, User:Deepak
Priority 1
Helps deployability? yes
Target for 9.1? yes

Feature roadmap/No power regressions

Feature subcategory Category:Power management
Requesters User:Gregorio, Ethiopia, Rwanda, Haiti.
Requirements Make sure power usage is not worse (needs more careful description) in next release.
Specification Tinderbox testing?


Owners User:Rsmith
Priority 1
Helps deployability? yes
Target for 9.1? yes

Feature roadmap/Shutdown menu

Feature subcategory Category:Power management
Requesters Haiti, Rwanda
  • 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
Specification See thread at: http://lists.laptop.org/pipermail/devel/2008-October/020530.html

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.

Owners User:PGF, User:Gregorio
Priority 1
Helps deployability? yes
Target for 9.1? yes

Feature roadmap/Image signing key delegation

Feature subcategory Category:Security, activation and deployability
Requesters Uruguay
Requirements * Must all a deployment to generate an image with their own key. See Trac ID: 9045
  • 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.
Specification See Partial key autonomy for one idea on how to implement this today.
Owners User:CScott
Priority 1
Helps deployability? yes
Target for 9.1? yes

Feature roadmap/Activation via wireless

Feature subcategory Category:Security, activation and deployability
Requesters User:Kimquirk
  • 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.
Specification See <trac>8976</trac> Need to add wireless AP support and/or add XO as activation server support.
Owners Please indicate developers or champions supporting this request
Priority 1
Helps deployability? yes
Target for 9.1? yes

Feature roadmap/Activation lease security

Feature subcategory Category:Security, activation and deployability
Requesters Peru, Ethiopia (especially last point), Uruguay?
Requirements =Overview=

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

Specification * <trac>4043</trac>
Owners Please indicate developers or champions supporting this request
Priority 1
Helps deployability? yes
Target for 9.1? yes

Feature roadmap/GUI OS updates

Feature subcategory Category:Security, activation and deployability
Requesters User:Eben, User:CScott
  • 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.
Owners Please indicate developers or champions supporting this request
Priority 1
Helps deployability? yes
Target for 9.1? yes

Feature roadmap/Single sign-on from Browse

Feature subcategory Category:Activity-related work
Requesters Reuben
Requirements Overview - The primary driver for this requirement is that the XO be able to recover its backed up files from the XS HTTP restore interafce without needing to enter a user name or serial number.
  • 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.
Owners User:Gregorio
Priority 2
Helps deployability? Yes
Target for 9.1? Yes

Feature roadmap/RTL support

Feature subcategory Category:Localization
Requesters Lebanon
Requirements * Must support Arabic in Sugar, Write and all activities.
  • Must start the cursor on the right and move to the left as characters are typed in Sugar, write and other activities.
Owners User:Sayamindu
Priority 2
Helps deployability? yes
Target for 9.1? yes

Feature roadmap/XO as internet gateway (formerly called MPP)

Feature subcategory Category:Network
Requesters Uruguay, User:Kimquirk, Michailis
Owners Please indicate developers or champions supporting this request
Priority 2
Helps deployability? Yes
Target for 9.1? Yes

Feature roadmap/Faster imaging

Feature subcategory Category:Security, activation and deployability
Requesters Ethiopia, Rwanda, Haiti
Requirements This feature request is needed to minimize the time to install a custom image over a wireless or wired network. It will be used when an XO comes from the factory with an older release. The deployment then needs to upgrade to the latest release and possibly install some customizations (e.g. content, language pack, activities, see also separate customization requirement below). The solution must be faster than imaging via USB sticks for imaging more than 1,000 XOs. Must allow install of new image via wireless or wired network. Possibly sub-variants of in school case for Mesh, Wireless AP, XS.

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.
Specification See also: Multicast NAND FLASH Update

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?
Owners User:Gregorio, User:Reuben, User:wmb@firmworks.com
Priority 2
Helps deployability? yes
Target for 9.1? yes
Personal tools
  • Log in
  • Login with OpenID
About OLPC
About the laptop
About the tablet
OLPC wiki