[Sugar-devel] Enhancing Sugar to support multiple users
simon at schampijer.de
Tue Sep 7 04:40:12 EDT 2010
On 09/06/2010 03:40 PM, pbrobinson at gmail.com wrote:
> 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:
>>> 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:
>>> 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.
Yes, this is true. I obviously used wired connections when using
LDAP/NFS. In a lap with fixed equipment this is an easy setup. For the
XOs, I agree this could lead to frustration. (even in my case kids very
confused because someone has pulled the cables)
> 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.
Interesting. A solution where you only need to sync twice (start/stop)
might be better in the wifi environment.
More information about the Devel