[IAEP] Announcing Fedora Sugar Spin!

Wed Nov 12 18:51:02 UTC 2008

On Wed, 2008-11-12 at 20:23 +0200, 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.

I'm only here to break the thread against fedora-announce-list.  Ignore
and move on... ;-)

-- 
Paul W. Frields
  gpg fingerprint: 3DA6 A0AC 6D58 FEC4 0233  5906 ACDB C937 BD11 3717
  http://paul.frields.org/   -  -   http://pfrields.fedorapeople.org/
  irc.freenode.net: stickster @ #fedora-docs, #fedora-devel, #fredlug
-------------- next part --------------
A non-text attachment was scrubbed...
Name: not available
Type: application/pgp-signature
Size: 189 bytes
Desc: This is a digitally signed message part
Url : http://lists.fedoraproject.org/pipermail/olpc/attachments/20081112/25b9fb6c/attachment.bin 