[Sugar-devel] GSoC proposal status

[Samuel Greenfeld]

Just for the record:

The XO laptop backup mechanism for Sugar creates separate
"datastore-YYYY-MM-DD_HH:MM" directories for each backup.

If I recall correctly, the schoolserver also periodically looks through
these backups, hardlinks identical items to save space, and prunes backups
beyond a set age.

I wouldn't be against fixing and/or redesigning XO backup & restore, but at
least on an XS schoolserver these already are versioned.

I have not tried XSCE to see how it handles things.


On Sat, Feb 20, 2016 at 9:40 PM, Tony Anderson <tony_anderson at usa.net>
wrote:

> Hi, Sam
>
> Thanks for your comments. These issues need review and comment within the
> community.
>
> "Just my 2c, but this complicates the experience a lot.  Do we show this
> temp journal entry to the user?  If so, wouldn't that be confusing?  But it
> we hide it, it becomes more complex.  Eg, a user is adding the finishing
> touches to a diagram in Paint, and adds it to Write activity, however since
> only the old version is visible they don't see the image they expected, and
> become confused.  Maybe this could be better served by basic git features
> in the journal, one of Martin's project ideas I believe."
>
> What I suggest does not change the user's experience of the Journal.
>
> When an activity is launched, it runs as activity.py. If an activity is
> resumed (associated with a data file in the Journal), activity.py loads
> that Journal object. This is the object that is saved when the activity
> terminates. What I am suggesting is that
> activity.py should load a copy of the Journal object (which naturally does
> not exist in the Journal until saved). This enables the activity to make a
> decision to
> overwrite the original object or to save a new object.
>
> You may have noticed this in the Journal. When you resume and then save,
> that object is now the most recent and no longer appears in its original
> chronological position. This reflects that the original journal object is
> saved back to the Journal (normally, by write_file)
>
> The scenario you describe: using Paint and then saving to Write is
> intermediated by the Journal. Paint saves the modified image to the
> Journal. The Write activity then adds it to its document. There should be
> no confusion. Assuming the user gave the image a new name, causing a new
> object to be saved or the user saved in the same name, replacing the object
> in the Journal. If the user has doubt, as at present, he/she should run
> Image Viewer to see the image.
>
> I really don't see git as relevant to the Journal. The proven technique of
> using file names to distinguish objects is easier to implement and familiar
> to experienced computer users. There is nothing to prevent a user from
> using classproject.1, classproject.2, .... to distinguish versions.
>
> "Browse save files work fine cross network connections.  I made one at
> home, and opening it at school I was able to show people all of my tabs."
>
> This worked because in both cases you are connected to the internet.
> Browse is saving urls. Had you opened Browse without a connection, you
> would have received an error. In last year's GSOC, Richa Sehgal added a
> capability to save an html page explicitly but this capability has not yet
> been integrated with Browse.
>
> "Using the metadata is also much harder, it is so easy to just chuck the
> json in there.  Even if we use metadata for eg, saving memorize, the
> metadata will be so activity specific that it is hard to use in a
> reflection tool.  I'm not sure what you want by this."
>
> I am trying to distinguish saving documents from saving state. Memorize
> needs to save state so that a user can resume a game. Naturally, state
> information is specific to the activity. However, it can be saved in the
> metadata record (saved in the Journal as a file). When resumed, Memorize
> can restore its state. Saving the state information as a document requires
> that it have a mime_type. This type would need to be unique to Memorize
> since no other activity would know how to process it (e.g. if it were saved
> as application/plain-text).
>
> As I understand reflection, the goal is to enable a user to look back at
> documents they created or worked on collaboratively. The Journal offers two
> impediments to that - clutter from non document-creating activities and the
> necessity to erase documents due to limited storage capacity. I think we
> need to distinguish between statistical analysis of a user's activities
> (the NSA use of metadata) and using the Journal to show the user a record
> of their own educational journey.
>
>
> "I have to agree with you here.  Having a kind of seamless journal that
> exists partially locally and fully on the school server would be nice.  But
> can a person designing this amuse that the user will have school server
> access most of the time?"
>
> The design is to invoke a backup service when the XO connects to the
> school server. This service recognizes objects which have been modified or
> which are new and saves the associated documents to the server-based store.
> Currently, I use a modified ds_backup.py to save to the /users directory on
> the school server (by serial number of the XO). This program operates using
> datastore as the input. The suggestion of using OwnCloud would make the
> files on the school server visible to the student.
>
> "How do you it fulfilling that need?  Are we exposing the owncloud web
> interface to children?  I pictured a seemless journal interface that merged
> the online storage and the local into one and provided means for pinning
> things locally.  I however picture the group task creating a new type of
> voulme (or web service) that allows for seemless sharing, not aiming to
> provide backup."
>
> These are exactly the issues we should tackle as a community in the
> Sugar-devel design process. OwnCloud is a part of current releases of XSCE.
> Its interface is controlled by administrator configuration. TK has used
> OwnCloud with children in Malaysia. From the user's perspective, the
> OwnCloud interface is a link (login) on the school server.
>
> Currently, I am using the 'keep' circle for this purpose. When it is
> filled, it means a copy of the file is stored locally. The user can 'fill'
> the keep icon to request that a local copy be made (the next time the
> backup is executed). The user can clear the keep icon to show that the
> backup process can delete the local copy.
> If the user 'erases' the Journal object, the backup process will delete
> the school server side copy.
>
> I don't know how sharing can be done seamlessly. The user needs to 'share'
> an object. Another user has to perform some action to add the object to
> his/her Journal. The user needs positive control over this process to
> manage limited storage.
>
> "Ah, hating on the home view ux is fun.  I was actually thinking about
> this a while ago, and wrote a blog post.  I'd like to hear your thoughts as
> it addresses the same issue:
> <https://www.sam.today/blog/sugar-nohomeview-design.html>
> https://www.sam.today/blog/sugar-nohomeview-design.html"
>
> I hate unity on Ubuntu with an abiding passion. The home view is the face
> of Sugar. The problem with the home view is exactly what you point out in
> your
> design document - it now confuses the functions of the Journal with the
> function of the Home View (and List View). This happened when an effort to
> make more use of the Journal resulted in making the default of the Home
> View to restart the latest execution of an activity. This confuses the
> activity with the task. When I launch the Write activity, I may want to
> continue editing an existing document or I may want to create a new one.
>
> I don't know of any desktop implementation that merges these two
> functions. If I own Word, I get a new document with the option to open an
> existing document. If I launch from a file explorer, Word opens that
> document for editing. This was the case with Sugar. If an activity was
> launched from the Home View, a new document was created. If the user
> launched from the Journal (Sugar's file explorer), that file was opened.
>
> I am only proposing that the default in the Home View return to starting
> new by default. The alt key can then be used by those who want to resume
> from the Home View (most of whom will click on the Journal button and
> resume from there).
>
> We should require documents to be stored under a user supplied name but
> much as in most other desktops, this decision should be required when the
> document is saved, not when the activity is opened. In some releases, there
> was an 'alert' when an activity was closed. Unfortunately this alert did
> not solicit a name, but a description of the file. It's implementation was
> a bit aggressive and so it was subsequently deleted. In the original Sugar,
> the user was expected to change the name in the Journal by changing the
> entry in the standard toolbar. In the new toolbar design this field is
> invisible to the user unless they click on the activity icon. Changing the
> name here should change the name in the Journal. However, with the current
> implementation, this is too late. The name change applies to the object
> that was opened so that it does not have the 'save as' ability to create a
> new document.
>
> "I will actually be persuing that feature, and the steps defined on that
> page as a feature for 0.110.  Eventually it will have a feature page, but
> it is the "onboard" branch of
> https://github.com/samdroid-apps/{sugar,sugar-artwork,sugar-toolkit-gtk3}.
> I invite you to test the patches and provide feedback."
>
> Your idea here is brilliant and addresses a continuing problem in the OLPC
> concept. One of the most insistent and persistent criticisms of OLPC has
> been
> the inadequate training of the teachers in a deployment and their
> inability to use the XO effectively. Much of this results from the practice
> of having knowledgeable people from the the gifted side of the digital
> divide go to the challenged side to give an introductory workshop
> (onboarding). Often the
> participants have no 'hard-copy' of the training materials and so soon
> forget details of the training or run into situations not covered.
>
> I would like the implementation to be 'interpretive' in nature so specific
> deployments and members of the community can devise their own scripts. As
> you have pointed out, you are assuming a user who is experienced with
> standard computers and their conventions. This is not the situation in our
> deployments in the challenged environments.
>
> Your scripts indicate a limited set of actions (define a 'hotspot',
> display a window based on cursor position, take a subsequent action based
> on an event). While it will be extra work, if you analyze the actions in
> your design document, you may find that they could be defined by a small
> number of parameters (and links to popups). These could then be documented
> in a script and executed by a 'onboarding' engine.
>
> "Sugarizer has a different collab model (some js thing) to the rest of
> Sugar.  However, SoaS and XO are both running the same Sugar, with the same
> collab model powered by Telepathy.  I have use their collaboration before."
>
> Sadly, I don't know enough about the technical issues. In Walter's
> context, we need a collaboration model for javascript activities
> (Sugar-web-activity). This collaboration model should work also for
> Sugarizer (As I understand it, Walter and Lionel have a goal that any
> Sugar-web-activity also works in Sugarizer).
> Since collab-wrapper is a layer between the underlying technologies and
> the user, it would be very valuable if that same 'api' would work in both
> the Python and the Javascript environments.
>
> Tony
>
>
> On 02/21/2016 05:00 AM, Sam P. wrote:
>
>
>
> On Sat, Feb 20, 2016 at 6:00 PM Tony Anderson <tony_anderson at usa.net>
> wrote:
>
>> Hi, Walter
>>
>> I have some concerns about the proposed GSOC tasks as well as some ideas
>> for new tasks.
>>
>> I agree that the Journal needs rethinking. Below are my thoughts
>> (re-thoughts?).
>>
>> Specifically,
>>
>> The Journal is the file system for Sugar. It does not use directories but
>> instead was intended to collect objects by tag (a la Picasa). Currently,
>> the user sees
>> a scrolled list of objects in chronological order. However, selection is
>> by activity or media type, not by a user defined criteria (as represented
>> in other systems by the directory).
>>
>> The Journal acts as an activity with awkward consequences for the user.
>> On the keyboard, the icon for the Journal (a magnifying glass or search
>> icon - not the icon shown in the frame) is to the left of the zoom group on
>> the keyboard and to the right on the frame. If the Journal is selected, it
>> replaces the current activity when the activity key is pressed. It also
>> appears as an activity when using alt-tab. The first makes using
>> screenshots awkward. Screenshots are given a title by the system of
>> 'Screenshot of ....'. The user needs to switch to the Journal to provide a
>> meaningful name. However, the user must open the frame and click on the
>> activity icon to return to it. If the Journal were viewed as a Sugar
>> service, the activity key would return the user to make another screen shot
>> or continue whatever the task is. Similarly, it is convenient to present
>> the user with instructions to perform a task using a Sugar activity (e.g.
>> Write). The instructions can be given by a web page or by a document in a
>> different activity. For example, a user could show a flag as an image in
>> Image Viewer and try to duplicate the flag with TurtleBlocks. However,
>> using alt-tab to switch between the activities requires cycling through the
>> irrelevant Journal activity or open the frame to click on the activity icon.
>>
>> More importantly, when a Journal object is launched from the Journal
>> activity, it is immediately loaded into activity.py. Therefore, any
>> subsequent action by the user will be saved and the previous object will be
>> overwritten. Suppose I resume the Paint Activity to continue making a
>> picture. However, I decide that after some strokes, the original picture
>> was better. There is nothing as a user I can do to revert to the original.
>> I suspect the reference to git may be intended to address this problem.
>> When an object is launched, activity.py should make a clone. The user
>> should then have the option to revert to the original or to overwrite it or
>> to change it's name so that a new object is created alongside the original.
>> I believe an implementation of the 'save/save as' logic of virtually all
>> other systems should be provided.
>>
>
> Just my 2c, but this complicates the experience a lot.  Do we show this
> temp journal entry to the user?  If so, wouldn't that be confusing?  But it
> we hide it, it becomes more complex.  Eg, a user is adding the finishing
> touches to a diagram in Paint, and adds it to Write activity, however since
> only the old version is visible they don't see the image they expected, and
> become confused.  Maybe this could be better served by basic git features
> in the journal, one of Martin's project ideas I believe.
>
>
>>
>> Probably, in the interests of 'reflection' or possibly statistical data,
>> the Journal saves every activity instance - by default with the name of the
>> activity. Further,
>> most activities now implement write_file to create a data file associated
>> with the object. This creates clutter in the Journal and takes storage for
>> meaningless data files. For example, the Browse activity saves a data file
>> containing URLs of open tabs. Aside from the fact that this creates
>> spurious error messages if Browse is opened in a different network
>> environment, it creates the unnecessary need to save a data file. I believe
>> that activities should only save a data file if the user supplies a name
>> for it and that activities should save state in the metadata, not in a data
>> file. Naturally, it may be desirable for Memorize to save its state so the
>> user can resume the game - this can be done by a field in the metadata.
>> However, when the Paint Activity saves a file, it is reasonable to assume
>> it contains an image (usable, for example, by the Image Viewer).
>>
>
> Browse save files work fine cross network connections.  I made one at
> home, and opening it at school I was able to show people all of my tabs.
>
> Using the metadata is also much harder, it is so easy to just chuck the
> json in there.  Even if we use metadata for eg, saving memorize, the
> metadata will be so activity specific that it is hard to use in a
> reflection tool.  I'm not sure what you want by this.
>
>
>>
>> The XO has limited storage capacity. A freshly installed XO-1 image
>> leaves about 300MB free space. A freshly installed image on other models
>> with 4GB capacity leaves 1.9GB free space. Today, it is almost impossible
>> to buy a USB stick with 2GB storage or less. When the available storage is
>> less than 50MB, the user sees a modal dialog saying the Journal is full
>> with the only option to look at the Journal. The Journal activity shows the
>> amount of available storage which could help a user avoid going below the
>> 50MB limit but is no help to correct the problem. Currently Sugar provides
>> no help to the user in dealing with this problem. Most deployments I am
>> familiar with reflash the laptop when this happens. So much for reflection.
>> Essentially this step erases the user's prior work.
>>
>> Journal backup, according to James Cameron, is beyond the scope of Sugar.
>> The present Sugar-independent (?!?) scheme was developed by Martin Langhoff
>> using rsync to create snapshots on the school server. This was a bad
>> decision. If a user deletes an object from the Joural on the XO to create
>> space, that object is deleted from the backup. The backup should be
>> considered the actual repository of Journal entries with effectively
>> unlimited space and the backup on the XO should upload new and modified
>> objects to that repository. Further the user should have a way to recall
>> data files from the repository as needed. In general, the limited storage
>> on the XO should be viewed as a cache of the users' data kept on the school
>> server.  Consider that OLPC recommends a minimum of 2GB storage on the
>> school server (/library/users) per registered laptop. However, at most, the
>> user has 1.9GB on the XO (which includes optional Sugar activities and
>> optional media and e-book downloads).
>>
>
> I have to agree with you here.  Having a kind of seamless journal that
> exists partially locally and fully on the school server would be nice.  But
> can a person designing this amuse that the user will have school server
> access most of the time?
>
>
>>
>> The proposed GSOC tasks include statements such as: "This idea needs more
>> thought and coding." I believe SugarLabs is responsible for doing the
>> thought and proposing the guidelines for implementation. This is not an
>> appropriate task for a GSOC participant. One of the obvious problems as a
>> Mentor in last years GSOC is that the participants had no experience with
>> or understanding of Sugar or how it works on an XO. The development
>> environment gives the developer many capabilities not available on an XO
>> (fast gpu, large memory, effectively unlimited storage, 24/7 high speed (>
>> 1MB/s) access to the internet, 1080p screen resolution and aspect ratio).
>> Further, Sugar on the development environment is not available on the XO
>> (and vice versa). Asking participants from this environment to design ui
>> for users on the other side of the digital divide requires an unreasonable
>> expectation of their ability to empathize.
>>
>> I would propose these tasks more as follows:
>>
>> 1. Brief explanation The Sugar Journal should provide a 'save/save as'
>> interface which should enable a user to choose whether to save the current
>> document when an activity is closed. The interface should require a name
>> change from 'current.activity' to a user supplied name. If the document is
>> derived from one currently saved in the Journal, the user should be allowed
>> to save (overwrite) or save as (create new document) by giving a new name
>> to the document. This could be accomplished by showing a modal dialog at
>> close time requesting the user to supply a name or not save the document.
>> If the document has a user supplied name, the dialog could request the user
>> to save or to provide a new name to create a new document.
>> Note: this approach satisfies the needs referenced in the git task. Git
>> is a little like a hammer looking for a nail. Using git for this function
>> will likely double the size of the data stored in the Journal (based on
>> normal experience using git). Unfortunately, we don't have this space on
>> the XOs. The standard
>> save/save as gives the user the ability to manage versions by using
>> unique names.
>>
>> 2. Brief explanation
>>         The Journal activity is currently implemented as an activity. It
>> should be changed to a 'service'. This means the Journal icon on the frame
>> should be to the left of the zoom group icons to match the sequence on the
>> keyboard. The Journal is always running as a service when the Sugar is
>> running. It is accessible by the Journal key on the keyboard and also by
>> the Journal button in the frame. When the view is switched to the Journal,
>> clicking on the activity view (right most key of the zoom group) should
>> switch the screen back to the current activity.
>>
>> 3. Brief explanation
>>         Sugar provides a method to backup and restore the Journal (one
>> method to a USB key and one method to the school server). The Journal also
>> provides a select box to enable an action to be taken for all selected
>> objects. This mechanism should be sufficient for the USB key case. However,
>> the school server backup currently is based on taking a snapshot of the
>> current Journal state. This means the size of the objects in a user's
>> Journal cannot exceed the available local store on an XO (300MB for an
>> XO-1, 1.9GB for other models). A mechanism is needed to save on the school
>> server all documents created by the user and to restore a selected object
>> to the Journal from the school server. Since many documents may represent
>> library objects (e-books, audio, image or video media), the mechanism
>> should recognize these and not save them as user documents. However, the
>> metadata saved should enable the system to download the library items again
>> as needed (and, as available).
>>     For example, the mechanism may be to upload Journal documents to an
>> OwnCloud repository. The user could then select an item in the OwnCloud
>> repository to be downloaded to the Journal. The user could also share any
>> item in OwnCloud with other user groups or individuals.
>>
>> Note: This would essentially accomplish the intent of the group/buddy
>> task. Further, OwnCloud could be provided on a school server or on the
>> internet. as appropriate.
>>
>
> How do you it fulfilling that need?  Are we exposing the owncloud web
> interface to children?  I pictured a seemless journal interface that merged
> the online storage and the local into one and provided means for pinning
> things locally.  I however picture the group task creating a new type of
> voulme (or web service) that allows for seemless sharing, not aiming to
> provide backup.
>
>> 4. Brief explanation
>>     One goal of Sugar is to record information about user sessions. This
>> is currently accomplished by creating statistics from the metadata stored
>> in the Journal.
>> Unfortunately, a consequence is that the Journal view fills with
>> essentially meaningless links to this metadata (mine fills with Terminal
>> Activity and Log entries).
>> This makes it much harder for the user to identify meaningful Journal
>> objects (documents, images, items from the library, ...). A mechanism is
>> needed to that session data can be logged independently of the Journal view
>> (i.e not shown on the screen). This logged information should be
>> transferred to a backup repository (e.g. school server or usb drive) as
>> soon as possible and deleted from the local store to free up space. The
>> available reporting activities should be modified to use this new mechanism.
>>
>> 5. Brief explanation
>>     The Journal icon provides information the amount of free space in the
>> user's store. if this amount is less than 50MB, a dialog is shown requiring
>> the user to switch to the Journal view and claiming that the 'Journal is
>> Full'. This message is, at best, misleading. The available storage can
>> arise from several causes - the fact that an activities 'instance' store
>> was not deleted, the space required by installed activities, or space
>> required by data files in /home/olpc/Library, or data stored by activities
>> in 'data', 'instance' or 'temp'. Currently, Sugar provides no guidance or
>> help to enable a user to deal with this problem short of reflashing the
>> image. The goal of this task is to provide a quota management system on
>> storage with a way for the user (e.g. by a special Sugar activity) to
>> analyze the usage of storage and to save by usb key or school server or
>> cloud storage large or currently unneeded items and then delete them. The
>> system should show the user the size of items and provide updates on how
>> much storage has been made free by his/her actions.
>>
>> 6. Brief explanation
>>     In Sugar's Home View, a click on an activity icon by default resumes
>> the most recent instance of the activity. This capability is designed into
>> the Journal and is redundant in the Home View. A Sugar activity is a tool
>> to enable the user to accomplish some task. If that task is not completed,
>> the user can resume it via the Journal. If the tool is to be used on a new
>> task, the user can launch it from the Home View. The current Home View
>> assumes that the intent of the user is to continue the most recent task
>> with that tool.
>>
>> This task should set the Home View default to launch a new instance of
>> the activity. The Alt key should be set to enable resuming a selected
>> instance of the activity.  By serendipity, this also shows the Home View
>> with black and white icons. Icons with color signifying a resumable
>> instance use the colors associated with the laptop. Unfortunately many of
>> these color combinations make the icon much more difficult to distinguish
>> than the black and white version.
>>
>
> Ah, hating on the home view ux is fun.  I was actually thinking about this
> a while ago, and wrote a blog post.  I'd like to hear your thoughts as it
> addresses the same issue:
> https://www.sam.today/blog/sugar-nohomeview-design.html
>
>
>> 7. Brief explanation.
>>      Sugar provides a 'web services' capability. However, these services
>> are only available to an XO which has connection to the internet. This is
>> not useful to a large number of users who do not have internet access. The
>> school server (e.g. XSCE) provides an alternative to the internet for many
>> deployments. This task is to provide a capability on the school server to
>> support some or all of the Sugar web services (e.g. by OwnCloud or ELGG).
>>
>> 8. Brief explanation
>>     There are a number of Sugar activities which currently require access
>> to the internet (InfoSlicer, GetBooks). These activities should have an
>> option to function with the school server. For example, GetBooks could
>> access books on the school server and InfoSlicer could create slices from
>> Wikipedia on the school server as Journal objects.
>>
>> 9. Brief explanation
>>     Sugar users are often new to computers and not familiar with other
>> operating systems. We need a mechanism to allow users to more quickly
>> develop skills in using the capabilities of the XO ('onboarding'). One
>> proposal is to develop scripts which lead the user through a series of
>> interactive steps illustrating common usage of the XO with Sugar (
>> <https://www.sam.today/blog/sugar-onboard-design.html>
>> https://www.sam.today/blog/sugar-onboard-design.html). This task is to
>> implement an interpretive system that allows
>> deployments or experienced users to create an 'onboard' script that
>> guides the user to carry out a task. The referenced proposal suggests some
>> user tasks where this mechanism could be employed. Since there is no finite
>> list of these tasks, an interpretive approach enables the scripts to be
>> created as necessary.
>> For example, how does a user switch to the Gnome desktop? A script could
>> be created guiding the user through the necessary steps. How does the user
>> make a screen shot, use Gimp in the gnome desktop to crop and resize, and
>> then insert it as an image in a Write document? How does the user initiate
>> or join a chat?
>>
>
> I will actually be persuing that feature, and the steps defined on that
> page as a feature for 0.110.  Eventually it will have a feature page, but
> it is the "onboard" branch of
> https://github.com/samdroid-apps/{sugar,sugar-artwork,sugar-toolkit-gtk3}.
> I invite you to test the patches and provide feedback.
>
>
>> 10. Brief explanation
>>     Sugar is available on the XO and some other platforms. In particular,
>> Sugar is available for 64-bit systems with Ubuntu 14.04 LTS installed (
>> <http://wiki.sugarlabs.org/go/Ubuntu>http://wiki.sugarlabs.org/go/Ubuntu).
>> Unfortunately, this procedure does not work with 32-bit systems. There
>> exists an opportunity to deploy Sugar
>> with relatively inexpensive or refurbished laptops which do not provide
>> 64-bit support. This task is to create a comparable version of Sugar which
>> can
>> be installed on 32-bit systems as an alternate Ubuntu desktop.
>>
>> 11. Brief explanation
>>     Many deployments want to protect their XOs against theft. OLPC
>> provides an 'activation lease' mechanism in firmware which makes it
>> impossible to
>> boot an XO once the activation lease has expired, unless the XO has
>> access to the key via a removable device. This task is to provide a similar
>> mechanism which is not dependent on OLPC. A USB key or network device
>> (school server) should have an inventory of XOs identified by serial_number
>> (and, perhaps, uuid). if this key is readable by the firmware, the XO
>> should boot. If the key is not readable (e.g. reflash), then the XO should
>> boot if the key is readable on a removable device or on the connected
>> school server. [this suggests the XO can connect to the schoolserver by
>> firmware alone - might be difficult].
>>     Whenever an XO connects with the network device, the network device
>> should confirm the activation lease and extend it by a time specified by
>> the deployment (administrative owner of the network device). A report
>> should be available to the deployment on the XO inventory and when each was
>> last connected to enable detection of 'missing' XOs. Perhaps, the mechanism
>> should have a 'blacklist' of serial_numbers of 'missing' laptops. If such a
>> laptop is connected, it could be allowed to proceed with a warning to the
>> administrator that the 'missing' laptop is in the house. This mechanism
>> should be available for optional implementation by a deployment without
>> reference to a central organization such as OLPC.
>>
>> 12. Brief explanation
>>     OLPC firmware in the XO-1 supported a feature called 'nandblaster'.
>> This mechanism allowed a 'master' XO to broadcast its image in a loop to
>> the XO Lan. Other XOs could then be flashed by the firmware by making a
>> copy of each sector as it was broadcast to their local store. Once a cycle
>> in the loop was finished, the XO could detach and was ready for reboot with
>> the newly installed image. This task is to re-create this capability where
>> the 'master' XO image could be on a network device such as a school server
>> or another XO. This mechanism should store a new version of firmware (as
>> done currently) so that the firmware upgrade can be automatically installed
>> on the next boot when connected to an AC adapter.
>>
>> 13. Brief explanation
>>     The OLPC model is that each user has full possession and is the only
>> user of an XO laptop. Therefore, Sugar assumes a 1-1 correspondence between
>> users and XO serial numbers. However, Sugar is being used on other
>> platforms (e.g. SOAS), where there is no obvious equivalent to a serial
>> number. SOAS and James Cameron have created versions of Sugar which do not
>> assume the user is 'olpc', but implement a standard username/password login
>> system. The users storage is allocated to his/her home directory.
>>     This task is to create a Sugar image for the XO which allows for
>> user's to login by username and password. The basic task is to move the
>> Activities folder
>> to a common space so that only one copy is needed per system. This will
>> support deployments where one set of laptops are shared across multiple
>> classes (and users) or where there one laptop is shared between two
>> students - one in a morning shift and the other in an afternoon shift.
>>
>> 14. Brief explanation
>>     The TuxMath activity is popular with deployments. However, the
>> upstream version appears to be abandoned. This task would be to implement a
>> sugar-web-activity math game comparable to TuxMath.
>>
>>
>>
>> I have some comments on the other tasks:
>>
>> "The newer Sugar builds have performance issues on *some old hardware*
>> with limited memory. This is keeping some Sugar deployments from upgrading.
>> This project is to look into the performance issues and tune Sugar for
>> low-memory devices."
>>
>> I think this task should be unambiguously focused on the XO-1 (1GB
>> store). The majority of deployed XOs are XO-1s with a 1GB store. These
>> deployments generally do not have the funds to purchase and deploy an SDHC
>> card for these devices (ask Adam about this possibility in Haiti, I was not
>> able to get a firm number from Rwanda but I believe they may have deployed
>> more than several thousand XO-1s. The cost is not so much the card itself,
>> but the logistics cost to prepare the cards with an XO-1 image and to
>> deliver the cards to the deployment locations).
>>
>> The performance problem is not limited to low-memory (250GB). It is also
>> related to no gpu, low persistent store, slower and more limited processor
>> and so on.). It is also likely that their are specific limitations on
>> executing newer software releases on this hardware. As a minimum, someone
>> who takes on this task needs an XO-1 (and possibly access to an XO-1.5 for
>> performance comparisons - a task for the mentor?).
>>
>> One task could be to identify some significant performance measures (a
>> form of benchmark which could be applied to all models and releases to
>> obtain
>> relative performance measures). The task also requires some analysis to
>> determine the bottlenecks limiting performance (processor speed, graphics
>> speed, memory usage, storage access times, etc.). This, in turn, requires
>> defining important workloads (boot, launch activity, switch activities,
>> shut down activity, shut down system, connect to network, effective network
>> speed, and so on). I think the community should be able to help with this
>> (what are the most significant tasks in Haiti which have unacceptable
>> response times on the XO-1?).
>>
>> It is likely that one result of this task may be to limit the
>> capabilities of Sugar on the XO-1.
>>
>> "Now that JavaScript has become a first class citizen in the Sugar
>> ecosystem, we must re-design our collaboration model to allow collaboration
>> between web activities regardless of the platform."
>>
>> I am not sure what is meant here by platform. Except for development
>> environments, I am only aware of Sugarizer, SOAS, and Sugar on XO in the
>> wild (i.e in use by deployments without any developers or computer
>> professionals on site). As I understood it, Sugar has adopted the
>> collab-wrapper model for Sugar activities. Is this collab-wrapper usable in
>> a Javascript environment? Is is possible for XO users to collaborate in
>> this model with users of SOAS or Sugarizer?
>>
>
> Sugarizer has a different collab model (some js thing) to the rest of
> Sugar.  However, SoaS and XO are both running the same Sugar, with the same
> collab model powered by Telepathy.  I have use their collaboration before.
>
>
>> Nutritional Microworld
>>
>> relevant tool—one that invites learners to explore fundamental concepts
>> of nutrition that are both intrinsic to music yet transcendent of a
>> specific discipline.
>> I assume the reference to music is a typo.
>>
>> At Eurovision 2014, a speaker demonstrated nsound - an alternative to
>> csound. The claim is a simpler and more understandable api.
>>
>> Turtle Confusion and Turtle Flags.
>>     These activities reproduce the Turtle Blocks engine. I think a
>> simpler solution is to provide the confusion images and the flag images via
>> html and have the user create them using the existing javascript Turtle
>> implementation. The user can easily switch screens via alt-tab or the
>> frame. For example, the confusion challenges and the flags could be
>> presented by an .xol content.
>>
>> I'll try to send you some additional task proposals as soon as I can.
>>
>> Tony
>>
>>
>> On 02/19/2016 05:30 PM, Walter Bender wrote:
>>
>> FYI, as per the discussion at this month's SLOB meeting, I submitted an
>> application to Google Summer of Code on behalf of Sugar Lbs. Lionel has
>> agreed to be the co-admin this summer. We should hear by the end of the
>> month as to whether or not we are accepted and how many slots we get.
>>
>> It is important that we add some more potential projects to the list in
>> the wiki over the next few days as a show of interest from the community.
>> Please add your ideas to:
>>
>> https://wiki.sugarlabs.org/go/Summer_of_Code/2016
>>
>> Thanks.
>>
>> -walter
>>
>> --
>> Walter Bender
>> Sugar Labs
>> http://www.sugarlabs.org
>>
>>
>>
>> _______________________________________________
>> Sugar-devel mailing listSugar-devel at lists.sugarlabs.orghttp://lists.sugarlabs.org/listinfo/sugar-devel
>>
>>
>> _______________________________________________
>> Sugar-devel mailing list
>> Sugar-devel at lists.sugarlabs.org
>> http://lists.sugarlabs.org/listinfo/sugar-devel
>>
>
>
> _______________________________________________
> Sugar-devel mailing list
> Sugar-devel at lists.sugarlabs.org
> http://lists.sugarlabs.org/listinfo/sugar-devel
>
>
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://lists.sugarlabs.org/archive/sugar-devel/attachments/20160221/06a46b2e/attachment-0001.html>