Re: [Telepathy] ANNOUNCE: telepathy-gabble 0.7.17
On Sun, Dec 14, 2008 at 20:33, Robert McQueen robert.mcqu...@collabora.co.uk wrote: The I accidentally an entire call *and* MUC release. Tarball: http://telepathy.freedesktop.org/releases/telepathy-gabble/telepathy-gabble-0.7.17.tar.gz Signature: http://telepathy.freedesktop.org/releases/telepathy-gabble/telepathy-gabble-0.7.17.tar.gz.asc Git repository: git://git.collabora.co.uk/git/telepathy-gabble.git http://git.collabora.co.uk/?p=telepathy-gabble.git (gitweb) Dependencies: * dbus 1.1.0 (D-Bus Tubes are no longer conditionally compiled) * dbus-glib 0.78 (fixes support for complex types in hashtables) F-10 doesn't have dbus-glib 0.78, only 0.76 so I can't add this to joyride yet. Do we want an OLPC-4 branch for dbus-glib to handle this? Enhancements: * Add support for the new draft ContactCapabilities spec to communicate tube capabilities. Fixes: * Incoming Jingle calls are no longer automatically accepted when the call is connected and the local codecs are ready. * Incoming MUC invites are no longer automatically accepted when changing your presence. Collabora, is this relevant to OLPC? If not, we can hold off on packaging this for now, but if we need it we must make the above happen... Regards Morgan * fd.o #18918: Send codec parameters according to XEP-0167. * Various Jingle tweaks. Regards, Rob -- Robert McQueen +44 7876 562 564 Director, Collabora Ltd. http://www.collabora.co.uk ___ Telepathy mailing list telepa...@lists.freedesktop.org http://lists.freedesktop.org/mailman/listinfo/telepathy ___ Devel mailing list Devel@lists.laptop.org http://lists.laptop.org/listinfo/devel
Re: [Telepathy] ANNOUNCE: telepathy-gabble 0.7.17
The I accidentally an entire call *and* MUC release. Tarball: http://telepathy.freedesktop.org/releases/telepathy-gabble/telepathy-gabble-0.7.17.tar.gz Signature: http://telepathy.freedesktop.org/releases/telepathy-gabble/telepathy-gabble-0.7.17.tar.gz.asc Git repository: git://git.collabora.co.uk/git/telepathy-gabble.git http://git.collabora.co.uk/?p=telepathy-gabble.git (gitweb) Dependencies: * dbus 1.1.0 (D-Bus Tubes are no longer conditionally compiled) * dbus-glib 0.78 (fixes support for complex types in hashtables) F-10 doesn't have dbus-glib 0.78, only 0.76 so I can't add this to joyride yet. Do we want an OLPC-4 branch for dbus-glib to handle this? Its built in rawhide so should be headed to F-10 shortly. If you want it before then we could tag the F-11 version but it would be better if we could wait and then we don't have yet another fork we have to deal with. Peter ___ Devel mailing list Devel@lists.laptop.org http://lists.laptop.org/listinfo/devel
Re: [Telepathy] ANNOUNCE: telepathy-gabble 0.7.17
On Mon, Dec 15, 2008 at 10:45, Peter Robinson pbrobin...@gmail.com wrote: The I accidentally an entire call *and* MUC release. Tarball: http://telepathy.freedesktop.org/releases/telepathy-gabble/telepathy-gabble-0.7.17.tar.gz Signature: http://telepathy.freedesktop.org/releases/telepathy-gabble/telepathy-gabble-0.7.17.tar.gz.asc Git repository: git://git.collabora.co.uk/git/telepathy-gabble.git http://git.collabora.co.uk/?p=telepathy-gabble.git (gitweb) Dependencies: * dbus 1.1.0 (D-Bus Tubes are no longer conditionally compiled) * dbus-glib 0.78 (fixes support for complex types in hashtables) F-10 doesn't have dbus-glib 0.78, only 0.76 so I can't add this to joyride yet. Do we want an OLPC-4 branch for dbus-glib to handle this? Its built in rawhide so should be headed to F-10 shortly. If you want it before then we could tag the F-11 version but it would be better if we could wait and then we don't have yet another fork we have to deal with. OK, I'll wait for it to land in F-10. Regards Morgan ___ Devel mailing list Devel@lists.laptop.org http://lists.laptop.org/listinfo/devel
Re: [Telepathy] ANNOUNCE: telepathy-gabble 0.7.17
Le lundi 15 décembre 2008 à 11:09 +0100, Peter Robinson a écrit : F-10 doesn't have dbus-glib 0.78, only 0.76 so I can't add this to joyride yet. Do we want an OLPC-4 branch for dbus-glib to handle this? I think we can wait that the updated package reach F-10. Collabora, is this relevant to OLPC? If not, we can hold off on packaging this for now, but if we need it we must make the above happen... No, that shouldn't be a problem. BTW I noticed this changelog entry in the rawhide version of telepathy-salut Enable OLPC support code. It is not used unless a client explicitely requests them. would this mean that the forks aren't required when this gets pushed to the F-10 packages? Actually Gabble doesn't have a --enable-olpc option (only Salut has one). I removed it from jhbuild's moduleset. But I'm afraid we still need the fork for the Rainbow workaround. G. ___ Devel mailing list Devel@lists.laptop.org http://lists.laptop.org/listinfo/devel
Re: [Sugar-devel] Wacom Bamboo with XO?
Hey Chris, Awesome, thanks for testing! On Sun, Dec 14, 2008 at 12:12 PM, Chris Marshall jns-cmarsh...@comcast.netwrote: * The display update seems to be by continuous stroke: XO #1 user draws a curve not lifting pen. After the stylus is lifted from the tablet the stroke updates on XO #2. That's intentional, for network performance reasons. I didn't want to try to create a realtime network application given the potential for shaky wireless. The painting algorithm is written in terms of strokes anyway so it would be very inefficient to try to paint two strokes simultaneously on one XO. If you have a friend available, I'd love to hear how it holds up over a Jabber server with both people scribbling simultaneously :) * The mouse would need to be moved on the other XO for the screen updates to propagate. That's *not* intentional, sounds like another side effect of the idling change (to reduce battery usage)! * The colors and brush parameters are common to both XOs although the display of the settings widget (color and brush type) did not update with changes from the other side. Also not intentional, sounds like a bug! Each XO should have its own brush settings. * Erasing the screen was only an option on XO #1 (the inviter) *but* the clear screen did not propagate to the other XOs so further drawing on XO #1 was not in sync with the images on XO #2. Suggest that clear image be propagated with the option to do a local save to Journal on XO #2 so that work is not lost if they wish to keep it. The erase should be propagated. Good idea regarding the option to keep, I'll see if it can be done (the receiving XO would have to queue canvas updates until the Alert was cleared - Sugar doesn't really provide for modal alerts). * It would be really cool if each XO had its own pointer with brush/palette/... options. One mode that would be nice might be a sort of side-by-side version where each XO would be able to draw its own part of the screen (by mask, not necessarily by rectangle) so the students could work on a joint drawing. Yeah, that's definitely how it's intended to be! It was designed such that both users can paint anywhere at the same time using different brushes, but that the strokes appear in a consistent order on both XOs. * A mural mode would be excellent with a large virtual drawing area and each XO able to pan around and draw wherever Good idea! As of v11 the painting canvas can be arbitrarily sized (it used to be locked at 1/2x the window size), so it might be smart to add a change canvas size option now. * The mouse drawing problem was also visible in collaboration. Yep, this is a global bug- I'm waiting to release the next version publicly until it and a few other things are fixed. Thanks again for the reports Chris, it's amazingly useful (and motivating)! :) Best, Wade ___ Devel mailing list Devel@lists.laptop.org http://lists.laptop.org/listinfo/devel
Re: Joyride SD card corruption
nn Dec 12 2008, at 11:34, Mikus Grinbergs was caught saying: WARNING -- since about build 2590 I can get my permanent SD card (ext2 filesystem) completely corrupted - I've had to restore it twice. [This is a regression - with 2583 and earlier I never saw any SD corruption. Note that my systems have multiple USB devices.] Hi Mikus, Can you re-test with 2586 and then 2587? 2587 brought in a kernel configuration change (CONFIG_USB_SUSPEND) and I'm wondering if it is the root cause. You can just update the kernels if you feel comfortable updating kernel RPMS as per http://wiki.laptop.org/go/Kernel#Installing_OLPC_kernel_RPMs. 2587: http://dev.laptop.org/~dilinger/master/kernel-2.6.27-20081210.1.olpc.05aa2d840dc7b96.i586.rpm pre-2587: http://dev.laptop.org/~dilinger/master/kernel-2.6.27-20081201.1.olpc.672cde9409f412e.i586.rpm Thanks, ~Deepak -- Deepak Saxena - Kernel Developer, One Laptop Per Child _ __o (o ---\, Give One Laptop, Get One Laptop //\ - ( )/ ( ) http://www.amazon.com/xoV_/_ ___ Devel mailing list Devel@lists.laptop.org http://lists.laptop.org/listinfo/devel
Re: Joyride SD card corruption
On Dec 15 2008, at 08:23, Deepak Saxena was caught saying: nn Dec 12 2008, at 11:34, Mikus Grinbergs was caught saying: WARNING -- since about build 2590 I can get my permanent SD card (ext2 filesystem) completely corrupted - I've had to restore it twice. [This is a regression - with 2583 and earlier I never saw any SD corruption. Note that my systems have multiple USB devices.] Hi Mikus, Can you re-test with 2586 and then 2587? 2587 brought in a I mean 2588 insted of 2587 here if you decide to do a full build update. I miss-read the logs. Thanks, ~Deepak -- Deepak Saxena - Kernel Developer, One Laptop Per Child _ __o (o ---\, Give One Laptop, Get One Laptop //\ - ( )/ ( ) http://www.amazon.com/xoV_/_ ___ Devel mailing list Devel@lists.laptop.org http://lists.laptop.org/listinfo/devel
sugar in mongolia (was Re: [Community-news] OLPC News (2008-12-15))
On Mon, Dec 15, 2008 at 15:25, Jim Gettys j...@laptop.org wrote: A Mongolian version of 8.2 has been installed in the Ulaanbaatar schools. The feedback is overwhelmingly positive. When David Cavallo visited a school where the new version is in use, the teachers actually shook his hand because they liked it so much. There is also a bug reporting system in place. I'm very happy to hear this, is there any way we could get more detailed feedback about usage of Sugar 0.82 in Mongolia? AFAIK, the feedback we got some months ago was about older versions of Sugar. Thanks, Tomeu ___ Devel mailing list Devel@lists.laptop.org http://lists.laptop.org/listinfo/devel
Re: [Telepathy] ANNOUNCE: telepathy-gabble 0.7.17
F-10 doesn't have dbus-glib 0.78, only 0.76 so I can't add this to joyride yet. Do we want an OLPC-4 branch for dbus-glib to handle this? I think we can wait that the updated package reach F-10. Collabora, is this relevant to OLPC? If not, we can hold off on packaging this for now, but if we need it we must make the above happen... No, that shouldn't be a problem. BTW I noticed this changelog entry in the rawhide version of telepathy-salut Enable OLPC support code. It is not used unless a client explicitely requests them. would this mean that the forks aren't required when this gets pushed to the F-10 packages? The other thing that might be worth considering early in the release cycle is to enable the updates-testing Fedora repository as this would enable updates to hit joyride quicker, and would also allow any regressions in thinks like dependencies to be noticed while the package is in testing before it hit Fedora updates and is too late. Peter ___ Devel mailing list Devel@lists.laptop.org http://lists.laptop.org/listinfo/devel
Re: [Telepathy] ANNOUNCE: telepathy-gabble 0.7.17
On Mon, Dec 15, 2008 at 12:09, Peter Robinson pbrobin...@gmail.com wrote: BTW I noticed this changelog entry in the rawhide version of telepathy-salut Enable OLPC support code. It is not used unless a client explicitely requests them. would this mean that the forks aren't required when this gets pushed to the F-10 packages? In addition to --enable-olpc we have patches to make tubes work under Rainbow that are required in the OLPC-4 branch but would weaken security on the F-10 version - so we still need the fork. Regards Morgan ___ Devel mailing list Devel@lists.laptop.org http://lists.laptop.org/listinfo/devel
Re: Downloading Scratch project to XO
Hi, Phillipp. Thanks for reporting this problem. I believe there is a way to tell the XO to associate the .sb file extension with Scratch. I will look into that and let you know if I figure it out. -- John On Dec 14, 2008, at 8:03 PM, Philipp Kocher wrote: Hi I would like to download Scratch projects from a local server to the XO. On the server I added the following line to the file /etc/mime.types: application/scratch sb The apache server is now sending files with sb-extension with mime type application/scratch. On the XO the mime type gets stored in the datastore metadata-file. After adding the following line to the Scratch activity/ activity.info file, Scratch gets started when clicking on the Scratch project in the Journal: mime_types = application/scratch The problem is that the project doesn't get opened. The scratch start script bin/scratch-activity gets called with the -u argument holding a datastore object ID, but the script doesn't handle the -u argument. How can I convert a datastore object ID to a filename, so scratch can open the project? And how do I get the necessary permissions to access the file? Thanks, Philipp Pepyride School Cambodia ___ Devel mailing list Devel@lists.laptop.org http://lists.laptop.org/listinfo/devel
Re: Downloading Scratch project to XO
John, does Scratch accept a .sb file on its command line? If so, the launcher script could get the file from the Journal and pass it on. - Bert - On 15.12.2008, at 18:53, John Maloney wrote: Hi, Phillipp. Thanks for reporting this problem. I believe there is a way to tell the XO to associate the .sb file extension with Scratch. I will look into that and let you know if I figure it out. -- John On Dec 14, 2008, at 8:03 PM, Philipp Kocher wrote: Hi I would like to download Scratch projects from a local server to the XO. On the server I added the following line to the file /etc/mime.types: application/scratch sb The apache server is now sending files with sb-extension with mime type application/scratch. On the XO the mime type gets stored in the datastore metadata-file. After adding the following line to the Scratch activity/ activity.info file, Scratch gets started when clicking on the Scratch project in the Journal: mime_types = application/scratch The problem is that the project doesn't get opened. The scratch start script bin/scratch-activity gets called with the -u argument holding a datastore object ID, but the script doesn't handle the -u argument. How can I convert a datastore object ID to a filename, so scratch can open the project? And how do I get the necessary permissions to access the file? Thanks, Philipp Pepyride School Cambodia ___ Devel mailing list Devel@lists.laptop.org http://lists.laptop.org/listinfo/devel ___ Devel mailing list Devel@lists.laptop.org http://lists.laptop.org/listinfo/devel
Slimmed Down Fedora 10 on XO (was Fedora 10 on XO)
Hi All, Thanks for all the feedback on my questions about what it would take to run a slimmed down Fedora 10 on the XO NAND. https://www.redhat.com/archives/fedora-olpc-list/2008-December/msg00022.html To reiterate, the goal is one distribution with two Desktop Environments (Sugar and one standard one). I think the main work now is to pick the minimal package list that we need and will fit on the XO NAND. Can anyone get a slimmed down Fedora 10 with window manager running on an XO? If so, can you record the packages and available space in the specifications section here? http://wiki.laptop.org/go/Feature_roadmap/Run_Fedora_applications_on_XO RTFM answers with URLs also welcome. Chris and Erik, Where are we with getting a proof of concept for this feature in place? You both mentioned some work in this area (Chris on resurrecting something Scott did and Erik on other work). Let me know the status and next steps. The hard part will come when we need to pick the bare minimum set of functionality. I especially want to know what additional libraries/RPMs/features we need to install beyond what we alrady have in XO 8.2.0. Thanks, Greg S ___ Devel mailing list Devel@lists.laptop.org http://lists.laptop.org/listinfo/devel
The new OLPC ads
http://www2.infopresse.com/blogs/actualites/archive/2008/12/15/article-29417.aspx ___ Devel mailing list Devel@lists.laptop.org http://lists.laptop.org/listinfo/devel
Project name : Retroscope has been set up
Thu, 4 Dec 2008 02:17:26 -0600, Gabriel Burt gabriel.b...@gmail.com wrote: 1. Project name : Retroscope Done. Your tree is here: git+ssh://gb...@dev.laptop.org/git/activities/retroscope 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 he...@laptop.org -- ...since wars begin in the minds of men, it is in the minds of men that the defenses of peace must be constructed. --Constitution of the United Nations Educational, Scientific, and Cultural Organization (UNESCO), 16 November, 1945 ___ Devel mailing list Devel@lists.laptop.org http://lists.laptop.org/listinfo/devel
Re: Downloading Scratch project to XO
Hi Philipp, I am not sure if this helps, but our apache config file has this for the Scratch file extension: AddType application/x-scratch-project sb My impression is that what you descrie has to do more with how the XO operating system handles the Scratch file type and/or with how to create the correct system call for Scratch to open a file. For the first, probably someone at OLPC might be able to you more, for the latter perhaps John know can help. Best. 2008/12/14 Philipp Kocher philipp.koc...@gmx.net: Hi I would like to download Scratch projects from a local server to the XO. On the server I added the following line to the file /etc/mime.types: application/scratch sb The apache server is now sending files with sb-extension with mime type application/scratch. On the XO the mime type gets stored in the datastore metadata-file. After adding the following line to the Scratch activity/activity.info file, Scratch gets started when clicking on the Scratch project in the Journal: mime_types = application/scratch The problem is that the project doesn't get opened. The scratch start script bin/scratch-activity gets called with the -u argument holding a datastore object ID, but the script doesn't handle the -u argument. How can I convert a datastore object ID to a filename, so scratch can open the project? And how do I get the necessary permissions to access the file? Thanks, Philipp Pepyride School Cambodia -- Andrés ___ Devel mailing list Devel@lists.laptop.org http://lists.laptop.org/listinfo/devel
Fixed Puritan bug on F10/Intrepid
Reuben, I was able to reproduce and work around the rpmdb version problem you found today on a new Intrepid vm I created on weka.l.o. Would you mind retesting with my new 767 compilation? (To do so, just wipe the compilation and re-clone it. I modified the cloning instructions so that, in the future, you'd be able to run 'git pull' to update.) Thanks, Michael ___ Devel mailing list Devel@lists.laptop.org http://lists.laptop.org/listinfo/devel
Re: XO deployment count?
On Mon, Dec 15, 2008 at 4:08 PM, Samuel Klein s...@laptop.org wrote: On Tue, Nov 18, 2008 at 1:30 PM, da...@lang.hm wrote: In countries all over the world, XOs are *actually arriving in children's hands*. --scott [*] roughly means there are lots of minor details I'm omitting; Peru rough numbers are good enough for answering critics who claim that OLPC is a failure, the only thing is that if different people give vastly different numbers we end up looking like idiots. The latest I have heard is more than half a million in the hands of students, and another half million on order or in the pipeline. That isn't good enough for updating the Wiki, but staff are completely out of bandwidth at least until after the New Year. There are supposed to be more blockbuster G1G1 ads coming, for one thing. We have zero information on sales through Amazon after the initial best-seller listings. the deployments page mentioned above is not linked to from the main page of the wiki (this is one of my gripes about most wikis, they end up having lots of information in them, but the linking structure is frequently so bad that you would never know it, which leads to multiple pages being maintained by different people, with conflicting information) OLPC Ghana page says that Ghana has ordered 10,000 units, and committed to enough for every child. But there is no contact information, and the Ministry in Ghana (moess.gov.gh) doesn't have a page for the project. if you could pass this along to the folks on the business side. they need to realize that we are part of their sales/marketing force. You certainly are. The main page is editable by anyone with a user account; I encourage anyone with ideas about what should go there to add specific suggestions to the talk page, or to update directly if the change is obvious. Most other pages, if you see that they aren't linking to the most current version of a relevant page, be bold and fix them. SJ ___ Devel mailing list Devel@lists.laptop.org http://lists.laptop.org/listinfo/devel -- Silent Thunder (默雷/धर्ममेघशब्दगर्ज/دھرممیگھشبدگر ج) is my name And Children are my nation. The Cosmos is my dwelling place, The Truth my destination. http://wiki.sugarlabs.org/go/User:Mokurai ___ Devel mailing list Devel@lists.laptop.org http://lists.laptop.org/listinfo/devel
Re: Minutes of Power in 9.1.0 meeting
On a different note, one test we might think about running is the closest thing the industry has to a standard battery life test. It's specified on a lot of the netbook specs. It's defined here: http://it.jeita.or.jp/mobile/e/index.html However, I'm also seeing that a lot of vendors are choosing not to use this test because it generally results in a number higher than what the typical user will actually get. I looked it over. Companies report the average of two measurements: The hours of power available when the machine is dialed down to minimum power, screen at its very dimmest (reflective mode for us), doing nothing, everything disabled. And the other measurement is when the system is playing back an MPEG movie, in a small window and with relatively standard OS and display settings. (We can't do this out of the box, but we could install an MPEG codec for the test, and run it that way. Or transcode their test movie to Ogg Theora and try that for simplified release testing, until we have to report an official number using MPEG.) It would be useful for us to measure and improve the numbers in both of those modes -- but the average will be highly misleading to everyone. Still, it would provide a comparison to netbooks and other computers. It would be nice if our runtime in the minimum power mode could in 9.1.0 be almost equal to our lid-closed suspend time, which I measured in #7879 to be 8 hours with mesh/wifi chip on, and 44+ hours with the mesh/wifi off. Actually, it won't be that good, because the test requires that the screen remain on (perhaps consuming 0.5W), though the reflective screen means we can turn off the backlight. So perhaps we'll get 16 to 20 hours in that mode. If so, averaging with perhaps 2 to 4 hours of active runtime, for a total standard number of about 10 to 12 hours would still be pretty good by comparison to typical netbook products. [First we'll have to fix a bunch of bugs...] John ___ Devel mailing list Devel@lists.laptop.org http://lists.laptop.org/listinfo/devel
No surprise on memory
-BEGIN PGP SIGNED MESSAGE- Hash: SHA1 I recently learned a few very important things about Linux memory management (I'm speaking about how its supposed to work, irrespective of any bugs). Operating systems experts already know all of this, but I did not. 1. Malloc lies. It will happily return a pointer to an allocation larger than the entire amount of physical memory, just hoping that you won't use it. This is called overcommit. 2. Even without swap, the system will never actually run out of memory. Instead, as some program attempts to make use of the memory that it has already allocated, the kernel will start paging out all clean pages that are not currently in use. At this point, the system has so little remaining free memory that only the specific pages of binaries that are currently in use can be held in memory. The system is essentially running executables directly from disk, which is so slow that it would take ages to finally run out of memory. Bernie helpfully compared this type of thrashing to Zeno's paradox. 3. To avoid getting stuck in this situation, the kernel has a OOM killer. This is a misnomer. The OOM killer picks a process to kill _before_ OOM is reached. It does this either because the system is already low on memory and is paging lots of stuff out to disk, or because the system is overcommitted by an unacceptably large ratio. I found this very surprising, and in some ways I still do. I read many justifications of these decisions, but I was curious to test it for myself. I was happy, therefore, to learn about /proc/sys/vm/overcommit_memory and /proc/sys/vm/overcommit_ratio. These knobs control the memory system. By setting overcommit_memory to 2 and overcommit_ratio to 95, it is possible to approximate the behavior that a naive C programmer might expect from the kernel. In this mode, malloc will only return a non-null pointer if the allocation can actually be fulfilled in physical memory. Also, this setting of overcommit_ratio ensures that 5% of memory is reserved to the kernel. I tried running 767 on an XO in this mode, and the bottom line is that the conventional wisdom is correct. I set the parameters and restarted X, and Sugar came up fine. Every view displayed correctly, including the Journal and the mesh view with buddies from Gabble. Some activities, like Calculate, run fine, but the big ones, like Record and Browse, are semi-functional at best, and at worst cause sugar to lock up entirely. This is not too surprising. I'm no expert, but making the system work well without overcommit would probably require extensive modifications to the python interpreter, the fd.o libraries (dbus, gstreamer, telepathy, etc.), gecko, and maybe even X. All of these would need to allocate only as much memory as they need, and react appropriately when malloc returns NULL. In other words, 'tain't gonna happen. Conclusion: no magic get-out-of-jail-free card. - --Ben -BEGIN PGP SIGNATURE- Version: GnuPG v2.0.9 (GNU/Linux) iEYEARECAAYFAklHLL4ACgkQUJT6e6HFtqSf7gCdGQlnXOaIAA/214NbLCjM3imi NdsAoJaFUD2SvtRtvKDn1NfytrJk2yN4 =TCMw -END PGP SIGNATURE- ___ Devel mailing list Devel@lists.laptop.org http://lists.laptop.org/listinfo/devel
Re: Minutes of Power in 9.1.0 meeting
On Mon, 15 Dec 2008, John Gilmore wrote: On a different note, one test we might think about running is the closest thing the industry has to a standard battery life test. It's specified on a lot of the netbook specs. It's defined here: http://it.jeita.or.jp/mobile/e/index.html However, I'm also seeing that a lot of vendors are choosing not to use this test because it generally results in a number higher than what the typical user will actually get. I looked it over. Companies report the average of two measurements: The hours of power available when the machine is dialed down to minimum power, screen at its very dimmest (reflective mode for us), doing nothing, everything disabled. And the other measurement is when the system is playing back an MPEG movie, in a small window and with relatively standard OS and display settings. (We can't do this out of the box, but we could install an MPEG codec for the test, and run it that way. Or transcode their test movie to Ogg Theora and try that for simplified release testing, until we have to report an official number using MPEG.) It would be useful for us to measure and improve the numbers in both of those modes -- but the average will be highly misleading to everyone. Still, it would provide a comparison to netbooks and other computers. It would be nice if our runtime in the minimum power mode could in 9.1.0 be almost equal to our lid-closed suspend time, which I measured in #7879 to be 8 hours with mesh/wifi chip on, and 44+ hours with the mesh/wifi off. Actually, it won't be that good, because the test requires that the screen remain on (perhaps consuming 0.5W), though the reflective screen means we can turn off the backlight. So perhaps we'll get 16 to 20 hours in that mode. If so, averaging with perhaps 2 to 4 hours of active runtime, for a total standard number of about 10 to 12 hours would still be pretty good by comparison to typical netbook products. as-is you are pretty good. I used the XO to follow presentation slides recently. with wifi and the backlight off I went from 9-5 and showed a bit more than half the battery life left (not a lot of activity, just moving the slides periodicly, but never idle enough to let it turn off the screen). so your 16 or so hours looks pretty reasonable. David Lang ___ Devel mailing list Devel@lists.laptop.org http://lists.laptop.org/listinfo/devel
Re: No surprise on memory
On Mon, Dec 15, 2008 at 11:21:18PM -0500, Benjamin M. Schwartz wrote: I'm no expert, but making the system work well without overcommit would probably require extensive modifications to the python interpreter, the fd.o libraries (dbus, gstreamer, telepathy, etc.), gecko, and maybe even X. All of these would need to allocate only as much memory as they need, and react appropriately when malloc returns NULL. In other words, 'tain't gonna happen. Couldn't we instrument malloc to report when it returns NULL (into an area of memory we have helpfully set aside for the purpose) and then report those events during testing, in order to find out and fix those instances of overallocation? -- James Cameronmailto:qu...@us.netrek.org http://quozl.netrek.org/ ___ Devel mailing list Devel@lists.laptop.org http://lists.laptop.org/listinfo/devel
Re: [Server-devel] Collaboration unreliable 0.5
2008/12/14 David Leeming leem...@pipolfastaem.gov.sb This is intermittent; 30 mins ago I did have 3 out of 4 showing, but after rebooting everything and waiting 30 mins, still no sign of any. My user group helping me test XS 0.5 has noticed the same issue. It's not limited to XOs in the neighborhood view, either. Several of us use other chat clients like finch, pidgin, gajim, and adium (on the Mac), and the buddy list in those does not reliably populate. Luckily we had already established the convention of a permanent MUC named chat, which no one had trouble joining. There, at least, we could see and chat with everyone fairly reliably. That is not an acceptable solution for children, of course. Our theory was that ejabberd isn't pushing out all the roster data to other connected users or there's a longer time interval in between pushes. We noticed if we stayed on long enough, eventually more folks would show up in the buddy list or the XO network home, but it seemed competely random. I think it's gotten better lately, but that's probably subjective. Anna Schoolfield Birmingham ___ Server-devel mailing list Server-devel@lists.laptop.org http://lists.laptop.org/listinfo/server-devel
Re: [Server-devel] Collaboration unreliable 0.5
On Sun, Dec 14, 2008 at 7:59 PM, David Leeming leem...@pipolfastaem.gov.sb wrote: I apologise if this issue has already been dealt with on this list. Thanks for bringing this up, it's definitely news to me. Testing on the ejabberd on 0.5 has been on load testing -- this is a new issue. A few questions - Are you using Access Points or AAs? (I seem to remember you were using APs...) - When an XO cannot see its buddies, what does olpc-netstatus say? I have used the same set up exactly with XS version 0.4 and it's all solid – the neighbourhood view fills up rapidly after connecting. What's causing the unreliability with 0.5? Unsure. Anna's email gives me a bit more info to sort this out. Let me try and reproduce this here... cheers, martin -- martin.langh...@gmail.com mar...@laptop.org -- School Server Architect - ask interesting questions - don't get distracted with shiny stuff - working code first - http://wiki.laptop.org/go/User:Martinlanghoff ___ Server-devel mailing list Server-devel@lists.laptop.org http://lists.laptop.org/listinfo/server-devel
Re: [Server-devel] xs on cd
On Sat, Dec 13, 2008 at 12:09 AM, Tony Anderson tony_ander...@usa.net wrote: At OLENepal, we are using a USB stick to install XS on the servers. We have created a 'boot cd' which installs XS from the USB stick when the server is unable to boot from CD. This saves have to reburn CD's. I do the same - there's an installcd-to-usb script I use here - actually, the name is mkusbinstall. Jerry wrote it - http://dev.laptop.org/git?p=projects/xs-livecd;a=tree;f=util;h=8994c236d2e3cec0dc9507e465fead8643cb51c6;hb=HEAD Can I recommend you guys consider moving to 0.5 ;-) or the (probably coming) 0.5.1 ? cheers, m -- martin.langh...@gmail.com mar...@laptop.org -- School Server Architect - ask interesting questions - don't get distracted with shiny stuff - working code first - http://wiki.laptop.org/go/User:Martinlanghoff ___ Server-devel mailing list Server-devel@lists.laptop.org http://lists.laptop.org/listinfo/server-devel
Re: [Server-devel] Collaboration unreliable 0.5
Hi I am using USB active antenna (prototype). Has always worked well with 0.4. I concur with Anna that if you leave them connected, after considerable time they do partially populate. I have run olpc-netstatus on all four laptops, making first certain that: - all are connected to School Server - all appear in eJabberd as online users - none appear in network neighbourhood (you can't see any on any laptop) 15 mins+ after first connected Remember, they are all registered and running 8.2 The olpc-netstatus shows the following: On ALL the four XOs: - Correct m0odel, serial, MAC - Build 767, Firmware CL1 Q2E18 Q2E - Libertas: 5.110.22.p18 - Correct Nick, uptime - IP msh0 172.18.10.2 (3,4,5 i.e. the four XOs) - DNS 172.18.0.1 - Telepaphy gabble - Jabber school.oceania.org - XOs 2 - Essid olpc-mesh - Channel 1 - School school.oceania.org - Config School Mesh Note, in eJabberd the server name is shown as schoolserver.oceania.org not school.oceania.org and the domain name was configured on the XS as schoolserver.oceania.org (that's also what the hostname is in the /etc/sysconfig/network file) David Leeming OLPC Coordinator, SPC and Technical Advisor, People First Network Honiara, Solomon Islands -Original Message- From: Martin Langhoff [mailto:martin.langh...@gmail.com] Sent: Tuesday, 16 December 2008 2:52 a.m. To: David Leeming Cc: XS Devel Subject: Re: Collaboration unreliable 0.5 On Sun, Dec 14, 2008 at 7:59 PM, David Leeming leem...@pipolfastaem.gov.sb wrote: I apologise if this issue has already been dealt with on this list. Thanks for bringing this up, it's definitely news to me. Testing on the ejabberd on 0.5 has been on load testing -- this is a new issue. A few questions - Are you using Access Points or AAs? (I seem to remember you were using APs...) - When an XO cannot see its buddies, what does olpc-netstatus say? I have used the same set up exactly with XS version 0.4 and it's all solid - the neighbourhood view fills up rapidly after connecting. What's causing the unreliability with 0.5? Unsure. Anna's email gives me a bit more info to sort this out. Let me try and reproduce this here... cheers, martin -- martin.langh...@gmail.com mar...@laptop.org -- School Server Architect - ask interesting questions - don't get distracted with shiny stuff - working code first - http://wiki.laptop.org/go/User:Martinlanghoff ___ Server-devel mailing list Server-devel@lists.laptop.org http://lists.laptop.org/listinfo/server-devel
