Occasional stuck keys on devanagari keyboard
I have about 40 XO's out of 2000 so far that occasionally show stuck keys in the corners of the keyboard, particularly the frame, fn, and right arrow key. The keys seem to stick occasionally but not consistently. For instance, w/ 5 XO's yesterday the keys were stuck on the first boot. On the second boot the problem went away. Today, I powered on the same XO's and the keys were stuck on the first boot. The problem went away on the second boot. We have firmware Q2E33 Can anyone shed some insight on this problem? -- Bryan W. Berry Technology Director OLE Nepal, http://www.olenepal.org ___ Devel mailing list Devel@lists.laptop.org http://lists.laptop.org/listinfo/devel
Fwd: Heart Rate Monitor Peripheral
-- Forwarded message -- From: Tom Boonsiri tom.boons...@gmail.com Date: Wed, Apr 8, 2009 at 2:31 AM Subject: Heart Rate Monitor Peripheral To: seth.woodwo...@gmail.com Fellow developers, Is your Measure activity feeling neglected? If so, shame on you. =) I'd like to encourage everyone to build on the great work of Arjun Sarwal and help us extend the sensor interface with our peripheral -- the heart rate monitor. Pictures of the device: http://farm4.static.flickr.com/3559/3419907541_f62b168dce_m.jpg http://farm4.static.flickr.com/3558/3420715230_00e29b7787_m.jpg It's a relatively simple device that measures the blood flow in your finger with an infrared sensor. Powered by USB, the device sends measurements to the XO via the AC/DC sensor interface (audio jack). Using a Measure variant with a heart beat detection method, we are able to display the heart rate (as shown in the pic). If you're a developer interested in integrating biofeedback into your application, please email me for more details on how you can get your hands on a few of our peripherals. Otherwise, we are looking for developers who can help us evolve the Measure activity to better suit the lesson plan we have created for the device. The device is not of clinical quality and solely for educational purposes. We are definitely interested in feedback on our direction. In the short-term, it would be interesting to develop a gui where you could structure a family tree (even extending it to branches for relatives) and allow kids to record measurements for various family members. This could potentially evolve into other health education efforts with a wiki backbone to support health wellness. Please send me your feedback and your interest! Thanks, Tom Boonsiri -- OLPC GoldenState (tom.boons...@gmail.com) ___ Devel mailing list Devel@lists.laptop.org http://lists.laptop.org/listinfo/devel
Rainbow, olpc-update, and olpcrd.
The main and probably most major issues outstanding are the kernel/boot process - so kernel/initscripts/olpcrd/initscripts/upstart/rainbow collection of stuff of which I have no real idea about. Updates? Peter, Your remark does not contain any specific questions so it's a little hard for me to give you a coherent update. Instead, I'll make some general remarks in the hope that they will elicit further questions. 1. As has been recently pointed out, Rainbow is not currently in use on any Sugar platform later than sugar-*-0.84 (i.e. OLPC's 8.2.*). However, some have wondered whether it might make a reappearance in sugar-*-0.86. To speed this outcome, I have prepared new versions of rainbow (0.8.*) which are easy to install and test on many different platforms. See http://wiki.laptop.org/go/Rainbow for current status information. (I await further rainbow-0.8.* questions, comments, concerns, and test results with particular interest.) 2. There is little change in the state of olpcrd and olpc-update. Daniel Drake did some nice work in February to make the toolchain support OFW-hosted key overlays and, so far as I know, is happily serving Paraguay-signed leases and software updates over Paraguay's test schools' wifi network. (Dan -- could you please update http://wiki.laptop.org/go/Security with links to a description of how you've deployed these technologies?) (Peter -- Did you have some specific question about the technology or about its inclusion [or lack thereof] in Fedora?) Regards from Athens, Michael ___ Devel mailing list Devel@lists.laptop.org http://lists.laptop.org/listinfo/devel
Re: move to rawhide update (Fedora QA breakage)
II. - What for me is an inhibitor is the bugzilla section tell us how to reproduce the problem. I have no desire whatsoever to try Mikus unfortunately plays a troll on the Internet. He probably isn't one in real life, but the way he uses the XO is extremely unusual, so he views the XO in ways that appear to be 77 degrees away from the usual viewpoint. His bug reports require careful interpretation if you want to avoid immediately discarding them as worthless. What good would it do for me to enter a bugzilla report? A dozen people would ask me for more information, and for more try this and try that. I have better things to do with my time. I'm sad to report that I tried to participate in a Fedora QA test day last week for some particular hardware I have (low end Radeon graphics). I filed one clear bug report, and four days later got the usual please send us lots of irrelevant info form letter. I filed a testy reply telling them they don't need it and please stop pretending to close out bug reports by demanding that the user send some irrelevant info. See: https://bugzilla.redhat.com/show_bug.cgi?id=493748 One of these irrelevant busybodies self-identifies as one of the Fedora BugZappers with this link: https://fedoraproject.org/wiki/BugZappers We are a group of volunteers and Red Hat employees whose primary mission is to review and triage bug report submissions on bugzilla.redhat.com, acting as a bridge between users and developers to aid in fixing and closing bugs. Now I see what's going on. Clueless people are crashing around in the bug database, helping developers by hassling users. Then if you don't answer the idiots, 30 days later they close out your bug report as CLOSED:INSUFFICIENT_DATA. Instead of a bridge, they seem to be more of a barrier, though perhaps they do good work somewhere. I think these are the same people who also trashed the OLPC suspend/resume is broken bug report, by running a script that declared it an obsolete problem that only applied to F10, even though the problem persists long after F10. But as the BugZapper credo says, No programming knowledge is necessary, and triagers don't necessarily need to understand the bugs they are working on. So I'll have to agree with Mikus's analysis of why not to bother filing Red Hat bugzilla bugs. Idiots will hassle you, and claim that the bug doesn't exist after all, then close it. (*) John (*): At Cygnus, we wrote a bug tracking system, PRMS. We made very sure that nobody except the original submitter could close out a bug report. The only thing developers or QA people could do was put the bug into feedback state, asking the original submitter to confirm that the bug really is fixed. I insisted on this process flow because of the numerous companies I'd reported bugs to, who regularly closed out my bugs without fixing them -- over and over. I'd search the bug reports at Sun and find six people all reporting the same bug I'd encountered -- and all six of them closed inappropriately by somebody whose job it was to close bug reports (not to fix bugs). Cygnus's customers appreciated the attention, even though it was sometimes a hassle for us to nudge them to close out the bugs we really HAD fixed. ___ Devel mailing list Devel@lists.laptop.org http://lists.laptop.org/listinfo/devel
Re: xapian and pyxapian
Simon Schampijer wrote: Peter Robinson wrote: Hi All, Just looking at the pyxapian package in Fedora. Its only even been used in the OLPC-2 cvs branch. There is no build in mainline fedora branches. Is it still used? According to the pyxapian site its been obsoleted/replaced by xappy. So i'm just wondering if its still used in OLPC 80x another later branches, or is it not used any more? Cheers, Peter I guess you are right. The sugar-datastore which uses xapian requires xapian-bindings-python The pyxapian package sounds highly obsolete to me. Regards, Simon Thanks Peter for taking care of following the 'Retired Package' process. Regards, Simon ___ Devel mailing list Devel@lists.laptop.org http://lists.laptop.org/listinfo/devel
Re: Rainbow, olpc-update, and olpcrd.
Peter, Your remark does not contain any specific questions so it's a little hard for me to give you a coherent update. Instead, I'll make some general remarks in the hope that they will elicit further questions. Sorry, there were no real questions, but its more about the status of where it stands within Fedora rawhide. The current understanding is what's documented at this link. If you have more to provide that would be great (I was already aware of rainbow and the PID changes but didn't put details in as I don't know alot about early boot processes). https://fedoraproject.org/wiki/OLPC/Packages_for_F11 1. As has been recently pointed out, Rainbow is not currently in use on any Sugar platform later than sugar-*-0.84 (i.e. OLPC's 8.2.*). However, some have wondered whether it might make a reappearance in sugar-*-0.86. To speed this outcome, I have prepared new versions of rainbow (0.8.*) which are easy to install and test on many different platforms. See I presume you mean later than 0.8.2? http://wiki.laptop.org/go/Rainbow for current status information. (I await further rainbow-0.8.* questions, comments, concerns, and test results with particular interest.) I believe the major concerns around about the changes to init to run it as PID 1 and what changes can be made for Fedora mainline acceptance. I have no idea about the pros and cons of this hence the generic query. 2. There is little change in the state of olpcrd and olpc-update. Daniel Drake did some nice work in February to make the toolchain support OFW-hosted key overlays and, so far as I know, is happily serving Paraguay-signed leases and software updates over Paraguay's test schools' wifi network. (Dan -- could you please update http://wiki.laptop.org/go/Security with links to a description of how you've deployed these technologies?) (Peter -- Did you have some specific question about the technology or about its inclusion [or lack thereof] in Fedora?) About its inclusion in Fedora. Peter ___ Devel mailing list Devel@lists.laptop.org http://lists.laptop.org/listinfo/devel
Re: [IAEP] Fwd: Heart Rate Monitor Peripheral
On Wed, Apr 08, 2009 at 03:44:05AM -0400, Seth Woodworth wrote: I'd like to encourage everyone to build on the great work of Arjun Sarwal and help us extend the sensor interface with our peripheral -- the heart rate monitor. Looks great! As I intended to do a similar device in the future (it's going to measure SpO2 (oxygen saturation) as well as that's what I'm interested in), I'd like to see the schematics. Are they available somewhere? Do you just amplify the current through a photo transistor or is there something more fancy going on, e.g. AGC? CU Sascha -- http://sascha.silbe.org/ http://www.infra-silbe.de/ signature.asc Description: Digital signature ___ Devel mailing list Devel@lists.laptop.org http://lists.laptop.org/listinfo/devel
Re: [IAEP] Fwd: Heart Rate Monitor Peripheral
Alas, the blocker with Measure (and Turtle Art with Sensors) is that we haven't come to consensus regarding a packaging strategy for the binary drivers we include for support of the sensor input; these differ by architecture, which wasn't a problem when we were building for just one architecture. Perhaps the packaging gurus can chime in. (See http://dev.sugarlabs.org/ticket/155). -walter On Wed, Apr 8, 2009 at 3:44 AM, Seth Woodworth s...@laptop.org wrote: -- Forwarded message -- From: Tom Boonsiri tom.boons...@gmail.com Date: Wed, Apr 8, 2009 at 2:31 AM Subject: Heart Rate Monitor Peripheral To: seth.woodwo...@gmail.com Fellow developers, Is your Measure activity feeling neglected? If so, shame on you. =) I'd like to encourage everyone to build on the great work of Arjun Sarwal and help us extend the sensor interface with our peripheral -- the heart rate monitor. Pictures of the device: http://farm4.static.flickr.com/3559/3419907541_f62b168dce_m.jpg http://farm4.static.flickr.com/3558/3420715230_00e29b7787_m.jpg It's a relatively simple device that measures the blood flow in your finger with an infrared sensor. Powered by USB, the device sends measurements to the XO via the AC/DC sensor interface (audio jack). Using a Measure variant with a heart beat detection method, we are able to display the heart rate (as shown in the pic). If you're a developer interested in integrating biofeedback into your application, please email me for more details on how you can get your hands on a few of our peripherals. Otherwise, we are looking for developers who can help us evolve the Measure activity to better suit the lesson plan we have created for the device. The device is not of clinical quality and solely for educational purposes. We are definitely interested in feedback on our direction. In the short-term, it would be interesting to develop a gui where you could structure a family tree (even extending it to branches for relatives) and allow kids to record measurements for various family members. This could potentially evolve into other health education efforts with a wiki backbone to support health wellness. Please send me your feedback and your interest! Thanks, Tom Boonsiri -- OLPC GoldenState (tom.boons...@gmail.com) ___ IAEP -- It's An Education Project (not a laptop project!) i...@lists.sugarlabs.org http://lists.sugarlabs.org/listinfo/iaep -- Walter Bender Sugar Labs http://www.sugarlabs.org ___ Devel mailing list Devel@lists.laptop.org http://lists.laptop.org/listinfo/devel
Re: [IAEP] Fwd: Heart Rate Monitor Peripheral
Right now this device works primarily with the XO-1, taking advantage of the AC/DC conversion going on in the XO's audio-in port. But if the gain were tweaked a bit more it could work with other audio cards. The fact that it is XO-1 Hardware specific means that packaging for different architectures isn't a problem in the short run, correct? On Wed, Apr 8, 2009 at 7:56 AM, Peter Robinson pbrobin...@gmail.com wrote: Alas, the blocker with Measure (and Turtle Art with Sensors) is that we haven't come to consensus regarding a packaging strategy for the binary drivers we include for support of the sensor input; these differ by architecture, which wasn't a problem when we were building for just one architecture. Perhaps the packaging gurus can chime in. (See http://dev.sugarlabs.org/ticket/155). So the sensors are the ones that can get plugged into the audio input/output on the XO? Is this custom to the XO or could be conceivably be implemented/used on other audio cards? Peter ___ Devel mailing list Devel@lists.laptop.org http://lists.laptop.org/listinfo/devel
Re: [IAEP] Fwd: Heart Rate Monitor Peripheral
There's generally no issue with hardware specific packages in distros (there certainly isn't an issue in Fedora), from the quick read I had of the ticket it looks more like the turtle activity didn't work on the non XO hardware. I presume that's because it couldn't load the specific libraries. Generally you would put the hardware specific bits in either a separate package from the app or a sub-package so that for devices where the hardware isn't present it doesn't need to be installed. This though would require the app to be able to detect the whether drivers/plugins are present or not and deal with it. There would be no issue installing them by default as long as it doesn't disturb other sound cards that aren't supported. Peter BTW the idea of the hardware sensors is very cool. Is there somewhere you can see what sensors are available for the XO and buy them? Right now this device works primarily with the XO-1, taking advantage of the AC/DC conversion going on in the XO's audio-in port. But if the gain were tweaked a bit more it could work with other audio cards. The fact that it is XO-1 Hardware specific means that packaging for different architectures isn't a problem in the short run, correct? On Wed, Apr 8, 2009 at 7:56 AM, Peter Robinson pbrobin...@gmail.com wrote: Alas, the blocker with Measure (and Turtle Art with Sensors) is that we haven't come to consensus regarding a packaging strategy for the binary drivers we include for support of the sensor input; these differ by architecture, which wasn't a problem when we were building for just one architecture. Perhaps the packaging gurus can chime in. (See http://dev.sugarlabs.org/ticket/155). So the sensors are the ones that can get plugged into the audio input/output on the XO? Is this custom to the XO or could be conceivably be implemented/used on other audio cards? Peter ___ Devel mailing list Devel@lists.laptop.org http://lists.laptop.org/listinfo/devel
Re: [IAEP] Fwd: Heart Rate Monitor Peripheral
Peter, In the ticket, I was trying to express my ignorance of how to proceed, but not suggest that the distros haven't dealt with these sorts of issues in the past. There are two separate issues I encountered with TA (and Measure). One is the need for patches to the alsa audio to accommodate the special OLPC hardware modifications. The other is a means within the Sugar bundling system to include binaries for multiple architectures. I actually had written a work-around for the former, but I remain ignorant about the details of how to best handle the latter. (At one point, Sascha had helped me include a script that would build the appropriate binaries at install time, but that solution depends upon a build environment be installed, which is not the default for most OLPC systems. Oops.) Regarding available sensors, Arjun describes some on the Measure page in the OLPC wiki http://wiki.laptop.org/go/Measure There are also many people working on USB sensor input devices that would be great to support in general. thanks. -walter On Wed, Apr 8, 2009 at 8:22 AM, Peter Robinson pbrobin...@gmail.com wrote: There's generally no issue with hardware specific packages in distros (there certainly isn't an issue in Fedora), from the quick read I had of the ticket it looks more like the turtle activity didn't work on the non XO hardware. I presume that's because it couldn't load the specific libraries. Generally you would put the hardware specific bits in either a separate package from the app or a sub-package so that for devices where the hardware isn't present it doesn't need to be installed. This though would require the app to be able to detect the whether drivers/plugins are present or not and deal with it. There would be no issue installing them by default as long as it doesn't disturb other sound cards that aren't supported. Peter BTW the idea of the hardware sensors is very cool. Is there somewhere you can see what sensors are available for the XO and buy them? Right now this device works primarily with the XO-1, taking advantage of the AC/DC conversion going on in the XO's audio-in port. But if the gain were tweaked a bit more it could work with other audio cards. The fact that it is XO-1 Hardware specific means that packaging for different architectures isn't a problem in the short run, correct? On Wed, Apr 8, 2009 at 7:56 AM, Peter Robinson pbrobin...@gmail.com wrote: Alas, the blocker with Measure (and Turtle Art with Sensors) is that we haven't come to consensus regarding a packaging strategy for the binary drivers we include for support of the sensor input; these differ by architecture, which wasn't a problem when we were building for just one architecture. Perhaps the packaging gurus can chime in. (See http://dev.sugarlabs.org/ticket/155). So the sensors are the ones that can get plugged into the audio input/output on the XO? Is this custom to the XO or could be conceivably be implemented/used on other audio cards? Peter -- Walter Bender Sugar Labs http://www.sugarlabs.org ___ Devel mailing list Devel@lists.laptop.org http://lists.laptop.org/listinfo/devel
Re: move to rawhide update (Fedora QA breakage)
Now I see what's going on. Clueless people are crashing around in the bug database, helping developers by hassling users. Then if you don't answer the idiots, 30 days later they close out your bug report as CLOSED:INSUFFICIENT_DATA. Instead of a bridge, they seem to be more of a barrier, though perhaps they do good work somewhere. I think these are the same people who also trashed the OLPC suspend/resume is broken bug report, by running a script that declared it an obsolete problem that only applied to F10, even though the problem persists long after F10. But as the BugZapper credo says, No programming knowledge is necessary, and triagers don't necessarily need to understand the bugs they are working on. I agree with you to a certain extent. I believe the reason for the relable as F10 is primarily due to the fact that Fedora is relatively fast moving. The idiots you refer to are in the case of the this has been reported in rawhide during the F10 development process so assigning it to F10 are in fact scripts so are complete idiots. There's a good reason to assign it from rawhide to the specific release that it was reported under, its because it moves very quickly. X is an example of this. There's been massive changes in the last 3-4 fedora releases and for example errors related to input devices reported in F-9 are completely irrelevant in F-10 because the entire X input subsystem was replaced. So to be able to see that it was reported in what became F-9 is important because its going to be completely different issue in F-10. Just because it gets moved from a rawhide designator to a F-10 one doesn't mean its closed, and if its still relevant for rawhide, you can update it. I do so regularly. As for the bugZappers. no comment :-) Peter ___ Devel mailing list Devel@lists.laptop.org http://lists.laptop.org/listinfo/devel
Re: [IAEP] Fwd: Heart Rate Monitor Peripheral
There are two separate issues I encountered with TA (and Measure). One is the need for patches to the alsa audio to accommodate the special OLPC hardware modifications. That would need to be accepted upstream by the alsa project, and then distros will automatically get the changes when they are part of a release. The other is a means within the Sugar bundling system to include binaries for multiple architectures. I actually had written a work-around for the former, but I remain ignorant about the details of how to best handle the latter. (At one point, Sascha had helped me include a script that would build the appropriate binaries at install time, but that solution depends upon a build environment be installed, which is not the default for most OLPC systems. Oops.) That would be just a packaging procedure. In the case of Fedora it would be just the arch dependant rpms as opposed to using a activity .xo file which I believe are arch independent. Unless I've missed something here. Regarding available sensors, Arjun describes some on the Measure page in the OLPC wiki Thanks! http://wiki.laptop.org/go/Measure There are also many people working on USB sensor input devices that would be great to support in general. In fedora at least from a driver perspective it would land in Fedora as soon as the upstream kernel has the drivers. I'm not sure whether there is a defined api for accessing those sort sensors on linux. If there was I would presume as the hardware is added that TA/measure would automatically get support for the hardware as its added, if there's not I presume there would need to be individual support added for each device. Peter ___ Devel mailing list Devel@lists.laptop.org http://lists.laptop.org/listinfo/devel
Re: [IAEP] Fwd: Heart Rate Monitor Peripheral
Alas, the blocker with Measure (and Turtle Art with Sensors) is that we haven't come to consensus regarding a packaging strategy for the binary drivers we include for support of the sensor input; these differ by architecture, which wasn't a problem when we were building for just one architecture. Perhaps the packaging gurus can chime in. (See http://dev.sugarlabs.org/ticket/155). So the sensors are the ones that can get plugged into the audio input/output on the XO? Is this custom to the XO or could be conceivably be implemented/used on other audio cards? Peter ___ Devel mailing list Devel@lists.laptop.org http://lists.laptop.org/listinfo/devel
Re: move to rawhide update
2009/4/8 John Gilmore g...@toad.com: Since OLPC's upstream is both Linus's kernel releases, and Fedora's distributions, there are two upstream places to push OLPC's hardware support patches to. Have we only been trying to get them into one of those places (Linus's)? The F11 kernel currently carries about 60 patches beyond Linus's version. Some are tiny 4kb patches; others are 300KB. Why aren't any of the XO-1 hardware support patches included in the F11 kernel? I don't think any effort has been made (since layoffs) to get any kernel patches upstream anywhere, mostly due to time constraints. But anyone is welcome to step up and do so! During a quick discussion with Chris and some others we seemed to agree on the following: - regardless of Fedora/F11/F12 status, policies or whatever, the first thing to do in any case is to get the patches upstream to Linus - we haven't actually tried sending our patches specifically to Fedora (knowing that they aren't quite ready for Linus) - but IMO this would be a bad idea - we don't really know Fedora's kernel policies for accepting non-upstream patches, or for backporting upstreamed patches into current Fedora kernels - my opinion: getting patches upstream to Linus, or perhaps even as far as linux-next, would be enough for the fedora kernel maintainers to include the patches in the F11 release kernel as an update. So let's not rule out suspend-on-F11.. it's possible that F11-plus-updates may work in future. The biggest showstopper right now seems to be finding someone to do the work of upstreaming the patches. And, in my opinion and experience, the correct way to do this is to approach upstream saying hey, we have this weird hardware, how would you like to see the kernel code crafted? here's a possible patch to act as the basis of discussions and *not* hey, we have this weird hardware, please take our patches as-is without consideration because we've shipped them internally for 2 years which makes the task harder (since kernel hacking may be needed as a result of discussions), but should lead to success :) Daniel ___ Devel mailing list Devel@lists.laptop.org http://lists.laptop.org/listinfo/devel
Re: [IAEP] Fwd: Heart Rate Monitor Peripheral
Hi In a related note Kristianpaulhttp://co.sugarlabs.org/wiki/index.php?title=Usuario:Kristianpaulaction=editredlink=1of Sugarlabs .co is testing measure in Soas (with arjun's help) in an effort to adapt it to all kinds of hardware. http://co.sugarlabs.org/go/Sobre_Measure Rafael Ortiz On Wed, Apr 8, 2009 at 7:40 AM, Peter Robinson pbrobin...@gmail.com wrote: There are two separate issues I encountered with TA (and Measure). One is the need for patches to the alsa audio to accommodate the special OLPC hardware modifications. That would need to be accepted upstream by the alsa project, and then distros will automatically get the changes when they are part of a release. The other is a means within the Sugar bundling system to include binaries for multiple architectures. I actually had written a work-around for the former, but I remain ignorant about the details of how to best handle the latter. (At one point, Sascha had helped me include a script that would build the appropriate binaries at install time, but that solution depends upon a build environment be installed, which is not the default for most OLPC systems. Oops.) That would be just a packaging procedure. In the case of Fedora it would be just the arch dependant rpms as opposed to using a activity .xo file which I believe are arch independent. Unless I've missed something here. Regarding available sensors, Arjun describes some on the Measure page in the OLPC wiki Thanks! http://wiki.laptop.org/go/Measure There are also many people working on USB sensor input devices that would be great to support in general. In fedora at least from a driver perspective it would land in Fedora as soon as the upstream kernel has the drivers. I'm not sure whether there is a defined api for accessing those sort sensors on linux. If there was I would presume as the hardware is added that TA/measure would automatically get support for the hardware as its added, if there's not I presume there would need to be individual support added for each device. Peter ___ 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: [IAEP] Fwd: Heart Rate Monitor Peripheral
Walter Bender wrote: Peter, In the ticket, I was trying to express my ignorance of how to proceed, but not suggest that the distros haven't dealt with these sorts of issues in the past. There are two separate issues I encountered with TA (and Measure). One is the need for patches to the alsa audio to accommodate the special OLPC hardware modifications. The other is a means within the Sugar bundling system to include binaries for multiple architectures. I What binary drivers are you talking about? -- Richard Smith rich...@laptop.org One Laptop Per Child ___ Devel mailing list Devel@lists.laptop.org http://lists.laptop.org/listinfo/devel
1cc network outage
We had an interruption in network services at 1cc from about 12:38 am to 12:47 am. This affected the reverse proxy server serving the wiki as well as phone and network services at 1cc. ___ Devel mailing list Devel@lists.laptop.org http://lists.laptop.org/listinfo/devel
[Server-devel] 100 user test on XS
I tested ejabberd from XS 0.5.2 with 100 concurrent users using hyperactivity. This is just using shared-roster. Memory usage was totaly under 1G with no swapping. It got a little slow on the client side running the hyperactivity code. The neighborhood view was pretty crowded but everything seemed to work well. This was a very basic test, but overall seems to be promising news. Dave -- Dave Bauer d...@solutiongrove.com http://www.solutiongrove.com ___ Server-devel mailing list server-de...@lists.laptop.org http://lists.laptop.org/listinfo/server-devel
Re: Devel Digest, Vol 38, Issue 1
On 4/2/09, Mitch Bradley w...@laptop.org wrote: Martin Langhoff wrote: On Thu, Apr 2, 2009 at 3:49 PM, Mitch Bradley w...@laptop.org wrote: It's nice to say they should see the light, but in my experience talking to many such companies, the fact of the matter is that it is a hard nut for them to swallow. I am under the impression that the relation between the OS vendor (and kernel/driver devs on the OS side) and the HW companies (with their hw and driver devs) is full of hard nuts to swallow. From reading horror stories around winhec, and ms bloggers making strained comments about driver developers, it doesn't sound like a bed of roses :-) But, for good or bad, management has gotten used to the dynamic w Redmond. That is absolutely correct. Windows drivers are a total pain in the ass (speaking from my experience making Windows run on the XO). But in compensation, once you get the driver right, or mostly so, it will work on hundreds of millions of machines for a few years. By it, I mean a specific binary that you can point to and say that is the one. When it stops working due to a new MS OS like Vista, you might be able to ignore the problem because the old product is several generations obsolete and you've already made your money on it. Sorry, you have to upgrade. Which is wrong and a very good thing about Linux. If you saw the outcry that followed when Creative labs aliented their customer base from Vista by offering new cards or a paid upgrade for Alchemy, you know how bad it was. I have a serious problem paying say $200 for a sound card that will still be mostly state of the art five years down the road but that doesn't have drivers two years after release, just because some company only thinks about profits. Having done the painful-but-necessary work to service the market that is big enough to return a profit, there is scant motivation to swallow additional nuts for a much smaller amorphous market that won't stay in focus. One of Joel Spolsky's essays pointed out that to attract customers from an entrenched competitor, you must ruthlessly eliminate the many barriers that make it difficult to switch. You must see those barriers from the customer's point of view; trying to impose your point of view on the customer just doesn't work. Breaking APIs in the kernel, AFAIK, is more related to changing things when security concerns arise than by will - after all, the people who do that end up having more work with affected drivers. There are plenty of companies that have the will to support changes. Some because they have server related hardware, some because they catter to the customer, like Intel, which has even contributted to advances in Xorg. And they manage fine, more than fine. Nvidia released 4 drivers in March, mostly to add features. Unfortunately, most just plain like to ignore it's customers, like the above cited Creative labs. Best regards, Tiago Marques I guess the main disconnect is that, for the FOSS community, the point of view is more important than the product. The commercial world is just the opposite. I am interested in discussing the meatier parts of whether the commiditization that FOSS has applied to sw affects hw and how some time over a beer. I would like that very much. I sincerely hope that we have the opportunity to meet in person at some point. ___ 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: Occasional stuck keys on devanagari keyboard
On 8 Apr 2009, at 07:20, Bryan Berry wrote: I have about 40 XO's out of 2000 so far that occasionally show stuck keys in the corners of the keyboard, particularly the frame, fn, and right arrow key. The keys seem to stick occasionally but not consistently. For instance, w/ 5 XO's yesterday the keys were stuck on the first boot. On the second boot the problem went away. Today, I powered on the same XO's and the keys were stuck on the first boot. The problem went away on the second boot. We have firmware Q2E33 Can anyone shed some insight on this problem? My (hardware) stuck XO-1 key experience was intermittent. Opening/ closing, moving, slight case flexing was enough to stop or start the issue. If it is the old hardware issue (and keys around the edge did seem to be the ones effected), the ~30min sticky tape fix worked and continues to work today for me (6 months on): http://wiki.laptop.org/go/Stuck_keys#Fix Regards, --Gary -- Bryan W. Berry Technology Director OLE Nepal, http://www.olenepal.org ___ 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: [IAEP] Fwd: Heart Rate Monitor Peripheral
Alas, the blocker with Measure (and Turtle Art with Sensors) is that we haven't come to consensus regarding a packaging strategy for the binary drivers we include for support of the sensor input; these differ by architecture, which wasn't a problem when we were building for just one architecture. Perhaps the packaging gurus can chime in. (See http://dev.sugarlabs.org/ticket/155). I'm guessing below, because I can't find the source of the binary driver you are discussing. The bug report doesn't point to it, and it isn't in an obvious place in the OLPC git or the Sugar gitorious. It's not a binary driver, it's just a library implemented in C or C++ rather than Python. This is only novel to the Sugar team -- the vast majority of packages in every Linux distro are already this way. There's already a python-alsaaudio package in Ubuntu: http://packages.ubuntu.com/intrepid/sound/python-alsaaudio If this is the module you're calling, your sugar-measure-activity package just has to mention that as a dependency, and all should be well. If you have your own unique python-alsaaudio module, you'll probably want to merge it with the already-existing one, and fix up Measure so it can call the existing public one. John ___ Devel mailing list Devel@lists.laptop.org http://lists.laptop.org/listinfo/devel
Re: [Server-devel] Gadget on XS
On Fri, Apr 3, 2009 at 10:15 AM, Guillaume Desmottes
guillaume.desmot...@collabora.co.uk wrote:
Did you properly configured ejabberd as explained in Gadget's README?
You should have something like that:
{5560, ejabberd_service, [
{ip, {127, 0, 0, 1}},
{access, all},
{host, gadget.jabber.sugarlabs.org, [{password, }]}]},
Your gadget.config should match these params.
Then don't forget to restart ejabberd to reload the new configuration.
This is what my jabber config looks like
{5560, ejabberd_service, [
{ip, {206, 192, 23, 224}},
{access, all},
{host, gadget.jabber.sugarlabs.org, [{password, }]}]},
and my gadget.config
server_host = 'jabber'
server_port = 5560
domain = 'sugarlabs.org'
password = ''
roster_path = 'gadget.roster'
Startup in log says
2009/04/08 15:52 -0400 [-] Log opened.
2009/04/08 15:52 -0400 [-] twistd 2.5.0 (/usr/bin/python 2.5.1) starting up
2009/04/08 15:52 -0400 [-] reactor class: class
'twisted.internet.selectreactor.SelectReactor'
2009/04/08 15:52 -0400 [-] Loading /usr/share/gadget/gadget.tac...
2009/04/08 15:52 -0400 [-] Loaded.
2009/04/08 15:52 -0400 [-] Starting factory
twisted.words.protocols.jabber.xmlstream.XmlStreamFactory instance at
0xa17c46c
2009/04/08 15:52 -0400 [Uninitialized] twisted.internet.tcp.Connector
instance at 0xa181b8c will retry in 2 seconds
2009/04/08 15:52 -0400 [Uninitialized] Stopping factory
twisted.words.protocols.jabber.xmlstream.XmlStreamFactory instance at
0xa17c46c
2009/04/08 15:52 -0400 [-] Starting factory
twisted.words.protocols.jabber.xmlstream.XmlStreamFactory instance at
0xa17c46c
2009/04/08 15:52 -0400 [Uninitialized] twisted.internet.tcp.Connector
instance at 0xa181b8c will retry in 5 seconds
2009/04/08 15:52 -0400 [Uninitialized] Stopping factory
twisted.words.protocols.jabber.xmlstream.XmlStreamFactory instance at
0xa17c46c
2009/04/08 15:52 -0400 [-] Starting factory
twisted.words.protocols.jabber.xmlstream.XmlStreamFactory instance at
0xa17c46c
2009/04/08 15:52 -0400 [Uninitialized] twisted.internet.tcp.Connector
instance at 0xa181b8c will retry in 16 seconds
2009/04/08 15:52 -0400 [Uninitialized] Stopping factory
twisted.words.protocols.jabber.xmlstream.XmlStreamFactory instance at
0xa17c46c
Thanks
Dave
G.
--
Dave Bauer
d...@solutiongrove.com
http://www.solutiongrove.com
___
Server-devel mailing list
Server-devel@lists.laptop.org
http://lists.laptop.org/listinfo/server-devel
