[IAEP] Announcing Fedora Sugar Spin!

[Greg Dekoenigsberg]

Thanks for the detailed analysis, Morgan.  Much appreciated.

--g

On Wed, 12 Nov 2008, Morgan Collett wrote:

> On Wed, Nov 12, 2008 at 18:02, Greg Dekoenigsberg <gdk at redhat.com> wrote:
>>
>> On Wed, 12 Nov 2008, Bill Kerr wrote:
>>
>>>      Meaning what, exactly?  Can you be more specific?
>>>
>>> Well, it's meant to be possible for collaboration to work out of the box.
>>> This did not happen with Wolfgang's Live CD converted to USB keys.
>>>
>>> Someone reported earlier on this list  that collaboration did work from
>>> USB keys on a Ubuntu network
>>>
>>> from morgan collett: "Link local presence should "just work", but I've
>>> never used the LiveCD images."
>>>
>>> At any rate Morgan asked us for some files and after they were sent
>>> reported back:
>>>
>>> from morgan collett:
>>> "Thanks for the logs. presenceservice.log shows that salut
>>> (LinkLocalPlugin) starts up successfully but doesn't detect anyone on
>>> the local network. gabble (ServerPlugin) repeatedly attempts to
>>> connect to a jabber server but fails - nevertheless salut is running."
>>>
>>> After this one of my students built a jabber server and we could do
>>> collaboration through that
>>>
>>> I was hoping that with the new Fedora USB key we could do collaboration
>>> out of the box, meaning without using the jabber server
>>>
>>> All I tested with the new Fedora USB key was trying to connect through
>>> Chat but that didn't work
>>>
>>> Let me know if you want more information or diagnostic files again - I can
>>> look up the details or ask joel for help if needed - just tell me exactly
>>> the information you need
>>>
>>> a bit more detail of the history here:
>>> http://xo-whs.wikispaces.com/connectivity
>>
>> Ah, right.
>>
>> So what we have is a complex policy issue, but it boils down to this:
>>
>> With whom should a new Sugar user be "collaborating" by default?
>>
>> Many options here.  Machines on the local mesh subnet?  Should there be a
>> default jabberd server?  Should there be discoverability of all jabberd
>> servers in the world?
>
> A quick explanation about the built-in policy of
> sugar-presence-service: On startup, telepathy-salut is started for
> link local presence and collaboration (avahi etc). If network manager
> reports a valid IP address, then telepathy-gabble is started to try
> and connect to the configured jabber server. Until such time as gabble
> connects successfully, salut continues to be the presence mechanism.
> When gabble connects, salut is stopped and presence is done via the
> jabber server.
>
> That policy is in the code base and is not configurable without modifying code.
>
> OLPC XO releases ship with no jabber server configured (and in the
> past, with a non-existant jabber server like ship2.jabber.laptop.org)
> since our ejabberd setup falls over with more than about 150 people on
> the server. (That is a more complex discussion which we have had
> several times - ask me if you want the explanation. A 9.1.0 feature
> should improve that.)
>
> Discoverability of jabber servers is unfortunately a good way to kill
> them all, with the above limitation. Servers listed on
> http://wiki.laptop.org/go/Community_Jabber_Servers are regularly down
> for long periods because of this.
>
> With Sugar 0.82 it is easy to set a jabber server in the control
> panel, but it should only be done by informed decision: Jabber servers
> should only be run for specific communities, like an XO community in a
> specific city, or a for a specific school, etc. We do not have an
> access control mechanism to restrict that, but when people go "Oh
> cool, let me try that one" at random then it denies service to the
> intended users of the server.
>
> Debian Lenny and Ubuntu Intrepid ship the required patches in their
> ejabberd packages, and there are rpms available as part of the XS
> project, for those who want to set up community servers.
>
>> My take:
>>
>> 1. Whatever default policy we choose will be wrong for a significant subset
>> of users.
>
> The way OLPC builds ship, two XOs on the same mesh channel or the same
> AP will see each other, out of the box. There's no server than can
> handle being the default, so it's simple: ship with no server
> configured.
>
> That relies on link local presence/collaboration actually working: if
> it isn't, you something to fix, since it works fine on OLPC 8.2.0 and
> other distros.
>
>> 2. Collaboration must be one of the "killer apps", and even if it doesn't
>> work out of the box *trivially*, it should be possible for users to iterate
>> through the possible collaboration network options with miminal pain.
>>
>> 3. Can we discuss this at next week's Sugar conference?  To me, answering
>> these questions is worth a day or more of face time.
>
> Unfortunately I won't be there in person but I'll try to participate
> remotely if time zones permit.
>
> Regards
> Morgan
>