New joyride build 2230
http://xs-dev.laptop.org/~cscott/olpc/streams/joyride/build2230 Changes in build 2230 from build: 2228 Size delta: 0.00M -xorg-x11-drv-geode 2.9.0-2.fc9 +xorg-x11-drv-geode 2.10.0-1.fc9 -cerebro 2.9.4-1.olpc3 +cerebro 2.9.8-1.olpc3 -boost 1.34.1-13.fc9 +boost 1.34.1-15.fc9 -coreutils 6.10-27.fc9 +coreutils 6.10-28.fc9 -elfutils-libelf 0.133-3.fc9 +elfutils-libelf 0.135-1.fc9 -xapian-bindings-python 1.0.6-1.fc9 +xapian-bindings-python 1.0.7-1.fc9 -xapian-core-libs 1.0.6-1.fc9 +xapian-core-libs 1.0.7-1.fc9 --- Changes for xorg-x11-drv-geode 2.10.0-1.fc9 from 2.9.0-2.fc9 --- + update to 2.10.0 drop upstreamed patches --- Changes for cerebro 2.9.8-1.olpc3 from 2.9.4-1.olpc3 --- + 2.9.8: Fixed licensing, added 'get_node_id' dbus interface (#7695) --- Changes for boost 1.34.1-15.fc9 from 1.34.1-13.fc9 --- + Fix changes meaning of keywords in boost date_time + Resolves: #450718 + Change devel-static back to static. + Related: #225622 --- Changes for coreutils 6.10-28.fc9 from 6.10-27.fc9 --- + dd: iflag=fullblock now read full blocks if possible + ls: --color now highlights files with capabilities (#449985) + suppressed failing test in tests/touch/no-create-missing -- This mail was automatically generated See http://dev.laptop.org/~rwh/announcer/joyride-pkgs.html for aggregate logs See http://dev.laptop.org/~rwh/announcer/joyride_vs_update1.html for a comparison ___ Devel mailing list Devel@lists.laptop.org http://lists.laptop.org/listinfo/devel
Re: specifying what services Activities may use
Hi Mikus, John, Michael et al, Thanks for testing some activities and noting that many are broken. This will certainly be a user problem! There was a thread on it two weeks ago: http://lists.laptop.org/pipermail/devel/2008-July/016501.html We didn't close it well. I can't speak effectively for activity developers so we need to hear from you, thanks for speaking up! One result of the last thread is a Release notes section for activities needing upgrade: http://wiki.laptop.org/go/Release_Notes/8.2.0#Activities_Needing_Upgrade I got Playgo and Measure off this thread. Add any others or name them here and I'll post them. I'm not sure if an activity that fails due to API change is a bug or a feature but we should keep a record of it for users and developers. Michael and team, Can we get documentation of all API changes (since 708 and 656) that affect activities ASAP? BTW where is the definitive documentation of all APIs available to activities and is it up to date? When can we freeze API changes for 8.2.0? Let me know how I can help in this area. I see it as critical to user satisfaction and activity developer satisfaction too. Thanks, Greg S ___ Devel mailing list Devel@lists.laptop.org http://lists.laptop.org/listinfo/devel
Re: TuxPaint woes (John Gilmore)
Hi John and Michael, Thanks to John for raising these concerns and sticking with us after a frustrating first two experiences. SimCity has good traction in the user base and its a very high priority activity for us. On when the code is stable and frozen enough to do final regression testing of activities: Michael, Can we track that as a milestone? Is that code freeze (a.k.a. package-level change control) which is targeted (pending confirmation e-mail) for Wed. August 6? On the question of future API re-architecture, it is under consideration for 9.1.0 and being tracked here: http://wiki.laptop.org/go/9.1.0 especially at http://wiki.laptop.org/go/9.1.0#e-mail_from_Ben_S I will try to warn well in advance of any future API changes and I will try to hold changes to a minimum (target none!) between 8.2.0 and 9.1.0. We need to hear confirmation from the engineers and we may need to revisit this after we put a stake in the ground on freezing 8.2.0 APIs. Thanks, Greg S Date: Tue, 29 Jul 2008 17:54:42 -0700 From: John Gilmore [EMAIL PROTECTED] Subject: Re: TuxPaint woes To: devel@lists.laptop.org, [EMAIL PROTECTED] Message-ID: [EMAIL PROTECTED] can't think of a faster way to make developers give up on our platform as a lost cause. As someone whose year-long OLPC-specific project (SimCity) was broken by Sugar interface changes right before the 650 release, I can report that it was pretty disheartening. Both the sound and the running icon for SimCity were broken (and remain unfixed today). The breakage was created *after* Electronic Arts' QA testers signed off on the fully functional SimCity release. The next release was the 656 bug-patch, not involving SimCity; the one after that was the update.1 non-release that was frozen for four months without visible progress, and then some random numbered snapshot became the release, except without any activities. There hasn't been one since. When, exactly, should we be testing SimCity against a release candidate? What level of interface freeze is OLPC and SugarLabs willing to give us? When we revise it until it works, and submit it to EA for another round of QA, we want to be sure that Sugar won't break it again with last-minute changes. There are many reasons to change Sugar interfaces. The datastore interface is totally terrible and can't survive, for example. But how about providing a second, improved, interface in parallel; then migrating most activities over to it; then deprecating the original interface, and gradually removing support for it over several releases? Rather than changing the syntax or semantics of the existing interface. And how about doing interface conversion work at the *beginning* of a 6-month development cycle, not at the very end? This isn't rocket science; many software projects have learned these lessons. Sugar can learn 'em too. John ___ Devel mailing list Devel@lists.laptop.org http://lists.laptop.org/listinfo/devel
Re: CIS solar charging-correct list?
Hi Edward, Given the essential need to charge in regions totally devoid of mains power (in our case inland New Guinea),the solar quest is naturally pretty crucial to the whole rollout. It's otherwise akin to being given a 4WD Mercedes, but with no ongoing fuel supply Yes, I am putting together a group to research electricity, Internet connections, and microfinance in order to get XOs to the poorest and most remote villages. We have done quite a bit of that research with the SolarNetOne project: http://gnuveau.net/cgi-bin/wiki.cgi In quite a few areas, VSAT or long range wifi are going to be your only options on upstream connectivity. For small scale solar charge controllers, the Tier project at Berkeley has some open schematics: http://tier.cs.berkeley.edu/wiki/Power Also, members of our team have had experience with microfinance of solar before: http://self.org Enjoy, Scott TIA - Manuka ( Wellington NZ) --- ___ Devel mailing list Devel@lists.laptop.org http://lists.laptop.org/listinfo/devel -- Edward Cherlin End Poverty at a Profit by teaching children business http://www.EarthTreasury.org/ The best way to predict the future is to invent it.--Alan Kay ___ 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
Stability (was Re: TuxPaint woes)
On 30.07.2008, at 13:20, Greg Smith wrote: On when the code is stable and frozen enough to do final regression testing of activities: Michael, Can we track that as a milestone? Is that code freeze (a.k.a. package-level change control) which is targeted (pending confirmation e-mail) for Wed. August 6? On the question of future API re-architecture, it is under consideration for 9.1.0 and being tracked here: http://wiki.laptop.org/go/9.1.0 especially at http://wiki.laptop.org/go/9.1.0#e-mail_from_Ben_S I will try to warn well in advance of any future API changes and I will try to hold changes to a minimum (target none!) between 8.2.0 and 9.1.0. We need to hear confirmation from the engineers and we may need to revisit this after we put a stake in the ground on freezing 8.2.0 APIs. What is frustrating is not even change itself - we all know that the platform is not stable yet so this is expected. The bad part is that changes happened after freezes, are usually unannounced, and remain undocumented even for major releases. For example, I filed http://dev.laptop.org/ticket/4695 about 9 months ago. Don't think anyone has worked on this. Also, it was silently moved to 8.2 without any notice in Trac. Bad. And it's not only API, I remember that a library was removed to save space very late in a release cycle which broke our activity (was a few releases ago). So the set of libraries shipped should be frozen about the same time the API is frozen (or maybe that is implied, since removing libraries could be seen as fundamental API change). - Bert - ___ Devel mailing list Devel@lists.laptop.org http://lists.laptop.org/listinfo/devel
What is the best way
... to connect the XO to a projector? Are there USB vga/etc cards known to work to with the XO? Thanks Victor Lazzarini Music Technology Laboratory Music Department National University of Ireland, Maynooth ___ Devel mailing list Devel@lists.laptop.org http://lists.laptop.org/listinfo/devel
Re: What is the best way
On 30.07.2008, at 14:16, Victor Lazzarini wrote: ... to connect the XO to a projector? Are there USB vga/etc cards known to work to with the XO? See http://wiki.laptop.org/go/Remote_display - Bert - ___ Devel mailing list Devel@lists.laptop.org http://lists.laptop.org/listinfo/devel
Re: What is the best way
bert wrote: On 30.07.2008, at 14:16, Victor Lazzarini wrote: ... to connect the XO to a projector? Are there USB vga/etc cards known to work to with the XO? See http://wiki.laptop.org/go/Remote_display the sisusbvga.ko module would be another module (along with a full set of USB modules, bluetooth modules, etc) that would be a good candidate for inclusion in a modules not installed by default but available via rpm package. (a la trac #7326) this would be an excellent packaging project for a volunteer contributor. paul =- paul fox, [EMAIL PROTECTED] ___ Devel mailing list Devel@lists.laptop.org http://lists.laptop.org/listinfo/devel
Re: specifying what services Activities may use
On Wed, 2008-07-30 at 07:02 -0400, Greg Smith wrote: Michael and team, Can we get documentation of all API changes (since 708 and 656) that affect activities ASAP? Are you talking about sugar APIs, or APIs for other library components present on the system which some activities may use? BTW where is the definitive documentation of all APIs available to activities and is it up to date? When can we freeze API changes for 8.2.0? Again, same question for both. Sorry to answer a question with a question :) Daniel ___ Devel mailing list Devel@lists.laptop.org http://lists.laptop.org/listinfo/devel
Re: Notes from today's Release Meeting(s)
On Tue, Jul 29, 2008 at 09:49:23PM -0700, S Page wrote: Michael Stone wrote: 5. Separately, I wish we were receiving even more volunteer testing. Can you help out? Fame, glory, and the undying gratitude of hundreds of thousands of children await you! Background: I'm just a G1G1. I don't have a Developer key, but on my own initiative I installed candidate-703 and candidate-708 using olpc-update and provided some feedback and bug reports. ... More clarity. Is more clarity needed more in some fora than in others? Is this nominated Wednesday build going to be a candidate build that mere users can install using olpc-update, or do I need the fabled bronze Developer key to become a joyride-like tester of nominated 8.2 builds? It will soon, but not yet. In a few weeks, once we're more confident in the sustainability and security of the build, then we'll publish an official candidate build with cryptographic signatures that mark it as suitable for mass installation. and that cloning/updating the Friends in Testing page would be useful. I'd never heard of http://wiki.laptop.org/go/Friends_in_testing I've never heard of X is a rather consistent refrain. Hrm. I did sign up for http://wiki.laptop.org/go/8.2.0#Put_Your_Name_Here_to_Confirm_You_Will_Try_the_Release_Candidate Thanks! I think once OLPC has a candidate build that people can install using olpc-update and has been smoke-tested, then it can publicize it on planet.laptop.org, olpcnews.com, forum.laptop.org, etc. Another mailing list won't help as much to get the word out. Okay. I'm not so sure. If you want more testing, just publicize as above. I didn't hear about candidate builds until I started following devel and figured out the wiki's green Latest Releases box. Should we make the Latest Releases box more prominent or readable? Me too, especially if there's clarity about olpc-update vs. the fabled developer key. You should probably request a developer key: http://wiki.laptop.org/go/Developer_key It will make your life as a tester much, much easier. Besides - Forth is fun! Michael ___ Devel mailing list Devel@lists.laptop.org http://lists.laptop.org/listinfo/devel
Re: specifying what services Activities may use
On Wed, Jul 30, 2008 at 11:03 AM, Greg Smith [EMAIL PROTECTED]wrote: Hi Daniel, What I think we need is a list of all APIs relevant to activity developers (maybe libraries too?). You can parse it however you want. The two resources we do have, that I know of, are: 1. http://wiki.laptop.org/go/Sugar_Almanac 2. http://wiki.laptop.org/go/API_reference Neither, it seems, is complete, but I think they are being actively worked on. I think our ability to adequately predict and/or prevent breakage will improve quite a bit over the next few releases, when a) APIs are better documented in the first place (which also gives us obvious places to indicate future changes, additions, and deprecations) and b) fewer pieces of the system need to change at once, lowering the number of variables involved. - Eben We need a list of anything that might break an activity. Give us whatever you have, even if its not the full story. Hopefully we can put together the full puzzle one piece at a time. Thanks, Greg S Daniel Drake wrote: On Wed, 2008-07-30 at 07:02 -0400, Greg Smith wrote: Michael and team, Can we get documentation of all API changes (since 708 and 656) that affect activities ASAP? Are you talking about sugar APIs, or APIs for other library components present on the system which some activities may use? BTW where is the definitive documentation of all APIs available to activities and is it up to date? When can we freeze API changes for 8.2.0? Again, same question for both. Sorry to answer a question with a question :) Daniel ___ 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
Re: specifying what services Activities may use
Greg, On Wed, Jul 30, 2008 at 11:03:41AM -0400, Greg Smith wrote: Hi Daniel, What I think we need is a list of all APIs relevant to activity developers (maybe libraries too?). You can parse it however you want. The potential size of that list is in the order of all software libraries useful to software developers. We need to have the developers tell us what they need. We need a list of anything that might break an activity. Give us whatever you have, even if its not the full story. Hopefully we can put together the full puzzle one piece at a time. Ideally we would have a list of dependencies for each activity. See: http://wiki.laptop.org/go/Development_issues * Choice of libraries and required applications: you may not have the dependencies you might need, or those dependencies might come at too high a memory cost. We will inventory what you can count on in the basic system as it becomes clear. In the meantime, make sure you know your application's dependencies. For compiled code, run it with ldd to get a list of all the libraries being loaded. For Python code, run it with python -v to get a list of all modules imported. As a first pass at this problem we can encourage activity authors to publicize dependencies for their application. We can help them do so by providing a set of steps (such as the one quoted above) which they can follow to build a dependency list and provide easy access to a repository of such dependency data. (Are we doing so already? My impression is that we are not.) This list will at least help us understand what dependencies are common among many activities and pick libraries to pull into our builds. Such dependency lists are a good prerequisite for any package management scheme for the XO, automated or not. Erik ___ Devel mailing list Devel@lists.laptop.org http://lists.laptop.org/listinfo/devel
Activity versions in Activities/G1G1
Hi Scott, You edited the [[Activities/G1G1]] page to change Chat from 35 to 42 (http://wiki.laptop.org/index.php?title=Activities/G1G1diff=0oldid=147844). However the version of Chat in the G1G1 Activity Pack linked from that page is 35. There is unclarity on the talk page too: http://wiki.laptop.org/go/Talk:Activities/G1G1 Chat-42 probably works on 703/708 but I have been testing that lately. In particular, I introduced PS API improvements in the 8.2 development cycle which, if I had been using in Chat, would have rendered it inoperable on 708. (The old API still works fine, but using the new API would simplify the activity code.) Can we agree on the appropriate use of this page? Thanks Morgan ___ Devel mailing list Devel@lists.laptop.org http://lists.laptop.org/listinfo/devel
Re: specifying what services Activities may use
On Wed, Jul 30, 2008 at 11:03:41AM -0400, Greg Smith wrote: Hi Daniel, We need a list of anything that might break an activity. The list of things that have to work in order for an activity (particularly a networked one) to work is larger than the memory and comprehension of any individual working on this project. It includes nasty things like * syscall semantics * file-system layouts * authorization data like file-system permissions * statistical biases in the outcomes of non-deterministic computations * availability of language interpreters * library APIs * computational complexity of default algorithms Fortunately, most of the things in the list change slowly. Unfortunately, as John has pointed out, we change them far faster and with far less warning and support than most other people in this business. Michael ___ Devel mailing list Devel@lists.laptop.org http://lists.laptop.org/listinfo/devel
Re: specifying what services Activities may use
On Wed, Jul 30, 2008 at 12:03:52PM -0400, Michael Stone wrote: On Wed, Jul 30, 2008 at 11:03:41AM -0400, Greg Smith wrote: Hi Daniel, We need a list of anything that might break an activity. The list of things that have to work in order for an activity (particularly a networked one) to work is larger than the memory and comprehension of any individual working on this project. It includes nasty things like Is this a reasonable categorization?: kernel version dependent: * syscall semantics system library dependent: * availability of language interpreters * library APIs nasty things we tend to change: * file-system layouts * authorization data like file-system permissions ouch!: * statistical biases in the outcomes of non-deterministic computations * computational complexity of default algorithms ___ Devel mailing list Devel@lists.laptop.org http://lists.laptop.org/listinfo/devel
Re: [sugar] specifying what services Activities may use
On Tue, 2008-07-29 at 17:09 -0400, Mikus Grinbergs wrote: Please ensure that you have filed tickets for each and every one of them What good will that do? We track issues through trac. Doing it through email is harder when you have a lot of email and a lot of issues. Filing a ticket keyworded 8.2.0:? will put it on our radar. While it can be useful to raise issues through email first, it easy to forget about emails. Trac is our designated issue-tracking system. Thanks, Daniel ___ Devel mailing list Devel@lists.laptop.org http://lists.laptop.org/listinfo/devel
Re: Feedback from deployment lead
Hi Greg, thanks for sending this one. Would be a good step forward if we found the way to connect field feedback to the testing team, so they can enter proper tickets that can track real improvements. I really hope that 9.1.0 will bring serious improvements regarding robustness of the datastore. Thanks again, Tomeu On Thu, Jul 24, 2008 at 3:59 PM, Greg Smith [EMAIL PROTECTED] wrote: Hi All, I got some good feedback this week on priorities from Carla who has led several of our early installations. Its posted at: http://wiki.laptop.org/go/9.1.0#Unadorned_and_unedited_user_feedback I probed for more detail on: Guarantee that everything they work on is saved –and/or backed up– and never lost. I think we will ensure no data is lost on shutdown (see recent autosave in 8.2.0 thread). However, their experience was a little different. See the details below. We have lost touch with them so this is all the info we are likely to get. Does this look familiar to anyone and if so do we know if its fixed in 8.2.0 (e.g. bug ID)? Please don't e-mail Carla directly on this. Give me a chance to gather the consensus of the list and get back to her. That way we won't bury her inbox and discourage further input. Thanks, Greg S Running 703 w/ Q2D14 they saw this: Write: In one group, many teachers lost all their work in Write. It didn't save automatically, and even if they saved manually, they suddenly lost all their data. It doesn't even appear on the Journal. It happened in at least 7 machines out of a group of 23 teachers and we couldn't find any pattern. I couldn't replicate the problem on mine. Also, instead of re-saving within the same file, it saves many new files every time it auto-saves, however sometimes it doesn't auto-save. This is for the 7 teachers that lost their work: They were using lots of tables, images, lots of formatting to the text (color, size,...) and the files were long... Since the journal didn't show it. They couldn't back it up to USB key One teacher was saving his work, then copied to a USB and tried looking at it on a PC (he tried all the 4 formats) and he always got a blank file with 0 Kb. (no significance to the caps - GS) RIGHT NOW TEACHERS ARE ALSO TELLING ME THAT IMAGES SAVED IN A FILE ARE NOT ALWAYS KEPT IN THE FILE , SPECIALLY IF SAVING UNDER HTML.. OR THEY SAVE IN ONE MACHINE SHARE IT WITH OTHERS AND OTHERS DON'T SEE THE IMAGES. THEY ARE SAVING 'WRITE' IN USB KEYS AND TRY TO SHARE IT AND THEN IT DISPLAYS NO-CONTENT IN OTHER XOs ...AND IN MY IBM LAPTOP I CAN'T SEE THE FILE. IT HAD HAPPENED TWICE. ___ 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
Re: [Testing] Random observations with joyride-2225 and latest activities
Sound like quite good points to me, can you make sure we have proper tickets for those? Thanks a lot, Tomeu On Tue, Jul 29, 2008 at 2:26 AM, Christoph Derndorfer [EMAIL PROTECTED] wrote: Hi all, I've been running joyride-2225 with what I believe to be the latest versions (as per the update software functionality of the sugar-control-panel) of some core activities. In the past half hour I have stumbled across some issues that I haven't seen mentioned anywhere else so I thought I'd share them: a) Record: using v56 the activity starts up fine, the display shows whatever the camera is capturing, I can go into fullscreen-mode, switch to different tabs, etc. However once I press the capture-button the whole thing basically freezes, sometimes I was still able to move the mouse but clicking wouldn't have any impact, at other times Sugar completely froze and I had to do a hard reset of the XO. b) TurtleArt: v7 is missing an l in the activity title so we're looking at TurteArt c) Read: This activity is only useful if started by clicking on a file with a mime-type that's associated to read. However it still shows up in the list view of the home-view even though you actually can't do anything with it once you start it. The activity.info file has the show_launcher property to define that behavior, not sure whether in this case it's simply set wrongly in the read .info or whether the list-view presently ignores this attribute. Another odd issue is that when you open read from the list / favorites view and you then want to close it you're presented with a keep error message which seems quite useless considering the fact that no activity / file was actually resumed. Again, not sure whether that's an issue with read or the underlying Journal structure. d) Brightness adjustment: up to 708 and most earlier joyrides that I have used in the past weeks allowed you to immediatly turn of the backlight by pressing ctrl + reduce brightness button. With joyride-2225 this doesn't work anymore. Let me know what you think. Cheers, Christoph -- Christoph Derndorfer Co-Editor OLPCnews, http://www.olpcnews.com ___ Testing mailing list [EMAIL PROTECTED] http://lists.laptop.org/listinfo/testing ___ Devel mailing list Devel@lists.laptop.org http://lists.laptop.org/listinfo/devel
Re: [sugar] Programming environments on the XO
On Tue, Jul 29, 2008 at 12:44 PM, Martin Sevior [EMAIL PROTECTED] wrote: On Fri, 2008-07-18 at 14:50 +1000, Martin Sevior wrote: On Thu, 2008-07-17 at 23:32 -0400, Brian Jordan wrote: The open source project Gobby also uses this sort of who-wrote-what text highlighting, SJ and I have recently (right before he left for Wikimania) been looking into getting similar functionality on the XO. Having this highlighting integrated with Write would be fantastic. OK Guys, I get the message :-) I'll look to see how this can be enabled by default in the most UI-easy way possible. OK Guys, Your wish is my command. See: http://msevior.livejournal.com/2008/07/29/ Awesome, anybody would like to expose this functionality in Write? Should be quite easy, but may involve adding API to abiwidget. Thanks a lot, Tomeu ___ Devel mailing list Devel@lists.laptop.org http://lists.laptop.org/listinfo/devel
Re: [sugar] Programming environments on the XO
On Wed, Jul 30, 2008 at 12:24 PM, Tomeu Vizoso [EMAIL PROTECTED]wrote: On Tue, Jul 29, 2008 at 12:44 PM, Martin Sevior [EMAIL PROTECTED] wrote: On Fri, 2008-07-18 at 14:50 +1000, Martin Sevior wrote: On Thu, 2008-07-17 at 23:32 -0400, Brian Jordan wrote: The open source project Gobby also uses this sort of who-wrote-what text highlighting, SJ and I have recently (right before he left for Wikimania) been looking into getting similar functionality on the XO. Having this highlighting integrated with Write would be fantastic. OK Guys, I get the message :-) I'll look to see how this can be enabled by default in the most UI-easy way possible. OK Guys, Your wish is my command. See: http://msevior.livejournal.com/2008/07/29/ Awesome, anybody would like to expose this functionality in Write? Should be quite easy, but may involve adding API to abiwidget. The original mockups for Write have been waiting for this moment to arrive. For the reference of any who dare to take on the task (The button being clicked is a Highlight text by author button): http://wiki.laptop.org/go/Image:Activity_write_view.jpg - Eben Thanks a lot, Tomeu ___ Sugar mailing list [EMAIL PROTECTED] http://lists.laptop.org/listinfo/sugar ___ Devel mailing list Devel@lists.laptop.org http://lists.laptop.org/listinfo/devel
suspend oddities
since i'm not sure which of these are known/expected/ alreadyfixed/beingignored, here are a few things i've noticed with suspend. i'll trac any that people think should, or comment existing trac if appropriate. disclaimer: some of this testing has been on my g1g1 machine, running 2159, XFCE (not sugar), with a USB keyboard. - gamepad keypresses aren't ignored during suspend. whether or not the gamepad is selected as a candidate wakeup event (via /sys/power/wakeup_events/gamekey), those keys will be queued for tty input while we're suspended. test by starting hexdump (or other key capture program), suspending, pushing any of the 8 keys on the bezel, and then resuming. note that the keys have registered. (this is/was true in 708 as well.) - the camera LED flashes while suspended. suspend the laptop, use the touchpad or a keyboard key. observe camera indicator blinking. also true on 708. - this got me thinking about wakeups and keypresses in general. if we're configured to wake up on keypresses or gamepad presses (something i've not seen work yet, btw), then the keypress causing the wake should be suppressed. don't know whether that's the case or not. paul =- paul fox, [EMAIL PROTECTED] ___ Devel mailing list Devel@lists.laptop.org http://lists.laptop.org/listinfo/devel
Re: suspend oddities
On Jul 30 2008, at 14:17, [EMAIL PROTECTED] was caught saying: since i'm not sure which of these are known/expected/ alreadyfixed/beingignored, here are a few things i've noticed with suspend. i'll trac any that people think should, or comment existing trac if appropriate. disclaimer: some of this testing has been on my g1g1 machine, running 2159, XFCE (not sugar), with a USB keyboard. - gamepad keypresses aren't ignored during suspend. whether or not the gamepad is selected as a candidate wakeup event (via /sys/power/wakeup_events/gamekey), those keys will be queued for tty input while we're suspended. test by starting hexdump (or other key capture program), suspending, pushing any of the 8 keys on the bezel, and then resuming. note that the keys have registered. (this is/was true in 708 as well.) The gamekeys go through PS2 so I'm guessing the EC is queeing that event for us. I can reproduce the same sort of behaviour with by switching to console on the XO, sleeping via /sys/power/state on serial console, and then hitting a keyboard key to wake up. On wakeup, the character appears on the shell. However, I just did the following here: echo 0 /sys/power/wakeup_events/ps2event echo mem /sys/power/state hit a key hit power button And I don't see the character on console, which means it did not get queued during suspend when wakeup on keypress is disabled. How are you trigerring resume? (FYI, gamekey has been renamed ps2event in latest kernels) - the camera LED flashes while suspended. suspend the laptop, use the touchpad or a keyboard key. observe camera indicator blinking. also true on 708. The way suspend currently works is that we actually go all the way back to userland and OHM makes a decision on whether we actually want to wake up or not based on our current state and what triggered the wakeup. I'm guessing the flashing is the camera driver resuming the device. If you're running XFCE on top of our OHM, you should see the same behaviour. The wakeup_event interface was put in place to stop this by allowing OHM to specify when we want to actually be woken up. - this got me thinking about wakeups and keypresses in general. if we're configured to wake up on keypresses or gamepad presses (something i've not seen work yet, btw), then the keypress causing the wake should be suppressed. don't know whether that's the case or not. From both our tests, it does not appear to be the case ATM. Whether this is intended or not, someone who's been around longer needs to answer. ~Deepak -- Deepak Saxena - Kernel Developer - [EMAIL PROTECTED] ___ Devel mailing list Devel@lists.laptop.org http://lists.laptop.org/listinfo/devel
Re: suspend oddities
On Wed, Jul 30, 2008 at 10:56:01AM -0700, Deepak Saxena wrote: On Jul 30 2008, at 14:17, [EMAIL PROTECTED] was caught saying: - gamepad keypresses aren't ignored during suspend. [...] However, I just did the following here: [...] And I don't see the character on console, which means it did not get queued during suspend when wakeup on keypress is disabled. This may relate to #6950 or #5703, as it seems a similar symptom to #6590. http://dev.laptop.org/ticket/6590 http://dev.laptop.org/ticket/5703 ~Deepak Martin pgp0J5ambAMgm.pgp Description: PGP signature ___ Devel mailing list Devel@lists.laptop.org http://lists.laptop.org/listinfo/devel
Re: suspend oddities
deepak wrote: On Jul 30 2008, at 14:17, [EMAIL PROTECTED] was caught saying: since i'm not sure which of these are known/expected/ alreadyfixed/beingignored, here are a few things i've noticed with suspend. i'll trac any that people think should, or comment existing trac if appropriate. disclaimer: some of this testing has been on my g1g1 machine, running 2159, XFCE (not sugar), with a USB keyboard. - gamepad keypresses aren't ignored during suspend. whether or not the gamepad is selected as a candidate wakeup event (via /sys/power/wakeup_events/gamekey), those keys will be queued for tty input while we're suspended. test by starting hexdump (or other key capture program), suspending, pushing any of the 8 keys on the bezel, and then resuming. note that the keys have registered. (this is/was true in 708 as well.) The gamekeys go through PS2 so I'm guessing the EC is queeing that event for us. I can reproduce the same sort of behaviour with by switching to console on the XO, sleeping via /sys/power/state on serial console, and then hitting a keyboard key to wake up. On wakeup, the character appears on the shell. However, I just did the following here: echo 0 /sys/power/wakeup_events/ps2event echo mem /sys/power/state hit a key hit power button And I don't see the character on console, which means it did not get queued during suspend when wakeup on keypress is disabled. How are you trigerring resume? via the power button. no console switching. whoa. when i try your test, on wakeup i get at least a screenful of newlines, complete with a screenful of bash prompts right after. ??? paul (FYI, gamekey has been renamed ps2event in latest kernels) - the camera LED flashes while suspended. suspend the laptop, use the touchpad or a keyboard key. observe camera indicator blinking. also true on 708. The way suspend currently works is that we actually go all the way back to userland and OHM makes a decision on whether we actually want to wake up or not based on our current state and what triggered the wakeup. I'm guessing the flashing is the camera driver resuming the device. If you're running XFCE on top of our OHM, you should see the same behaviour. The wakeup_event interface was put in place to stop this by allowing OHM to specify when we want to actually be woken up. - this got me thinking about wakeups and keypresses in general. if we're configured to wake up on keypresses or gamepad presses (something i've not seen work yet, btw), then the keypress causing the wake should be suppressed. don't know whether that's the case or not. From both our tests, it does not appear to be the case ATM. Whether this is intended or not, someone who's been around longer needs to answer. ~Deepak -- Deepak Saxena - Kernel Developer - [EMAIL PROTECTED] =- paul fox, [EMAIL PROTECTED] ___ Devel mailing list Devel@lists.laptop.org http://lists.laptop.org/listinfo/devel
Re: suspend oddities
Deepak Saxena wrote: The gamekeys go through PS2 so I'm guessing the EC is queeing that event for us. I can reproduce the same sort of behaviour with by switching to console on the XO, sleeping via /sys/power/state on serial console, and then hitting a keyboard key to wake up. On wakeup, the character appears on the shell. Gamekeys show up as virtual keys. They should behave identical to the keyboard. The EC reads them and injects them into the keyboard stream. However, I just did the following here: echo 0 /sys/power/wakeup_events/ps2event echo mem /sys/power/state hit a key hit power button Why did you need to hit the power button? And I don't see the character on console, which means it did not get queued during suspend when wakeup on keypress is disabled. The process is the same. If you get a wakeup from gamekey then the keypress should follow. Turn on your ps2 debugging and verify that indeed you do not get key events. -- Richard Smith [EMAIL PROTECTED] One Laptop Per Child ___ Devel mailing list Devel@lists.laptop.org http://lists.laptop.org/listinfo/devel
Re: suspend oddities
smith wrote: Deepak Saxena wrote: The gamekeys go through PS2 so I'm guessing the EC is queeing that event for us. I can reproduce the same sort of behaviour with by switching to console on the XO, sleeping via /sys/power/state on serial console, and then hitting a keyboard key to wake up. On wakeup, the character appears on the shell. Gamekeys show up as virtual keys. They should behave identical to the keyboard. The EC reads them and injects them into the keyboard stream. However, I just did the following here: echo 0 /sys/power/wakeup_events/ps2event echo mem /sys/power/state hit a key hit power button Why did you need to hit the power button? i assume because he'd just disabled ps2event wakeups. And I don't see the character on console, which means it did not get queued during suspend when wakeup on keypress is disabled. The process is the same. If you get a wakeup from gamekey then the keypress should follow. Turn on your ps2 debugging and verify that indeed you do not get key events. when you say should follow, you mean as implemented, i assume? i'd argue that the keypress should definitely _not_ follow. paul =- paul fox, [EMAIL PROTECTED] ___ Devel mailing list Devel@lists.laptop.org http://lists.laptop.org/listinfo/devel
Re: suspend oddities
On Jul 30 2008, at 15:45, Richard A. Smith was caught saying: Deepak Saxena wrote: The gamekeys go through PS2 so I'm guessing the EC is queeing that event for us. I can reproduce the same sort of behaviour with by switching to console on the XO, sleeping via /sys/power/state on serial console, and then hitting a keyboard key to wake up. On wakeup, the character appears on the shell. Gamekeys show up as virtual keys. They should behave identical to the keyboard. The EC reads them and injects them into the keyboard stream. However, I just did the following here: echo 0 /sys/power/wakeup_events/ps2event echo mem /sys/power/state hit a key hit power button Why did you need to hit the power button? B/c I disabled wakeup on ps2event. And I don't see the character on console, which means it did not get queued during suspend when wakeup on keypress is disabled. The process is the same. If you get a wakeup from gamekey then the keypress should follow. Turn on your ps2 debugging and verify that indeed you do not get key events. Right, but in this case I had disabled the wakeup on gamekey. From what I can tell, everything is working as expected. ~Deepak -- Deepak Saxena - Kernel Developer - [EMAIL PROTECTED] ___ Devel mailing list Devel@lists.laptop.org http://lists.laptop.org/listinfo/devel
New update.1 build 709
http://pilgrim.laptop.org/~pilgrim/olpc/streams/update.1/build709 Changes in build 709 from build: 708 Size delta: 0.00M -bootfw q2d16-1.olpc2.unsigned +bootfw q2e12-1.olpc2.unsigned -olpc-utils 0.74-1.olpc2 +olpc-utils 0.74-2.olpc2 --- Changes for bootfw q2e12-1.olpc2.unsigned from q2d16-1.olpc2.unsigned --- + q2e12 this is an unsigned image + trac #7607 - minimal fix for JFFS2 hang problem + q2e11 this is an unsigned image + Add new board ID with future placeholders + Allow ofw to disable battery charging system + Incorporate OFW2 modifications + trac #7399 - fixed test /nandflash::fixbbt command. + trac #7180 - new boot animation frames (background is white not gray) to match the new UI design. + trac #7141 - improved error messages for secure FS update. + SD driver - Increased data timeout to the max value, since some cards timeout with lesser values. + camera selftest - display the camera image expanded to fill the screen. In the movie mode, mirror image the display and automatically adjust the brighness according to the ambient conditions. + Latest OFW firmware: q2e10 -- This mail was automatically generated See http://dev.laptop.org/~rwh/announcer/update.1-pkgs.html for aggregate logs See http://dev.laptop.org/~rwh/announcer/joyride_vs_update1.html for a comparison ___ Devel mailing list Devel@lists.laptop.org http://lists.laptop.org/listinfo/devel
Re: CIS solar charging-correct list?
Scott: Thanks for this solar net one info, which (as an electronic guru) impresses me. Are those PV arrays 600 Watts?? Yikes- allow ~US$3k for these alone (about the annual salary for a teacher in many downtrodden areas). Double this for the battery bank! Maintenance? IMHO such a solar scheme is pipe dream stuff for subsistence lifestyle regions that can hardly stretch to a litre of kerosine for lights, even just a single one may be orders of magnitude more costly than schools villages in the PNG/Solomon Islands region can justify... Stan in NZ ___ Devel mailing list Devel@lists.laptop.org http://lists.laptop.org/listinfo/devel
Re: [sugar] Notes from today's Release Meeting(s)
On 30 Jul 2008, at 15:59, Michael Stone wrote: On Tue, Jul 29, 2008 at 09:49:23PM -0700, S Page wrote: I'm not so sure. If you want more testing, just publicize as above. I didn't hear about candidate builds until I started following devel and figured out the wiki's green Latest Releases box. Should we make the Latest Releases box more prominent or readable? Right now it's very – hmmm, safe – and so it should be. How about once your confident of a release candidate and a singed image is available, it gets an addition block (in warning red tint perhaps) noting an RC for those willing to live on the bleeding edge is available for testing? I guess this will only have much impact if the RC is about for at least few weeks. --Gary ___ Devel mailing list Devel@lists.laptop.org http://lists.laptop.org/listinfo/devel
Collaboration Requirements
Hi All, I wrote up some collaboration requirements to help get us to a definition of collaboration support that teachers can use in schools. This is my first somewhat rigorous requirements definition for OLPC so comments on style as well as substance are welcome. I will take one round of comments then I'll find a place for it in the wiki (more comments always welcome after that). Collaboration requirements for OLPC XOs and XS Greg Smith July 30, 2008 Background: The concept of Collaboration has been around for a long time. I have used cuseeme, MeetingPlace, NetMeeting, WebEx, IRC, AIM, Gobbby, Sametime, PC Anywhere, Cisco HD Video conferencing and others. Our challenge is different in three respects. - wireless - educational use - greater scale Motivation: The goal of this requirement definition is to provide all the information necessary to define tests and fix critical collaboration bugs in 8.2.0 and to set a goal for 9.1.0. The best case is that this write up motivates test cases which results in a list of detailed examples of collaboration that will be supported in 8.2.0. These examples should be deployable and usable by teachers in class. Examples of use cases generated by teachers are at: http://wiki.laptop.org/go/Use_Cases#Collaboration_Examples Collaboration is an area where we are on the cutting edge of available technology. It was well promoted and teachers on the sur list have repeatedly asked for a definition of how to use it successfully. A list of activities supposedly enabled for collaboration is at: http://wiki.laptop.org/go/Collaboration_Central Documentation on previous wireless tests is at: http://wiki.laptop.org/go/Test_Config_Notes#Wireless_.26_Network Requirements Definition: I set a high bar but I try to balance between available technology and the desires of the teachers. I hope can at least test to this standard soon, even if we don't close all bugs found by that testing until later. Requirements beginning with must are critical to success, should are very important but can be deferred and nice to have are very useful but likely to be deferred. If a must requirement cannot be met, we should still attempt to support as much of it as possible (e.g. if we can't do 50 XOs in N9, 40 or 30 should be tested and supported). I - Network Requirements i - Supported Architectures N1 - Must support one of the four network scenarios defined at: http://wiki.laptop.org/go/Networking_scenarios The scenarios in priority order are named as follows. S1 - Simple Wifi S2 - School Wifi S3 - Simple Mesh S4 - School mesh (no need to test, just recorded here for completeness) ii - RF Environments N2 - Must support environments where there are no other RF signals beyond the APs as needed by the network scenario. N3 - Must support RF environments where up to 2 other APs are visible in the XO neighborhood. N4 - Should support environments where there are up to 4 other APs visible in the XO neighborhood. II - Scale i - Scale of XOs collaborating N5 - Must support up to 10 XOs collaborating together. See activity examples for exact steps. N6 - Should support up to 20 XOs collaborating together. N7 - Nice to support up to 30 XOs collaborating together. ii - Scale of XOs visible within range of each other N8 - In N5 above must allow up to 1500 XOs within range in the school. Can require that all other XOs aside from those collaborating have their antennas turned off. N9 - Must allow 50 (should allow 100, nice to have 300) other XOs within range in the school where all XOs have their radios turned on. Can require that only those collaborating are using the network (AKA everyone else is verbally asked to stop using the Internet and stop collaborating) but they can leave their XO radios on in scenario S1 N10 - Must allow 50 (should allow 100, nice to have 300) XOs within range in the school where all XOs have their radios turned on. Can require that only those collaborating are using the network (AKA no collaboration and no Internet access) in scenario S2. N11 - Must allow 50 (should allow 100, nice to have 300) XOs within range in the school where all XOs have their radios turned on. Can require that only those collaborating are on a given Mesh channel (1,6 or 11) while all the other XOs are on different Mesh channels in scenario S3 III Types of collaboration In all cases, a single XO starts activity, then shares it, then other XOs join the shared activity. N12 - Must support up to 3 XOs using an activity and all others XOs (as allowed by the scale) watching what happens on that screen. N14 - Should support 10 XOs (as allowed by scale) using an activity simultaneously. N15 - Nice to have all XOs as allowed by scale using an activity simultaneously. N16 - Must support pairs of two XOs collaborating with each other up to the number of XOs supported by scale. N17 - Should support all the partitions of XOs collaborating with each other (e.g. with 6 XOs, allow 2,2,2 and 3,3 and
Re: Evince (was Re: New joyride build 2222)
S Page wrote: Mikus Grinbergs wrote: Noticed that sugar-evince 2.20.1.1-3.olpc3 brought in poppler 0.6.2-5.olpc3, which is 3 MB. I think 8.1.0 and 8.1.1 have the same dependency (on poppler-0.6.2.4-olpc2). Evince needs Poppler to render PDFs. http://live.gnome.org/Evince/SupportedDocumentFormats Speaking of Evince, does Read support DjVu in 8.2.0? http://djvu.org/docs/ has some test files. http://dev.laptop.org/ticket/2448 says yes, but http://dev.laptop.org/ticket/6223 and http://dev.laptop.org/ticket/6426 suggest no. I don't care, except that http://wiki.laptop.org/go/Image_file_formats presents DjVu as OLPC's preferred e-book file format. I have to vote that I do care. DjVu is much more efficiently rendered at high resolution being designed for that purpose. In fact, DjVu format is efficient enough that often a direct scan of a document at 300dpi compressed to DjVu format is smaller and faster displayed than a PDF file of the same document. I believe some timings were reported in a previous thread around the bug ticket: #6223. A look at the ticket indicates it has been pushed back to 9.1.0. --Chris ___ Devel mailing list Devel@lists.laptop.org http://lists.laptop.org/listinfo/devel
Re: suspend oddities
talking with richard just now i realized that there's been a bit of disconnect, at least on my part, in understanding our current suspend design. i was complaining that keypresses were arriving while my machine was suspended. richard pointed out that it's meant to work that way. my use-case was i've suspended my laptop because i want to toss it in my backpack, and no button presses should register. richard's use-case is my laptop is suspended because i'm in ebook mode, and i want the game-pad keys to wake me up just enough to flip pages on my document. turns out the EC goes out of its way to make sure this happens. so, while i still think there may be bugs (in that i think i get keypresses even when i've told the system that keypresses shouldn't wake me up -- but i'll doublecheck that), there's clearly a terminology problem: suspend and sleep have too many meanings, and none of the traditional meanings include the XO's ebook behavior. any thoughts on this? i'm not sure drowsy mode or zombie mode have quite the right connotation. maybe catnap mode. i think we also realized that we may need some more logic (somewhere) to control wakeup events, since both the ebook and toss-in-backpack modes are valid use cases. paul deepak wrote: On Jul 30 2008, at 14:17, [EMAIL PROTECTED] was caught saying: since i'm not sure which of these are known/expected/ alreadyfixed/beingignored, here are a few things i've noticed with suspend. i'll trac any that people think should, or comment existing trac if appropriate. disclaimer: some of this testing has been on my g1g1 machine, running 2159, XFCE (not sugar), with a USB keyboard. - gamepad keypresses aren't ignored during suspend. whether or not the gamepad is selected as a candidate wakeup event (via /sys/power/wakeup_events/gamekey), those keys will be queued for tty input while we're suspended. test by starting hexdump (or other key capture program), suspending, pushing any of the 8 keys on the bezel, and then resuming. note that the keys have registered. (this is/was true in 708 as well.) The gamekeys go through PS2 so I'm guessing the EC is queeing that event for us. I can reproduce the same sort of behaviour with by switching to console on the XO, sleeping via /sys/power/state on serial console, and then hitting a keyboard key to wake up. On wakeup, the character appears on the shell. However, I just did the following here: echo 0 /sys/power/wakeup_events/ps2event echo mem /sys/power/state hit a key hit power button And I don't see the character on console, which means it did not get queued during suspend when wakeup on keypress is disabled. How are you trigerring resume? (FYI, gamekey has been renamed ps2event in latest kernels) - the camera LED flashes while suspended. suspend the laptop, use the touchpad or a keyboard key. observe camera indicator blinking. also true on 708. The way suspend currently works is that we actually go all the way back to userland and OHM makes a decision on whether we actually want to wake up or not based on our current state and what triggered the wakeup. I'm guessing the flashing is the camera driver resuming the device. If you're running XFCE on top of our OHM, you should see the same behaviour. The wakeup_event interface was put in place to stop this by allowing OHM to specify when we want to actually be woken up. - this got me thinking about wakeups and keypresses in general. if we're configured to wake up on keypresses or gamepad presses (something i've not seen work yet, btw), then the keypress causing the wake should be suppressed. don't know whether that's the case or not. From both our tests, it does not appear to be the case ATM. Whether this is intended or not, someone who's been around longer needs to answer. ~Deepak -- Deepak Saxena - Kernel Developer - [EMAIL PROTECTED] =- paul fox, [EMAIL PROTECTED] ___ Devel mailing list Devel@lists.laptop.org http://lists.laptop.org/listinfo/devel
Re: [sugar] Random observations with joyride-2225 and latest activities
On Wed, Jul 30, 2008 at 03:05:18PM -0400, Daniel Drake wrote: On Tue, 2008-07-29 at 09:32 +0200, Christoph Derndorfer wrote: a) Record: using v56 the activity starts up fine, the display shows whatever the camera is capturing, I can go into fullscreen-mode, switch to different tabs, etc. However once I press the capture-button the whole thing basically freezes, sometimes I was still able to move the mouse but clicking wouldn't have any impact, at other times Sugar completely froze and I had to do a hard reset of the XO. Your save-nand image loaded onto my XO just fine, but Record worked fine. Must be something hardware related. very odd. It could also be hardware independent but non-deterministic. Or deterministic but triggered under input that you didn't give. Michael ___ Devel mailing list Devel@lists.laptop.org http://lists.laptop.org/listinfo/devel
Re: CIS solar charging-correct list?
Hi Stan, On Thu, 31 Jul 2008, Stan. SWAN wrote: Scott: Thanks for this solar net one info, which (as an electronic guru) impresses me. Thanks. We have been refining it a bit also. Are those PV arrays 600 Watts?? Yikes- allow ~US$3k for these alone (about the annual salary for a teacher in many downtrodden areas). Double this for the battery bank! Its a little less than that. The array and battery bank are enough for 6-7 user seats and a VSAT terminal 24/7, plus the long range wifi, which will be central to building any ISP type services out. To date, most of the systems have been subsidized by non-profits for placement in developing nations. You are still looking at a higher cost with multiple power sources, and a way higher cost with building a standard power grid. The first hurdle to be overcome is power supply. This is impossible with PC's, as you are probably aware, due to the cost of the power system. OLPC is a good solution for this. We use geodes in the SolarNet thin clients... very efficient. The second challenge is connectivity. The mesh is pretty good for this too, once there is an upstream circuit somewhere within range of the mesh. In many places, this will be VSAT or long range wifi hops. The backbone has to start somewhere... Maintenance? Distilled water in the batteries, with an option for maintenence free batteries. The latter just cost more per wH of storage. Notwithstanding, much better than the maintenence on a standard diesel generator, which is the power source of choice in western Africa. IMHO such a solar scheme is pipe dream stuff for subsistence lifestyle regions that can hardly stretch to a litre of kerosine for lights, Solomans? http://self.org/solomonislands.shtml These things are possible, just not as a simple capital exchange. even just a single one may be orders of magnitude more costly than schools villages in the PNG/Solomon Islands region can justify... I know it seems pricy... its new. Component cost will go down over time, but one has to remember that when buying solar panels, one is buying 20 years worth of electricity up front. The point was that I have put quite a bit of effort into RD on rural power systems for networks, and if any of that knowledge would be helpful, I am happy to provide it. I think you will likely be better off with a single large central charging station in the school than individual panels for each OLPC. Cheers, Scott Stan in NZ ___ Devel mailing list Devel@lists.laptop.org http://lists.laptop.org/listinfo/devel
Re: suspend oddities
[EMAIL PROTECTED] wrote: so, while i still think there may be bugs (in that i think i get keypresses even when i've told the system that keypresses shouldn't wake me up -- but i'll doublecheck that), there's clearly a terminology problem: suspend and sleep have too many meanings, and none of the traditional meanings include the XO's ebook behavior. You need to test with my latest firmware. I fixed some spurious SCI that were causing bogus wakeups. -- Richard Smith [EMAIL PROTECTED] One Laptop Per Child ___ Devel mailing list Devel@lists.laptop.org http://lists.laptop.org/listinfo/devel
Re: Newer ds-backup-client RPMs for joyride...
Martin, When releasing ds-backup revisions, please update documentation like http://wiki.laptop.org/go/Ds-backup Sorry that I forgot as well! Michael ___ Devel mailing list Devel@lists.laptop.org http://lists.laptop.org/listinfo/devel
Re: Collaboration Requirements
On Wed, Jul 30, 2008 at 05:21:34PM -0400, Greg Smith wrote: This is my first somewhat rigorous requirements definition for OLPC so comments on style as well as substance are welcome. This feels very similar to an RFC. Take a look at RFC 2223 Instructions to RFC Authors and think about whether you could happily follow its guidance. The concept of Collaboration has been around for a long time. I have used cuseeme, MeetingPlace, NetMeeting, WebEx, IRC, AIM, Gobbby, Sametime, PC Anywhere, Cisco HD Video conferencing and others. You cite a number of collaborative systems with which you have personal experience. I think we should really be citing collaborative systems (both digital and otherwise) from which we take our inspiration and our warnings. (I have some favorites, but I'll let you think about the issue first before sharing.) Our challenge is different in three respects. - wireless - educational use - greater scale I agree that it's different but I think you left some important things out like the existence of side-channels provided by physical proximity of the participants. Motivation: The goal of this requirement definition is to provide all the information necessary to define tests and fix critical collaboration bugs in 8.2.0 At this date, unless we decided to slip the release by several weeks, there will be essentially no opportunity to fix critical collaboration bugs in 8.2.0 proper. However, these bugs are certainly of great interest for follow-on bugfix releases made prior to 9.1.0. The best case is that this write up motivates test cases which results in a list of detailed examples of collaboration that will be supported in 8.2.0. These examples should be deployable and usable by teachers in class. Examples of use cases generated by teachers are at: http://wiki.laptop.org/go/Use_Cases#Collaboration_Examples Collaboration is an area where we are on the cutting edge of available technology. We're actually on the trailing edge of collaboration technology and far, far behind on collaborative teaching aids. Email, free web hosting, filesharing networks, Croquet, erights.org, Alice ML, multi-pointer X, Groovy, the distributed source control movement, and the Google Apps suite seem much closer to the leading edge of technology, to name a few. It was well promoted and teachers on the sur list have repeatedly asked for a definition of how to use it successfully. Insofar as we make no use of our own collaborative technology as part of our daily learning and teaching, we're not able to use it successfully ourselves. Documentation on previous wireless tests is at: http://wiki.laptop.org/go/Test_Config_Notes#Wireless_.26_Network More relevant documentation is available at http://wiki.laptop.org/go/Collaboration_Network_Testbed Requirements Definition: I set a high bar but I try to balance between available technology and the desires of the teachers. I hope can at least test to this standard soon, even if we don't close all bugs found by that testing until later. Requirements beginning with must are critical to success, should are very important but can be deferred and nice to have are very useful but likely to be deferred. Please consider using RFC 2119's definitions instead. If a must requirement cannot be met, we should still attempt to support as much of it as possible (e.g. if we can't do 50 XOs in N9, 40 or 30 should be tested and supported). I - Network Requirements i - Supported Architectures N1 - Must support one of the four network scenarios defined at: http://wiki.laptop.org/go/Networking_scenarios Please define support before using it here. The scenarios in priority order are named as follows. S1 - Simple Wifi S2 - School Wifi S3 - Simple Mesh S4 - School mesh (no need to test, just recorded here for completeness) I'm not sure that your priorities are correct. My understanding was that I believe that School Wifi is higher-priority (for collaboration; perhaps not for networking) than Simple Wifi. ii - RF Environments Is there an N1 that I missed. N2 - Must support environments where there are no other RF signals beyond the APs as needed by the network scenario. You need to be more precise here. RF signals and visible APs are _wholly_ different measurements. In particular, I believe that I should be able to hook up a spectrum analyzer (or run some software on my XO) and be able to immediately judge whether my environment meets your criteria. Furthermore, understand that APs by themselves consume relatively little bandwidth. It's the _clients_ of those APs (and other sources of noise) which consume the bandwidth that is inherently present in the spectrum. II - Scale i - Scale of XOs collaborating N5 - Must support up to 10 XOs collaborating together. See activity examples for exact steps. Since different collaborative activities consume different amounts of bandwidth, this is not an adequately specified requirement. ii - Scale of XOs visible within
Re: [sugar] specifying what services Activities may use
Bobby Powers [EMAIL PROTECTED] writes: recent joyrides include an activity updater which should help with this. And you guys could get rid of the scary red warning on the wiki :) on which page? See the barking here: http://wiki.laptop.org/go/OLPC_Update.1_Software_Release_Notes Activities must be installed separately. And unless my memory is fooling me, I'm pretty sure the warning was red at some point on this page: http://wiki.laptop.org/go/Olpc-upgrade Note that in builds 700 and above, you must install activities separately It's not that important anyway. It just occurred to me that the dependancies management challenge could be somehow dealt with by delivering a set of default activities. I'm not aware of any software distribution drawing such a strong line between the core system and the applications/activities. -- Bastien ___ Devel mailing list Devel@lists.laptop.org http://lists.laptop.org/listinfo/devel
joyride-weekly: joyride-2230
Dear world, This week's 'please test this joyride' is joyride-2230. Test group release notes, care of Charlie, are available at http://wiki.laptop.org/go/Test_Group_Release_Notes#Build_Joyride_2230 I'll push this announcement out further as discussed in last night's email as soon as I'm able. Michael ___ Devel mailing list Devel@lists.laptop.org http://lists.laptop.org/listinfo/devel
Re: Newer ds-backup-client RPMs for joyride...
On Thu, Jul 31, 2008 at 11:27 AM, Michael Stone [EMAIL PROTECTED] wrote: When releasing ds-backup revisions, please update documentation like http://wiki.laptop.org/go/Ds-backup Looks like we've both updated the page :-) m -- [EMAIL PROTECTED] -- School Server Architect - ask interesting questions - don't get distracted with shiny stuff - working code first - http://wiki.laptop.org/go/User:Martinlanghoff ___ Devel mailing list Devel@lists.laptop.org http://lists.laptop.org/listinfo/devel
Re: Collaboration Requirements
Dear Greg and Michael, It seems to me that we spend more time discussing things, instead of implementing them. The issue of scalability in large ad-hoc networks has been around for more than a decade and some pretty descent research results have been out there for several years now. Even if you pick one randomly you are guaranteed to scale by a whole order of magnitude better than OLPC's current implementation. Just pick one and implement it. I'm afraid that it is no exaggeration if I say that, from a network engineering standpoing, the current collaboration mechanism is literally the worse one possible, scaling quadratically with the number of nodes no matter if an access point is used or not. I do not mean to sound condescending, but rather note that it is very easy to improve on our current situation. I would rather see us spending our time iterating through implementation of a viable solution, large-scale testing (anyone testing collaboration with _scale_ in mind using 2-3 XOs should just be fired) and thinking about how to build and use feedback mechanisms (that do not involve humans) from actual deployments in schools in the US (where an internet connection is dependable) wrt our collaboration technology. Pol -- Polychronis Ypodimatopoulos Graduate student Viral Communications MIT Media Lab Tel: +1 (617) 459-6058 http://www.mit.edu/~ypod/ ___ Devel mailing list Devel@lists.laptop.org http://lists.laptop.org/listinfo/devel
Re: Collaboration Requirements
On 31 Jul 2008, at 01:07, Michael Stone wrote: On Wed, Jul 30, 2008 at 05:21:34PM -0400, Greg Smith wrote: It was well promoted and teachers on the sur list have repeatedly asked for a definition of how to use it successfully. Insofar as we make no use of our own collaborative technology as part of our daily learning and teaching, we're not able to use it successfully ourselves. I've often wondered why we (royal we) don't have a scheduled meeting where the communication is specifically attempted using Sugar only available tools (XO HW, emulation or jhbuild on whatever platforms are currently viable). With the main action being based in Chat, with a shared Write session for meeting minutes; Xo IRC works well for me (most reliable and open form of live collaboration on the XO so far) and could be the fallback when other things implode. It's all about developers being prepared to eat their own... so to speak, and it would send out the right signals about the expected quality and robustness of solutions. I was pretty disappointed to see gobby seemingly adopted (not anything is wrong with gobby), it just clearly shouts, we don't trust our own software to be reliable enough to use for a 1hr meeting. It might actually help making 'itches to scratch'. --Gary ___ Devel mailing list Devel@lists.laptop.org http://lists.laptop.org/listinfo/devel
Solar charging-personal versus central etc.
Scott- thanks for the informative reply. I've long been an enormous PV fan- you couldn't really ask for a better technology- and have become even more so with global energy hikes, the arrival of CIS/CIGS PVs. Low voltage,long life rugged ultrabright white LEDs are now threatening to make CFLs obsolete too. Your 20 years of electricity comment needs qualifying, as with just ~10 years of storage battery life means at least one battery bank replacement in that time = extra. I favour both centralised AND personal solar power, as it's all too easy in many communities to get off side with the guys controlling resources.You know how these things can go no doubt, especially when tribal issues arise. A supply fuse my inconveniently blow just when you want a top up... Additionally XO use surely means colossal inconvenience having to walk into the village (with all it's distractions) wait 3 hours just to charge the battery. At weekends especially kids could be helping at home have a simpler slower (maybe loaned) personal solar charger. I'd be very focused on a SLA battery being initially PV charged too, as having to leave an XO itself out in the sun may mean theft, accidental damage or even ruination by rain/wind. Personal chargers are achievable right now proof of concept tweakable, while larger centralised ones require much planning huge finance. Long range WiFi? I modestly point to my celebrated = www.usbwifi.orconhosting.net.nz which outlines field work cost effective enhancements. Almost ANYTHING in the LOS path of 2.4GHz signals will attenuate them. Are you factoring this in? To conclude- lets not forget laptop power needs are falling drastically! Intel Atom powered netbook offerings are increasingly thick on the ground, many run for 6-8 hours per charge. Laptop charging energy may decrease at much the same rate as have cell phone power needs over the last 15 years. My first calculator in 1973 ran for 3 hours per charge, yet most modern offerings (infinatly more powerful) run for months/years on a few AA cells. Stan --- Stan. SWAN - Educator/writer/consultant (ICT-Electronics-Sustainable Energy) EMAIL: = [EMAIL PROTECTED] (Work) = [EMAIL PROTECTED] CELL: (64)-021-672-958 HOME: (64)-(4)-562-7494 GST Reg: 36-921-021 POSTAL: 24 Tuatoru St, Eastbourne-L.H., Wellington 5013, NEW ZEALAND. ___ Devel mailing list Devel@lists.laptop.org http://lists.laptop.org/listinfo/devel
New joyride build 2233
http://xs-dev.laptop.org/~cscott/olpc/streams/joyride/build2233 Changes in build 2233 from build: 2232 Size delta: -1.97M -etoys 3.0.2059-1 +etoys 3.0.2068-1 -squeak-vm 3.10-3olpc6 +squeak-vm 3.10-3olpc7 --- Changes for etoys 3.0.2068-1 from 3.0.2059-1 --- + Allow to configure Squeaklet directory location by VM parameter (trac #7624) + Initial import of GStreamer + Fix PolygonMorphs stepTime + Pango Speed up + Convert ParticleDyeInWater.mpg to OGG --- Changes for squeak-vm 3.10-3olpc7 from 3.10-3olpc6 --- + Allow to configure Squeaklet directory location by VM parameter (trac #7624) + Initial import of GStreamer + Fix PolygonMorphs stepTime + Pango Speed up + Convert ParticleDyeInWater.mpg to OGG -- This mail was automatically generated See http://dev.laptop.org/~rwh/announcer/joyride-pkgs.html for aggregate logs See http://dev.laptop.org/~rwh/announcer/joyride_vs_update1.html for a comparison ___ Devel mailing list Devel@lists.laptop.org http://lists.laptop.org/listinfo/devel
Update-server - showing too many files?
Hi Scott, I'm looking some more at the update-server sw, and also looking at how rsync://updates.laptop.org behaves, and what olpc-update uses. Right now, the server publishes a top-level 'root' directory, which is what the client seems to be looking for, and also a number of other things that the client seems to ignore. See $ rsync rsync://updates.laptop.org/build-703 drwx--4096 2008/07/03 19:42:45 . -rw-r--r-- 318 2008/05/01 22:29:07 ChangeLog -rw-r--r-- 0 2008/07/30 23:53:12 access -rw-r--r-- 139630 2008/05/01 22:29:07 build.log -rw-r--r-- 3604455 2008/05/01 22:29:07 contents -rw-r--r-- 1112432 2008/05/01 22:29:07 fakeroot.state -rw-r--r-- 137 2008/05/01 22:29:07 rsyncd.conf -rw-r--r-- 6 2008/07/03 19:42:47 size -rw-r--r-- 0 2008/06/26 14:56:37 sticky drwxr-xr-x4096 2008/03/27 01:12:45 root root and content are what olpc-update seems to care about. All the other ones are internal to the server. Changelog and build.log seem to be 'nice to haves' from the EXTRAS array, but nothing reads them. Do you agree? How much of this is desired from your POV? m -- [EMAIL PROTECTED] [EMAIL PROTECTED] -- School Server Architect - ask interesting questions - don't get distracted with shiny stuff - working code first - http://wiki.laptop.org/go/User:Martinlanghoff ___ Devel mailing list Devel@lists.laptop.org http://lists.laptop.org/listinfo/devel
Re: Collaboration Requirements
Dear Pol, Greg and Michael, There is so much going on here that it's difficult to approach. I mostly second Michael's comments. Though Greg obviously took a lot of his time to put these goals together, I think we are missing the target. It's good to have goals such as 40 XOs being able to chat on a quiet environment but right now, they seem just too arbitrary. I'm not saying that the requirements are not legitimate, or do not come from legitimate sources (deployments), I'm just saying that we're approaching the scalability problem in an unrealistic way. I'll try to explain why and them I'll propose an alternative approach (i.e. where to put our efforts) Characterization is hard = Spectrum conditions are *very* difficult to characterize. Having a spectrum analyzer will give you some idea of the conditions in a point in space (where the spectrum analyzer is) and in a certain time interval (the consolidation interval) that may be completely irrelevant or misleading. Many times it's like predicting the growth of an specific plant on Alice's garden based on the average annual temperature on the whole country. My point is that 10 nodes may be able to chat until someone opens the door or an elevator stops on the floor. What I mean is that the only quantitative measurement that's of any value is the theoretical maximum limit. What we need to know is how many nodes will be able to chat under ideal (and unreal) conditions and them clarify to all the involved that there is no way to achieve that, ever (with the current implementation, or build). That all we can do is to wait for the elevator to go away, for the microwave oven to be turned off, or for the neighbor to stop downloading an mpeg via his access point. How do we get there is the next topic. Analytical models are necessary Each application has it's own demands and expectations must be set according to these demands. Activities requirements on terms of traffic (ideally bandwidth, delay, jitter, but minimally bandwidth) should be known. This is how you determine if a given link can or cannot support, say, a VoIP conversation. We must be able to model the traffic demands of our collaboration software likewise. What is the traffic generated by a chat between 10 XOs if each participant types one message of 20 bytes at every ten seconds? Once you have that number you should take the transport into consideration. For example, by determining that each of the chat messages will be encoded in a UDP frame of 460 bytes, that will be transmitted at 2Mbps, and will consume 2ms to be transmitted. On top of that you should consider how will this frame flood the mesh, if that's the case, i.e. computing the number of retransmissions. You do that and this will give you a number. You validate this on a testbed that tries to emulate the most favorable environment. If you get anywhere near you analytical model, you're good to go. If not, understand why and try to determine if your model is flawed (monitoring the testbed will tell you) or if your testbed is too way under optimal (some experience required to say so, but basically you try to change the environment and repeat the measures to see if there was improvements). Improvements are mandatory = In parallel you do your improvements in the stack. You try to write more efficient applications, middleware and protocols to achieve the same result. You trim out unnecessary overhead, you compact, you aggregate, you wait before transmitting so maybe you don't need to. There is a lot we already know on that front that we really need to implement (I agree with Pol on that). We can send beacon and probe requests less frequently, we can raise the route expiration time, just to mention two things that do not imply any change in code. But we also need to change code, to substitute one protocol for another, etc. I don't want to start discussing this now. I am just basically trying to say that efforts to improve scalability should happen in parallel to the modeling and analysis and should be a *permanent* effort in the development of the whole stack. In short. We have a limited resource - the shared spectrum. The only effective thing to do are: * design/implement a less spectrum demanding collaboration * build analytical models of this collaboration and try to extract realistic expectations from it. Cheers! Ricardo On Wed, Jul 30, 2008 at 11:32 PM, Polychronis Ypodimatopoulos [EMAIL PROTECTED] wrote: Dear Greg and Michael, It seems to me that we spend more time discussing things, instead of implementing them. The issue of scalability in large ad-hoc networks has been around for more than a decade and some pretty descent research results have been out there for several years now. Even if you pick one randomly you are guaranteed to scale by a whole order of magnitude better than OLPC's current implementation. Just pick one and implement it. I'm afraid that it
Re: Solar charging-personal versus central etc.
On Thu, 31 Jul 2008, Stan. SWAN wrote: Scott- thanks for the informative reply. No problem. I've long been an enormous PV fan- you couldn't really ask for a better technology- I concur. and have become even more so with global energy hikes, the arrival of CIS/CIGS PVs. The uni-solar us-64 thin films we have deployed in the field are doing great. I am very encouraged by the recent significant advances in PV. This for example is great: http://web.mit.edu/newsoffice/2008/solarcells-0710.html Low voltage,long life rugged ultrabright white LEDs are now threatening to make CFLs obsolete too. Like these? LED's are the right choice, I think. http://solarnetone.org/web5.jpg Your 20 years of electricity comment needs qualifying, When one purchases solar panels, they are buying an approximate given number of kikowatt hours at a fixed price, doled out mostly evenly over the lifetime of the panels. When I say 20 years I mean they will get 95% or better of rated output 20 years down the road, and they can plan on getting those kilowatt hours every day for 20 years. as with just ~10 years of storage battery life means at least one battery bank replacement in that time = extra. And a $ number that is difficult to quantify. How much does 1600Ah @ 12VDC cost 10 years from now. How much does it weigh. What does it look like? I seriously doubt it will be lead acid by then, even though we use vented lead acid batteries now for the best Ah/$ ratio. I favour both centralised AND personal solar power, In general, I agree, and its great if there is a microfinance option for those who choose to install personal power production. In some cases the central charging station will be these individuals first exposure to solar power, or computers. as it's all too easy in many communities to get off side with the guys controlling resources.You know how these things can go no doubt, especially when tribal issues arise. A supply fuse my inconveniently blow just when you want a top up... Alas... Additionally XO use surely means colossal inconvenience having to walk into the village (with all it's distractions) wait 3 hours just to charge the battery. I was thinking more they leave for home with a full charge, every time. At weekends especially kids could be helping at home have a simpler slower (maybe loaned) personal solar charger. thats lots if charge controllers and panels getting less than full usage... I'd be very focused on a SLA battery being initially PV charged too, as having to leave an XO itself out in the sun may mean theft, accidental damage or even ruination by rain/wind. Personal chargers are achievable right now proof of concept tweakable, while larger centralised ones require much planning huge finance. I'm not arguing against personal chargers if people want them. Ideally the central power system encourages people to add their own PV systems at home. The shared system ultimately has cost benefits over many smaller units, which is important when introducing a technology. Long range WiFi? I modestly point to my celebrated = www.usbwifi.orconhosting.net.nz which outlines field work cost effective enhancements. Almost ANYTHING in the LOS path of 2.4GHz signals will attenuate them. Are you factoring this in? Yep. Thats what the 50' of LMR-400, the 12dB omni, and the 400mw radio are for. Repeaters and directionals as necesary, of course. To conclude- lets not forget laptop power needs are falling drastically! Intel Atom powered netbook offerings are increasingly thick on the ground, many run for 6-8 hours per charge. VIA's new one is pretty good too. The turion X2 machine we use as the server for the SolarNet is around 20 watts or so. Laptop charging energy may decrease at much the same rate as have cell phone power needs over the last 15 years. My first calculator in 1973 ran for 3 hours per charge, yet most modern offerings (infinatly more powerful) run for months/years on a few AA cells. That would be nice, wouldn't it, for all types of applications. Solar powered vehicles, PV and wind storage, mobile devices... Enjoy, Scott Stan --- Stan. SWAN - Educator/writer/consultant (ICT-Electronics-Sustainable Energy) EMAIL: = [EMAIL PROTECTED] (Work) = [EMAIL PROTECTED] CELL: (64)-021-672-958 HOME: (64)-(4)-562-7494 GST Reg: 36-921-021 POSTAL: 24 Tuatoru St, Eastbourne-L.H., Wellington 5013, NEW ZEALAND. ___ 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
Re: [Server-devel] ds-backup - help with a trial happening right now
On Thu, Jul 31, 2008 at 12:19 PM, Michael Stone [EMAIL PROTECTED] wrote: People do occasionally volunteer, you know. It's fine to say that _you_ are too busy, but please don't speak for everyone. Good point. In any case, there's better hope on devel@ where people know more about the XO sw :-) So copying devel@ - in a nutshell, Pia is in a deployment in Niue, and asking for help backporting ds-backup-client to 703. the internals of the datastore on the laptop (datastore is the back-end of the journal) need an update that has not been tested on 703. I believe that may be the only update made to the DS since 703 and I doubt it depends on anything but a JSON library. To expand on that, and for anyone keen on trying, you'll need 703 plus... - simplejson (ISTR it's not packaged for F6, but a backport is possible) - datastore v8.2 or newer - this is the risky change, there is a small chance that other parts of Sugar/Journal act up with it. - ds-backup-client 0.7 cheers, m -- [EMAIL PROTECTED] [EMAIL PROTECTED] -- 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
[Server-devel] Update-server - showing too many files?
Hi Scott, I'm looking some more at the update-server sw, and also looking at how rsync://updates.laptop.org behaves, and what olpc-update uses. Right now, the server publishes a top-level 'root' directory, which is what the client seems to be looking for, and also a number of other things that the client seems to ignore. See $ rsync rsync://updates.laptop.org/build-703 drwx--4096 2008/07/03 19:42:45 . -rw-r--r-- 318 2008/05/01 22:29:07 ChangeLog -rw-r--r-- 0 2008/07/30 23:53:12 access -rw-r--r-- 139630 2008/05/01 22:29:07 build.log -rw-r--r-- 3604455 2008/05/01 22:29:07 contents -rw-r--r-- 1112432 2008/05/01 22:29:07 fakeroot.state -rw-r--r-- 137 2008/05/01 22:29:07 rsyncd.conf -rw-r--r-- 6 2008/07/03 19:42:47 size -rw-r--r-- 0 2008/06/26 14:56:37 sticky drwxr-xr-x4096 2008/03/27 01:12:45 root root and content are what olpc-update seems to care about. All the other ones are internal to the server. Changelog and build.log seem to be 'nice to haves' from the EXTRAS array, but nothing reads them. Do you agree? How much of this is desired from your POV? m -- [EMAIL PROTECTED] [EMAIL PROTECTED] -- 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