On Mon, Sep 6, 2010 at 2:05 PM, Daniel Drake <d...@laptop.org> wrote: > On 5 September 2010 13:57, Christoph Derndorfer > <christoph.derndor...@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 _______________________________________________ Devel mailing list Devel@lists.laptop.org http://lists.laptop.org/listinfo/devel