status of project hosting?
What is the status of pending project hosting requests? ___ Devel mailing list Devel@lists.laptop.org http://lists.laptop.org/listinfo/devel
Re: [Localization] XOs for Cambodia (was...)
On Sun, Feb 24, 2008 at 6:14 PM, Javier SOLA [EMAIL PROTECTED] wrote: Walter Bender wrote There is a government standard Unicode keyboard... Can you please send me a pointer to this? (I am by default using the standard layout defined by the XKB symbol table that is standard with Linux, but as you note, it seems suboptimal.) I am afraid it is the same. There are vowels that Unicode refused to include in the table, because they could be constructed with two code points, but they are quite used standard vowels, and it does not make sense not to have them in the keyboard. This decision on the part of character set experts, native speakers of many languages, and linguists in the Unicode Consortium was quite correct. Unicode encodes characters, not glyphs, and certainly not keystrokes. It is not the fault of Unicode that almost all software developers used to work in broken software models for character handling, including one byte per character and one character per keystroke. It is of course possible to type correct Khmer on one-code-point-per-keystroke keyboards, just as it is possible to type accented European letters on keyboards that do not have all of them. Thus compose, `, o creates ò on the US International keyboard for Linux and on other layouts such as Dvorak. ['Ò' is used in Kreyòl (Haitian Creole French), which we are currently localizing to.] Possible, but not always appropriate. Technology has to solve the problem. Exactly right. The correct solution for Khmer is to create a Khmer IME for SCIM (Smart Common Input Method), which will be standard on XOs. IMEs can take in more than one keystroke to choose a character, as for syllabic writing systems (Ethiopian, Japanese kana, and others) or logographic writing systems (Chinese, Yi, Mayan, and others), and can generate more than one Unicode code point per keystroke, as is required by widely-used keyboards for Yoruba and other languages. See http://wiki.laptop.org/go/SCIM for information on available SCIM IMEs, how to install SCIM in current laptop builds, and a link to instructions for creating SCIM IMEs. I have put in a bug for the lack of a Khmer IME that satisfies local preferences. Feel free to add comments and design guidelines, or to take part in creating the IME. Walter, are you up for creating a table-driven Khmer IME in addition to your keyboard work? https://dev.laptop.org/ticket/6568 http://sourceforge.net/project/showfiles.php?group_id=133361package_id=164533 If you think that this is not necessary, then why is XO doing localization? Necessary no. But of course it is better to work with the local language, so of course we work with local experts to do so. This is a strong opinion. It disagrees with most educators in the world and their experience. You need a lot of data (evaluations) to back up such opinion. A strong but empirically verified conclusion (not opinion). It is of course perfectly logical and appropriate that educators would observe that children cannot learn by reading textbooks in a foreign language. (There are a few very carefully designed foreign-language teaching books using visual cues to the meaning of all words used. I began learning German as a child from a book called German Through Pictures, but that is not what we are talking about here.) However, textbooks are no longer the appropriate context for all educational questions. Electronic teaching materials do not have to be textbooks. They can make use of a wide range of built-in interactive software capabilities that provide active positive feedback to the inquisitive child. Illiterate preschoolers are routinely observed discovering how to use an XO without instruction, particularly the Paint, TamTamJam (music), Record (camera), and Memorize (concentration game) activities, which are almost entirely visual. A great deal of work has gone into minimizing the use of written language on the XO. It does not have conventional menus, but is icon-driven as much as possible. I count 17 words in the user interface in the Paint activity, and there are visual cues to the meaning of all of them. The earliest model for all of this on computerns is Omar Khayyam Moore's Edison Talking Typewriter, http://www.winwenger.com/archives/part26.htm, which he programmed to teach two-year-olds to read and write. A more recent example is the Indian Hole-in-the-Wall-Computer experiment, in which school dropouts discovered and taught each other how to use a computer with no instruction. See http://www.pbs.org/frontlineworld/stories/india/kids.html, among many other reports. But the Montessori Method materials, teaching arithmetic with Cuisenaire rods, teaching music by ear, and many other non-verbal teaching techniques predate computers. I have spent the last five years of my life in Cambodia, doing localization, and designing tools like Pootle o the WordForge localization Editor, because I know it NOT to be true,
Re: Preparing the XOs for next week's test
Le samedi 23 février 2008 à 08:13 -0500, Walter Bender a écrit : Read sharing is a critical feature. Please do test it. Would be good to consider to include my fix for #6540 then. It's waiting review and merge from a Read developer. G. ___ Devel mailing list Devel@lists.laptop.org http://lists.laptop.org/listinfo/devel
Re: Wireshark
A version of wireshark which is patched to monitor the new mesh protocol is available at: (older, F7 version) http://dev.laptop.org/~wad/wireshark-0.99.5.mesh.patch http://dev.laptop.org/~wad/wireshark-0.99.5-1.i386.rpm http://dev.laptop.org/~wad/wireshark-gnome-0.99.5-1.i386.rpm (current, F8 version) http://dev.laptop.org/~wad/wireshark-0.99.7.mesh.patch http://dev.laptop.org/~wad/wireshark-0.99.7.mesh.i386.rpm http://dev.laptop.org/~wad/wireshark-gnome-0.99.7.mesh.i386.rpm I'm still not seeing RREQ traffic, but I haven't played around with the new version much. Enjoy, wad On Feb 21, 2008, at 2:54 PM, Javier Cardona wrote: On 2/21/08, John Watlington [EMAIL PROTECTED] wrote: Thanks for the reply. What is your estimate of the difficulty in supporting the new mesh format ? We were really hoping to examine the simple mesh traffic carefully next week, and this puts a big crimp in those plans. It would take me about three hours, including testing, generating the patch, etc. I don't have that time this week but may work on it early next week. Javier wad On Feb 21, 2008, at 1:20 PM, Javier Cardona wrote: John, The patch was up to date up until we had to change the format of broadcast traffic. It has not been updated since. Unicast traffic should still be parsed correctly. Please contact Ronak if you want us to work on this. Cheers, Javier On 2/21/08, John Watlington [EMAIL PROTECTED] wrote: Yeah, but I was hoping not to have to parse each packet manually to determine if it is carrying data (TCP,UDP,etc.) or Path/Route discovery traffic. So nobody has patched wireshark to actually decipher mesh traffic ? wad On Feb 21, 2008, at 9:31 AM, Ricardo Carrano wrote: Isn't the LLC traffic what you're looking for? I see a lot of multicast traffic on your file, particularly to 01:00:5e:7f:47:31. They are LLC. On Thu, Feb 21, 2008 at 10:38 AM, John Watlington [EMAIL PROTECTED] wrote: My screen looks like the screen shot you sent when looking at that data. I can see the mesh headers on the pings. Take a look at the data I pointed to. It tried to record a session of a number of laptops collaborating. I set the capture mask to 7 (beacons, link layer, and data). But all I see in wireshark is beacons and LLC traffic. Given your data and screenshot, this is user error not misapplied patch... Still, is there any way to dig deeper into simple mesh traffic ? wad On Feb 21, 2008, at 8:15 AM, Ricardo Carrano wrote: capture.dump -- Javier Cardona cozybit Inc. -- Javier Cardona cozybit Inc. ___ Devel mailing list Devel@lists.laptop.org http://lists.laptop.org/listinfo/devel
Git Repository, etc. for Read ETexts Activity Project
To Whom It May Concern, Two weeks ago I submitted a form requesting hosting for my Activity, a simple Python app that will do everything the Read activity currently does, but which will work on Gutenberg Etexts either in ascii format or in Zip format where the Zip file contains a single ascii text file. These are the formats used for most Gutenberg etexts. The project is shaping up nicely. I don't have everything working 100%, but I'm getting there, and I think the end result will be a very useable and worthwhile Activity. I still have not received any response to my request. I'm thinking about setting up a project in SourceForge instead, but really I think it belongs on the OLPC site. That is where it will be most visible, where I might be able to get help with translation, etc. I am frustrated that I have not received *any* response to my form though. Even an email saying that my request was received would be better than nothing. If I do go with the SourceForge option I'll need a name for the project. I was thinking about setting up one project that could host several Activities, since the ones I'm working on are fairly small. Suggestions for names would be welcome. James Simmons ___ Devel mailing list Devel@lists.laptop.org http://lists.laptop.org/listinfo/devel
Test / debug week has begun
All developers in the 1CC area should plan to spend time in the board room helping with setup, discussion of bugs, builds, and testing for our scaling, mesh testing. Please don't run any XO laptops outside of the board room today (and perhaps this whole week). Thanks! Kim ___ Devel mailing list Devel@lists.laptop.org http://lists.laptop.org/listinfo/devel
Re: Preparing the XOs for next week's test
On Sunday 24 February 2008, Giannis Galanis wrote: Kim, You can see the diffs here: http://dev.laptop.org/~rwh/announcer/joyride_vs_update1.html http://dev.laptop.org/%7Erwh/announcer/joyride_vs_update1.html You will see that there are plenty of new stuff in joyride than just a telepathy-salut update. One thing we can do is use 693 and install the specific package, or make a new Update.1 build that includes it. But we should test it individually before putting it in the update.1 build. One thing we can do is have half the XOs with 1721 in one channel, and the other half with 693 in another channel. So we need a new read package and a new telepathy-salut. Giannis can you please make sure we have a trac bug filled requesting these. Who do i need to talk to to get the Read build done? Dennis signature.asc Description: This is a digitally signed message part. ___ Devel mailing list Devel@lists.laptop.org http://lists.laptop.org/listinfo/devel
Re: Preparing the XOs for next week's test
I'll have an updated Read package ready in a few hours. Cheers, Reinier Dennis Gilmore wrote: On Sunday 24 February 2008, Giannis Galanis wrote: Kim, You can see the diffs here: http://dev.laptop.org/~rwh/announcer/joyride_vs_update1.html http://dev.laptop.org/%7Erwh/announcer/joyride_vs_update1.html You will see that there are plenty of new stuff in joyride than just a telepathy-salut update. One thing we can do is use 693 and install the specific package, or make a new Update.1 build that includes it. But we should test it individually before putting it in the update.1 build. One thing we can do is have half the XOs with 1721 in one channel, and the other half with 693 in another channel. So we need a new read package and a new telepathy-salut. Giannis can you please make sure we have a trac bug filled requesting these. Who do i need to talk to to get the Read build done? Dennis ___ Devel mailing list Devel@lists.laptop.org http://lists.laptop.org/listinfo/devel -- Reinier Heeres Waalstraat 17 2515 XK Den Haag The Netherlands Tel: +31 6 10852639 ___ Devel mailing list Devel@lists.laptop.org http://lists.laptop.org/listinfo/devel
Avahi optimisations
Hi, As a result of a talk of Jim, Lennart and some Collabora folks at LCA there were some suggestions how one could potentially optimise the network load of avahi. See the commented list below :) * play around with the announce intervals, RR TTLs and stuff - We already changed the hostname RR interval from 2 minutes to 10 minutes. Upping it even more probably won't make a significant change in the traffic levels, but makes the time before avahi detects a node is gone even longer. * minimize announced services (starting with dropping _workstation._tcp) - Dropping _workstation._tcp can be done by setting publish-workstation=false in the avahi config. This is the only redundant service we announce. As this is never resolved the impact of this change will be quite small. * Minimize size of announced services (i.e. drop unnecessary data from TXT) - The biggest item in the TXT of contacts is the key (which is BIG). But this key is a requirement of bitfrost, so we can't get rid of it. * Change timers to give avahi more time to accoumulate and collapse RRs - Quite some protocol/traffic analysis needs to be done for this one. And i'm afraid the potential rewards are quite small. * Play around with the code that inserts additional data into packets. - According to lennart avahi inserts both the TXT and the SRV record when one requests a PTR record as it's quite common to request this information afterwards. I don't remember seeing this behaviour in network traces, so this needs to be verified. If it's the case, this might save a reasonable amount of traffic as our TXT record is huge. Of course, more potential optimisations might be discovered by doing analysis of the network traffic. But i'm personally afraid that these will take a huge amount of effort for at best moderate gains (Assuming no glaring bugs in avahi) Sjoerd -- Wisdom is knowing what to do with what you know. -- J. Winter Smith ___ Devel mailing list Devel@lists.laptop.org http://lists.laptop.org/listinfo/devel
ctrl:nocaps for qemu emulation
sorry for the perhaps slightly non-devel question, but if i can't type, i can't develop. :-) what's the syntactic sugar i need to apply to /etc/X11/xorg.conf to do what i usually accomplish by adding this to the Generic Keyboard stanza? Option XkbOptionsctrl:nocaps the xorg.conf files on the XO (under qemu emulation, at least -- i don't yet have my G1G1 XO) are just quirky enough that nothing i've tried works. (i assume i'll have the same issue with external keyboards -- having tried typing on a borrowed XO, i suspect i'll be attaching one fairly often.) thanks, paul =- paul fox, [EMAIL PROTECTED] (arlington, ma, where it's 37.4 degrees) ___ Devel mailing list Devel@lists.laptop.org http://lists.laptop.org/listinfo/devel
Re: Avahi optimisations
On Mon, 2008-02-25 at 18:08 +0100, Sjoerd Simons wrote: Hi, As a result of a talk of Jim, Lennart and some Collabora folks at LCA there were some suggestions how one could potentially optimise the network load of avahi. See the commented list below :) * play around with the announce intervals, RR TTLs and stuff - We already changed the hostname RR interval from 2 minutes to 10 minutes. Upping it even more probably won't make a significant change in the traffic levels, but makes the time before avahi detects a node is gone even longer. * minimize announced services (starting with dropping _workstation._tcp) - Dropping _workstation._tcp can be done by setting publish-workstation=false in the avahi config. This is the only redundant service we announce. As this is never resolved the impact of this change will be quite small. * Minimize size of announced services (i.e. drop unnecessary data from TXT) - The biggest item in the TXT of contacts is the key (which is BIG). But this key is a requirement of bitfrost, so we can't get rid of it. How much of the traffic is the key? * Change timers to give avahi more time to accoumulate and collapse RRs - Quite some protocol/traffic analysis needs to be done for this one. And i'm afraid the potential rewards are quite small. We're setting up to get data more routinely; hopefully we'll have some this week. * Play around with the code that inserts additional data into packets. - According to lennart avahi inserts both the TXT and the SRV record when one requests a PTR record as it's quite common to request this information afterwards. I don't remember seeing this behaviour in network traces, so this needs to be verified. If it's the case, this might save a reasonable amount of traffic as our TXT record is huge. Of course, more potential optimisations might be discovered by doing analysis of the network traffic. But i'm personally afraid that these will take a huge amount of effort for at best moderate gains (Assuming no glaring bugs in avahi) I also note we do nothing regarding suspend/resume and adjusting timeouts properly, per the mdns spec. Do you have a feel for what the effect of implementing that there would be? - Jim -- Jim Gettys One Laptop Per Child ___ Devel mailing list Devel@lists.laptop.org http://lists.laptop.org/listinfo/devel
Re: Preparing the XOs for next week's test
On Feb 25, 2008, at 17:42 , Dennis Gilmore wrote: On Sunday 24 February 2008, Giannis Galanis wrote: Kim, You can see the diffs here: http://dev.laptop.org/~rwh/announcer/joyride_vs_update1.html http://dev.laptop.org/%7Erwh/announcer/joyride_vs_update1.html You will see that there are plenty of new stuff in joyride than just a telepathy-salut update. One thing we can do is use 693 and install the specific package, or make a new Update.1 build that includes it. But we should test it individually before putting it in the update.1 build. One thing we can do is have half the XOs with 1721 in one channel, and the other half with 693 in another channel. So we need a new read package and a new telepathy-salut. Giannis can you please make sure we have a trac bug filled requesting these. Who do i need to talk to to get the Read build done? If Etoys sharing is to be tested, then you need to update the etoys rpm (was approved for update.1, trac #6548). - Bert - ___ Devel mailing list Devel@lists.laptop.org http://lists.laptop.org/listinfo/devel
Re: Avahi optimisations
On Mon, Feb 25, 2008 at 12:21:22PM -0500, Jim Gettys wrote: On Mon, 2008-02-25 at 18:08 +0100, Sjoerd Simons wrote: Hi, As a result of a talk of Jim, Lennart and some Collabora folks at LCA there were some suggestions how one could potentially optimise the network load of avahi. See the commented list below :) * play around with the announce intervals, RR TTLs and stuff - We already changed the hostname RR interval from 2 minutes to 10 minutes. Upping it even more probably won't make a significant change in the traffic levels, but makes the time before avahi detects a node is gone even longer. * minimize announced services (starting with dropping _workstation._tcp) - Dropping _workstation._tcp can be done by setting publish-workstation=false in the avahi config. This is the only redundant service we announce. As this is never resolved the impact of this change will be quite small. * Minimize size of announced services (i.e. drop unnecessary data from TXT) - The biggest item in the TXT of contacts is the key (which is BIG). But this key is a requirement of bitfrost, so we can't get rid of it. How much of the traffic is the key? The key/value pairs in mdnds just for the key is about 625 bytes in a TXT record of about 792 bytes. Most other RR are in the size range of 16-32 bytes. So the TXT record is by far the biggest RR and 75% of that is the key. Ofcourse the TXT record is not always part of a MDNS, but how often it occurs depends on your usage patterns (A new node in the network always needs to get the TXT of all others for example). Also it might be included more then strictly needed (see one of the later point). * Change timers to give avahi more time to accoumulate and collapse RRs - Quite some protocol/traffic analysis needs to be done for this one. And i'm afraid the potential rewards are quite small. We're setting up to get data more routinely; hopefully we'll have some this week. That's good to see. Analysing what traffic goes around in a real XO network might reveal some interesting things. * Play around with the code that inserts additional data into packets. - According to lennart avahi inserts both the TXT and the SRV record when one requests a PTR record as it's quite common to request this information afterwards. I don't remember seeing this behaviour in network traces, so this needs to be verified. If it's the case, this might save a reasonable amount of traffic as our TXT record is huge. Of course, more potential optimisations might be discovered by doing analysis of the network traffic. But i'm personally afraid that these will take a huge amount of effort for at best moderate gains (Assuming no glaring bugs in avahi) I also note we do nothing regarding suspend/resume and adjusting timeouts properly, per the mdns spec. Do you have a feel for what the effect of implementing that there would be? Which potentially changes are you specifically referring to here ? I'm not really aware of potential changes in this respect that could help a lot with the traffic. Sjoerd -- The Wright Bothers weren't the first to fly. They were just the first not to crash. ___ Devel mailing list Devel@lists.laptop.org http://lists.laptop.org/listinfo/devel
Re: Avahi optimisations
On Mon, 2008-02-25 at 19:28 +0100, Sjoerd Simons wrote: I also note we do nothing regarding suspend/resume and adjusting timeouts properly, per the mdns spec. Do you have a feel for what the effect of implementing that there would be? Which potentially changes are you specifically referring to here ? I'm not really aware of potential changes in this respect that could help a lot with the traffic. Search for sleep in draft-cheshire-ext-multicastdns.txt. My memory is that Lennart said there wasn't anything implemented in Avahi for these cases. Rather than improvements, I'm worried that frequent suspend/resumes may be generating unneeded traffic. - Jim -- Jim Gettys One Laptop Per Child ___ Devel mailing list Devel@lists.laptop.org http://lists.laptop.org/listinfo/devel
Re: Wireshark
Applies the patch and compiled but failed to execute (on Ubuntu)... 14:43:34 Err file about_dlg.c: line 250 (splash_update): assertion failed: (ul_sofar = ul_count) Aborted (core dumped) Any ideas? Has someone tried this on Ubuntu? On Mon, Feb 25, 2008 at 4:37 AM, John Watlington [EMAIL PROTECTED] wrote: A version of wireshark which is patched to monitor the new mesh protocol is available at: (older, F7 version) http://dev.laptop.org/~wad/wireshark-0.99.5.mesh.patchhttp://dev.laptop.org/%7Ewad/wireshark-0.99.5.mesh.patch http://dev.laptop.org/~wad/wireshark-0.99.5-1.i386.rpmhttp://dev.laptop.org/%7Ewad/wireshark-0.99.5-1.i386.rpm http://dev.laptop.org/~wad/wireshark-gnome-0.99.5-1.i386.rpmhttp://dev.laptop.org/%7Ewad/wireshark-gnome-0.99.5-1.i386.rpm (current, F8 version) http://dev.laptop.org/~wad/wireshark-0.99.7.mesh.patchhttp://dev.laptop.org/%7Ewad/wireshark-0.99.7.mesh.patch http://dev.laptop.org/~wad/wireshark-0.99.7.mesh.i386.rpmhttp://dev.laptop.org/%7Ewad/wireshark-0.99.7.mesh.i386.rpm http://dev.laptop.org/~wad/wireshark-gnome-0.99.7.mesh.i386.rpmhttp://dev.laptop.org/%7Ewad/wireshark-gnome-0.99.7.mesh.i386.rpm I'm still not seeing RREQ traffic, but I haven't played around with the new version much. Enjoy, wad On Feb 21, 2008, at 2:54 PM, Javier Cardona wrote: On 2/21/08, John Watlington [EMAIL PROTECTED] wrote: Thanks for the reply. What is your estimate of the difficulty in supporting the new mesh format ? We were really hoping to examine the simple mesh traffic carefully next week, and this puts a big crimp in those plans. It would take me about three hours, including testing, generating the patch, etc. I don't have that time this week but may work on it early next week. Javier wad On Feb 21, 2008, at 1:20 PM, Javier Cardona wrote: John, The patch was up to date up until we had to change the format of broadcast traffic. It has not been updated since. Unicast traffic should still be parsed correctly. Please contact Ronak if you want us to work on this. Cheers, Javier On 2/21/08, John Watlington [EMAIL PROTECTED] wrote: Yeah, but I was hoping not to have to parse each packet manually to determine if it is carrying data (TCP,UDP,etc.) or Path/Route discovery traffic. So nobody has patched wireshark to actually decipher mesh traffic ? wad On Feb 21, 2008, at 9:31 AM, Ricardo Carrano wrote: Isn't the LLC traffic what you're looking for? I see a lot of multicast traffic on your file, particularly to 01:00:5e:7f:47:31. They are LLC. On Thu, Feb 21, 2008 at 10:38 AM, John Watlington [EMAIL PROTECTED] wrote: My screen looks like the screen shot you sent when looking at that data. I can see the mesh headers on the pings. Take a look at the data I pointed to. It tried to record a session of a number of laptops collaborating. I set the capture mask to 7 (beacons, link layer, and data). But all I see in wireshark is beacons and LLC traffic. Given your data and screenshot, this is user error not misapplied patch... Still, is there any way to dig deeper into simple mesh traffic ? wad On Feb 21, 2008, at 8:15 AM, Ricardo Carrano wrote: capture.dump -- Javier Cardona cozybit Inc. -- Javier Cardona cozybit Inc. ___ Devel mailing list Devel@lists.laptop.org http://lists.laptop.org/listinfo/devel
Re: Wireshark
Ricardo, On 2/25/08, Ricardo Carrano [EMAIL PROTECTED] wrote: Applies the patch and compiled but failed to execute (on Ubuntu)... 14:43:34 Err file about_dlg.c: line 250 (splash_update): assertion failed: (ul_sofar = ul_count) Aborted (core dumped) Any ideas? Has someone tried this on Ubuntu? Oh, I just commented out that assertion and it all worked with a fuss: (lt-wireshark:32429): Gtk-CRITICAL **: gtk_progress_set_percentage: assertion `percentage = 0 percentage = 1.0' failed Who cares if the progress bar goes beyond 100%... :) Javier On Mon, Feb 25, 2008 at 4:37 AM, John Watlington [EMAIL PROTECTED] wrote: A version of wireshark which is patched to monitor the new mesh protocol is available at: (older, F7 version) http://dev.laptop.org/~wad/wireshark-0.99.5.mesh.patch http://dev.laptop.org/~wad/wireshark-0.99.5-1.i386.rpm http://dev.laptop.org/~wad/wireshark-gnome-0.99.5-1.i386.rpm (current, F8 version) http://dev.laptop.org/~wad/wireshark-0.99.7.mesh.patch http://dev.laptop.org/~wad/wireshark-0.99.7.mesh.i386.rpm http://dev.laptop.org/~wad/wireshark-gnome-0.99.7.mesh.i386.rpm I'm still not seeing RREQ traffic, but I haven't played around with the new version much. Enjoy, wad On Feb 21, 2008, at 2:54 PM, Javier Cardona wrote: On 2/21/08, John Watlington [EMAIL PROTECTED] wrote: Thanks for the reply. What is your estimate of the difficulty in supporting the new mesh format ? We were really hoping to examine the simple mesh traffic carefully next week, and this puts a big crimp in those plans. It would take me about three hours, including testing, generating the patch, etc. I don't have that time this week but may work on it early next week. Javier wad On Feb 21, 2008, at 1:20 PM, Javier Cardona wrote: John, The patch was up to date up until we had to change the format of broadcast traffic. It has not been updated since. Unicast traffic should still be parsed correctly. Please contact Ronak if you want us to work on this. Cheers, Javier On 2/21/08, John Watlington [EMAIL PROTECTED] wrote: Yeah, but I was hoping not to have to parse each packet manually to determine if it is carrying data (TCP,UDP,etc.) or Path/Route discovery traffic. So nobody has patched wireshark to actually decipher mesh traffic ? wad On Feb 21, 2008, at 9:31 AM, Ricardo Carrano wrote: Isn't the LLC traffic what you're looking for? I see a lot of multicast traffic on your file, particularly to 01:00:5e:7f:47:31. They are LLC. On Thu, Feb 21, 2008 at 10:38 AM, John Watlington [EMAIL PROTECTED] wrote: My screen looks like the screen shot you sent when looking at that data. I can see the mesh headers on the pings. Take a look at the data I pointed to. It tried to record a session of a number of laptops collaborating. I set the capture mask to 7 (beacons, link layer, and data). But all I see in wireshark is beacons and LLC traffic. Given your data and screenshot, this is user error not misapplied patch... Still, is there any way to dig deeper into simple mesh traffic ? wad On Feb 21, 2008, at 8:15 AM, Ricardo Carrano wrote: capture.dump -- Javier Cardona cozybit Inc. -- Javier Cardona cozybit Inc. -- Javier Cardona cozybit Inc. ___ Devel mailing list Devel@lists.laptop.org http://lists.laptop.org/listinfo/devel
Re: Avahi optimisations
On Mon, Feb 25, 2008 at 02:42:21PM -0500, Jim Gettys wrote:
Search for sleep in draft-cheshire-ext-multicastdns.txt. My memory is
that Lennart said there wasn't anything implemented in Avahi for these
cases.
Rather than improvements, I'm worried that frequent suspend/resumes
may be generating unneeded traffic.
Right. I misinterpreted your comment. As far as i can tell, by not implementing
suspend detection avahi actually saves you from extra traffic. As in, it won't
send gratuitous announcements after wake-up or flush it cache faster then
normal.
What does actually cause extra traffic is the fact that during the sleep period
avahi misses MDNS packets. Which prevents duplicate {Question,Answer}
supressions from working as intended.
Sjoerd
--
Facts are stubborn, but statistics are more pliable.
___
Devel mailing list
Devel@lists.laptop.org
http://lists.laptop.org/listinfo/devel
Re: Avahi optimisations
* Minimize size of announced services (i.e. drop unnecessary data from TXT) - The biggest item in the TXT of contacts is the key (which is BIG). But this key is a requirement of bitfrost, so we can't get rid of it. So far as I have been informed, the Bitfrost protections that would require key transmission have not even been planned, let alone implemented. Given that we think reducing mDNS bandwidth usage is a good idea, does anyone see a real problem with dropping these keys until that basic design work has been completed? Michael ___ Devel mailing list Devel@lists.laptop.org http://lists.laptop.org/listinfo/devel
Re: Preparing the XOs for next week's test
Hi, On second thought I think a new Read build is not required for this. However, there is a newer version available in joyride that's not in update-1, I'm making a ticket for that. Guillaume: your patches are on master and will be included soon. Cheers, Reinier Reinier Heeres wrote: I'll have an updated Read package ready in a few hours. Cheers, Reinier Dennis Gilmore wrote: On Sunday 24 February 2008, Giannis Galanis wrote: Kim, You can see the diffs here: http://dev.laptop.org/~rwh/announcer/joyride_vs_update1.html http://dev.laptop.org/%7Erwh/announcer/joyride_vs_update1.html You will see that there are plenty of new stuff in joyride than just a telepathy-salut update. One thing we can do is use 693 and install the specific package, or make a new Update.1 build that includes it. But we should test it individually before putting it in the update.1 build. One thing we can do is have half the XOs with 1721 in one channel, and the other half with 693 in another channel. So we need a new read package and a new telepathy-salut. Giannis can you please make sure we have a trac bug filled requesting these. Who do i need to talk to to get the Read build done? Dennis ___ Devel mailing list Devel@lists.laptop.org http://lists.laptop.org/listinfo/devel -- Reinier Heeres Waalstraat 17 2515 XK Den Haag The Netherlands Tel: +31 6 10852639 ___ Devel mailing list Devel@lists.laptop.org http://lists.laptop.org/listinfo/devel
Re: Avahi optimisations
As soon as we have a baseline measurement of packets to measure against, I think we should remove this and the workstation record, and then retake the measurements. - Jim On Mon, 2008-02-25 at 16:42 -0500, Michael Stone wrote: * Minimize size of announced services (i.e. drop unnecessary data from TXT) - The biggest item in the TXT of contacts is the key (which is BIG). But this key is a requirement of bitfrost, so we can't get rid of it. So far as I have been informed, the Bitfrost protections that would require key transmission have not even been planned, let alone implemented. Given that we think reducing mDNS bandwidth usage is a good idea, does anyone see a real problem with dropping these keys until that basic design work has been completed? Michael -- Jim Gettys One Laptop Per Child ___ Devel mailing list Devel@lists.laptop.org http://lists.laptop.org/listinfo/devel
Project Hosting Application: Poetry Jam
On Mon Jan 7 11:57:57 EST 2008, Thomas Tuttle wrote: 1. Project name : Poetry Jam Done. Your tree is here: git+ssh://[EMAIL PROTECTED]/git/activities/poetryjam Please follow instructions here for importing your project: http://wiki.laptop.org/go/Importing_your_project Let us know if you have any problems with your tree. Happy hacking. Cheers, -- Henry Edward Hardy [EMAIL PROTECTED] ___ Devel mailing list Devel@lists.laptop.org http://lists.laptop.org/listinfo/devel
Project hosting application - quake-terminal
On Mon Jan 7 12:31:31 EST 2008, Rupa Deadwyler wrote: 1. Project name : quake-terminal Done. Your tree is here: git+ssh://[EMAIL PROTECTED]/git/activities/quake-terminal Please follow instructions here for importing your project: http://wiki.laptop.org/go/Importing_your_project Let us know if you have any problems with your tree. Happy hacking. Cheers, -- Henry Edward Hardy [EMAIL PROTECTED] ___ Devel mailing list Devel@lists.laptop.org http://lists.laptop.org/listinfo/devel
Project Hosting request: Moon (a resend)
1. Project name : Moon 2. Existing website, if any : http://wiki.laptop.org/go/Moon 3. One-line description : Moon phase activity 4. Longer description : Displays current Moon phase image information 5. URLs of similar projects : None 6. Committer list UsernameFull nameSSH2 key URL E-mail - -- garycmartin Gary C Martinhttp://garycmartin.com/ id_dsa.pubgary at garycmartin dot com 7. Preferred development model [X] Central tree. Every developer can push his changes directly to the project's git tree. This is the standard model that will be familiar to CVS and Subversion users, and that tends to work well for most projects. [ ] Maintainer-owned tree. Every developer creates his own git tree, or multiple git trees. He periodically asks the maintainer to look at one or more of these trees, and merge changes into the maintainer- owned, main tree. This is the model used by the Linux kernel, and is well-suited to projects wishing to maintain a tighter control on code entering the main tree. 8. Set up a project mailing list: [ ] Yes, named after our project name [ ] Yes, named __ [X] No 9. Commit notifications [ ] Notification of commits to the main tree should be e-mailed to the list we chose to create above [ ] A separate mailing list, projectname-git, should be created for commit notifications [X] No commit notifications, please 11. Translation [X] Set up the laptop.org Pootle server to allow translation commits to be made [ ] Translation arrangements have already been made at ___ 12. Notes/comments: FYI: Sorry for the dupe request, I sent this in a couple of weeks back but can't see it in the online archives. ___ Devel mailing list Devel@lists.laptop.org http://lists.laptop.org/listinfo/devel
Re: Alternative power/recharging source?
[EMAIL PROTECTED] wrote: And the EC, the memory, various pull up/down resistors, and few other suspend voltage regulators. All these add up to a non-trivial amount. you are not nessasarily going to be powering the system memory In the current setup powering the memory is not optional during suspend it is placed into self-refresh. Jespin at Usenix last year. however I can't just cite my memory, so I went looking on the website and found that snippet of information. however, it almost doesn't matter which of us is right. the mere fact that we are having this disagreement indicates a need for better documentation of this sort of info. It may not matter to you but it matters quite a bit to me since its part of my job. :) I'm part of the OLPC hardware team. The accurate measurement and reporting of the XO power draw is our responsibility. So when I see numbers flying about that I know are inaccurate I've been trying to correct them and find the source so it can get corrected as well. Unfortunately, as you and John Gilmore are pointing out, OLPC has previously made verbal and published statements with wattage numbers prior to mass production hardware. These statements, while not false, are only really useful when you know the context under which they were measured or extrapolated. In many cases this context did not make it into the statement or publication. So on that note here's some measurements I took this weekend with the context of the measurement: Consider these authoritative as of 2008-2-24. Sleep (No WLAN Firmware, Lid closed) .25W Ebook (No WLAN Firmware, Mono display, No backlight) .71W Mesh(Lid closed, WLAN) 1.1W Suspend (WLAN, Color display, backlight dimmed by ohm) 1.9W Suspend (WLAN, Color display, backlight minimum)1.7W Idle(WLAN, Backlight full, CPU on, no load) 3.9W 4.9 Peak Camera (WLAN, Backlight full, CPU on, high load) 6.5W 8.7 Peak Notes: These were measured and processed via my battery power logging script and a python hack I wrote (So I could quit using openoffice). See http://wiki.laptop.org/go/XO_Power_Draw#XO_power_draw for the code and a lot of gory details. No WLAN Firmware != 'olpc-control-panel -s radio off' since it does nto appear to turn every thing off. With radio-off Ebook mode drew 1.3W -- Richard Smith [EMAIL PROTECTED] One Laptop Per Child ___ Devel mailing list Devel@lists.laptop.org http://lists.laptop.org/listinfo/devel
Re: Avahi optimisations
Michael Stone wrote: * Minimize size of announced services (i.e. drop unnecessary data from TXT) - The biggest item in the TXT of contacts is the key (which is BIG). But this key is a requirement of bitfrost, so we can't get rid of it. So far as I have been informed, the Bitfrost protections that would require key transmission have not even been planned, let alone implemented. Given that we think reducing mDNS bandwidth usage is a good idea, does anyone see a real problem with dropping these keys until that basic design work has been completed? That's right - we have a meeting planned with Ivan and Jonathan Herzog to look at the *requirements* for crypto, so everything we have now is subject to change, and we are not using the keys *for crypto*. However, Sugar's UI code currently tracks buddy objects by key, so the key is required to be unique. I have a patch in #4656 to fix this, as it prevented more than one key-less buddy from being displayed (e.g. a regular XMPP client). This patch was considered too invasive for Update.1 and has bit-rotted and needs to be redone. We also identify friends in ~/.sugar/default/friends by key so that needs to change. Since then we applied the patch in #6142 which actually *requires* all buddies to have a key, due to a problem discovered by using hyperactivity. Removing the keys from the TXT records without fixing these issues will break mesh view so it's not something you can quickly have up and running. Regards Morgan ___ Devel mailing list Devel@lists.laptop.org http://lists.laptop.org/listinfo/devel
Re: Avahi optimisations
On Tue, Feb 26, 2008 at 12:57 AM, Morgan Collett [EMAIL PROTECTED] wrote: Michael Stone wrote: * Minimize size of announced services (i.e. drop unnecessary data from TXT) - The biggest item in the TXT of contacts is the key (which is BIG). But this key is a requirement of bitfrost, so we can't get rid of it The obviously correct thing to do is transmit the key *hash* and only send the full key if it is explicitly requested. If buddy identity means anything to you, you've got the full key stored locally anyway, and you only need to transfer it *once* when the buddy is added the first time. sha-256 is only 32 bytes, almost a 20-fold reduction in size. --scott -- ( http://cscott.net/ ) ___ Devel mailing list Devel@lists.laptop.org http://lists.laptop.org/listinfo/devel
Re: Avahi optimisations
On Tue, Feb 26, 2008 at 07:57:27AM +0200, Morgan Collett wrote: However, Sugar's UI code currently tracks buddy objects by key, so the key is required to be unique. I have a patch in #4656 to fix this, as it prevented more than one key-less buddy from being displayed (e.g. a regular XMPP client). This patch was considered too invasive for Update.1 and has bit-rotted and needs to be redone. We also identify friends in ~/.sugar/default/friends by key so that needs to change. Since then we applied the patch in #6142 which actually *requires* all buddies to have a key, due to a problem discovered by using hyperactivity. Removing the keys from the TXT records without fixing these issues will break mesh view so it's not something you can quickly have up and running. Does sugar make any assumptions about the size of the key? IOW can we instead of removing the key completely, use a smaller key? Sjoerd -- From listening comes wisdom and from speaking repentance. ___ Devel mailing list Devel@lists.laptop.org http://lists.laptop.org/listinfo/devel
