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@lists.sugarlabs.org
http://lists.sugarlabs.org/listinfo/sugar-devel
_______________________________________________
Sugar-devel mailing list
Sugar-devel@lists.sugarlabs.org
http://lists.sugarlabs.org/listinfo/sugar-devel
_______________________________________________
Sugar-devel mailing list
Sugar-devel@lists.sugarlabs.org
http://lists.sugarlabs.org/listinfo/sugar-devel
