GNOME and protecting Sugar --

classic Classic list List threaded Threaded
7 messages Options
Reply | Threaded
Open this post in threaded view
|

GNOME and protecting Sugar --

Martin Langhoff
Hi Bernie,

in Paraguay, how did you manage the situation with GNOME and
protecting Sugar from obvious damage.

Back then, the first apparent issue was that ~/Activities appeared
right in the middle of the gnome file manager, and was way too
tempting to mess with it (and messing with it would kill Sugar).

 - How did you solve the problem? There was mention on the list of a
".hidden" file with hints to the file manager, did you use that?
Something else?

 - Were there any other problems? Solutions?

a large deployment is wondering about adding GNOME to the mix
(including Orca is one of the reasons...), and how to manage the
risk...

cheers,



m
--
 [hidden email]
 [hidden email] -- School Server Architect
 - ask interesting questions
 - don't get distracted with shiny stuff  - working code first
 - http://wiki.laptop.org/go/User:Martinlanghoff
_______________________________________________
Devel mailing list
[hidden email]
http://lists.laptop.org/listinfo/devel
Reply | Threaded
Open this post in threaded view
|

Re: GNOME and protecting Sugar --

Chris Ball-8
Hi,

   >  - How did you solve the problem? There was mention on the list
   > of a ".hidden" file with hints to the file manager, did you use
   > that?  Something else?

The .hidden file has its disadvantages: we don't have a way to browse
the source code of all the activities in Sugar, but GNOME can provide
that by letting you double-click on source files to open them in gedit.

Martin, is the deployment also worried about kids deleting activities
inside Sugar?  If so, it sounds like we want a general undeletable
flag set on ~/Activities/ (that the disk-full script can bypass).
Doesn't seem to be a way to achieve that, though.

- Chris.
--
Chris Ball   <[hidden email]>
One Laptop Per Child
_______________________________________________
Devel mailing list
[hidden email]
http://lists.laptop.org/listinfo/devel
Reply | Threaded
Open this post in threaded view
|

Re: GNOME and protecting Sugar --

Chris Ball-8
Hi,

   > Martin, is the deployment also worried about kids deleting
   > activities inside Sugar?  If so, it sounds like we want a general
   > undeletable flag set on ~/Activities/ (that the disk-full script
   > can bypass).  Doesn't seem to be a way to achieve that, though.

If we wanted to do this without caring about an upstreamed solution,
I'd probably suggest applying this:  http://lwn.net/Articles/211193/
and then doing "chattr -R +u /home/olpc/Activities" in the build
scripts, and "chattr -R -u /home/olpc/Activities/$i" in the disk space
cleanup script, just before deleting an activity when out of space.

(As the comments to the patch point out, this is an abuse of the
intended +u semantics.)

- Chris.
--
Chris Ball   <[hidden email]>
One Laptop Per Child
_______________________________________________
Devel mailing list
[hidden email]
http://lists.laptop.org/listinfo/devel
Reply | Threaded
Open this post in threaded view
|

Re: GNOME and protecting Sugar --

bernie
In reply to this post by Martin Langhoff
El Tue, 15-06-2010 a las 18:27 -0400, Martin Langhoff escribió:

> in Paraguay, how did you manage the situation with GNOME and
> protecting Sugar from obvious damage.
>
> Back then, the first apparent issue was that ~/Activities appeared
> right in the middle of the gnome file manager, and was way too
> tempting to mess with it (and messing with it would kill Sugar).
>
>  - How did you solve the problem? There was mention on the list of a
> ".hidden" file with hints to the file manager, did you use that?
> Something else?

During the last development cycle we lacked the time to lock-down GNOME
a little more and we're still paying the consequences :-(


>  - Were there any other problems? Solutions?

Indeed, some kids manage to do damage Sugar, with or without intention.
More frequently, they mess up the panel icons in ways that make it
difficult to restore functionality.

In one case, a kid managed to click "Disable Networking" in nm-applet
and then switch back to Sugar. Not "Disable Wireless", that would have
been easy! It took me one hour of debugging to figure that out.

Everyone, including teachers and teacher trainers, manages to fill up
the filesystem with large multimedia files downloaded from the Internet,
solowing down the system due to frequent jffs2 garbage collections.

In some cases, it's not the user's fault: various programs, including
Firefox and Browse, can hide up to 50MB of junk in dot-files. Clever
users managed to discover some of these locations and passed the word.

If a kid breaks the system in any non obvious way, the technicians will
just reflash it. Now we have a rudimentary UI to restore the journal
backup, but all work done in GNOME is lost.


> a large deployment is wondering about adding GNOME to the mix
> (including Orca is one of the reasons...), and how to manage the
> risk...

On the positive side, many children and teachers simply love GNOME. It
would no longer be possible for us to convince them to upgrade to a
version which removes it.

Perhaps unsurprisingly, a teacher told me that her younger son likes
Sugar, while the older uses GNOME.

To mitigate the problem:

 - lock down the panel:

    http://library.gnome.org/admin/deployment-guide/

 - add a "panic button" to olpc-configure which would bring up a
   text menu with various recovery functions, such as resetting
   GNOME configuration to its default and clearing temporary caches.

 - remove the desktop switcher icon from the Sugar control panel
   give the field technicians a secret shell command to restore it.
   This should prevent children who are too young to figure it out.

 - Hide the Activities. We can't really make them read-only or
   immutable because the updater runs as user olpc.

 - Also hide .sugar

A 100% robust GNOME desktop would require a complete redesign. The end
result might end up being very similar to Sugar! The only practical
advantage of GNOME over Sugar is its flexibility. If we lock it down too
much, it would become quite useless.

Rather than preventing breakage at all costs, which is rather hard, we
could spend some time to improve our backup/restore procedures to
minimize the chance of user data loss.

Tch and Jasg have been working with Esteban (Plan Ceibal) to cleanup and
enhance backups. I'll merge their patches over the next few days to give
them some exposure, even though we're still there are several
opportunities for enhancement.

--
   // Bernie Innocenti - http://codewiz.org/
 \X/  Sugar Labs       - http://sugarlabs.org/

_______________________________________________
Devel mailing list
[hidden email]
http://lists.laptop.org/listinfo/devel
Reply | Threaded
Open this post in threaded view
|

Re: GNOME and protecting Sugar --

Martin Langhoff
On Tue, Jun 15, 2010 at 8:17 PM, Bernie Innocenti <[hidden email]> wrote:
> During the last development cycle we lacked the time to lock-down GNOME
> a little more and we're still paying the consequences :-(

Ouch.

>>  - Were there any other problems? Solutions?
>
> Indeed, some kids manage to do damage Sugar, with or without intention.
> More frequently, they mess up the panel icons in ways that make it
> difficult to restore functionality.

Mess up the panel icons in Sugar or in Gnome?

> In one case, a kid managed to click "Disable Networking" in nm-applet
> and then switch back to Sugar. Not "Disable Wireless", that would have
> been easy! It took me one hour of debugging to figure that out.

That would be in Gnome.

> Everyone, including teachers and teacher trainers, manages to fill up
> the filesystem with large multimedia files downloaded from the Internet,
> solowing down the system due to frequent jffs2 garbage collections.

That has nothing to do with Gnome.

> In some cases, it's not the user's fault: various programs, including
> Firefox and Browse, can hide up to 50MB of junk in dot-files. Clever
> users managed to discover some of these locations and passed the word.

Good to know. Still, not much to do with Gnome.

...


> To mitigate the problem:
>
>  - lock down the panel:
>
>    http://library.gnome.org/admin/deployment-guide/
>
>  - add a "panic button" to olpc-configure which would bring up a
>   text menu with various recovery functions, such as resetting
>   GNOME configuration to its default and clearing temporary caches.
>
>  - remove the desktop switcher icon from the Sugar control panel
>   give the field technicians a secret shell command to restore it.
>   This should prevent children who are too young to figure it out.
>
>  - Hide the Activities. We can't really make them read-only or
>   immutable because the updater runs as user olpc.
>
>  - Also hide .sugar

Ok -- that's a good initial guide - thanks!



m
--
 [hidden email]
 [hidden email] -- School Server Architect
 - ask interesting questions
 - don't get distracted with shiny stuff  - working code first
 - http://wiki.laptop.org/go/User:Martinlanghoff
_______________________________________________
Devel mailing list
[hidden email]
http://lists.laptop.org/listinfo/devel
Reply | Threaded
Open this post in threaded view
|

Re: GNOME and protecting Sugar --

bernie
El Wed, 16-06-2010 a las 08:19 -0400, Martin Langhoff escribió:

> > Indeed, some kids manage to do damage Sugar, with or without intention.
> > More frequently, they mess up the panel icons in ways that make it
> > difficult to restore functionality.
>
> Mess up the panel icons in Sugar or in Gnome?

In GNOME. If you try hard enough, apparently you can make some icons
become invisible and unreachable even though they're somewhere in the
panel.


> > Everyone, including teachers and teacher trainers, manages to fill up
> > the filesystem with large multimedia files downloaded from the Internet,
> > solowing down the system due to frequent jffs2 garbage collections.
>
> That has nothing to do with Gnome.

The problem is applications bypassing the journal: it becomes hard to
hunt down these files to reclaim the space.


> > In some cases, it's not the user's fault: various programs, including
> > Firefox and Browse, can hide up to 50MB of junk in dot-files. Clever
> > users managed to discover some of these locations and passed the word.
>
> Good to know. Still, not much to do with Gnome.

Yes, it's the individual applications, but it's hard for users to figure
out why the disk became full after using Firefox, and how to solve the
problem.

If users learn that deleting random dot files in their homes could fix
problems, there's a risk that they will try to delete them at random.


> Ok -- that's a good initial guide - thanks!

Let me know if you do some work in this direction, I'd be very
interested in joining efforts.

--
   // Bernie Innocenti - http://codewiz.org/
 \X/  Sugar Labs       - http://sugarlabs.org/

_______________________________________________
Devel mailing list
[hidden email]
http://lists.laptop.org/listinfo/devel
Reply | Threaded
Open this post in threaded view
|

Re: [Sugar-devel] GNOME and protecting Sugar --

Luke Faraone
Administrator
-----BEGIN PGP SIGNED MESSAGE-----
Hash: SHA1

On 06/16/2010 10:39 AM, Bernie Innocenti wrote:
> Yes, it's the individual applications, but it's hard for users to figure
> out why the disk became full after using Firefox, and how to solve the
> problem.

Try http://en.wikipedia.org/wiki/Baobab_(software) if you want something
GUI-oriented that will show you what's using your disk.

- --
Luke Faraone
http://luke.faraone.cc
-----BEGIN PGP SIGNATURE-----
Version: GnuPG v1.4.10 (GNU/Linux)

iEYEARECAAYFAkwY5QsACgkQtrC51grHAgbwOwCgmZcreXq5f8oGnML9S3OU5TD2
WOQAn1jcraKZ9+t7SoXlkJlwEeLgOVBW
=yRHT
-----END PGP SIGNATURE-----
_______________________________________________
Devel mailing list
[hidden email]
http://lists.laptop.org/listinfo/devel