New joyride build 2230

2008-07-30 Thread Build Announcer v2
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

2008-07-30 Thread Greg Smith
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)

2008-07-30 Thread Greg Smith
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?

2008-07-30 Thread scott
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)

2008-07-30 Thread Bert Freudenberg

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

2008-07-30 Thread Victor Lazzarini
... 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

2008-07-30 Thread Bert Freudenberg

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

2008-07-30 Thread pgf
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

2008-07-30 Thread Daniel Drake
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)

2008-07-30 Thread Michael Stone
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

2008-07-30 Thread Eben Eliason
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

2008-07-30 Thread Erik Garrison
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

2008-07-30 Thread Morgan Collett
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

2008-07-30 Thread Michael Stone
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

2008-07-30 Thread Erik Garrison
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

2008-07-30 Thread Daniel Drake
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

2008-07-30 Thread Tomeu Vizoso
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

2008-07-30 Thread Tomeu Vizoso
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

2008-07-30 Thread Tomeu Vizoso
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

2008-07-30 Thread Eben Eliason
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

2008-07-30 Thread pgf
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

2008-07-30 Thread Deepak Saxena
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

2008-07-30 Thread Martin Dengler
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

2008-07-30 Thread pgf
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

2008-07-30 Thread Richard A. Smith
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

2008-07-30 Thread pgf
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

2008-07-30 Thread Deepak Saxena
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

2008-07-30 Thread Build Announcer v2
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?

2008-07-30 Thread Stan. SWAN
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)

2008-07-30 Thread Gary C Martin
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

2008-07-30 Thread Greg Smith
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)

2008-07-30 Thread Chris Marshall
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

2008-07-30 Thread pgf
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

2008-07-30 Thread Michael Stone
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?

2008-07-30 Thread scott
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

2008-07-30 Thread Richard A. Smith
[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...

2008-07-30 Thread Michael Stone
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

2008-07-30 Thread Michael Stone
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

2008-07-30 Thread Bastien
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

2008-07-30 Thread Michael Stone
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...

2008-07-30 Thread Martin Langhoff
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

2008-07-30 Thread Polychronis Ypodimatopoulos
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

2008-07-30 Thread Gary C Martin
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.

2008-07-30 Thread Stan. SWAN
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

2008-07-30 Thread Build Announcer v2
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?

2008-07-30 Thread Martin Langhoff
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

2008-07-30 Thread Ricardo Carrano
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.

2008-07-30 Thread scott


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

2008-07-30 Thread Martin Langhoff
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?

2008-07-30 Thread Martin Langhoff
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