[Sugar-devel] GSoC proposal status
Tony Anderson
tony_anderson at usa.net
Sun Feb 21 19:30:10 EST 2016
I haven't used the ds_backup.py as released, but AFIK rsync uses the -d
flag which deletes objects from the backup if they have been deleted in
the Journal.
While it does make multiple snapshots, AFIK, the restore mechanism does
not support using them for versioning. I don't believe there are any
changes in the XSCE implementation form XS-6.
Tony
On 02/22/2016 07:56 AM, Samuel Greenfeld wrote:
> 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
> <mailto: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"
>
> 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
> <https://github.com/samdroid-apps/%7Bsugar,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 <mailto: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).
>> 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
>> <https://github.com/samdroid-apps/%7Bsugar,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).
>> 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 list
>>> Sugar-devel at lists.sugarlabs.org
>>> <mailto:Sugar-devel at lists.sugarlabs.org>
>>> http://lists.sugarlabs.org/listinfo/sugar-devel
>>
>> _______________________________________________
>> Sugar-devel mailing list
>> Sugar-devel at lists.sugarlabs.org
>> <mailto:Sugar-devel at lists.sugarlabs.org>
>> http://lists.sugarlabs.org/listinfo/sugar-devel
>>
>
>
> _______________________________________________
> Sugar-devel mailing list
> Sugar-devel at lists.sugarlabs.org
> <mailto: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/20160222/3a1053c3/attachment-0001.html>
More information about the Sugar-devel
mailing list