[Sugar-devel] Enhancing Sugar to support multiple users

[pbrobinson at gmail.com]

On Mon, Sep 6, 2010 at 2:05 PM, Daniel Drake <dsd at laptop.org> wrote:
> On 5 September 2010 13:57, Christoph Derndorfer
> <christoph.derndorfer at gmail.com> wrote:
>> Hi,
>>
>> I just created a new ticket (http://bugs.sugarlabs.org/ticket/2292) to get
>> some discussions started on what changes need to be made to Sugar to work
>> well in an environment where multiple users will work on the same machine
>> (which is how Peru's next 300,000 XOs will be used:
>> http://www.olpcnews.com/countries/peru/peru_between_one_laptop_per_child_and_seven_children_per_laptop.html).
>>
>> Obviously this touches upon a lot of areas from simple naming of the
>> machine, over the Journal, backups and probably a whole host of other issues
>> that I haven't though of yet.
>
> When we discussed this while I was in Peru, one requirement they
> identified is that the kid would log onto an XO one day and do some
> work, and then log onto another XO the following week and continue the
> same work.
>
> Assuming this still stands, this strongly calls for a network-based
> home directory system with some kind of network login service (but
> someone with experience in such areas should comment). This would
> require a number of changes at the OS level and server level, but
> Sugar would be left untouched, as far as I can think.

The standard way of doing this in unix is to use nfs and automount
with NIS/LDAP authentication. This would mount the users home
directory on login. There's a number of issues that come up with this
implementation for the XOs in that wireless would need to connect
prior to this and NFS over wifi would be interesting at best due to
wifi dropouts. To mitigate that problem you'd probably have to wedge
some of the caching filesystems that are being developed to allow the
home directory to be cached. Suddenly your getting a very complex
solution to fix the problem.

The other possible alternative to this would be to use something like
couchdb to store the contents of the journal and associated config
files where you can have a local couchdb that replicates to a remote
service. This might be the simpler solution but would obviously
require development.

Peter