Feature roadmap: Difference between revisions
m (→Priorities from Engineering: fix link) |
(→Other) |
||
| Line 707: | Line 707: | ||
{{Feature_request |
{{Feature_request |
||
|Name= |
|Name= Developers Center w/ documentation for users and developers |
||
|Requesters=[[User:Mchua|Mel]] |
|Requesters=[[User:Mchua|Mel]] |
||
|Requirements= |
|Requirements= |
||
Revision as of 16:30, 4 November 2008
Overview
This page intends to layout a long term strategy for prioritizing software development on the XO. Feature lists for individual releases will appear on their respective pages as listed features get prioritized, scoped and a targeted. In addition to outlining goals and strategies, an extensive feature roadmap is maintained on this page. This page goes hand-in-hand with the Feature requests page, as follows:
- 1. Feature requests
- Features, requirements and requests by country. This page contains verbatim requests from technical leads or translated and reviewed rewrites of initial feedback. Only items specifically requested by a qualified technical lead, administrator, teacher or student in the country should go in this section.
- 2. Feature roadmap
- Feature suggestions by technical strategy. Each item on this page should include reference to the;Requester: (e.g. country or engineer or URLs to relevant discussions and sites). It should also include a reference to which element of the strategy it fits in to (if available).
Features are prioritized based solely on their value towards achieving the goals and executing the strategy. The amount of effort required and the availability of engineers to expend such effort is not included in the prioritization decision. The engineering and test work, the availability of relevant software and the available resources will be added as critical decision factors when determining what features are delivered in each release. This page is meant to be abstracted from releases and it should therefore include a superset of priorities for any given release.
Suggestions for providing input
- Please sign in to the wiki when updating this page so we know who made the edits.
- Raw, unfiltered feedback from countries and deployments should go on the Feature requests page.
- Feel free to add to this page following the guidelines described above.
- Comments on the submissions of others are best provided on the discussion page, or the discussion page for that particular section.
- Edits to original submissions should be discussed with the original poster beforehand.
- Follow the template when Requesting Features or Enhancements.
- Use the trac template when referencing tickets/bugs.
- Additional suggestions for providing input are welcome.
- Create a new section (At the == header 2 == level) for your country or request if none present are adequate.
Goals
Educational goals
Technical goals
Strategy
Educational strategy
Technical strategy
This section outlines the main areas of technology focus. All of the specific features should address one of these primary concerns. The choice of these comes from listening to users and deployment leads and hearing what their concerns. If a proposal for development does not fit in one of these areas, it should still be listed. Then it can stand on its own or the strategic priorities should be adjusted or added to.
Requests by deployments
See also: Deployments
The features listed in this roadmap are carefully selected based upon direct feedback from countries and deployments, which can be found en masse on the Feature Requests page.
Roadmap
Adding to the roadmap
This section lists major features to be added to Sugar over time. Each request should use the feature request template (you can copy/paste from below), providing as much information as possible. Direct feedback from countries and deployments should be provided on the Feature requests page instead.
Please sign in to the wiki before adding or editing feature requests.
{{Feature_request
|Name=
|Requesters=
|Requirements=
|Specification=
|Owners=
}}
The elements of such a request are described below. The text for these elements may be listed on the same line as the parameter, just after the equals (=) sign, or on the following line(s). Where appropriate, please use numbered or bulleted lists to identify individual requirements or specification ideas.
- Name
- A brief, one-line summary of the feature, used as the title on the page
- Requesters
- Deployments, engineers, or both who support the request
- Requirements
- User level requirement definition; Links to detailed wiki pages, mailing list threads, or other resources are welcome
- Specification
- Design and technical implementation ideas; Links to detailed wiki pages, mailing list threads, or other resources are welcome
- Owners
- Names of developers and/or champions of the request who will ensure that progress is made
See also: general suggestions for providing input.
New activities
| Requesters | Birmingham, Juliano | |
| Requirements | From Birmingham:
From Juliano:
| |
| Specification | ||
| Owners |
Better eBook reader
| Requesters | Birmingham, Haiti, Devel thread | |
| Requirements | * Description of challenges here: http://lists.laptop.org/pipermail/devel/2008-October/020662.html See the rest of the thread too.
Desired improvements
| |
| Specification | Possible support eVince:
http://live.gnome.org/Evince/SupportedDocumentFormats per Jim e-mail: http://lists.laptop.org/pipermail/devel/2008-October/020719.html ? | |
| Owners | Greg |
Sugarized color picker
| Requesters | Juliano | |
| Requirements | A better color picker in Paint & Write. Current one "...is made for professionals to get the HTML code of the color, but it also leads to error since people need to select the color in the circle and then in the triangle. It is giving bad time to people around here [Rwanda]". From Juliano in e-mail 9/1 | |
| Specification | ||
| Owners |
Easy "Sugarization"
| Requesters | Wanda, David | |
| Requirements | * Make it easy to sugarize third party applications. It should be trivial to take an existing application which runs on Fedora (or other Linux too?) and install and run it on the XO. The basic sugarization interface for that should be usable by a non-programmer. Not all sugar features need to be enabled (will define exact list if this gets to requirements definition stage). Additional sugar capability may require programming (e.g. collaboration). The goal is to allow deployments to use any state of the art application available in Linux/Fedora.
| |
| Specification | See related X-windows threads on devel (links and references appreciated). This may also impact datastore and other areas. | |
| Owners | Greg^ |
Concept Maps
| Requesters | Panama and OLPC Sur | |
| Requirements | * Support a concept maps making application. Can be on XS or Internet or XO only
| |
| Specification | * See some of the options and available tools at: http://lists.laptop.org/pipermail/devel/2008-September/018811.html | |
| Owners | Greg |
Power management
Improved battery life
| Requesters | Kim, Carla, Gnu, Ethiopia, Juliano | |
| Requirements | 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. | |
| Specification | 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:
| |
| Owners | Gnu, Chris, Greg^ |
| Requesters | Haiti, Rwanda | |
| Requirements | 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. | |
| Specification | See thread at: http://lists.laptop.org/pipermail/devel/2008-October/020530.html | |
| Owners | PGF, Greg^ |
No power regressions
| Requesters | Greg, Ethiopia, Rwanda, Haiti. Also make sure that EC draws the minimum possible power when XO is actually shutdown. | |
| Requirements | Make sure power usage is not worse (needs more careful description) in next release. | |
| Specification | Tinderbox testing? | |
| Owners | Richard |
Hardware support
Accurate touchpad
| Requesters | Carla, Rwanda, Ethiopia, Haiti | |
| Requirements | User talk:Gregorio#Priorities from Carla.
| |
| Specification | ? | |
| Owners | Wad, PGF, Greg^ |
Collaboration
Synchronous Collaboration
| Requesters | Carla and David, Teachers on OLPC-Sur, Peru technical leaders | |
| Requirements | See detailed collaboration requirements here: 9.1.0 Collaboration Requirements
| |
| Specification | ||
| Owners | ^Greg |
Asynchronous collaboration
| Requesters | Juliano, Cynthia | |
| Requirements | * Must allow students to post and work on projects together. One student can create something and share it with other students who edit it and save etc.
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 | |
| Specification | ||
| Owners | Greg^, Martin |
Scalable presence service
| Requesters | ||
| Requirements | * Complete Gadget implementation, which should hopefully fix our current scalabity issues and offer new features as activity and buddies search. (cassidy)
| |
| Specification | See Gadget integration TODO for more details. | |
| Owners | Guillaume Desmottes, Dafydd Harries, Eben Eliason, Morgan Collett |
Scalable Link-local presence
| Requesters | ||
| Requirements | Undefined | |
| Specification | ||
| Owners | Morgan Collett, Sjoerd Simons, Elliott Fairweather, Polychronis Ypodimatopoulos |
Collaboration Groups
| Requesters | Peru | |
| Requirements | Group support in gabble and salut (Trac #4043) | |
| Specification | ||
| Owners | Eben |
Performance
Faster activity launch and save
| Requesters | Peru, Uruguay | |
| Requirements | ||
| Specification | <trac>6472</trac> | |
| Owners |
Faster task switching
| Requesters | Peru, Uruguay | |
| Requirements | ||
| Specification | ||
| Owners | Erik |
General UI sluggishness
| Requesters | Uruguay, Peru | |
| Requirements | ||
| Specification | From: http://lists.laptop.org/pipermail/sugar/2008-July/007471.html | |
| Owners | Marco, Erik |
Reliability
Memory Pressure
| Requesters | Elana, Peru, Carla | |
| Requirements | http://sugarlabs.org/go/DevelopmentTeam/0.84/Reliability#Memory_bloat | |
| Specification | ||
| Owners |
Journal never loses work
| Requesters | Everyone | |
| Requirements | * Sugar must never lose data. Activities must save on exit and leave an item in the journal. Once an item is ion the journal it must remain there until the user removes it. | |
| Specification | http://sugarlabs.org/go/ReleaseTeam/Releases/Sucrose/0.83.1#sugar-datastore | |
| Owners | Tomeu, Greg^ |
Clipboard
| Requesters | Eben | |
| Requirements | http://sugarlabs.org/go/DevelopmentTeam/0.84/Reliability#Solid_clipboard | |
| Specification | ||
| Owners | Eben, Tomeu, Marco |
Journal, File Manipulation
"Candy Bag" or "Bulletin Board" activity
| Requesters | ||
| Requirements | 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. From: http://lists.laptop.org/pipermail/devel/2008-July/017459.html | |
| Specification | I'd be curious to see if there is a benefit to having a task like this manifested as an activity. It might work well. In fact, this might be the "Bulletin board" activity we've been wanting all along. There's also a design for a more embedded XO to XO object transfer system. Eben 19:40, 19 September 2008 (UTC) | |
| Owners |
Object transfer
| Requesters | several deployments; not sure which | |
| Requirements | A way to send objects from one XO to another without a USB key, and without sharing the activity. | |
| Specification | XO to XO object transfer system. Eben 19:40, 19 September 2008 (UTC) | |
| Owners | Simon, Eben |
Copying files between Journal and USB
| Requesters | Bastien, Uruguay | |
| Requirements | As close to one click to copy files from Journal to USB. | |
| Specification | ||
| Owners |
File name and directory access
| Requesters | Gnu, Ben, Erik, Greg, Marvin | |
| Requirements | Allow listing, copying and finding files with standard Unix commands in the terminal view. See also point #1 at: 9.1.0#e-mail from Ben S | |
| Specification | ||
| Owners |
Localization
Translation Technology (See an earlier post, Scaling and localization in package management, for background.)
Spell checking
| Requesters | Sayamindu, Sur list | |
| Requirements | ||
| Specification | ||
| Owners | Sayamindu |
Language customization
| Requesters | Sayamindu, Sur list | |
| Requirements | An ability customize language (and related settings) without OLPC intervention | |
| Specification | ||
| Owners |
Chinese language support
| Requesters | Kim | |
| Requirements | ||
| Specification | ||
| Owners |
RTL support
| Requesters | ||
| Requirements | ||
| Specification | ||
| Owners |
SCIM
| Requesters | 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. | |
| Specification | ||
| Owners | Sayamindu |
Multilanguage Support
| Requesters | Sayamindu | |
| Requirements | An ability choose multiple languages in order of preference (eg: an Aymara speaker would choose Aymara followed by Spanish) | |
| Specification | Mockup for the Sugar control Panel has been created by Eben at http://interdimensionmedia.com/scratch/settings-10.jpg . The feature is <trac>8875</trac> | |
| Owners | Sayamindu |
Security, activation and deployability
GUI OS Updates
| Requesters | Eben, Scott | |
| Requirements | Easy GUI update of OS over net or from USB; Mostly for G1G1 but useful for all. | |
| Specification | (I believe this needs to be divided into 'customization key' and initial install. The install has to do with the logistics, USB keys and wireless downloads. Customization has to do with how the image is created before the logistics of how to get it on laptops. Kimquirk 17:25, 9 October 2008 (UTC))
Many deployments have noted how hard it is to install or upgrade, especially on thousands of XOs. One issue is that inevitably, the Xos ship from the factory with an older build and countries need to upgrade them before deploying. I call that "upgrade in a warehouse". In other cases the XOs get deployed but there is little or no WAN available to upgrade. | |
| Owners |
Faster imaging
| 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:
| |
| Specification | See also: Multicast NAND FLASH Update Some open issues to be addressed by the design proposal:
limit it to set # of XOs at a time? Can we scale it by using more "channels" or more APs?
| |
| Owners | Greg, Reuben, Mitch |
Image customization
| Requesters | Uruguay, Ethiopia, Colombia,Peru, Mexico (the last two especially for startup image customization). See source thread from Colombia at: http://lists.laptop.org/pipermail/devel/2008-July/017299.html | |
| Requirements | 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.
See also:
The following two points need redefinition and clarification:
| |
| Specification | * http://lists.laptop.org/pipermail/devel/2008-March/011553.html | |
| Owners |
School server push of XO images
| Requesters | Peru | |
| Requirements | * The XO should be able to get the latest build from the school server
| |
| Specification | ||
| Owners | Martin |
Activation lease security
| Requesters | Peru, Ethiopia (points 4 and 5), Uruguay? | |
| Requirements | * 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 (I call this "deactivated").
See also write up on "Actual security requirements": User:Mstone/Commentaries/Security_1 | |
| Specification | * <trac>4043</trac> | |
| Owners |
Theft reporting
| Requesters | Peru? | |
| Requirements | Sometimes known as 'active kill'. If the laptop is stolen, the serial number can be added to a 'stolen laptop' list so the laptop's activation can be turned off the next time it finds either a local school server or a global tracking server.
| |
| Specification | ||
| Owners |
XO Monitoring
| Requesters | Peru | |
| Requirements | Provide XS database and an API so that countries can create reports and monitoring for various aspects of XOs such as:
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. | |
| Specification | I (Kim) think there might be some work in the XO to make the information available; and a database and API spec from the school server. | |
| Owners | Kim |
Network
802.1x Support
| Requesters | Uruguay | |
| Requirements | Must allow association with APs running 802.1x | |
| Specification | http://en.wikipedia.org/wiki/IEEE_802.11#Standard_and_amendments | |
| Owners |
Reliable access to encrypted APs
| Requesters | G1G1 | |
| Requirements | Must reliably (better definition needed) associate with APs running WEP, WPA and WPAv2 | |
| Specification | ||
| Owners |
Network Manager GUI
| Requesters | ||
| Requirements | Needs definition of exactly what should be changed, why and how. | |
| Specification | ||
| Owners |
Document and Improve default network connection
| Requesters | ? | |
| Requirements | Better default network connection choice algorithm (e.g. if USB - Ethernet is connected, use it first source: A Callahan).
This algorithm should be "smart" in its first choice but should also be adjustable in the GUI.
Needs further definition. | |
| Specification | ||
| Owners |
GUI, Usability
Remove the "frame" feature
| Requesters | Joe | |
| Requirements | Remove the "frame" feature. | |
| Specification | Remove the "frame" feature altogether. Concentrate all icons either in the bottom or the top of the screen, make them much smaller, also reassign the related to "frame" keyboard's key to do something more useful. Benefits: more useful screen's real estate, no delay currently experienced while switching the frame, especially by using a cursor. Simpler is better, isn't it? | |
| Owners |
Hardware alerts
| Requesters | Uruguay | |
| Requirements | http://lists.laptop.org/pipermail/sugar/2008-July/007086.html | |
| Specification | 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 There is a visual design for the notification system as well. | |
| Owners |
Contextual help
| Requesters | Brianne | |
| Requirements | 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. | |
| Specification | ||
| Owners |
Trash can
| Requesters | Bastien | |
| Requirements | http://lists.laptop.org/pipermail/sugar/2008-August/007889.html | |
| Specification | ||
| Owners |
Scalable zoom levels
| Requesters | UI Team, Collabora | |
| Requirements | We need to support a mechanism for auto-filtering the view to a "reasonable" set of activities and XOs, and provide rich mechanisms (search and filters) for adjusting one's perspective on the view to find items of interest. | |
| Specification | Gadget is the core of this effort. We need some additional UI work to hook it up. One aspect of the solution is the addition of list views to all zoom levels, making it possible to list the entire set of people, activities, access points etc, see their icon and name at a glance, sort alphabetically or by type, and also filter as desired. | |
| Owners | Eben, Collabora |
Other
System Clock
| Requesters | Birmingham and seen on devel list (anyone have time to search for the threads?) | |
| Requirements |
| |
| Specification | ||
| Owners | Greg |
Screen Zoom
| Requesters | Greg | |
| Requirements | This idea came from watching kids and grownups gathering around an XO and trying to see what someone else is doing.
| |
| Specification | Ben said that the Geode has HW scaling with interpolation. This feature should come at no/bare minimum cost to CPU cycles and performance. | |
| Owners | Greg |
Universal view source
| Requesters | Tomeu | |
| Requirements | One more step towards implementing the original vision of the "View source" key.
| |
| Specification | See this thread for an implementation proposal. | |
| Owners | Tomeu |
Developers Center w/ documentation for users and developers
| Requesters | Mel | |
| Requirements | Strictly speaking, this is not a technical feature; however, like technical features, this would require developer time in exchange for enhancing our capabilities to implement and (commercially) support technical features, so I am including it here.
| |
| Specification | If this were implemented mainly by developers, it would be a large task for the developer responsible for each subcomponent to take responsibility for creating this section. So instead, I would suggest putting the load on a single editor who would be in charge of talking with developers, asking them questions, and formatting their (objective: minimize the workload on developers as much as possible). I could see this being half-time contract work, maybe for 2-3 months during 9.1 development, to create and release a first version of a "developers' center" with an infrastructure that can be easily updated for future releases. | |
| Owners | None yet. |
Priorities from Engineering
The following is maintained here for the history and a look at what people want to do by engineer. However, I hope that everything in this section will also have a place in the Feature list above. If you added something here, please also find a home for it in the section above.
Thanks Gregorio 13:13, 23 October 2008 (UTC)
- #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
- #8170
- #8171
- #8177
Upgrade journal per: OLPC Human Interface Guidelines/The Laptop Experience/The Journal
Less flickering in starting activities and other screen changes - Michael
Show memory usage to user:
We provide no end user feedback on memory usage, either. We should investigate whether revisiting our previous attempt to give such feedback, now that Linux can provide much better information than it could when we abandoned our previous donut attempt. The users could really help, if only we let them know a bit about what was going on...
From Jim e-mail to devel: http://lists.laptop.org/pipermail/devel/2008-September/018944.html
Fedora 10 rebase?
Fix all GPL issues and get sign off from FSF that we are fully compliant.
Ensure the blinking of the lights is meaningful.
http://lists.laptop.org/pipermail/sugar/2008-September/008237.html
Debug tool that easily allows plug of diagnostic USB stick which analyzes and reports back detailed status.
ErikG idea from Uruguay
Backup to Internet idea from Walter:
http://lists.laptop.org/pipermail/sugar/2008-September/008340.html
Stability suggestion from Albert C (and his children) re. protecting against out of RAM conditions:
http://lists.laptop.org/pipermail/devel/2008-September/019575.html
Sugar roadmap
http://sugarlabs.org/go/ReleaseTeam/Roadmap/0.84
Easier Access to and Help Using Source Code
Put a link in the library on the XO which links to GIT or other relevant source. (source: John/Gnu)
Improved clipboard
Here is a rough specification of the intended design for a usable multi-item clipboard. I'll add a list of related tickets shortly.
Sugar architecture ideas
From thread started by Michael S
http://lists.laptop.org/pipermail/sugar/2008-July/007304.html
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.
Easy update for G1G1
I think this is the biggest missing feature for G1G1 users, honestly. The software update control panel for activities is a great step in the right direction, but to really get people into Sugar moving forward, we have to make one-click updates a reality. They have no school server or other centralized source doing it for them, and we can't expect many to go through the manual update process. Once we have a super-simple control-panel-integrated dev key request process, we should also adjust the update UI to offer cutting-edge updates to those with keys.
From Eben and Joe
Suggestions from User:CScott
Moved to User:CScott#Desiderata_for_9.1.0. Crib proposals from there. The canonical source for my 9.1.0 proposals is now the postings to devel@ I made, with subject lines beginning, "9.1 Proposal:".
TODO list of User:Sayamindu
- Language Packs version 3
- Packs should be as RPMs
- Utilize patches from Ubuntu for Python and Glibc to define a separate install location/search path for PO files installed via the packs
- Also see CScott's wishlist above.
- SCIM support
- Conversion of all existing layouts to m17n db format , along with refinements and better support for modifiers whenever possible (<trac>6280</trac>
- Modification of relevant startup and configuration scripts for SCIM support
- User experience for keyboard layout switching should not change
- Proper handling of Amharic characters (<trac>8494</trac>)
- Implementation of OLPC_Nepal_Keyboard
- Enhanced i18n
- Better support for translation of content
- Investigation of the possibility of using native digits for translations <trac>7857</trac>
- Read improvements
- Better Ebook mode support (still vague on this.. expect more details soon)
- Terminal improvements
- Copy paste and drag and drop support enhancements
- Pippyfication (<trac>5543</trac>)
- Better handling of "Run as root in the UI"
- Support for standard desktop applications in Sugar
- Replace matchbox with something more friendlier to standard desktop applications
- Support for .desktop files in the launcher list
- Support startup-notification
- Support standard application icons on the frame
Thoughts from User:cjb
- Power turned on by default.
- Translation of Sugar inside Sugar?
- A working Distribute activity for journal objects (could be in the Journal)
Thoughts from User:Mstone
- Security already contains my immediate security roadmap.
- My user page links to several of my other ideas, many of which are procedural improvements with software components.
- My largest ongoing concern is that we have not yet smoothly carried a deployment through an update to a new major stable release. (Peru may become our first exception to this rule, but this remains to be seen.)
Notes from sj
This page shouldn't be broken down by contributor; it needs serious refactoring and organization by topic and scope.
Library and bundle updates:
- API and .info unification across content and activity bundles. Making both and a general generic bundle clearly described within an overarching bundle format.
- thought experiment : how does one present an activity (has its own isolation-friendly code) that includes a library bundle (its own browser-browsable static content, help and supplemental materials) and a generic resource bundle (a repository of sounds and images) look like? How do other parts of the system (the Journal, Browse, other activities) see and interact with these three collections of material (to browse and copy the code, to view the static content, to aggregate the resource collections with other collections)?
- a Dynamic library implementation
- coordination of a unified help interface building on top of the library bundles defined for each activity on the system.
- integration of some way to update and share this. related to how to leave a comment on/about an activity or file/resource
- coordination of local library bundles, and regional caches of viewed material, school server caches of bundles, and web caches.
- cleaner display of available bundles via a bundle updater; relatd to but not the same as the current software upgrade function, which has a strong emphasis on olpc-stamped/signed materials
Sharing updates:
- provide a way to send a file to someone else. related to bundle (activity).
- provide a way to publish material to the world. related slightly to how edublog works now? see also robson's and juliano's interests here
- add support for asynchronous sharing over time : the sharing of an effort should not require everyone to be online at once.
Adding basic interface pieces that we want to support in the long term, and making them do something familiar, reliably, every time they are at hand. "escape", "stop/start", "share", "view source", "keep", "cut" and "paste" should all do fairly reliable things across activities. Make them do something recognizable even when the activity developer hasn't provided an app-specific hook for same.
Replacement file system
The current file system used on the XO ([JFFS2]) was developed in the days of 32/64MiB NOR flash devices and does not scale well to the 1GiB NAND devices we are using today and certainly will not deal well with larger devices in gen 1.5 and gen 2 systems. The main issues are that JFFS2 needs to scan all blocks at mount time and that the garbage collection algorithm increasingly consumes CPU cycles as the system fills up. The first issue manifests itself as large delays at boot up to mount the file system as it is full (need to quantify this), and the second issue simply means less CPU cycles can be dedicated to user task processing. In the last few years, there has been much activity in the embedded Linux world on alternatives to JFFS2 and we need to investigate these to determine which one best fits our needs:
- YAFFS2 : Has been around for several years and in active use in the embedded space. It does not provide compression out of the box as the devices that use it often carry already compressed data such as MP3 and MPG files.
- UBIFS: A new file system recently merged into the kernel designed for use on large flash devices. Supports compression out of the box and supports disabling compression on a per-inode basis, which is something we desire.
- LogFS : Another JFFS2 replacement designed for fast operation and scalability. Still fairly new and not in very active use AFAIK.
- Btrfs : A very new file system that is primarily targeted for large storage systems with features such as snapshotting, RAID support, and online fsck. David Woodhouse has expressed that he will look into getting this to work on NAND, but it is too new of a code base to consider for 9.1
- Managed NAND : (Not an option for existing XO machines, but might be a direction for future hardware) The industry seems to be moving away from raw NAND in favor of a NAND-chip plus microcontroller solution. The microcontroller implements a Flash Translation Layer that hides the low level NAND details, presenting a higher level interface that looks like an ordinary hard disk, so an ordinary filesystem layout like ext3 could be used. The driving force behind managed NAND is rapid hardware evolution toward multi-level-cell NAND chips and smaller process geometries, which change important NAND parameters like page sizes and ECC. The situation is similar to what happened with hard disks in the 80's, where raw-disk interfaces gave way to SCSI and IDE, which hide the ugly low-level details that changed every technology generation. Managed NAND options include LBA-NAND from Toshiba (pin-compatible with NAND chips), eMMC from multiple vendors (with an SD/MMC-compatible hardware interface), and various "disk on chip" products (IDE-compatible interface).
Development process
- Analyze and quantify the use patterns that trigger issues with JFFS2.
- Gather requirements for a new file system that go beyond solving above issues.
- Develop/integrate a set of tests for FS performance and reliability that take into account our use patterns, the above issues, and any other features we wish to validate.
- Study the three main alternatives (YAFFS, UbiFS, LogFS) to determine what requirements they meet
- Run our FS test suite on above alternatives
- Analyze test results and requirements study and make a decision on which alternative to use.
Deployment process
Once a file system is chosen from the above process, we will have to:
- Integrate the file system into our kernel if it is not upstream (YAFFS2 or Logfs)
- Integrate the file system support packages into our build system and file system images
- Update our build scripts to generate the proper image type for
Activity impact
This change should not have any impact on activity developers as it is at a very low level of the stack.
End-user impact
End users will see faster boot up time and will not see (as much) performance degradation as the file system fills up.
Comments from other interested parties
Browse/XULRunner opportunities from User:Skierpage
XULRunner 1.9.1, the Mozilla code powering Firefox 3.1, should be released in the 9.1.0 timeframe.
Activities and content can use its new features, at the risk of incompatibility with earlier Sugar releases.
<audio> and <video> in the browser
XULRunner 1.9.1 supports the HTML5 <audio> and <video> tags, providing the ability to play OGG audio and video files natively in the browser. This will probably improve performance and reduce memory footprint compared with embedding the Totem plugin, the trade-off needs to be tested and Browse configured accordingly.
Wikipedia articles and thus Wikislices can take advantage of this, and richer multimedia in Browse becomes practical.
Key modules and relevant module roadmaps
Standard information
(These are all semantic annotations that other pages such as Releases can query.)
Release notes: Release notes/Feature roadmap
Status: status::gathering requirements and setting priorities
Primary maintainer: not chosen yet
ECO: not yet
Primary objectives:
- [[Has objective::This is a time-based release per the process at: Release Process Home.]]
- Has objective::Not chosen yet.
The process is not final. It is a set of rough guidelines still being worked out and subject to change.
Lead customer: ?
Build number and URL: Build number::999
Schedule: tbd, should be first half CY 09 and possibly as early as December 2008.
Template proposal
A proposed template for managing this page:Template:Feature_request. In addition to looking nice, use of a template makes it easy to update or adjust the appearance of all feature requests easily in the future.
My cool feature
| Requesters | Some countries | |
| Requirements | Some requirements
| |
| Specification | Detailed specification
| |
| Owners | Some developers |