Installation of non-sugar programs

[Bernie Innocenti]

On Sun, 2010-03-14 at 18:59 -0400, Richard A. Smith wrote:
> Bernie,
> 
> Thanks again for your talk to the support gang on Sunday.  It was very 
> informative.

I have some more notes about the schools and the school servers which
need to be cleaned up for the blog. Anything else you like to know, let
me know and I'll ask around.

This week I'll spend more time with the formadores (teacher trainers).


> Some of the topics you discussed about usage differences between the 
> teachers and children and the _very_ different views they have about 
> keeping data made me think about a 1.5 discussion that has surfaced a 
> few times.
> 
> It revolves around the division of space of the disk in 1.5.  We 
> currently have  /boot and / in separate partitions.

Why split / and /boot? On Linux distros, this is a work-around for
legacy BIOSes which were unable to read beyond the 1024 cylinder,
but it's unlikely that OFW is affected :-)

Does / perhaps use filesystem options that OFW cannot cope with?


>   There is discussion 
> that we should continue and break /home out into its own partition as 
> well.  There are various pros and cons associated with separation of 
> system and user data.  A lot of these are based on how the developers 
> think the system is used.  You of course have real world data on usage 
> that is very valuable.

I have seen a few user journals. One was 500MB and could not be restored
on the new system.

Many kids who came to the lab, however, had journals that were almost
empty. They probably delete things manually, but I don't know why. Maybe
to avoid performance degradation? To hide what they're doing from us?
I'll ask this question next time.


> One con of separate partitions is that the amount of stuff a user can 
> install via yum is now limited by the size of the system partition 
> rather than by the available disk space because of yum limitations.
>
> Based on your observations do you see that as a pro or con?  Is there a 
> large amount of installation of non-sugar apps for Gnome in the F11-XO1 
> images? Sugar apps are installed in the user data so they would not 
> suffer from the limit.

So far the kids have not had enough time to play with Gnome. Users don't
have the PackageKit GUI, so they would really have to use the command
line to install stuff.

The moment they figure out that there are ~20,000 installable packages,
including thousands of games, you can bet they will go wild and install
as much stuff as possible, limited only by available bandwidth.

Since the entire 4GB flash wouldn't suffice, we could as well restrict
them to a mere 2GB or even less. In any case, let's hope that Yum will
work robustly in low disk space situations.


> Do you think that breaking out /home into its own partition would help 
> or hurt how Paraguay the folk are operating?  You discussed 3 very 
> different user groups. Techs vs teachers vs children.

I think partitioning would help the technicians, saving them from the
backup-restore step. It opens some new technical issues, too:

1) Activities would fall out of sync with respect to the system on
   upgrades (and downgrades!). Many of the non-trivial activities
   (Browse, Write, eToys) have implicit dependencies on exact version
   of system libraries.

2) Flashing is also used as a remedy for cases of corruption.
   Scartch and other non-sugarized activities can be creatively abused
   to overwrite random files in their homes. Not to mention software
   bugs.

To solve (1), we could move activities somewhere in the system
partition, where they belong. Unprivileged installation is still
possible by setting permissions accordingly.

To solve (2), we might create a "panic usb" which would format /home and
reset it to default.

Alternatively, we could keep one partition and give the technicians a
bootable usb stick which would automate the backup / copy-nand / restore
procedure. At this time, they're using two simple scripts to tar up the
journal and restore it which have to be invoked from the terminal.

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