[Sugar-devel] [DESIGN RFC] Onboarding

[Tony Anderson]

Hi, James

This thread is growing but each time there is new information.

At least as of 0.106, Sugar has the backup URL (see 
/usr/bin/ds_backup.py and ds_backup.sh). I can't say whether they are being
used.

The primary flaw in ds_backup.py is that it performs an rsync (with -d). 
This means if a user deletes a Journal object on
the XO, it will be deleted from the backup. Since users often delete 
Journal objects to free space, this means those items are lost.

The strategy I use is to back up Journal objects individually. The 
'keep' star is used to control backup and restore. If the user clears 
the keep,
the backup deletes the local document to free space. if the 'keep' star 
is set, the backup downloads the document. In this way, no student's 
documents
are lost because of storage limitations.

When storage is full (the infernal modal dialog you get 'Your Journal is 
Full'), common practice is to reflash the XO. In this context restoring 
the Journal simply recreates the original problem. Incremental backup 
means that the restore only restores the metadata, the documents remain 
on the school server. The user can request individual documents be 
downloaded to the XO as needed.
The fact that the backup and restore control panel doesn't support a 
school server doesn't surprise me - it is characteristic of the 
disconnect I am
referring to. Integrating Sugar with the school server causes problems 
for users (and developers) who do not have one.

There are those who feel the goal of OLPC (the concept not the 
organization) is to provide one laptop per individual child working at 
home as is
typical in the developed world. This allows the comfortable assumption 
that users have access to the same resources as the developers 
(continuous broadband internet, for example).

However, my involvement and I believe that of many others is to support 
deployments in the developing world which provide one laptop per child
in a community school in the developing world (or developed world) where 
internet access is rarely possible or is too expensive or too slow. In 
this environment, the schoolserver provides a means to give the students 
local access to information from the internet.

Where funding is insufficient, more than one child may need to share a 
laptop. As Walter Bender described it in the Malaysia Summit, 'one 
laptop per child' means there are enough laptops that each child in the 
group has their own to use at that time.

In such deployments, there is rarely enough funding for extra equipment 
such as usb keys, external hard drives and so on. It is a design goal to
satisfy requirements with the resources available (including the school 
server and  related network support). Since the XO has limited storage, 
backing
up the school server is essential to preserving the documents produced 
by the users (not just for hardware failure, but more importantly to 
handle the situation when available storage falls below 50MB).

The login at install time is not needed. However, the code could be 
re-used to provide a standard session login with multiple users sharing 
a laptop.

Tony

On 12/28/2015 09:20 AM, James Cameron wrote:
> Yes, but we're talking about Sugar here, not the XO.  Sugar supports
> more than the XO.
>
> Sugar supports a school server using the register feature, which sets
> a Jabber server and a backup URL.
>
> Sugar uses the new Jabber server as a replacement for the default
> provided by Sugar Labs.
>
> Sugar does not use the backup URL.
>
> Sugar's backup and restore control panel is for local media only;
> there is no backend for a school server.  Your school server
> maintainers don't appear to have noticed the disconnect.
>
> The move to system packaged activities instead of user directory was
> not a significant change in our Ubuntu integration.  That work was
> already led by Debian.  Similar had been done by Fedora SoaS years
> before.
>
> I've no plans to restore a login to the XO images.  This isn't
> something that OLPC needs.  We'd prefer that each child have a laptop.
>
> On Mon, Dec 28, 2015 at 08:02:27AM +0200, Tony Anderson wrote:
>> Hi, James
>>
>> One of the big problems in our community is the disconnect between
>> the school server and the XO. The two work together form a system.
>> Ejabberd supports gabble which is how collaboration works for XOs
>> connected to a school server. The design of the school server has
>> always made
>> Moodle the opening screen for http://schoolserver (which is where
>> you are directed by the button on the Browse main screen).
>>
>> I think you made some modifications to Sugar for the Ubuntu version
>> such as moving the Activities folder to common space. This would
>> also have to
>> be done for the XO images. I suppose you could consider backup and
>> restore of the Journal out of scope of Sugar as well - but it is
>> essential for laptops with minimal storage. This is what the
>> 'register' menu option is about. While Ubuntu provides a login, this
>> would have to be restored to the XO images.
>> I am sure there are other issues that will come up.
>>
>> However, you have provided an exciting opportunity.
>>
>> Tony
>>
>> On 12/28/2015 07:47 AM, James Cameron wrote:
>>> Sure, but as I said, not really a function of Sugar, but instead of
>>> the operating system that Sugar is installed on.  Sugar does all the
>>> right things already.  The other things you are using with Sugar, such
>>> as Moodle and ejabberd, are also somewhat out of scope for Sugar.
>>>
>>> On Mon, Dec 28, 2015 at 07:32:59AM +0200, Tony Anderson wrote:
>>>> Hi, James
>>>>
>>>> This issue of supporting more than one user per machine is very
>>>> important in the wild (not many deployments can afford literally one
>>>> laptop per
>>>> child and so provide classroom sets with each laptop having multiple users.
>>>>
>>>> On registration, a new user is created server-side: the serial
>>>> number of the laptop. This is used for login to Moodle but more
>>>> importantly for backup of the Journal and for ejabberd (association
>>>> between nick and serial-number).
>>>>
>>>> It would be relatively easy to make the registration procedure
>>>> create a username account on the school server and to
>>>> backup to and restore from that account. Moodle can be fixed
>>>> relatively easily. I am not familiar with the details of ejabberd
>>>> and
>>>> collaboration so that will require some research
>>>>
>>>> I'll be able to give this serious attention when I get back to the
>>>> Philippines in
>>>> late January. You have created a very exciting opportunity for Sugar.
>>>>
>>>> Tony
>>>>
>>>>
>>>>
>>>> On 12/27/2015 11:51 PM, James Cameron wrote:
>>>>> Thanks Sam!
>>>>>
>>>>> I like the design.  It reminds me of one we discussed in Netrek
>>>>> development at about the same phase of the project lifecycle; long
>>>>> after the peak of interest.
>>>>>
>>>>> It doesn't look like it would be much programming.
>>>>>
>>>>> It could involve sound as well; as reinforcement of each goal.
>>>>>
>>>>> It could show progress more clearly; a series of "achievements" which
>>>>> are "unlocked".
>>>>>
>>>>> Trivial text layout error in the design makes reading it difficult;
>>>>> most visible in the "Interface Design" text before the next image,
>>>>> where forced line breaks occur, after "yet" and "overlays".  Probably
>>>>> caused by browser width not varied in testing.
>>>>>
>>>>> Some hasty JavaScript might show animation of hotspot engagement.
>>>>>
>>>>> A definition of onboard may be useful.
>>>>>
>>>>> I'm interested in seeing more.
>>>>>
>>>>> --
>>>>>
>>>>> Tony raises some important problems, several of which are not
>>>>> functions of Sugar, but of software integration choices made by Sugar
>>>>> downstream organisations.  The most interesting one for me personally
>>>>> is how to support more than one user per machine, but this isn't
>>>>> something that OLPC needs, so the wider community should drive it
>>>>> forward.
>>>>>
>>>>> A school server with accounts, a login greeter on the laptop
>>>>> integrated with the authentication server, and a locally cached
>>>>> network filesystem?  Perhaps the school server guys and gals could
>>>>> look into it?
>>>>>
>>>>> Meanwhile, in my experience, Sugar handles multiple login users very
>>>>> well already.
>>>>>
>>>> _______________________________________________
>>>> 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