Re: [sugar] Collaboration day!
I can join by phone too after noon on Tuesday, although I would prefer IRC. Pol On 11/14/2008 10:11 AM, Marco Pesenti Gritti wrote: Hello! I'm excited that Guillaume Desmottes is joining us at Sugarcamp, and we can actually have a good discussion about our collaboration infrastructure. I'm eager to learn about it and to figure out a roadmap for 0.84 and beyond. He will arrive on Monday afternoon (17h30) and go back Wednesday night (19h45). I propose to make Tuesday a collaboration day and spend a lot of time in learning, planning and hacking about it. Morgan will be present by phone. Brendan proposed a talk about it. Marco -- Polychronis Ypodimatopoulos Graduate student Viral Communications MIT Media Lab Tel: +1 (617) 459-6058 http://www.mit.edu/~ypod/ ___ Sugar mailing list Sugar@lists.laptop.org http://lists.laptop.org/listinfo/sugar
Re: [sugar] Proposed: Cerebro status meeting
Hi Morgan, I'm available. Pol On 10/17/2008 07:45 AM, Morgan Collett wrote: I'd like to catch up on the progress of Cerebro, telepathy-synapse and other ideas for scalable link local presence before we get into planning this feature for Sugar 0.84: http://sugarlabs.org/go/DevelopmentTeam/0.84/Collaboration#Scalable_link_local_presence Can we have a meeting next week to see where things are at? Channel: #sugar-meeting Proposed time: Wednesday Oct 22, at 14:00 UTC (http://timeanddate.decenturl.com/1400utc) or 17:00 UTC (http://timeanddate.decenturl.com/1700utc) Regards Morgan ___ Sugar mailing list Sugar@lists.laptop.org http://lists.laptop.org/listinfo/sugar
Re: [sugar] Give a Laptop, Change the World : G1G1 2008
John Gilmore wrote: I prefer the Sugar learning platform And my laundress prefers fabric revitalization consultant. Sugar isn't about learning. Sugar is a user interface. It draws icons and decorations on the screen, starts and stops programs, and lets you turn control knobs. The things Sugar competes with aren't learning platforms, they're user interfaces, like Gnome or Hildon. At first, it sounds like your correct, but I think you're not. Gnome is a general-purpose desktop environment, hildon is gear towards mobile interfaces on small screen real estate, and Sugar is an environment with a focus on collaboration and abstraction of concepts such as files and user accounts. As such, it could sustain a learning process better than other general purpose environments. Pol -- Polychronis Ypodimatopoulos Graduate student Viral Communications MIT Media Lab Tel: +1 (617) 459-6058 http://www.mit.edu/~ypod/ ___ Sugar mailing list Sugar@lists.laptop.org http://lists.laptop.org/listinfo/sugar
Re: [sugar] Give a Laptop, Change the World : G1G1 2008
is there anything like a poster/flyer in high resolution PDF? p. Samuel Klein wrote: This year's G1G1 program will start November 17 in the US. Please help us spread the word. Below is a short email blurb about this year's program ( from [[G1G1 2008/text]] ). We are coordinating some community art and outreach on the grassroots list as well (http://lists.laptop.org/listinfo/grassroots). There will be a lunch outreach meeting about G1G1 in #olpc on irc.freenode.net this Friday at 1200 EST (and @ 1CC for those in the area); sign up if you think you can make it, or leave your thoughts about what we should cover / who we should contact / what we can do better this time around: http://wiki.laptop.org/go/G1G1_meetings For giving, SJ = One Laptop per Child is launching its second ''Give 1, Get 1'' [G1G1] program starting November 17, 2008, following last year's popular program which received donations from over 80,000 people. This year the XO laptops will be shipped to donors through Amazon.com. The laptops feature the latest release of the Sugar window manager, running on a Linux-based Fedora Core operating system. For answers to frequently asked questions, and for other XO giving programs, see the OLPC wiki. More on G1G1 2008: http://wiki.laptop.org/go/G1G1_2008 More about the XO: http://laptop.org/en/laptop/ Photos, stories and other media from the first year's deployments are available from a community media page and from the OLPC photostream. If you have been involved with a deployment, please contribute your own. OLPC's Flickr photostream: http://flickr.com/photos/olpc Contribute share media: http://wiki.laptop.org/go/Community_media ___ Sugar mailing list Sugar@lists.laptop.org http://lists.laptop.org/listinfo/sugar -- Polychronis Ypodimatopoulos Graduate student Viral Communications MIT Media Lab Tel: +1 (617) 459-6058 http://www.mit.edu/~ypod/ ___ Sugar mailing list Sugar@lists.laptop.org http://lists.laptop.org/listinfo/sugar
[sugar] Firefox to adopt a Frame in the future?
In the following video, mozilla labs present Aurora, which showcases collaborative browsing and other concepts. Around time 4:50'' in the video, they present a Frame that shows: top: frequently used objects left: history: recently used objects left: temporary objects area, sorted by most recent bottom: objects in use right now http://labs.mozilla.com/projects/concept-series/ Pol -- Polychronis Ypodimatopoulos Graduate student Viral Communications MIT Media Lab Tel: +1 (617) 459-6058 http://www.mit.edu/~ypod/ ___ Sugar mailing list Sugar@lists.laptop.org http://lists.laptop.org/listinfo/sugar
Re: [sugar] Activity names vs. types
Hi Ben, Benjamin M. Schwartz wrote: I last discussed this issue with you at http://wiki.laptop.org/go/On_Presence_updates/User_Profiles/Collaboration. ~ I didn't understand your perspective then, and I still don't understand it now. Please be more specific on what part of the activity type you don't understand. I thought of it similarly to port numbers, some of which are well known and some are not. Different web servers may be used on port 80, but they all use the HTTP protocol. I understand that you may not agree with the port numbering system altogether and I don't really insist on activity types either. Just an idea. Why does the name field have to be some fixed size? Would it not be more efficient and flexible to use delimiters and let the size float? I was being plainly lazy. I still think there should be a proper design, potentially from scratch, of the activity sharing mechanism, as I am not satisfied neither with cerebro's implementation, nor with telepathy's. Pol -- Polychronis Ypodimatopoulos Graduate student Viral Communications MIT Media Lab Tel: +1 (617) 459-6058 http://www.mit.edu/~ypod/ ___ Sugar mailing list Sugar@lists.laptop.org http://lists.laptop.org/listinfo/sugar
Re: [sugar] Remarks on the Work of Sugar
-level memory protection. Evidence: Sugar packs great functionality into a small number of processes and occupies only one uid. Evidence: Sugar's process-level boundaries (e.g. shell, DS, PS, telepathy CMs, rainbow, activities) seem to me to be strongly correlated with the existence of cliques of the developers who built them. 7) Sugar prefers IPC techniques with inferior human interfaces (DBus, X) to IPC techniques with superior human interfaces (HTTP, 9P, environment variables, well-known files, process arguments + status codes + man pages). Regards, Michael P.S. - Let me know if you'd like to see more such remarks in the future (perhaps on other subsystems?) or if you'd like to see more detailed exploration of any of the items noted above. ___ Devel mailing list [EMAIL PROTECTED] http://lists.laptop.org/listinfo/devel -- Polychronis Ypodimatopoulos Graduate student Viral Communications MIT Media Lab Tel: +1 (617) 459-6058 http://www.mit.edu/~ypod/ ___ Sugar mailing list Sugar@lists.laptop.org http://lists.laptop.org/listinfo/sugar
[sugar] profile information
Hi, Is it possible for Sugar users to have an extensible profile? Currently, this only encompasses nickname and colors, but are there plans to extend this somehow? I propose using a dictionary to represent an extensible list of key/value pairs, some of which will be mandatory, like nickname, colors, key (countries may want to enforce other mandatory fields, like grade, class etc). This dictionary would be loaded from storage on boot and saved on every change. As a result, the control panel would be extended to accomodate a table so that users can append more info about themselves. Not to mention that all profiles should be shared and locally indexed on each XO to look for specific users. Comments? Pol -- Polychronis Ypodimatopoulos Graduate student Viral Communications MIT Media Lab Tel: +1 (617) 459-6058 http://www.mit.edu/~ypod/ ___ Sugar mailing list Sugar@lists.laptop.org http://lists.laptop.org/listinfo/sugar
Re: [sugar] journal object transfer for 8.2
An OLPC intern would have actually taken up this task, but changed direction for the summer. I 'm not sure though how network robustness will improve if some networking (such as file transfer) is done in the Journal. A slightly more radical change may be necessary ;-) p. Walter Bender wrote: I would argue otherwise. Since Sugar has no control over the robustness of the network, having some way of sharing at a basic level from the Journal is seemingly a high priority. Half of the high-priority bugs in the link you provide are in fact not really Sugar bugs, but subsystem bugs. The others don't seem to be particularly pressing. -walter On Mon, Jun 9, 2008 at 4:12 PM, Michael Stone [EMAIL PROTECTED] wrote: Tomeu, have heard occasional requests to implement the sending and sharing of journal entries. It's a desirable feature but, from my perspective, it's much lower in immediate priority than work which brings the sugar UI revision into a releasable condition and which polish the existing work by closing several of the 379 tickets assigned to component 'sugar': http://dev.laptop.org/query?status=assignedstatus=newstatus=reopenedcomponent=sugarorder=prioritycol=idcol=summarycol=statuscol=typecol=prioritycol=milestonecol=component So the questions are: is this a feature we should deliver for the 8.2 release? In my opinion, no. Do you think differently? Michael ___ Devel mailing list [EMAIL PROTECTED] http://lists.laptop.org/listinfo/devel ___ Devel mailing list [EMAIL PROTECTED] http://lists.laptop.org/listinfo/devel -- Polychronis Ypodimatopoulos Graduate student Viral Communications MIT Media Lab Tel: +1 (617) 459-6058 http://www.mit.edu/~ypod/ ___ Sugar mailing list Sugar@lists.laptop.org http://lists.laptop.org/listinfo/sugar
[sugar] Volunteers/help for sugar/cerebro integration
Hi, I'm looking for help/volunteers to assist with the integration process of cerebro [1] into sugar. Cerebro offers a fast and efficient data transport and collaboration mechanism between tens of XOs in simple mesh. Using cerebro we can make the simple mesh scale as well as the current limit using school server WiFi and improve the collaboration experience in many application scenarios. The integration can be done in either of these two ways: 1) Create a new telepathy connection manager that will act as interface between telepathy and cerebro. Some preliminary work already done by Michael Stone [2]. 2) Add the necessary callbacks in cerebro that will allow it to act as presence service to sugar directly [3]. Cerebro provides the necessary functionality, but lacks several dbus callbacks. Questions/comments? [1] http://wiki.laptop.org/go/Cerebro [2] http://dev.laptop.org/git?p=users/mstone/telepathy-cerebro;a=tree;hb=HEAD [3] /usr/lib/python2.5/site-packages/sugar/presence/presenceservice.py Thanks, Pol -- Polychronis Ypodimatopoulos Graduate student Viral Communications MIT Media Lab Tel: +1 (617) 459-6058 http://www.mit.edu/~ypod/ ___ Sugar mailing list Sugar@lists.laptop.org http://lists.laptop.org/listinfo/sugar
Re: [sugar] OLPC priorities for Sugar in the August release
Are there any plans to provide a command-line based interface to managing UI options such as share/join/leave/invite? I would argue that in the long run it would be faster to type something like join write by Tom which would have the same effect as many point-and-click actions in order to join the write activity that tom started (or which Tom is participating in now). I would suggest giving the user the option of having such a command line at the bottom of the mesh view, similarly to the search at the top. Pol Eben Eliason wrote: Pentagram and myself have been putting effort into solidifying designs for Sugar Groups. In a first rendition, it shouldn't require much more than an extension of the invitation framework to support group invites, and a simple UI for creating a group. I think even without advanced features such as bulletin boards, implicit group chats, and other details we've talked about surrounding the idea in the past, this will be a big way to improve the collaboration space even by making it extremely simple to say share with my group. I aim to have some screenshots which present this in a manner which might be feasible for August (if not, definitely Dec.) posted to the Designs page on the wiki by the weekend. - Eben On Wed, May 14, 2008 at 5:53 AM, Guillaume Desmottes [EMAIL PROTECTED] wrote: Le mercredi 14 mai 2008 à 11:48 +0200, Tomeu Vizoso a écrit : * Groups, models for groups (Peru, Hernan) Is this groups in Sugar? Do we have some kind of requirements? There are some discussions about groups here: https://dev.laptop.org/ticket/4043 G. ___ Devel mailing list [EMAIL PROTECTED] http://lists.laptop.org/listinfo/devel ___ Sugar mailing list Sugar@lists.laptop.org http://lists.laptop.org/listinfo/sugar -- Polychronis Ypodimatopoulos Graduate student Viral Communications MIT Media Lab Tel: +1 (617) 459-6058 http://www.mit.edu/~ypod/ ___ Sugar mailing list Sugar@lists.laptop.org http://lists.laptop.org/listinfo/sugar
Re: [sugar] OLPC priorities for Sugar in the August release
Eben Eliason wrote: On Wed, May 14, 2008 at 3:22 PM, Polychronis Ypodimatopoulos [EMAIL PROTECTED] wrote: Are there any plans to provide a command-line based interface to managing UI options such as share/join/leave/invite? I would argue that in the long run it would be faster to type something like join write by Tom which would have the same effect as many point-and-click actions in order to join the write activity that tom started (or which Tom is participating in now). This is an interesting idea, though I hope that we can make the search/filter UI strong enough to make it almost redundant. For instance, typing in simply Write Tom should turn up all instances of write which have participants named Tom in them (plus some other stuff, potentially). Typing something more specific like activity:write starter:tom would find more precise results. If we can make that filter nearly instant, it would simply take /one/ click to join the appropriate activity. The search field is focused when arriving in the view anyway, so even from within an activity it only takes one extra keystroke (mesh button) to initiate this process. (I recognize that pressing enter would be faster than even this single click, but at the same time wonder how frequently we could have 100% certainty of what a given command intends, since the usernames and activity names are not guaranteed to be unique anyway.) Oh, that's great! Then there is no need for a separate command line. Then, how about extending the functionality of Search with escaped commands like /join ... a-la-irc? Also, would it make sense to show a similar command line in views other than just the mesh view, such as in the activity? p. ___ Sugar mailing list Sugar@lists.laptop.org http://lists.laptop.org/listinfo/sugar
Re: [sugar] 65-node simple mesh test (and counting... ;-)
John Watlington wrote: One interesting note is that the suggested routing algorithm for 802.11s is a combination of reactive and proactive routing (unlike our current one, which is solely reactive). Perhaps that provides the adaptation necessary for the mesh to work ? If you refer to the hybrid routing protocol, it constructs a spanning tree of the whole mesh network rooted at some node. This is meant to be used in non-homogenous meshes (eg having an MPP or access point that acts as the root). So it may help in a school environment, but not in a simple mesh environment where all nodes are equal (if you attempt to build a different tree rooted at every node, you will probably face the wrath of a proactive protocol running on a mobile network - god save us from such a day ;-) ___ Sugar mailing list Sugar@lists.laptop.org http://lists.laptop.org/listinfo/sugar
[sugar] 65-node simple mesh test (and counting... ;-)
Dear devel, Here are the latest results from Cerebro's (http://cerebro.mit.edu) scaling properties. A 65-node testbed was used (703, Q2D14). The NetworkManager had to be disabled in order to stabilize the behavior of each XO's wireless interface. Unfortunately, the difficulty and time necessary to manage increasingly more nodes is linear (given that the NetoworkManager is disabled ;-), but increases steeply. ** Test plan: Cerebro was started on all 65 laptops almost at the same time. We attempted to emulate the 65 children turn on their laptops in class at the same time scenario. With Yani's help, it took about 5 seconds for both of us to press 'enter' on all laptops. Each XO would discover each other, exchange profile information and keep exchanging presence/discovery information. ** Measurements: Quantitative: According to the protocol, presence (mac address) arrives about other XOs first, then the profile for the newly arrived mac address is queried and finally the profile is cached. We assume that initially each XO has no cached information about other XOs. As a result, every XO will query everyone else. We measured the time it took for each XO to discover and exchange profile information with everyone else, bandwidth usage at all times (during profile exchange and after the network stabilized when all profiles were received everywhere) Qualitative: Collaboration was tested on all 65 nodes: one shared a chat session, everyone else joined. The chat session was based on Cerebro's collaboration model. ** Results: Discovery and profile information: The following graph shows arrival of profile information at each XO from other XOs a function of time. Each bar is a 3-second bucket representing the average number of profile arrivals during this 3-second period. The standard deviation is shown with the blue lines. http://wiki.laptop.org/images/a/af/65-arr-1.png The following graph is the cumulative distribution function. It shows that, on average, each XO has received about 95% of the profiles of the rest of the nodes within just 20 seconds. This performance boost is due to the fact that each XO queried for its profile, responds by broadcasting the profile, instead of unicasting it to the requester. As a result, the other nodes receive the profile too and the next node is queried, yielding a linear cost, instead of a quadratic one. http://wiki.laptop.org/images/7/72/65-cdf-1.png Bandwidth usage: The following wireshark snapshot shows bandwidth usage that peaks momentarily at about 60kbytes/sec. The snapshot is also in accordance with the first graph above, showing that after about 55 seconds the network stabilizes. After the network stabilizes, bandwidth usage drops to 1 packet every 3 seconds (less than 500bytes/sec), as the arrival rate adapts to the density of the network. http://wiki.laptop.org/images/5/51/Bandwidth-presence-info-1.png Chat session: Before the experiment was started, a node shared a chat session and all 64 nodes joined consistently. I sent a few chat messages from a couple of XOs and were received on all other XOs. ** Other notes After about 6.4 hours of continuous operation on all 65 nodes, Cerebro shows stable memory usage (10MB) and consistent CPU usage (83 minutes of CPU usage in 'top'). Comments/suggestions? Pol -- Polychronis Ypodimatopoulos Graduate student Viral Communications MIT Media Lab Tel: +1 (617) 459-6058 http://www.mit.edu/~ypod/ ___ Sugar mailing list Sugar@lists.laptop.org http://lists.laptop.org/listinfo/sugar
Re: [sugar] 65-node simple mesh test (and counting... ;-)
On Fri, May 9, 2008 at 10:57 AM, Marcus Leech [EMAIL PROTECTED] wrote: I'd be *very* interested to compare the distribution on a wired network. It seems to me that given the broadcast model, everybody should see everybody else in much shorter time than the 55 seconds shown in the outlying cluster on that graph. Marcus, this is indeed an interesting idea. However it has a significant problem: wiring up more than 60 XOs onto a switch requires equipment, time and space that OLPC cannot presently provide. Such a testbed though is absolutely necessary not only as a proof of concept for your suggestion, but also for doing large scale mesh network testing in general. The common, but erroneous, assumption is often made that a wireless network is just like a wired network, but with the wires removed. So very true! On a wireless network, broadcasts are successfully received with much lower probability. RF is mysterious and magical, and all sorts of connection asymmetries, near-field effects, and radiation lobe patterns conspire to make it unlikely that *everyone* can hear you equally at once -- and then you get into remote collisions and other mechanisms that make you unaware that not everyone heard you. And there is not 'ack' mechanism for 802.11 broadcast. All these are true also, but I think we're mystifying things a little bit here. The wireless medium is unpredictable mainly because its properties are also a function of time (a non-issue in wired networks), but at least (thank God!) it [the wireless medium] does not discriminate between broadcast and unicast frames! Adding an ack scheme to broadcasts should yield equal (or even better due to lowered speed) reliability using broadcast frames. Even without the ack scheme, I noticed that, on average, some 95% of the data transmitted over broadcast are successfully received on all nodes. We are throwing this away by discarding it on our wireless interfaces. Pol -- Polychronis Ypodimatopoulos Graduate student Viral Communications MIT Media Lab Tel: +1 (617) 459-6058 http://www.mit.edu/~ypod/ ___ Sugar mailing list Sugar@lists.laptop.org http://lists.laptop.org/listinfo/sugar
[sugar] Cerebro released
(sorry for cross-postings) The first release of Cerebro is out! Cerebro basically offers scalable presence information and a simple collaboration API. Features currently include: - presence information (including distance and route) for all other users in the network - dynamic rate of updates based on density of neighborhood: No more than 1 update every 5 seconds (on average) guaranteed. - mesh network extended to regular 802.11b/g devices - extensible user profile including nickname, colors, keys, IP addreses, picture of arbitrary size, status message etc - file sharing using an efficient multicast mechanism - simple collaboration mechanism through 'share', 'join', 'leave' functions - simple programming API based on dbus (see examples) http://wiki.laptop.org/go/Cerebro Enjoy! Pol -- Polychronis Ypodimatopoulos Graduate student Viral Communications MIT Media Lab Tel: +1 (617) 459-6058 http://www.mit.edu/~ypod/ ___ Sugar mailing list Sugar@lists.laptop.org http://lists.laptop.org/listinfo/sugar
[sugar] The limits of Mesh View
What are the practical limits at the moment? How many icons can we fit at a maximum? Pol ___ Sugar mailing list Sugar@lists.laptop.org http://lists.laptop.org/listinfo/sugar
Re: [sugar] The limits of Mesh View
Eben Eliason wrote: On Fri, Apr 18, 2008 at 11:51 PM, Polychronis Ypodimatopoulos [EMAIL PROTECTED] wrote: What are the practical limits at the moment? How many icons can we fit at a maximum? I'll give a somewhat vague response (mainly because even I'm not sure) to kick things off. To begin with, the answer depends in large part to the topography of the collaboration space. The view is much more scalable when the grouping factor of XOs is high, such that some activities cluster a number of them into a ring. This organizing factor makes things scalable, and was a key element of our design phase. If it turns out that most collaborations involve only 2 or 3 XOs, and very few involve 5 or more, we won't hit the type of layout we envisioned early on. That said, I think the rough limits are going to lie between 50 and 100 (I said I'd be vague!) icons in the view at any one time before it becomes to difficult to manage. In our initial sketches, which allowed up to 25 or so (class size) XOs to be in a given activity, we could handle 150 or more while retaining some visual clarity. Of course, we're working on ideas for improving scalability in general, such that the entire neighborhood is accessible via the search capability even when only a (potentially small!) subset of that neighborhood gets shown in the view by default. Additionally, we intend to add list views to all of the zoom levels, which will provide a sortable, searchable, filterable list of all activities, people, and devices present for the more extreme cases. - Eben 1) I don't understand how larger collaboration groups would increase scalability. I would think it's the other way around: larger circles - larger radius of unoccupied space - less icons 2) I also did a vague estimation of one exterme: the number of XO icons that can be packed in screen. I think it's about 13x26 icons (of course it's possible to do that by dividing the screen resolution with the svg size, but was too lazy for that ;-). A full screen of icons would not be legible either, but was I just trying to explore the limits. Pol ___ Sugar mailing list Sugar@lists.laptop.org http://lists.laptop.org/listinfo/sugar
[sugar] project idea - any takers?
I admit this kind of (very) late, but here is a project idea that I would love to mentor: Depending on your coding skills you could write a small activity to abstract the process of writing simple network applications that involve various hardware parts of the laptop (sound card, camera, microphone, network card). This activity would allow children to synthesize simple network programs like when my laptop hears a sound, send an email to my friend X, if you receive a message (packet) from this friend, take a picture and send it to my other friend Y For example a child may write small program using your activity to detect a sound and when it does, it will take a picture and send it somewhere over email (a nifty little monitoring system). Children should be able to put together simple programs like that in a la etoys, by drag-n-drop of icons on screen and setting their properties, making loops and so on. Any takers? Pol -- Polychronis Ypodimatopoulos Graduate student Viral Communications MIT Media Lab Tel: +1 (617) 459-6058 http://www.mit.edu/~ypod/ ___ Sugar mailing list Sugar@lists.laptop.org http://lists.laptop.org/listinfo/sugar
