[Sugar-devel] [DESIGN RFC] Onboarding

[James Cameron]

No, ds-backup is not part of Sugar.

As I said before, Sugar itself does not use the backup URL.  I've
checked the Sugar code already.

ds-backup (not Sugar) does read the backup URL from GConf schema
/desktop/sugar/backup_url  (Given Sugar has migrated to GSettings,
so too should ds-backup).

Sugar developers do not maintain ds-backup, and it is not in the other
operating system builds that use Sugar.  So it can be ignored unless
Sugar developers want to help the school server developers somehow.  I
don't think anybody here has time for that.

On Mon, Dec 28, 2015 at 04:06:26PM +0200, Tony Anderson wrote:
> 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
> 

-- 
James Cameron
http://quozl.netrek.org/