9.1.0 requirements: Difference between revisions
Line 184: | Line 184: | ||
countries. <br> |
countries. <br> |
||
http://lists.laptop.org/pipermail/localization/2008-July/001249.html |
http://lists.laptop.org/pipermail/localization/2008-July/001249.html |
||
=== Groups === |
|||
4043 |
|||
== Performance and Reliability == |
== Performance and Reliability == |
Revision as of 14:44, 4 August 2008
Release 9.1.0 Overview
This is a time based release per the process at:
Release Process Home
The process is not final. It is a set of rough guidelines still being worked out and subject to change.
Technical Strategy
Faster, more robust, better integration of activities, more collaboration...
See requirement definition at Requirements
Sales - Deployment Strategy
See customers below.
Pedagogical Strategy
....
Primary Release Drivers
Date The goal (not confirmed) is to make this release public sometime between December, 2008 and June, 2009.
Customers
Features
Target Deployments
See: User talk:Gregorio#Shipment Quantities and Languages
Uruguay
Spanish
100K x XOs?
http://wiki.laptop.org/go/OLPC_Uruguay
Peru
Spanish
100K x XOs?
http://wiki.laptop.org/go/OLPC_Peru
http://wiki.laptop.org/go/Peru_activity_pack
40K XOs coming from 656
100K XOs probably coming from 708 (exact build tbd) Gregorio 10:46, 31 July 2008 (UTC)
Mexico
Spanish
50K x XOs
Mongolia
Mongolian?
20K x XOs
Rwanda
French 10K x XOs
Haiti
Kreyol
13K x XOs
Ethiopia
Amharic
5k x XOs
Cambodia
Khmer
1000 XOs
Afghanistan
Dari
3000 x XOs
Thailand
Thai
500 x XOs
India
Devanagari
500
Brazil
Portuguese
200 x XOs
Arabic
Sabra and Shatila (Lebanon)
500 x XOs
Oceania
Enlish?
500 x XOs
Italy
Italian
600 x XOs
Turkey
Turkish?
15k x XOs
Senegal
French
1000 x XOs
Argentina
Equitorial Guinea
Panama
Spanish
Birmingham
English
South Carolina
English
New York City
English
G1G1
English, other?
China
?
Priorities from Deployments
Should list what, who and why on each item. Should link to detailed requirements and use cases eventually.
See User talk:Gregorio#Priorities from Carla
Activity Related Work
Requests from Birmingham.
New activities:
Firefox, Flash, mplayer
A spreadsheet (I'm going to use gnumeric until Socialcalc is ready for production)
A more full featured pdf reader (yes, I know there's the Read activity, but I'm planning on installing the full evince and making sure Firefox can open pdfs with it)
A document editor the user can insert images into (the full Abiword would be great for this, but the current workaround [after editing a file] is to open write, then hit ctrl+n)
General requests:
I have got to be able to sugarize third party applications.
Longer Battery Life
Requirement Definition
Requirements#Power Management Requirements
Who requested
Kim
Touchpad
Requirement Defintion
Who requested
Improved in 8.2.0
Priority request from Carla
Collaboration
Requirement Definition Phase 1
Allow for intuitive mesh connection and activity-sharing.
Must support first two use cases defined at: Use Cases#Collaboration Examples
Requirements#Mesh / Connectivity_Requirements
Requirements#AbiWord Sharing Requirements
http://lists.laptop.org/pipermail/sugar/2008-July/007407.html
May need to include that link in developer section below, tbd
Requirement Definition Phase 2
Interschool, other use cases.
Who requested
Priority request from Carla and David.
Also several thread on OLPC-Sur.
Peru technical leaders
Inter-school communication
What I see as most missing and most necessary is a safe space for collaboration between students at different schools, even in different
countries.
http://lists.laptop.org/pipermail/localization/2008-July/001249.html
Groups
4043
Performance and Reliability
Faster activity launching
6472
- File/activity open
- File save
- Task switching
- Activity or main GUI responsivesness to cursor
- Hardware
Suggestions from Marco
From: http://lists.laptop.org/pipermail/sugar/2008-July/007471.html
1 General UI sluggishness.
Without going too deep into the stack, I think there is a lot of space or improvement even in the python code. Michael mentioned icon cache and mesh view layout, both areas of the code that didn't get any love for a while and where I'm convinced we can make big/quick progresses. I'm planning to spend a lot of my time on this in the next release cycle.
2 Datastore performance.
I'd expect improving jffs2 performance would be a big win there. The UI can probably be smarter in the way it uses the datastore too Finally we can try to improve at the datastore level, but there we clash with the rewrite plans. I think we should find an agreement on the datastore design and just try and get it done for 9.1.0, there are two many things blocking on it.
We need to allocate time and focus to do some good profiling and then attack the problems we find. That's why I'm advocating for the next Sugar release cycle to be largely about perfomance improvements, bug fixes and code refactoring, with the possible exception of the datastore rewrite.
File Management
Candybag Idea for a new activity: Candy Bag. You open a bag (i.e. you launch the CandyBag activity), then you put journal entries in it, then sharing this activity means that your friends can grab a candy in your bag.
> >If we want the kids who *love* their machines to come to *know* and > > *evolve* their machines, there's a lot more work to be done.
Let's not lose the focus of making the *teachers* love the machines. And let's don't see children as small "hackus homunculus"! :)
From: http://lists.laptop.org/pipermail/devel/2008-July/017459.html
See also point #3 at
http://wiki.laptop.org/go/9.1.0#e-mail_from_Ben_S
Localization
Spell checking as part of l10n. (Sayamindu and Sur list)
Allow adding a language after the build is created and without OLPC intervention
Chinese support (Kim)
Better RTL support
Security Activation and Deployability
School server push of XO images
Requirement: The XO should be able to get the latest build from the school server
- The administrator makes the desired build available in the designated
directory. When ready, the administrator requests to 'push' the build to all laptops as they come on line. Both of these activities should be an easy-to-use UI at the school server.
- A test requirement is the ability to create a white list of serial numbers
that should be upgraded with the push.
Source: Peru
Activation lease security feature
Requirement - if the laptop is stolen, and doesn't contact its local school server within some period time (activation lease time); then it will tell the user that it will not activate on next boot and provide date and time.
Requirement - it is not possible 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... (not trying to solve the problem, just want to note this requirement).
Source: Peru
XO Monitoring
Requirement: Provide XS database and an API so that countries can create reports and monitoring for various aspects of XOs:
- Version of code
- Which laptops are being seen each day
- Total number of laptops being seen per day
- Number of laptops accessing the internet
- List of URLs being accessed
- List of URLs per laptop
- Which activities are being used per laptop
- Number of minutes in each activity per laptop; can we determine (and subtract) idle time?
- Number of minutes in each activity within and outside of school hours (perhaps this means we capture the 'start' time of each activity and allow the reporting to decide if this is during or outside of school hours).
Background and implementation ideas:
I think there might be some work in the XO to make the information available; and a database and API spec from the school server. This is not as high priority for their deployment as the passive lease management, but I believe this feature will be important for any deployment. We should try to get feedback from other deployments as to the information we want to collect.
Source: Peru
Customized Startup Images
Must allow changing startup picture by copying an image to the XO. This should not require any OLPC developer intervention and should not need a new or special build.
http://lists.laptop.org/pipermail/devel/2008-July/017299.html
Source: Colombia and Mexico before.
Already present in 8.1.0. See: http://wiki.laptop.org/go/Tweaking_the_boot_animation
Network Manager Connections
G1G1 encryption.
802.11i (AKA 802.1x) Uruguay
Unadorned and unedited user feedback
6th grade kids feedback on build 656:
http://sextosdela37.blogspot.com/2008/04/analizando-el-uso-de-las-laptop-en-el.html
Priorities from Carla: User talk:Gregorio#Priorities from Carla
Comments from technical user in Ecuador:
http://lists.laptop.org/pipermail/olpc-sur/2008-July/000408.html
GUI and Usability
Request from Uruguay for HW alerts:
http://lists.laptop.org/pipermail/sugar/2008-July/007086.html
Designs ideas from Scott and Eben in thread. e.g. I hope our alert system will use the freedesktop.org standard: http://www.galago-project.org/specs/notification/index.php
More prominent help information - Brianne, G1G1
One idea from Eben. From: http://lists.laptop.org/pipermail/sugar/2008-August/007547.html
All of our initial discussions on help focused around a contextual help system, and I still hope that this is where we'll be taking this in the future. By embedding (?) icons within the secondary palette menus for various devices, objects, activities, and even individual buttons and controls, we can provide a way to launch into the help activity and dive directly to the relevant info for the activity, control, etc. selected. In addition, I'd like to support a community driven help system by which, in addition to the activity/olpc provided help, it's possible for kids to add tips, tricks, images, tutorials, and other info to these sections for later consumption by peers.
This is a noble, but ambitious goal, which is why a simple and static help activity is the present solution, and why it's only integrated into the system at a single point - the activity itself.
Priorities from Engineering
- #4662 needed for better activity capabilities.
- #2447 caps lock
- #1997 flashing in write
- NAND full crashes system
- I think analyzing performance of non-JFFS2 file systems and picking a replacement should be a high-priority item for 9.1 update.
- from: http://lists.laptop.org/pipermail/devel/2008-July/016994.html
- #2188 sharing files and resources between activities
- #1496 Switch to real public keys - Scott
Fedora 10 rebase?
Faster Upgrade
Make it easier to upgrade many laptops in the field. Several cases:
Updates:
- XOs in warehouse need update before being shipped.
- XOs in school with no WAN
- XOs in school with thin WAN pipe (BW <= 1Mb/s)
- XOs in in school with good WAN (BW >= 1Mb/s)
Possibly sub-variants of in school case for Mesh, Wireless AP, XS.
e-mail from Ben S
http://lists.laptop.org/pipermail/sugar/2008-July/007390.html
1. The datastore
Sugar's design calls for a centralized rich data storage system, the
datastore. The datastore provides secure, limited file access to
Activities, manages file metadata, maintains a differentially compressed
history of all work, ensures reliable backups to a trusted server, and
mediates the connection to removable media. Every one of these features
is crucial to Sugar's functioning, and almost none are really working at
this time. We cannot afford another release based on the present
datastore, as it fails to implement the features we require, and is
unreliable even in the features it supposedly implements.
Solution:
There have, at this point, been at least five distinct proposals for a
next-generation datastore design, all differing in underlying
implementation and user-facing functionality. We need to have a Once And
For All datastore summit, draw up a compromise datastore design, and
implement it. We can do this by 9.1.0, if we are willing to make it a
priority.
Additional Links:
- The current datastore
- Olpcfs
- Sugar Datastore Summit in January (item 10).
- SDS (stands for Simple Data Store or possibly something else)
- Git-based datastore design
- Expose the file system on save, open and in the journal. Source: Marvin Minsky
2. OS Updates
We now have hundreds of thousands of laptops deployed in the field,
running a variety of OS versions. OLPC cannot afford to support a
multitude of decrepit versions, and children cannot afford to suffer
defects that have long since been fixed. We need a reliable, fast,
update system that does not rely on the network, so that children
everywhere can move to the
latest version of Sugar without losing their data. The update system must
support tremendously invasive upgrades, like repartitioning the NAND and
replacing JFFS2, because we expect to do this in short order.
Solution:
A secure usb autoreinstallation stick is required. It is not technically
challenging to implement, but it must be made a priority, and then be made
widely available and idiot-proof.
3. File Sharing
Students and teachers have no good way to distribute files directly from
one person's Journal to another. If all Activities that open a file do
not implement Collaboration, then there is simply no way to transfer that
file over the network. This is the most basic possible network
functionality --- FTP was standardized in 1971 --- but it is completely
missing from our system.
Solution:
A number of technical proof-of-concept programs have been written for
distributing files, using methods like HTTP over stream tubes and
Cerebro's Teleport. There is an excellent set of [[Specifications/Object_Transfers|UI mockups for this]
functionality. All that is left is to Get It Done.
Additional Links:
4. Activity Modification
A keystone of the Sugar design has always been the user's ability to edit
any Activity, and to cement this a "View Source" key was designed right
into the hardware. This functionality is simply missing, and that
prevents us from making our principal claim regarding an emphasis on user
modification.
Solution:
"Develop" must be polished, finished, and included by default. This will
require modifications to the core system, in order to support an endless
variety of slightly modified Activities. It will also require work on the
Develop program itself. If volunteer efforts are not moving fast enough, OLPC
must ensure that someone is working on the problem as a professional.
Additional links:
- Develop
- Previous, stalled attempt at Develop
- Current status of "view source"
- OLPC_Human_Interface_Guidelines/The_Laptop_Experience/View_Source
- EAG_The_Laptop_Experience:_View_Source
5. Bitfrost
Sugar, as it currently stands, is among the least secure operating systems
ever, far less secure than any modern Linux or Windows OS. I can easily
write an Activity that, when run by the user, escalates to root privileges
and does anything I like with the system. Given Sugar's competitive
status against Windows XO, this failing threatens the very existence of
the project. The Sugar designs have long stated that safely running
untrusted code from a classmate is a key goal for learning, but the
current software accomplishes precisely the opposite.
Solution:
NO ONE IS WORKING ON BITFROST. That's right. Everyone who was working on
Sugar security (after activation) has either left OLPC or moved into
another role. Someone must be assigned to continue the security work, or
it will certainly never make progress. Anyone who _does_ take on this
challenge will start from a much better position than previously,
because many of the Vserver features have moved into the mainline kernel
over the last few versions. The kernel now contains a number of new,
powerful isolation and control primitives.
6. Power management
Power management is the raison d'etre of the XO hardware. It is the
reason that the hardware took four times as long to develop as a standard
laptop, the reason that we suffer from the closed Marvell operating
system, the reason that OLPC's best engineers flew around the globe
fighting with details of voltage and capacitance. In an increasingly
crowded low cost laptop market, it is one of OLPC's few remaining
distinctions. As of 8.2.0, aggressive suspend is available, but its
functionality is still far from the target.
Solution:
Enabling aggressive power management is a major challenge, perhaps more
difficult than anything else on this list. We know what is required for a
first step: ensure that we can reliably wake up from a hardware timer.
This single feature would be enough to enable a basic sleepy approach that is truly transparent to software. Other work includes removing USB from the critical path on resume. Aggressive suspend may not be ready for 9.1.0, but if no one is working on it it will never be ready.
Suggestions from CScott
- Better "legacy app" compatibility; this should allow us to run existing apps like firefox, pidgin, and gimp in a reasonable manner:
- Replace matchbox window manager with XMonad
- Switch to standard freedesktop.org startup notification mechanism
- Implement freedesktop.org notifications mechanism for alerts (low battery, low disk space, available software update)
- Improved antitheft mechanisms:
- ECO fix and EC improvements
- Security control panel, with "am I stolen" and lease renewal buttons: <trac>1502</trac>
- olpcrd work: <trac>7397</trac>
- Improved update mechanisms
- Real COW for pristine versions, allowing...
- ...binary-diff updates over http (avoiding rsync in many cases)
- Integration of core OS updates with software update control panel
- Integration of software updates with notification system
- Security/isolation work
- Implementation of P_SF_CORE, P_SF_RUN
- Mechanism to validate updates to loopholed activities & allow user to manage exceptions
- Persistent activity storage
- NSS modules for rainbow users and for olpc/root users
- Rainbow
- Journal improvements
- Proper display of 'new versions' of activities
- Tagging system to allow folder-like management for advanced users
- Datastore rework
- Translation improvements
- translation system should look in local, then activity, then system translation tables, then repeat for each in a set of fallback languages (eg, quechua, spanish, english)
- separable translation packs
- wiki-like editing of translatable labels in the UI