Re: testing ejabberd
I've written up my recent testing of ejabberd for the wiki: http://wiki.laptop.org/go/Ejabberd_resource_tests It is not completely satisfactory: I don't have the resources to test up to 3000 active users which I believe is an important target. At lower numbers, however, ejabberd's memory consumption seems to be linear, and it looks to be roughly the case that 0.5 GB per 1000 users is enough. (Just barely -- that's a limit, not a recommendation). With 1200 users making some communication every 15 seconds, the 2GHz dual core pentium was bouncing along with a load average around 2 and ejabberd over 100% CPU usage. I don't know whether 15 seconds is a reasonable interval: if e.g. each keystroke in a shared Write touches ejabberd, then 15 seconds seems long; otherwise perhaps it's very short. Once I realised that the open files resource limit was killing ejabberd (which took an embarrassingly long time, not helped by cryptic log messages), it was stable under all loads. From time to time I tried sharing activities between XOs and they were always responsive. Douglas ___ Devel mailing list Devel@lists.laptop.org http://lists.laptop.org/listinfo/devel
hyperactivity limits
I wrote: It is not completely satisfactory: I don't have the resources to test up to 3000 active users which I believe is an important target. Just to clarify this: it was actually client resources I ran out of, not the server (though that must have been getting close to melt down). I used hyperactivity, but could only maintain about 250 connections from each instance. Guillaume: you mentioned somewhere that you had worked on a Gabble bug relating to hyperactivity, so I tried a git snapshot and got a recurring trace back with this punchline: dbus.exceptions.DBusException: org.freedesktop.Telepathy.Errors.NotImplemented: \ Unknown property BuddyGadgetAvailable on org.laptop.Telepathy.Gadget Do I need to replace other stuff than just Gabble? Or should I not bother yet? Is 250 connections in the order that you get? Perhaps my hyperactivity has issues all of its own. Douglas ___ Devel mailing list Devel@lists.laptop.org http://lists.laptop.org/listinfo/devel
Re: Signed candidate-765 and gg-765-2 builds available for testing.
Michael Stone wrote: I have decided to publish 8.2-765 as a signed Candidate http://download.laptop.org/xo-1/os/candidate/765/ (raw os) I reverted my signed (no-developer key) XO-1 back to build 650 (ship.1, 7.1.0) and did a ``olpc-update --usb`` to update to candidate-765. I had the expected issues of no sudo and having to update olpc-update itself, and it worked! This wasn't a perfect test because I didn't revert firmware as well, I was on latest q2e18 firmware throughout. I improved and simplified the early sections of http://wiki.laptop.org/go/olpc-update for the USB upgrade path. I noticed one slightly confusing thing. The line of text in a virtual terminal and in `cat /etc/issue` is: OLPC build 765 (stream 8.2; variant devel_jffs2) ^^^? ^? I guess this candidate stream isn't a real stream, it's just a special treatment of certain builds. But why is the variant called devel ? According to http://wiki.laptop.org/go/OS_images#Image_variants , devel Contains tools useful for developers of the OLPC operating system, including: yum, rpm, vim-minimal, openssh-server, xterm, which, file, tree, wget, xorg-x11-twm, gdb packages My OS only has some of those. I think these days there isn't a Normal image any more, just devel_? Will this variant devel_ go away when 8.2.0 moves to http://download.laptop.org/xo-1/os/official/ ? I see a newer http://download.laptop.org/xo-1/os/candidate/766/ ; Friends_in_testing still suggests candidate-765. http://download.laptop.org/xo-1/custom/g1g1/gg-765-2/ (G1G1 composite) I see a newer gg-766-3. But nobody has explained when or how you'd upgrade to a gg- build (is it for a clean-install with activities?), so I think it goes unmentioned on the wiki. Regards, -- =S Page user:skierpage ___ Devel mailing list Devel@lists.laptop.org http://lists.laptop.org/listinfo/devel
Re: hyperactivity limits
Le jeudi 02 octobre 2008 à 19:28 +1300, Douglas Bagnall a écrit : I wrote: Hi Douglas, It is not completely satisfactory: I don't have the resources to test up to 3000 active users which I believe is an important target. Just to clarify this: it was actually client resources I ran out of, not the server (though that must have been getting close to melt down). I used hyperactivity, but could only maintain about 250 connections from each instance. Guillaume: you mentioned somewhere that you had worked on a Gabble bug relating to hyperactivity, so I tried a git snapshot and got a recurring trace back with this punchline: Yeah, I discovered some vicious Gabble bugs when using hyperactivity. One of my fix [1] wasn't merged yet. I will ask to Daf to review it. dbus.exceptions.DBusException: org.freedesktop.Telepathy.Errors.NotImplemented: \ Unknown property BuddyGadgetAvailable on org.laptop.Telepathy.Gadget Sorry about that, I forgot to push my patch after the API change. Please update your hyperactivity with [2]. Do I need to replace other stuff than just Gabble? Or should I not bother yet? Is 250 connections in the order that you get? Perhaps my hyperactivity has issues all of its own. I also observed issues when running too much connections on the same Gabble instance (IIRC around 250 connections as you). I'll continue to test and try to fix more of them. For now, you can run multi instances of Gabble and hyperactivity. Hyperactivity doesn't support multi instances yet, so you'll have to make a full copy of it for each instance (don't forget to erase your accounts directory to create new ones). I should fix that too. G. [1] http://monkey.collabora.co.uk/telepathy-gabble_fix-tube/ [2] https://dev.laptop.org/git?p=users/guillaume/hyperactivity/.git;a=summary ___ Devel mailing list Devel@lists.laptop.org http://lists.laptop.org/listinfo/devel
Re: Walter Bender: Re: devkeys, prettyboot, and G1G1
On Thu, Oct 02, 2008 at 12:07:51AM -0400, Bobby Powers wrote: On Wed, Oct 1, 2008 at 10:35 PM, Edward Cherlin [EMAIL PROTECTED] wrote: I don't mind if the G1G1 donors have the option to participate in testing secured laptops, but I utterly reject the notion that we can jerk customer/donors around like this without their permission in advance. They _will_ complain publicly. While it is a SMALL hassle, I don't understand how it is jerking customers around before they've even bought a machine. As long as the policy (whatever it turns out to be) is clearly stated on the wiki/amazon site, by purchasing a laptop they are consenting to this. With that said, I would probably lean towards preferring unsecured machines (with pretty boot enabled, of course). Such small hassles, when repeated across hundreds of thousands of people, tend to eat up a lot of time. We should be trying to save users this time. I think we have sufficiently utilized G1G1 users to test our security system. My general perception is this test demonstrated that a significant fraction of users want unlocked laptops so that they can do interesting things. Even if the average user doesn't care about what an unlocked laptop allows them to do, what is the harm in shipping developer keys on all the G1G1 laptops? We'll save everyone who wants to install non-standard builds the time required to learn about and obtain developer keys. We'll save the support costs required to process and answer all the queries about developer keys. And we'll reduce the infrastructural costs of managing the generation of the keys. Erik ___ Devel mailing list Devel@lists.laptop.org http://lists.laptop.org/listinfo/devel
Re: [sugar] rendering test
Michel Dänzer wrote: As a result of ee7c684f21d, the PutImage hook in ShmFuncs is no longer being used. Shall I commit a cleanup? ShmPutImage is still accelerated though (also, that commit is only in 1.5, not 1.4). What kind of cleanup do you have in mind? Remove the unused PutImage hook from the ShmFuncs structure. Also maybe move the whole structure definition in the xserver as it doesn't seem like something that belongs to the public xextproto interface. -- \___/ Bernie Innocenti - http://www.codewiz.org/ _| X | Sugar Labs Team - http://www.sugarlabs.org/ \|_O_| It's an education project, not a laptop project! ___ Devel mailing list Devel@lists.laptop.org http://lists.laptop.org/listinfo/devel
Re: Walter Bender: Re: devkeys, prettyboot, and G1G1
+1 On Thu, Oct 2, 2008 at 9:45 AM, Erik Garrison [EMAIL PROTECTED] wrote: On Thu, Oct 02, 2008 at 12:07:51AM -0400, Bobby Powers wrote: On Wed, Oct 1, 2008 at 10:35 PM, Edward Cherlin [EMAIL PROTECTED] wrote: I don't mind if the G1G1 donors have the option to participate in testing secured laptops, but I utterly reject the notion that we can jerk customer/donors around like this without their permission in advance. They _will_ complain publicly. While it is a SMALL hassle, I don't understand how it is jerking customers around before they've even bought a machine. As long as the policy (whatever it turns out to be) is clearly stated on the wiki/amazon site, by purchasing a laptop they are consenting to this. With that said, I would probably lean towards preferring unsecured machines (with pretty boot enabled, of course). Such small hassles, when repeated across hundreds of thousands of people, tend to eat up a lot of time. We should be trying to save users this time. I think we have sufficiently utilized G1G1 users to test our security system. My general perception is this test demonstrated that a significant fraction of users want unlocked laptops so that they can do interesting things. Even if the average user doesn't care about what an unlocked laptop allows them to do, what is the harm in shipping developer keys on all the G1G1 laptops? We'll save everyone who wants to install non-standard builds the time required to learn about and obtain developer keys. We'll save the support costs required to process and answer all the queries about developer keys. And we'll reduce the infrastructural costs of managing the generation of the keys. Erik ___ Devel mailing list Devel@lists.laptop.org http://lists.laptop.org/listinfo/devel -- Walter Bender Sugar Labs http://www.sugarlabs.org ___ Devel mailing list Devel@lists.laptop.org http://lists.laptop.org/listinfo/devel
Preparation of 8.2 Final ECO Form
Hi Michael, Can you begin filling out the final ECO form for 8.2? I believe that entails updating this page: http://wiki.laptop.org/go/ECO/8.2.0/Checklist Let's build it with the assumption that 8.2-767 will be the release version. All systems are go according to the latest info I have. Quanta begins their final test Monday 10/6 and our official launch date (start of manufacturing, update of Wiki pages, sending out announcement e-mails, etc.) is Monday 10/13. I think we should have the ECO filled in and completed ASAP to be safe. Let me know what I can do to help. Thanks, Greg S ___ Devel mailing list Devel@lists.laptop.org http://lists.laptop.org/listinfo/devel
Re: Peru and Microsoft announcement
Hi SJ, quote who=Samuel Klein We don't have to frame it as us vs. them. We can just announce the state of current deployments, and discuss plans for future deployments and G1G1, including whatever can be said in public about the Microsoft trials. Everybody wants to know what's up with the Amazon deal, too. We could have a formulaic please check out our latest public announcements email, and a list that media orgs can sign up to to receive regular pointers to longer announcements. Something between the sporadic Press Release and the detailed weekly community-news blurbs. Yes, that'd be awesome. Perhaps a monthly digest with highlights from the community news, and anything that OLPC wants to communicate to the wide world. It was mentioned the community news has only 2000 subscribers. I didn't even know it was public although I've heard about it, and I've had people be tentative about forwarding it thinking it was an internal resource, so it probably needs to be promoted more as an open public resource, if that is it's purpose. I believe there is an internal newsletter, why doesn't OLPC have a monthly public news feed that is on the main website that talks about stuff happening which would give the world (and community trying to support OLPC) the information we all need :) The amount of times I've had people both from the FOSS community and the general community ask me what is going on is crazy, and damaging. And I'm not even on the inside, I'm just involved with some regional projects! As mentioned elsewhere, we have a community-news list (http://lists.laptop.org/listinfo/community-news), but it only goes out to some 2000 people. It might be valuable to have a list for shorter, more specific announcements that includes a regular link to the community-news archive, and any major essays or press pieces, which we can broadcast to a much larger audience. Definitely. An in which you can carefully message around the the successes and taboo topics to help people get it right. I think most of the problem at the moment is simply that people don't know what's going on half the time. If it is any help, Im sure there are many people in the community who would be happy to help (including me) with something like this, with keeping the general public and community informed in a more public fashion. There is generally a lot of good will towards the project around the world but real and positive public information is key to maintaining that good will. This is a good point. For instance, it would be useful to post and wikify the community-news archives on the wiki (this would both give them much higher google rank and help highlight red-links for a number of efforts, deployments, or concepts that deserve public descriptions but don't have their own page yet on our wiki). That'd be cool. It'd be great to have the latest post of community news and this regular update on the front page with a link to the subscriptions. Why don't you blog the updates so people can subscribe to the rss feed (and it can be aggregated OLPCnews.com for instance). Cheers, Pia -- OLPC Australia http://olpc.org.au/ Linux Australia http://linux.org.au/ Open Source Industry Australia http://osia.net.au/ Software Freedom Day http://softwarefreedomday.org/ Women hold up half the sky. - Mao Tse Tung ___ Devel mailing list Devel@lists.laptop.org http://lists.laptop.org/listinfo/devel
Major power concern
Hi all, I've just noticed that release candidate 765 when fully charged tells me I have 2 1/2 hours of usage. This is a major concern, and something we really need to fix for this release. As I tested it, it appeared to get about a minute or two to each percentage of battery. Below are some initial results as I know people want them sooner rather than later :) I was asked in #olpc to see if ohmd is running. It is. Anything else I can check for? I found that by default the power savings option was turned off. I turned it on for one of the test laptops below. All laptops were simply turned on and the mouse hovered over the battery symbol for status, no apps were run nor other activity run. The % is the indicated remaining battery time. Test 1 - default 765 image 765 started at (98%) fully charged 64% 1.48hrs remaining @ 65 mins running time 50% 1.24hrs remaining @ 98 mins running time 45% 1.16hrs remaining @ 108 mins running time Estiamted time = ~2 1/2 - 3hrs Test 2 - default 765 image but with power savings on 765 started at (93%) mostly charged with power savings turned on and rebooted 93% @ 0 mins running time 92% @ 2.35 10 mins running time 90% @ 2.32 35 mins running time 90% @ 2.32 41 mins running time 90% @ 2.32 50 mins running time Estimated full time = ~10hrs+ Test 3 - default 711 image 711 build started at (97%) fully charged (no percentage available) 94% @ 10 mins running time 89% @ 23 mins running time 84% @ 35 mins running time 73% @ 68 mins running time Estimated time = 4-5 hrs Please note these are initial results and I won't know for sure until another few hours for the first round, and a few repeats, but at least this gets other able to start testing :) This issue could be a major problem for this new release and if unfixed would seriously undermine the awesome efforts of all involved in the great changes for 8.2.0. Just for reference I've seen trials for primary schools with other devices and one of the main benefits of the XO over them was better power, so we need to maintain that :) If you are interested the other main reasons were screen size, the ease of prepacking a full suite of apps/content, the relative cost of the wireless infrastructure needed, and the community around OLPC. Cheers, Pia -- Linux Australia http://linux.org.au/ Open Source Industry Australia http://osia.net.au/ Software Freedom Day http://softwarefreedomday.org/ He who loves the world as his body may be entrusted with the empire. - Lao-tzu ___ Devel mailing list Devel@lists.laptop.org http://lists.laptop.org/listinfo/devel
Re: Walter Bender: Re: devkeys, prettyboot, and G1G1
On Thu, Oct 2, 2008 at 9:45 AM, Erik Garrison [EMAIL PROTECTED] wrote: On Thu, Oct 02, 2008 at 12:07:51AM -0400, Bobby Powers wrote: With that said, I would probably lean towards preferring unsecured machines (with pretty boot enabled, of course). Such small hassles, when repeated across hundreds of thousands of people, tend to eat up a lot of time. We should be trying to save users this time. As I said in June, afaic G1G1 machines should all be sent out with developer keys. http://lists.laptop.org/pipermail/security/2008-June/000426.html Kim made two related points: 1 - Assuming we get to the point where upgrading is an easy click from the G1G1 machine, then we want to be sure that people don't mistakenly load non-signed images. If you are not a developer; doesn't this add a level of protection that we want for 90% of G1G1 recipients? I don't think this is the sort of security people need -- again, those 90% aren't going to be trying updates in the first place. If we want to add a required --security=off flag to the olpc-update command to indicate that you recognize you are installing an unsecured build, that's fine. 2 - I believe our support issues will go up significantly as people who have little or no experience are encouraged to download all sorts of untested builds with no easy way to get back to a working system. To feel better about the support issues, I would like the one-button push that restores a laptop to factory default. I don't know about the former; the latter is a great idea. These feel to me like useful things to address for 8.2.1, though not for the initial g1g1 images. SJ We'll save everyone who wants to install non-standard builds the time required to learn about and obtain developer keys. We'll save the support costs required to process and answer all the queries about developer keys. And we'll reduce the infrastructural costs of managing the generation of the keys. Erik ___ 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
Perspective and Compromise Positions
John, Mitch, First, thanks for improving pretty-boot! Second, I have a suggestion for you: I have always regarded our various locks (software: firmware lock, activation lock, kernel lock, reflash lock, root password, minimal default ui; hardware: USB/SD slots, screws, solder-points) as reifications of the idea that our intended end users' desire to be responsible for maintaining their system falls along a continuum. You, and probably all the folks reading this list fall near one end of that spectrum whereas I am given to understand that most of our intended end users fall at the other end. Consequently, I have no particular moral, social, or economic difficulty recommending the current arrangement though, like Scott, I'm interested in making it easier for people to adapt the system they receive to better reflect their actual desires. However, perspective aside, a compromise position that would seem very reasonable to me would be to make the software shipped to G1G1 'happy to boot or NAND-flash anything' but unwilling to write the SPI flash without authorization. The compelling advantage of this position is that it would permit all of the diagnosis and most of the ease of use that you desire while still protecting OLPC from most of the risk presented by making it trivial to brick laptops manually (let alone in an automated, networked fashion, which I suspect would be doable in your current proposal). Thoughts? Michael P.S. - As others have suggested, please do not assume that any individual on this list speaks for everyone else involved; in almost all cases, they speak only for themselves (but for their clique with whatever measure of authority they happen to hold). P.P.S. - In my opinion, it would be necessary to slip the 8.2.0 schedule by at least a three weeks in order to make the change I suggest above; however, I'd be happy to try to help you push it into a future engineering change order. ___ Devel mailing list Devel@lists.laptop.org http://lists.laptop.org/listinfo/devel
Walter Bender: Re: devkeys, prettyboot, and G1G1
Mitch and I have come up with a way to ship G1G1 laptops so that they will pretty-boot, but still come from the factory without any need for developer keys (in the Forth disable-security setting). This requires a small edit to /boot/olpc.fth in the OS build, to load the XO child image, freeze the screen, and put the first progress dot down just before jumping to Linux. It's detailed here: http://dev.laptop.org/ticket/7896 I know the support crew would be much happier if G1G1 laptops were shipped able to run test builds and patched software, if users could interact with Forth to diagnose their hardware, if they could run unsigned Forth code from USB collector keys, etc. Unfortunately, an IRC discussion with Scott today revealed that the engineering team has decided that we *must* ship G1G1 laptops with a requirement for development keys. The reason: because too many kids in the third world will be getting lockdown laptops, and we want the G1G1 recipients to be guinea pigs to debug the laptops, to be sure the laptops work even when locked down (and that they unlock properly when the kid requests a jailbreak key). I see this is utterly backwards. The countries that want DRM on their laptops should be paying the price in support problems and infrastructure. Not the donors who sponsor a G1G1 laptop, and not the free software community who donate to help push this project along. As believers in freedom, we shouldn't be defaulting EVERY laptop to being locked by its manufacturer. Yet that's the argument: because some of them are locked, all of them must be locked. Or perhaps it's slightly more nuanced: A country that orders thousands can order them without DRM, but G1G1 users can't. That sounds reasonable, but I've interacted with several country teams (Nepal and South Pacific), who had come away from OLPC with the impression that it would be incredibly dangerous to turn off the security of the laptops. In Nepal's case I was unable to disabuse them of this odd notion. So no country asks for freedom in their laptop shipments, and no G1G1 is shipped with freedom, and thus every OLPC laptop is jailed, like every iPhone. John Date: Wed, 1 Oct 2008 08:34:09 -0400 From: Walter Bender [EMAIL PROTECTED] To: John Gilmore [EMAIL PROTECTED] Subject: Re: devkeys, prettyboot, and G1G1 Cc: Mitch Bradley [EMAIL PROTECTED] If Mitch is comfortable with his fix, I cannot see any reason not to ship developer keys with G1G1 machines--it would save everyone headaches, especially on support; but of course I cannot speak for OLPC these days. -walter On Tue, Sep 30, 2008 at 7:26 PM, John Gilmore [EMAIL PROTECTED] wrote: I recall discussing this last time but don't recall the reasons not to do it this way. We did ship them all pre-activated. I questioned people after the fateful meeting, and it seemed to me that the problem was that Nicholas wanted pretty-boot, and Mitch was unwilling to try to disentangle pretty-boot from secure-boot. Secure-boot was already a tangle of ugly Forth code, and he was sure that adding more complexity there would result in security holes or bugs. Since then, he has figured out the one-line circumvention that's documented in bug #7896. The circumvention is in the OS (since OFW keeps no state). John -- Walter Bender Sugar Labs http://www.sugarlabs.org ___ Devel mailing list Devel@lists.laptop.org http://lists.laptop.org/listinfo/devel
Re: Major power concern
Pia, From my reading of your description you ran the 765 and 711 test on 2 different machines and did not swap the battery between machines. Is this correct? If so there is a flaw in the methodology. You should ideally run all tests on the same machine with the same battery or at least use the same battery in both machines for the test. To determine if it is a battery problem follow the instructions for using opc-pwr-log. (This should be pre-installed on 757). The instructions are at: http://wiki.laptop.org/go/XO_LiFePO4_Recovery_Procedure /Robert H. On Oct 2, 2008, at 3:53 PM, Pia Waugh wrote: Hi all, I've just noticed that release candidate 765 when fully charged tells me I have 2 1/2 hours of usage. This is a major concern, and something we really need to fix for this release. As I tested it, it appeared to get about a minute or two to each percentage of battery. Below are some initial results as I know people want them sooner rather than later :) I was asked in #olpc to see if ohmd is running. It is. Anything else I can check for? I found that by default the power savings option was turned off. I turned it on for one of the test laptops below. All laptops were simply turned on and the mouse hovered over the battery symbol for status, no apps were run nor other activity run. The % is the indicated remaining battery time. Test 1 - default 765 image 765 started at (98%) fully charged 64% 1.48hrs remaining @ 65 mins running time 50% 1.24hrs remaining @ 98 mins running time 45% 1.16hrs remaining @ 108 mins running time Estiamted time = ~2 1/2 - 3hrs Test 2 - default 765 image but with power savings on 765 started at (93%) mostly charged with power savings turned on and rebooted 93% @ 0 mins running time 92% @ 2.35 10 mins running time 90% @ 2.32 35 mins running time 90% @ 2.32 41 mins running time 90% @ 2.32 50 mins running time Estimated full time = ~10hrs+ Test 3 - default 711 image 711 build started at (97%) fully charged (no percentage available) 94% @ 10 mins running time 89% @ 23 mins running time 84% @ 35 mins running time 73% @ 68 mins running time Estimated time = 4-5 hrs Please note these are initial results and I won't know for sure until another few hours for the first round, and a few repeats, but at least this gets other able to start testing :) This issue could be a major problem for this new release and if unfixed would seriously undermine the awesome efforts of all involved in the great changes for 8.2.0. Just for reference I've seen trials for primary schools with other devices and one of the main benefits of the XO over them was better power, so we need to maintain that :) If you are interested the other main reasons were screen size, the ease of prepacking a full suite of apps/content, the relative cost of the wireless infrastructure needed, and the community around OLPC. Cheers, Pia -- Linux Australia http:// linux.org.au/ Open Source Industry Australia http:// osia.net.au/ Software Freedom Day http:// softwarefreedomday.org/ He who loves the world as his body may be entrusted with the empire. - Lao-tzu ___ 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: Walter Bender: Re: devkeys, prettyboot, and G1G1
How about providing dev. keys for G1G1 laptops with no delay ?Would you consider it an improvement ? wad On Oct 1, 2008, at 10:15 PM, John Gilmore wrote: Mitch and I have come up with a way to ship G1G1 laptops so that they will pretty-boot, but still come from the factory without any need for developer keys (in the Forth disable-security setting). This requires a small edit to /boot/olpc.fth in the OS build, to load the XO child image, freeze the screen, and put the first progress dot down just before jumping to Linux. It's detailed here: http://dev.laptop.org/ticket/7896 I know the support crew would be much happier if G1G1 laptops were shipped able to run test builds and patched software, if users could interact with Forth to diagnose their hardware, if they could run unsigned Forth code from USB collector keys, etc. Unfortunately, an IRC discussion with Scott today revealed that the engineering team has decided that we *must* ship G1G1 laptops with a requirement for development keys. The reason: because too many kids in the third world will be getting lockdown laptops, and we want the G1G1 recipients to be guinea pigs to debug the laptops, to be sure the laptops work even when locked down (and that they unlock properly when the kid requests a jailbreak key). I see this is utterly backwards. The countries that want DRM on their laptops should be paying the price in support problems and infrastructure. Not the donors who sponsor a G1G1 laptop, and not the free software community who donate to help push this project along. As believers in freedom, we shouldn't be defaulting EVERY laptop to being locked by its manufacturer. Yet that's the argument: because some of them are locked, all of them must be locked. Or perhaps it's slightly more nuanced: A country that orders thousands can order them without DRM, but G1G1 users can't. That sounds reasonable, but I've interacted with several country teams (Nepal and South Pacific), who had come away from OLPC with the impression that it would be incredibly dangerous to turn off the security of the laptops. In Nepal's case I was unable to disabuse them of this odd notion. So no country asks for freedom in their laptop shipments, and no G1G1 is shipped with freedom, and thus every OLPC laptop is jailed, like every iPhone. John Date: Wed, 1 Oct 2008 08:34:09 -0400 From: Walter Bender [EMAIL PROTECTED] To: John Gilmore [EMAIL PROTECTED] Subject: Re: devkeys, prettyboot, and G1G1 Cc: Mitch Bradley [EMAIL PROTECTED] If Mitch is comfortable with his fix, I cannot see any reason not to ship developer keys with G1G1 machines--it would save everyone headaches, especially on support; but of course I cannot speak for OLPC these days. -walter On Tue, Sep 30, 2008 at 7:26 PM, John Gilmore [EMAIL PROTECTED] wrote: I recall discussing this last time but don't recall the reasons not to do it this way. We did ship them all pre-activated. I questioned people after the fateful meeting, and it seemed to me that the problem was that Nicholas wanted pretty-boot, and Mitch was unwilling to try to disentangle pretty-boot from secure-boot. Secure-boot was already a tangle of ugly Forth code, and he was sure that adding more complexity there would result in security holes or bugs. Since then, he has figured out the one-line circumvention that's documented in bug #7896. The circumvention is in the OS (since OFW keeps no state). John -- Walter Bender Sugar Labs http://www.sugarlabs.org [gnu: I also cc'd this to support-gang, but that required sending it from a different email address, due to how I am subscribed there.] ___ 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: Major power concern
Hi all, On Thu, 2 Oct 2008 20:41:15 -0700, Robert Howard [EMAIL PROTECTED] wrote: From my reading of your description you ran the 765 and 711 test on 2 different machines and did not swap the battery between machines. Is this correct? If so there is a flaw in the methodology. You should ideally run all tests on the same machine with the same battery or at least use the same battery in both machines for the test. I did the same test for 765 on two new machines with almost identical results. The 765p and 711 tests were for comparison and I know I need to do further testing but wanted to raise the flag asap considering the image is to be released soon and his could be a big issue. This was advised on #olpc. To determine if it is a battery problem follow the instructions for using opc-pwr-log. (This should be pre-installed on 757). The instructions are at: http://wiki.laptop.org/go/XO_LiFePO4_Recovery_Procedure Will do and will post results. Cheers, Pia ___ Devel mailing list Devel@lists.laptop.org http://lists.laptop.org/listinfo/devel
Re: Walter Bender: Re: devkeys, prettyboot, and G1G1
On Fri, Oct 03, 2008 at 12:27:48AM -0400, John Watlington wrote: How about providing dev. keys for G1G1 laptops with no delay ?Would you consider it an improvement ? I would consider it a mediocre usability improvement in exchange for a moderate security risk -- it fails to permit any simplification of the testing instructions while permanently increasing the opportunity for Murphy to strike by causing us to treat some SNs separately from others and by removing opportunity for review and intervention. At best, it provides 'instant gratification' by taking the currently manual process of 'asking for your devkey quickly' to its logical extreme. On the other hand, I suppose it's worth considering since it's only an administrative change. Do you have a different analysis of its merits? Do you weigh the risk of autogenerating devkeys for stolen laptops differently than I do? Michael ___ Devel mailing list Devel@lists.laptop.org http://lists.laptop.org/listinfo/devel
Re: Walter Bender: Re: devkeys, prettyboot, and G1G1
On Thu, Oct 2, 2008 at 1:59 PM, John Gilmore [EMAIL PROTECTED] wrote: I see this is utterly backwards. The countries that want $feature on their laptops should be paying the price in support problems and infrastructure. I've edited your quote a bit. G1G1 participants support us is many ways, one of them being early users of many features that are mainly targetted to our XO users in deployment/pilot countries. The DRM stuff is a feature of many that falls within this list. That's all I wanted to clarify, _many_ things on G1G1 are not there for the G1G1 donors, and would be hard to justify if we looked at them as primary targets. So this is not 'backwards', it's our modus operandi. You can argue for an exception here -- perhaps this feature is specially painful or burdensome for G1G1. Let's keep the perspective straight. Note: I don't have an opinion either way WRT DRM on G1G1 machines, and haven't participated in any discussions about it, so not familiar with the arguments pro and against. 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 ___ Devel mailing list Devel@lists.laptop.org http://lists.laptop.org/listinfo/devel
Re: [Server-devel] testing ejabberd
I've written up my recent testing of ejabberd for the wiki: http://wiki.laptop.org/go/Ejabberd_resource_tests It is not completely satisfactory: I don't have the resources to test up to 3000 active users which I believe is an important target. At lower numbers, however, ejabberd's memory consumption seems to be linear, and it looks to be roughly the case that 0.5 GB per 1000 users is enough. (Just barely -- that's a limit, not a recommendation). With 1200 users making some communication every 15 seconds, the 2GHz dual core pentium was bouncing along with a load average around 2 and ejabberd over 100% CPU usage. I don't know whether 15 seconds is a reasonable interval: if e.g. each keystroke in a shared Write touches ejabberd, then 15 seconds seems long; otherwise perhaps it's very short. Once I realised that the open files resource limit was killing ejabberd (which took an embarrassingly long time, not helped by cryptic log messages), it was stable under all loads. From time to time I tried sharing activities between XOs and they were always responsive. Douglas ___ Server-devel mailing list Server-devel@lists.laptop.org http://lists.laptop.org/listinfo/server-devel
[Server-devel] hyperactivity limits
I wrote: It is not completely satisfactory: I don't have the resources to test up to 3000 active users which I believe is an important target. Just to clarify this: it was actually client resources I ran out of, not the server (though that must have been getting close to melt down). I used hyperactivity, but could only maintain about 250 connections from each instance. Guillaume: you mentioned somewhere that you had worked on a Gabble bug relating to hyperactivity, so I tried a git snapshot and got a recurring trace back with this punchline: dbus.exceptions.DBusException: org.freedesktop.Telepathy.Errors.NotImplemented: \ Unknown property BuddyGadgetAvailable on org.laptop.Telepathy.Gadget Do I need to replace other stuff than just Gabble? Or should I not bother yet? Is 250 connections in the order that you get? Perhaps my hyperactivity has issues all of its own. Douglas ___ Server-devel mailing list Server-devel@lists.laptop.org http://lists.laptop.org/listinfo/server-devel
Re: [Server-devel] What's cooking in the XS pot this week (2008-10--01)
Greg, We will be setting up two labs here in Nepal, one in the next couple weeks and likely one in the first week of November at Nepal's Dept of Education. Depending on our experiences in those labs, we want to roll out a new version of the XS in November to our two pilot schools and possibly a new pilot school. This mirrors our priorities A stable and scalable eJabber is critical as are basic XS features like: - Caching - Filtering (is DanGuardian built in and shipped with the XS ?) - NAT w/ two exceptions. We still find it a bear to install the XS from scratch. That could be our fault but it needs to be easier to set up ejabberd properly. It also needs to be easier to get dansguardian up and running. As far as I can tell dansguardian is not pre-installed on the XS in XS 0.4. Our volunteer Tony Anderson has been working on this and has a better understanding of the problems we are having. I strongly agree that, while Moodle is important, a lot of work needs to be done on ejabberd and dansguardian. Message: 1 Date: Wed, 01 Oct 2008 12:42:19 -0400 From: Greg Smith [EMAIL PROTECTED] Subject: Re: [Server-devel] What's cooking in the XS pot this week (2008-10--01) To: Martin Langhoff [EMAIL PROTECTED] Cc: XS Devel server-devel@lists.laptop.org Message-ID: [EMAIL PROTECTED] Content-Type: text/plain; charset=ISO-8859-1; format=flowed Hi Martin, Thanks for the update! Its great to see all the items planned for or in 0.5: http://dev.laptop.org/query?status=assignedstatus=closedstatus=newstatus=reopenedorder=prioritycol=idcol=summarycol=statuscol=typecol=prioritycol=componentmilestone=xs-0.5 On your question of who is waiting for XS 0.5, I know of at least two deployments that are building labs and testing configurations with XS software: Paraguay Birmingham Both will need a stable XS that they can use ASAP. Whether they will go with XS 0.5 or not depends on what 0.5 includes, when 0.6 will be available and what it includes. AFAIK Moodle is not a must have item for either deployment. A stable and scalable eJabber is critical as are basic XS features like: - Caching - Filtering (is DanGuardian built in and shipped with the XS ?) - NAT Birmingham may start using XOs and an XS in schools in mid-Novemeber. Paraguay will probably start later but we should lock down their version ASAP as they want lead time to really flush out all issue in the lab. They may both use the backup and restore feature if they have enough disk on the server (of course they will use it whether they like it or not as you can't turn it off :-). I think there other deployments that will want to use a school server before the end of 2008. Two other features which may tip the balance for deployments are upgrade of XO images and activities via school server cache (Peru). Spending a little more time to make sure that XS 0.5 is very stable and well documented is a good idea. However, we should start to be more precise about the features and dates for each release we plan to deliver before the end of CY 08. Thanks, Greg S ___ Server-devel mailing list Server-devel@lists.laptop.org http://lists.laptop.org/listinfo/server-devel
Re: [Server-devel] What's cooking in the XS pot this week (2008-10--01)
Wad, you're right that Dansguardian is a can of worms but it is a very important can of worms that needs to work w/ minimal configuration, at least initially. I would say that the initial install should set a medium level of restriction and then leave it to the local deployment teams to tweak it to cultural norms. On Fri, 2008-10-03 at 00:17 -0400, John Watlington wrote: On Oct 2, 2008, at 11:51 PM, Bryan Berry wrote: Greg, We will be setting up two labs here in Nepal, one in the next couple weeks and likely one in the first week of November at Nepal's Dept of Education. Depending on our experiences in those labs, we want to roll out a new version of the XS in November to our two pilot schools and possibly a new pilot school. This mirrors our priorities A stable and scalable eJabber is critical as are basic XS features like: - Caching - Filtering (is DanGuardian built in and shipped with the XS ?) - NAT w/ two exceptions. We still find it a bear to install the XS from scratch. That could be our fault but it needs to be easier to set up ejabberd properly. It also needs to be easier to get dansguardian up and running. As far as I can tell dansguardian is not pre-installed on the XS in XS 0.4. What default permissions should be provided for DansGuardian ? What list of banned sites and keywords ? No real disagreement. But one of the issues with DansGuardian is that the configuration reflects local mores, and it is difficult to provide a default. How do we ensure that a deployment provides the configuration files ? Cheers, wad ___ Server-devel mailing list Server-devel@lists.laptop.org http://lists.laptop.org/listinfo/server-devel
Re: [Server-devel] What's cooking in the XS pot this week (2008-10--01)
On Thu, Oct 2, 2008 at 5:42 AM, Greg Smith [EMAIL PROTECTED] wrote: On your question of who is waiting for XS 0.5, I know of at least two deployments that are building labs and testing configurations with XS software: Paraguay Birmingham Those two appear to be a bit later. We can probably get 0.6 out the door for them mid-november-ish, with a few more end-user features :-) Actually, this is good so we now know the target date for xs-0.6 should be early-to-mid Nov. AFAIK Moodle is not a must have item for either deployment. Well, a UI for the XS will be a must-have for them, and that is based on Moodle, so... A stable and scalable eJabber is critical as are basic XS features like: - Caching - NAT those are in - Filtering (is DanGuardian built in and shipped with the XS ?) that's not in 0.5 - we can prioritise for 0.6. Spending a little more time to make sure that XS 0.5 is very stable and well documented is a good idea. Just a little time... 0.5 is base frameworks, some basic features, 0.6 is the now we add useful features release. However, we should start to be more precise about the features and dates for each release we plan to deliver before the end of CY 08. so far I'm hoping to keep my cards close to my chest for 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
Re: [Server-devel] What's cooking in the XS pot this week (2008-10--01)
I don't have time currently to work on this but I will ask Tony and our interns Avash and Aakash to work on this. On Fri, 2008-10-03 at 00:37 -0400, John Watlington wrote: Perhaps you want to suggest a specific set of configuration files that provides what you consider a medium level of restriction, including blacklists ? wad On Oct 3, 2008, at 12:31 AM, Bryan Berry wrote: Wad, you're right that Dansguardian is a can of worms but it is a very important can of worms that needs to work w/ minimal configuration, at least initially. I would say that the initial install should set a medium level of restriction and then leave it to the local deployment teams to tweak it to cultural norms. On Fri, 2008-10-03 at 00:17 -0400, John Watlington wrote: On Oct 2, 2008, at 11:51 PM, Bryan Berry wrote: Greg, We will be setting up two labs here in Nepal, one in the next couple weeks and likely one in the first week of November at Nepal's Dept of Education. Depending on our experiences in those labs, we want to roll out a new version of the XS in November to our two pilot schools and possibly a new pilot school. This mirrors our priorities A stable and scalable eJabber is critical as are basic XS features like: - Caching - Filtering (is DanGuardian built in and shipped with the XS ?) - NAT w/ two exceptions. We still find it a bear to install the XS from scratch. That could be our fault but it needs to be easier to set up ejabberd properly. It also needs to be easier to get dansguardian up and running. As far as I can tell dansguardian is not pre-installed on the XS in XS 0.4. What default permissions should be provided for DansGuardian ? What list of banned sites and keywords ? No real disagreement. But one of the issues with DansGuardian is that the configuration reflects local mores, and it is difficult to provide a default. How do we ensure that a deployment provides the configuration files ? Cheers, wad ___ Server-devel mailing list Server-devel@lists.laptop.org http://lists.laptop.org/listinfo/server-devel
Re: [Server-devel] What's cooking in the XS pot this week (2008-10--01)
On Fri, 2008-10-03 at 18:09 +1300, Martin Langhoff wrote: On Fri, Oct 3, 2008 at 4:51 PM, Bryan Berry [EMAIL PROTECTED] wrote: We will be setting up two labs here in Nepal, one in the next couple weeks and likely one in the first week of November at Nepal's Dept of Education. Depending on our experiences in those labs, we want to roll out a new version of the XS in November to our two pilot schools and possibly a new pilot school. I'm very interested in hearing about those experiences. this depends on how much progress Tony can make. Unfortunately, too much management crap and talking w/ donors keeps me from spending enough time on the XS w/ two exceptions. We still find it a bear to install the XS from scratch. That could be our fault but it needs to be easier to set up ejabberd properly. It also needs to be easier to get dansguardian up and running. As far as I can tell dansguardian is not pre-installed on the XS in XS 0.4. How happy are you with DanGuardian? Is it a useful filter? We use it internally w/in our office and we are happy w/ it. We use it locally to eat our own dog food. By default it blocks a lot if not most content on the Internet, including stuff that doesn't seem objectionable at all. I think dans is essential because it will keep the adults from using up all the bandwidth to look at porn. the secondary reason, to protect kids is also important ;) In terms of install we have some proposed patches to the ejabberd config issues, so it's likely to be sorted in 0.5 or 0.6. Our volunteer Tony Anderson has been working on this and has a better understanding of the problems we are having. Right - keen on hearing your notes Tony :-) Also - as discussed with Wad, I'll be interested in suggestions on how to handle the local rulemaking both for small pilots and large deployments. cheers. m ___ Server-devel mailing list Server-devel@lists.laptop.org http://lists.laptop.org/listinfo/server-devel
Re: [Server-devel] What's cooking in the XS pot this week (2008-10--01)
On Fri, Oct 3, 2008 at 6:22 PM, Bryan Berry [EMAIL PROTECTED] wrote: How happy are you with DanGuardian? Is it a useful filter? We use it internally w/in our office and we are happy w/ it. We use it locally to eat our own dog food. By default it blocks a lot if not most content on the Internet, including stuff that doesn't seem objectionable at all. Yeah, that's one of my concerns. I looked a little bit at DG documentation a few days ago, as I was fighting with Squid's memory usage, to understand how resource intensive it is, and how it works. And in the back of my mind the question was - is this the right tool? When you mention it blocks most content, I'm less than thrilled. A filter that is too blunt will actually backfire -- will be too easy to false-match and also easy to workaround. Users will learn something but perhaps not what we want. A smarter filter, one that does not give all/most users an incentive to find workarounds, is a much healthier solution. But I'll get deep into it later, more likely in the 0.6 cycle. Now that you mention you're using it in a real life setup, what does top tell you about its memory usage? I think dans is essential because it will keep the adults from using up all the bandwidth to look at porn. the secondary reason, to protect kids is also important ;) Noble causes indeed! 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
