headers
Walter Bender | 1 Dec 21:10
Picon

[Community-news] OLPC News 2007-12-01

1. Montevideo: We've only just begun!! The first deployment machines
were handed out in Escuela No. 109 in Florida, a rural department of
Uruguay. The second batch was handed out in Escuela No. 24 in Villa
Cardal, which has been a pilot site since May of this year. In Cardal,
we gave children production XOs and collecting their old Beta-2 units.
The OLPC deployment in Uruguay is being run by Miguel Brechner as part
of Proyecto Ceibal (Ceibo is the national flower of Uruguay), a
presidential initiative to equip each child with a laptop. The Ceibal
offices are housed in a Montevideo complex called LATU, or Laboratorio
Tecnológico del Uruguay, which is a public/private sector cooperative
technical lab now responsible for much of Uruguay's technical
certification and quality control programs, as well as serving an
incubator role for various engineering and technical projects. The
OLPC team has put all of their blood, sweat and code into the project
over the past three years because of the unshaken belief that it is
the right thing to do. Now it is real. You can read more about our
first deployment on Ivan Krstić's blog (See
http://radian.org/notebook/first-deployment).

2. Changshu: Mass Production is now very stable. We are using our line at 100%
 capacity. Congratulations to Quanta for stabilizing
 production just three weeks after MP start.

3. G1G1: Every "Day 1" Give One Get One participant (those that
donated on November 12, the
 first day of our campaign) received email on Wednesday informing them to
 expect their "Get" laptops between December 14 and 24. Delivery windows for
 other G1G1 participants were calculated and posted: "Get" laptops
 ordered thus far will be arriving, at the latest, by mid-January 2008.
 Brightstar and OLPC have been working closely to determine when the
(Continue reading)

Permalink | Reply | 0 comments |
headers
stas zytkiewicz | 2 Dec 14:42
Picon

Where to announce activity news

Hello, were should activity developers post news about activity
updates or announce new releases.

Thanks,
Stas

--

-- 
Educational activities for schools
http://www.schoolsplay.org
http://gvr.sf.net
Permalink | Reply | 2 comments |
headers
Jani Monoses | 2 Dec 15:38
Favicon

sugar xubuntu livecd

Hello,

now that the browser activity is working[*], I have modified a Xubuntu 
7.10 liveCD to include the existing .deb packages of Sugar. They are up 
to date as of git master, equivalent of current joyride.

TamTam and Etoys are not yet packaged.

It boots in plain Xfce and the emulator is in the applications menu, 
'Other' section

Starting in native sugar can be achieved by relogging in and choosing 
the sugar session. User is 'ubuntu' and there in no password.

It can be installed to the hard drive as any Ubuntu derived liveCD, by 
using the install icon on the desktop.

There's a script in the download directory which puts the ISO on a 
bootable USB stick for easier testing.

http://startx.ro/sugar/

Jani

[*] Dropping --enable-safe-browsing from the config options in the 
ubuntu xulrunner-1.9 package make it no longer crash in pyxpcom. No idea 
why, but it works.
Permalink | Reply | 0 comments |
headers
Michael Burns | 4 Dec 01:44
Picon

Updating third-party activities

The topic came up in #sugar today about the process of updating activities that were not shipped with the image (for lack of a better term, "third-party activities"). There are two standard ways:

1. Join a shared activity that is using a newer version of code than you have
2. You download a .XO from the web and it installs overtop an existing (signed by the same key, etc) activity. You can optionally uninstall that activity from the journal, before doing this.

The question that came up (#3), is how to distribute updates to these activities in mass instead of having the user be required to go find the latest version and manually compare (push/notify vs. pull). Installin activities will put dated, potentially buggy pieces of code (bitfrost or not, broken features ruin the user experience) on these machines with no good ways of getting at newer, improved versions of that code.

What is planned way to solve this? Could we add a field to the activity's metadata file about where hosting server is to check for newer versions of the .xo file? SJ described it on IRC as:

step 1 : check all known bundle repositories, ask for updates to your installed bundles
step 2 : collate the results by flag (importance / type of upgrade)
step 3 : confirm signatures for those the user chooses to install

Thoughts?

--
Michael Burns * Student
Open Source {Education} Lab 
_______________________________________________
Sugar mailing list
Sugar <at> lists.laptop.org
http://lists.laptop.org/listinfo/sugar
Permalink | Reply | 0 comments |
headers
Guillaume Desmottes | 4 Dec 17:34
Picon

The futur of the mesh view

Hi,

We recently started the design of a futur XMPP server component. It
should solve the scalability problems with current implementation and
will avoid to display hundreds of buddies and activities on the mesh
view, making it unusable.

We'd like to know what are the exact plans from an use cases point of
view and discuss few points about that.

- Friends will always be displayed in the mesh view when they are
online.  Do we want to show: them, them and their current activity, them
surrounded by all their activities, their current activity surrounded by
everyone in that activity?

- Do we want any extra information for the friends screen, for example
your friend surrounded by all of his activities?

- Users will be able to search for buddies (using search keys as color,
alias, name, email, etc.). The result of this search will be displayed
on the mesh view. Same question, what about their activities? Should we
display them too?

- Kids will also perform activity searches (using keys as name, type,
color, maybe participants?). Here again, the result will appear on the
mesh view. Do we plan to display buddies who are in these activities
too?

- Which kind of search method will be proposed in the GUI? Should we
support different options in our search protocol (as substring,
equality, case insensitive,...)?
How do we plan to distinguish a search for users from a search for
activities? Should we show all matching activities and all matching
buddies?

- Currently each activity has an globally unique identifier. This ID
make sense in Sugar as it have to identify shared and not shared
activities. But it's redundant in the PS and CM's (Gabble and Salut) as
each shared activity can also be identified using its muc's jid. Would
it be possible to make activity ID's *locally* unique? So we could
simplify/sanitize our XMPP protocol and Telepathy API. It seems activity
ID's are used when restoring shared instance but it's not clear if it
should assume these ID's are global or not.

You can find more explanations about the current stage of our
investigations on http://wiki.laptop.org/go/XMPP_Extensions#Use_Cases
and http://wiki.laptop.org/go/XMPP_Component_Protocol .
Please tell us if you see wrong assumptions or missing use cases.

	G.
Permalink | Reply | 22 comments |
headers
Eben Eliason | 4 Dec 18:07
Picon

Re: The futur of the mesh view

> - Friends will always be displayed in the mesh view when they are
> online.  Do we want to show: them, them and their current activity, them
> surrounded by all their activities, their current activity surrounded by
> everyone in that activity?

The Neighborhood view should have a consistent visual design, in which
activities have their participants clustered around them.  Friends
should be shown with their active activity, along with its other
participants.

> - Do we want any extra information for the friends screen, for example
> your friend surrounded by all of his activities?

This screen is less defined.  My current thought is that it should
really just be a filtered version of mesh view, obeying the same
grouping logic, but perhaps not including the "other participants."
That said, it seems that we could show all of their shared activities
(not private ones) in this view if we choose to move to a
representation different from the Neighborhood.

> - Users will be able to search for buddies (using search keys as color,
> alias, name, email, etc.). The result of this search will be displayed
> on the mesh view. Same question, what about their activities? Should we
> display them too?

Yes, the view should be the same (participants clustered around
activities) regardless of the search term or type.

> - Kids will also perform activity searches (using keys as name, type,
> color, maybe participants?). Here again, the result will appear on the
> mesh view. Do we plan to display buddies who are in these activities
> too?

Absolutely.

> - Which kind of search method will be proposed in the GUI? Should we
> support different options in our search protocol (as substring,
> equality, case insensitive,...)?

Case insensitive search is a must.  Substring matching is also a good
idea.  In general I feel that it's a good idea to make this implicit,
though that obviously results in more matches.  Of course, I suspect
we'll still need to perform a loose ranking and only return the best
results anyway, so that shouldn't be a problem.  In this model,
equality would simply be ranked higher.

In general, I think we'll use OR implicitly for search terms, though
again that results in more matches.  Maybe that's a bad idea;
thoughts? If it doesn't increase complexity too much, I'd be happy to
have transparent support for logical grouping and boolean operators as
well.  In a large pool of people and activities, explicit AND and NOT
operators would be really useful for more advanced users.

> How do we plan to distinguish a search for users from a search for
> activities? Should we show all matching activities and all matching
> buddies?

There are two types of input planned:  a search, and several filters.
The search field provides freeform input and should match on all
types: buddies, activities, and devices.  The filters will be
specifically for activities and buddies, individually.

We basically want to show everything that matches any of these.  What
would be nice to have is "simulated" support for metadata.  That is,
in the Journal we intend to allow searches for key:value pairs which
will return only entries which match on that particular metadata
field.  In the Neighborhood, we could support keys such as:  name,
email, group, activity, title, etc.  This would target the search and
limit the number of undesired matches.

- Eben
Permalink | Reply | 18 comments |
headers
Bert Freudenberg | 4 Dec 18:28
Picon
Gravatar

Re: The futur of the mesh view


On Dec 4, 2007, at 18:07 , Eben Eliason wrote:
> In general, I think we'll use OR implicitly for search terms, though
> again that results in more matches.  Maybe that's a bad idea;
> thoughts?

Bad idea, yes. This should be AND by default. OR can be simulated by  
simply searching for each term separately.

And IMHO the friends view should simply be a filtered mesh view.

- Bert -
Permalink | Reply | 16 comments |
headers
Eben Eliason | 4 Dec 18:34
Picon

Re: The futur of the mesh view

On Dec 4, 2007 12:28 PM, Bert Freudenberg <bert <at> freudenbergs.de> wrote:
>
> On Dec 4, 2007, at 18:07 , Eben Eliason wrote:
> > In general, I think we'll use OR implicitly for search terms, though
> > again that results in more matches.  Maybe that's a bad idea;
> > thoughts?
>
>
> Bad idea, yes. This should be AND by default. OR can be simulated by
> simply searching for each term separately.

Yeah, I think you're right; AND is a better default.  It's also a
non-issue if we can add explicit OR operators to a search.

> And IMHO the friends view should simply be a filtered mesh view.

Right, this is my gut feeling as well.  If we choose that route, the
remaining question is at what level we filter.  We eliminate devices
and activities which don't have any of our friends in them, but do we
also eliminate non-friends even if they are in a friend's activity?
It's possible that people will make so many friends that this is a
good idea for scalability, but it will change the grouping dynamic
between the views.

- Eben
Permalink | Reply | 12 comments |
headers
Pascal Scheffers | 4 Dec 18:35

Re: The futur of the mesh view


On 4 dec 2007, at 18:28, Bert Freudenberg wrote:

> And IMHO the friends view should simply be a filtered mesh view.

Indeed, and I would also keep the icon sizes the same on both views.  
If social networking sites are any indication, children will be really  
promiscuous with adding friends: expect each child to have between 100  
and 200 friends easily.

- Pascal.
Permalink | Reply | 0 comments |
headers
Pascal Scheffers | 4 Dec 18:51

Re: The futur of the mesh view


On 4 dec 2007, at 18:34, Eben Eliason wrote:

>
>> And IMHO the friends view should simply be a filtered mesh view.
>
> Right, this is my gut feeling as well.  If we choose that route, the
> remaining question is at what level we filter.  We eliminate devices
> and activities which don't have any of our friends in them, but do we
> also eliminate non-friends even if they are in a friend's activity?

That triggers different filtering idea:

I don't know where it should go, but do we need a classroom view? In a  
school I would expect it to be useful to have a view of all laptops in  
the same classroom. For example, use the filter expression on the  
neighborhood view to create a virtual class: If I have a filter  
expression #myclass, the view shows all laptops which also have that  
expression set. Sort of like IRC channels?

I know a textual expression may be a poor choice for those who can't  
write yet, so maybe the teacher sets such an expression and a special  
icon appear in the view, colors derived from the name?

- Pascal.
Permalink | Reply | 10 comments |

Gmane