Re: SD card flashing time

[Martin Langhoff]

On Thu, Sep 16, 2010 at 7:53 PM, James Cameron  wrote:
> I agree, this should work.  It seems about the same amount of work as
> building all images small and resizing them up on first boot.

Indeed.

The core idea that is interesting is having the "firstboot" be a
"special boot" that execs while still in the warehouse, instead of in
kids' hands.

Lowers risk significantly.

Maybe from a separate initrams, or from the standard one (resize2fs
and its libs aren't that large).



m
-- 
 martin.langh...@gmail.com
 mar...@laptop.org -- School Server Architect
 - ask interesting questions
 - don't get distracted with shiny stuff  - working code first
 - http://wiki.laptop.org/go/User:Martinlanghoff
___
Devel mailing list
Devel@lists.laptop.org
http://lists.laptop.org/listinfo/devel

Re: FREE OLPC Repair+Training FEST - Cambridge, Mass - Sat Sept 18, NOON-3PM

[Holt]

Awesome we've a dozen+ truly wonderful RSVPs for Saturday's Clinic: 
coming from as far away as 7hrs down the road in Rochester NY (go 
http://foss.rit.edu/blog !), New Jersey, and even some exotic land 
called CaliFilippines, but can you guess the Furthest?? (*)


OLPC's VP of Hardware Engineering is working with me to find some really 
cool door prizes as a result, so no this ain't Cuba where even BIC 
lighters are repaired, but nor did we imagine how successful this 
skillbuilding/videomaking event (helping Palestinian kids & beyond) 
would become.../welcome All Olin College students :)/


And with particular apologies to those atoning as part of Yom Kippur who 
cannot participate this Saturday, I dearly hope all can participate 
online later -- empowering overlooked+marginalized kids in all countries 
-- with our growing library of How-To-Vids that I'd *love* for someone 
to step forward and begin curating, organizing the best here just like 
Wikipedia does?


   http://wiki.laptop.org/go/Disassembly

Thanks & See Y'all Soon, Saturday Noon, working fast to earn your free 
lunch!


(*) sorry Philippines SuperCherry @ 
http://queakland.org/about/people/bio.jsp?id=60 we actually have several 
great volunteers from Kazakhstan arriving; wonderful folks whose names 
are *not* Borat, but might give you all your first taste of Kazakh 
Cuisine ;)



Holt wrote:

Be there or be square, at an event that might never happen again--
don't miss your rock star trainers who will be:

   _Ian Daniher_: *pioneered the OLPC Community
   Repair Center* in the spring of 2007, inspiring
   many others around the world here:
   http://wiki.laptop.org/go/Repair_center_locations

   _Richard Smith_: *invented half this stuff*, anything and
   everything XO, XO-1.5 and beyond, nevermind
   you can't find a friendlier guy (north of Arkansas;
   with apologies to Mary Lou Jepsen who May have
   invented even more ;)

Come walk through the XO-1 de-bricking process, *learning critical
repair techniques* like this to protect your own XO investment and
helping tons of others globally, if the screen ever stops working etc:

   http://wiki.laptop.org/go/Fix_clock
   http://olpc-france.org/blog/2010/09/date-systeme-invalide/

We'll also produce some *awesome new videos* for upcoming OLPC
deployments in the Midde East, meeting some of this region's
http://wiki.laptop.org/go/The_*Learning_Team* as well as surveying some
brand new XO-1.5 repair tricks!

   When:  12 Noon to 3PM
   Saturday, September 18

   Where: OLPC Headquarters
   1 Cambridge Center, 10th Floor
   Kendall Square / MIT Red Line Subway Stop
   Cambridge, Massachusetts

   Lunch:  Included *if* you help de-brick at least 2 XOs,
   for use by dedicated OLPC volunteers worldwide:
   http://wiki.laptop.org/go/Contributors_program

   RSVP: ALL WELCOME, families/friends and all ages,
   but you must reply to holt @ laptop . org
   (including your phone number, thanks)

/   Price:   Enthusiasm -- Smile or you will NOT be admitted to OLPC!!/

Aside from our upcoming *Oct 21/22 - 24 San Francisco Community Summit*
(details *imminent* at http://olpcsf.org/CommunitySummit2010 ) you
will NOT find a more committed group of volunteer *fixers, tinkerers &
doers*, anywhere on our reduced, reused and recycled planet.
Thank you for joining in 5 days; Thanks for keeping it Real!
___
Devel mailing list
Devel@lists.laptop.org
http://lists.laptop.org/listinfo/devel

Re: SD card flashing time

[James Cameron]

On Thu, Sep 16, 2010 at 07:28:39PM -0400, Martin Langhoff wrote:
> On Thu, Sep 16, 2010 at 7:01 PM, James Cameron  wrote:
> > No, certainly not. ?There's no justification for either mke2fs or
> > resize2fs to write to blocks that do not form part of the filesystem
> > metadata. ?Why would you want to zero-out blocks anyway?
> 
> Thinking of a deployment trying minimize reflash times.

Make sure to mention NANDblaster.

> What if they have a signed Forth script to run on a USB stick that... ?
> 
>  - runs fs-update u:\myimage.zd -- a "small-sized" img
>  - boots a signed kernel and signed initramfs from the USB stick --
> where the initramfs just executes resize2fs, prints success/failure
> and waits to be switched off

I agree, this should work.  It seems about the same amount of work as
building all images small and resizing them up on first boot.

-- 
James Cameron
http://quozl.linux.org.au/
___
Devel mailing list
Devel@lists.laptop.org
http://lists.laptop.org/listinfo/devel

Re: SD card flashing time

[Mitch Bradley]

On 9/16/2010 1:28 PM, Martin Langhoff wrote:
> On Thu, Sep 16, 2010 at 7:01 PM, James Cameron  wrote:
>> No, certainly not.  There's no justification for either mke2fs or
>> resize2fs to write to blocks that do not form part of the filesystem
>> metadata.  Why would you want to zero-out blocks anyway?
> Thinking of a deployment trying minimize reflash times.
>
> What if they have a signed Forth script to run on a USB stick that... ?
>
>   - runs fs-update u:\myimage.zd -- a "small-sized" img
>   - boots a signed kernel and signed initramfs from the USB stick --
> where the initramfs just executes resize2fs, prints success/failure
> and waits to be switched off

That would probably work.

> cheers,
>
>
>
> m
___
Devel mailing list
Devel@lists.laptop.org
http://lists.laptop.org/listinfo/devel

Re: SD card flashing time

[Martin Langhoff]

On Thu, Sep 16, 2010 at 7:01 PM, James Cameron  wrote:
> No, certainly not.  There's no justification for either mke2fs or
> resize2fs to write to blocks that do not form part of the filesystem
> metadata.  Why would you want to zero-out blocks anyway?

Thinking of a deployment trying minimize reflash times.

What if they have a signed Forth script to run on a USB stick that... ?

 - runs fs-update u:\myimage.zd -- a "small-sized" img
 - boots a signed kernel and signed initramfs from the USB stick --
where the initramfs just executes resize2fs, prints success/failure
and waits to be switched off

cheers,



m
-- 
 martin.langh...@gmail.com
 mar...@laptop.org -- School Server Architect
 - ask interesting questions
 - don't get distracted with shiny stuff  - working code first
 - http://wiki.laptop.org/go/User:Martinlanghoff
___
Devel mailing list
Devel@lists.laptop.org
http://lists.laptop.org/listinfo/devel

Re: #10363 NORM 10.1.3: Auto-Suspend gets in the way when sharing over Salut

[James Cameron]

On Thu, Sep 16, 2010 at 05:38:29PM -0400, Martin Langhoff wrote:
> 2 - hack the Tubes/Telepathy stack to _prevent sleep_ while an actual
> collaboration session is running

This might help.  Once an activity is shared, the laptop stays awake
until the activity is stopped.

(sugar-toolkit.git)
--- a/src/sugar/activity/activity.py
+++ b/src/sugar/activity/activity.py
@@ -916,6 +916,14 @@ class Activity(Window, gtk.Container):
 self._share_id = self._pservice.connect("activity-shared", 
 self.__share_cb)
 self._pservice.share_activity(self, private=private)
+# inhibit suspend during sharing
+path = '/var/run/powerd-inhibit-suspend/%s' % os.getpid()
+try:
+fd = open(path, 'w')
+except IOError:
+pass
+else:
+fd.close()
 
 def _show_keep_failed_dialog(self):
 alert = Alert()

-- 
James Cameron
http://quozl.linux.org.au/
___
Devel mailing list
Devel@lists.laptop.org
http://lists.laptop.org/listinfo/devel

Re: SD card flashing time

[James Cameron]

On Thu, Sep 16, 2010 at 05:42:03PM -0400, Martin Langhoff wrote:
> On Thu, Sep 16, 2010 at 2:15 AM, James Cameron  wrote:
> > What is interesting about the filesystem result is that it takes longer
> > despite writing far less data; 1.6 GB out of 4 GB. ?And there was no
> > ext3 journal involved during the write.
> 
> But probably a lot of fs updates.

Redundant writes of filesystem metadata, yes.

> >> That'd be more fair
> > I wasn't trying to be fair, I was trying to win.
> 
> I like that.
> 
> I am still very curious about resize behaviour. Does resize2fs
> zero-out the blocks?

No, certainly not.  There's no justification for either mke2fs or
resize2fs to write to blocks that do not form part of the filesystem
metadata.  Why would you want to zero-out blocks anyway?

-- 
James Cameron
http://quozl.linux.org.au/
___
Devel mailing list
Devel@lists.laptop.org
http://lists.laptop.org/listinfo/devel

Re: SD card flashing time

[Martin Langhoff]

On Thu, Sep 16, 2010 at 2:15 AM, James Cameron  wrote:
> What is interesting about the filesystem result is that it takes longer
> despite writing far less data; 1.6 GB out of 4 GB.  And there was no
> ext3 journal involved during the write.

But probably a lot of fs updates.

>> That'd be more fair
> I wasn't trying to be fair, I was trying to win.

I like that.

I am still very curious about resize behaviour. Does resize2fs
zero-out the blocks?

cheers,


m
-- 
 martin.langh...@gmail.com
 mar...@laptop.org -- School Server Architect
 - ask interesting questions
 - don't get distracted with shiny stuff  - working code first
 - http://wiki.laptop.org/go/User:Martinlanghoff
___
Devel mailing list
Devel@lists.laptop.org
http://lists.laptop.org/listinfo/devel

Re: #10363 NORM 10.1.3: Auto-Suspend gets in the way when sharing over Salut

[Martin Langhoff]

On Thu, Sep 16, 2010 at 5:05 AM, Tomeu Vizoso  wrote:
> So the problem is that if you had to resync all state for each machine
> every time they wake up, you would use lots of bandwidth with the
(...)
> Another issue with this is that you not only want to resync presence,
> but shared activities also would need to resync their state.

Correct. My notes on the bug are probably unreadable -- it was late
last night, apologies.

What I mean to say is that we could

1 - explore the interaction between sleep timeouts and Salut resync
frequency for presence

2 - hack the Tubes/Telepathy stack to _prevent sleep_ while an actual
collaboration session is running

I think #1 needs to be done regardless, as it'll improve behaviour
even if/when we our networking/suspend issues sorted. And some of the
issues in network/suspend interaction won't be easy to resolve.

cheers,



m
-- 
 martin.langh...@gmail.com
 mar...@laptop.org -- School Server Architect
 - ask interesting questions
 - don't get distracted with shiny stuff  - working code first
 - http://wiki.laptop.org/go/User:Martinlanghoff
___
Devel mailing list
Devel@lists.laptop.org
http://lists.laptop.org/listinfo/devel

Learning by Playing

[Carlos Nazareno]

Hi guys. Interesting paradigm-changing case studies of video game use
in elementary classrooms + curricula & how today's tech-savvy children
are different. (NY Times free registration required)

Learning by Playing: Video Games Win a Beachhead in the Classroom
http://www.nytimes.com/2010/09/19/magazine/19video-t.html

I don't agree with some of the things in the article (horrific stuff
such as doing away with handwriting and spelling), but there there are
many interesting tidbits in there such as “failure-based learning”:

Quote:
"children who persist in playing a game are demonstrating a valuable
educational ideal. “They play for five minutes and they lose,” he
says. “They play for 10 minutes and they lose. They’ll go back and do
it a hundred times. They’ll fail until they win.” He adds: “Failure in
an academic environment is depressing. Failure in a video game is
pleasant. It’s completely aspirational.”

-
On the subject of handwriting, I think the rise of tablets &
touchscreens may bring a new revival of penmanship (at least with
block print). The increasing non-standardization of keyboards due to
the plethora of computer & device form factors is actually destroying
touch-typing & making it obsolete. (IMHO, mobile is the future of
computing)

Don't you guys find the system of emphasizing fast typing on a layout
purposely made to slow down typing absurd? (QWERTY).

The wonderful thing a virtual keyboard provides is the ability to
re-map/reskin keyboards. I wonder how fast kids would be able to type
if it became ABCD instead of QWERTY? (I miss the Texas Instrument
Speak & Spell) -> http://en.wikipedia.org/wiki/Speak_%26_Spell_(toy)

Oddly enough, I text faster on a traditional cellphone keypad (which
is technically ABCD) than on a Blackberry-style qwerty phone keypad
due to muscle memory & layout confusion.

Anyway, I've come across astounding "kids + computers" stuff over here myself.

While walking around the talipapa market in a visit to Boracay island
here in the Philippines last month, I saw a tiny 6-year old local
playing Counter-Strike deathmatch (
http://en.wikipedia.org/wiki/Counter-strike ) and holding his own
against his older friends (ranging from 8-11 year olds) in a small
internet cafe. I'll upload the video to youtube once I find my phone
data cable.

A couple of years ago, I also saw three 8-year old street kids pool
together money to play Command and Conquer: Red Alert 3 (
http://en.wikipedia.org/wiki/Command_%26_Conquer:_Red_Alert_3 ) taking
turns hot-seat style at a cheap internet cafe

Cue gasps of horror aside on videogame violence, I mean wow. At 8
years old, I could barely grasp running and jumping at the same time
with Super Mario Brothers.

Just goes to show how flexible kids are on computers and how they can
easily get around supposedly "complex" interfaces.

-- 
carlos nazareno
http://twitter.com/object404
http://www.object404.com
--
core team member
phlashers: philippine flash actionscripters
http://www.phlashers.com
--
poverty is violence
___
Devel mailing list
Devel@lists.laptop.org
http://lists.laptop.org/listinfo/devel

Re: Bad interaction between sleep timeouts and Salut?

[Daniel Drake]

On 16 September 2010 18:11, John Gilmore  wrote:
> It's pretty simple, actually.  When in "idle suspend", the system should
> remain fully functional, just burning fewer ergs.  It's an optimization,
> not a change of behavior.
>
> This means the system should wake up anytime it would've gotten an
> interrupt during normal operation.  Which means for any unicast
> packet, any ARP packet directed to it, and any multicast packet that
> it's listening for.

Right. The Marvell firmware already has a load of logic for deciding
whether to pass frames to the host when the host is powered up, i.e.
it only passes:
 1. Broadcast
 2. Multicast in a group that we're subscribed to
 3. Unicast to this particular XO
etc

It should be a simple firmware tweak to make the same filter apply to
the "The host is asleep, I've received a frame, do I wake it up?"
question.

This will result in a lot of wakeups, but I think this is the only way
to reliably achieve this optimization without affecting the behaviour
of the system. And optimizations can happen afterwards to reduce the
wakeups.

Daniel
___
Devel mailing list
Devel@lists.laptop.org
http://lists.laptop.org/listinfo/devel

Re: Bad interaction between sleep timeouts and Salut?

[Daniel Drake]

On 16 September 2010 18:54, John Watlington  wrote:
> On XO-1.5, the use of an SD interface makes suspend/resume without
> turning off the WLAN work much better.

Actually, http://dev.laptop.org/ticket/9960 shows that wake-on-WLAN is
unreliable on XO-1.5. It's a trivial test to make it break.
In another ticket, Hal repeated the same test on XO-1 and was able to
reproduce it, but only after a much longer time.
In other words, XO-1 wasn't perfect and XO-1.5 has regressed quite
significantly in this area.

Daniel
___
Devel mailing list
Devel@lists.laptop.org
http://lists.laptop.org/listinfo/devel

Re: Bad interaction between sleep timeouts and Salut?

[John Watlington]

On Sep 16, 2010, at 1:28 PM, Hal Murray wrote:

>>> Assuming the problem is in the Avahi level, we should make
>>> sure that the system is coming out from suspend when
>>> the radio receives multicast activity directed to us so Avahi
>>> can properly update its
> 
>> That is exactly the problem. It's taking forever-and-a-day to get that
>> sorted. Details at http://dev.laptop.org/ticket/9535 
> 
> It's worse than just multicast not working.  The basic wakeup from a packet 
> directly addressed to the machine doesn't work reliably.

On XO-1.5, the use of an SD interface makes suspend/resume without
turning off the WLAN work much better.   Unfortunately, a side effect
was that the firmware for the new chip (Marvell 88W8686, taking half
the power of the one used in XO-1) doesn't yet support wake-on-multicast.

I agree that fixing this is the correct solution.

Cheers,
wad

___
Devel mailing list
Devel@lists.laptop.org
http://lists.laptop.org/listinfo/devel

Re: #10363 NORM 10.1.3: Auto-Suspend gets in the way when sharing over Salut

[Tomeu Vizoso]

On Thu, Sep 16, 2010 at 19:06, Richard A. Smith  wrote:
> On 09/16/2010 05:05 AM, Tomeu Vizoso wrote:
>
>> So the problem is that if you had to resync all state for each machine
>> every time they wake up, you would use lots of bandwidth with the
>> power consumption associated, so much that it may not have been worth
>> sleeping.
>
> Hmmm... /me has questions about this.  Care to give me your breakdown of
> what power you think you are using?
>
> Going in to suspend saves approx 3-4 Watts.  Even if you only suspended
> for 1 second generating enough WLAN traffic to use 3-4 watts _above_
> what you are already using for idle.  I'm not sure that is what would
> happen.

Sorry, I wasn't clear. I wasn't referring to the case when a laptop
wakes up and gets its collaboration state from a server, but to the
server-less case in which getting that state means querying all other
accessible nodes, thus waking them up.

The effect of a single laptop coming out from suspend would mean
reducing the total time that the network is sleeping, and the more
laptops in the network, the less time they can sleep and the more
often they have to update their whole state.

If we let the other laptops sleep, then from the optic of the user the
representation of the network is probably equally confusing as it is
now.

Frankly, I think I'm a newcomer to this discussion so it's quite
probable that I'm missing something. I would though leave Salut out
from this for now and focus on how mDNS could work in this
semi-connected use case.

Just for the sake of looking at what others have done in a similar
situation, Apple implemented Sleep Proxies:
http://en.wikipedia.org/wiki/Sleep_Proxy_Service But seems to have
been dropped from the last IETF draft.

Regards,

Tomeu

> --
> Richard A. Smith  
> One Laptop per Child
> ___
> 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: Bad interaction between sleep timeouts and Salut?

[Hal Murray]

>> Assuming the problem is in the Avahi level, we should make
>> sure that the system is coming out from suspend when
>> the radio receives multicast activity directed to us so Avahi
>> can properly update its

> That is exactly the problem. It's taking forever-and-a-day to get that
> sorted. Details at http://dev.laptop.org/ticket/9535 

It's worse than just multicast not working.  The basic wakeup from a packet 
directly addressed to the machine doesn't work reliably.

I think it's good that you are pushing in this area, but please don't be 
discouraged if you don't see any results.  There is a reason that suspend was 
disabled by default for os852/10.1.2

http://dev.laptop.org/ticket/10232
WiFi dies on suspended XO-1, os300
http://dev.laptop.org/ticket/10195
wifi interface eth0 disappears on the XO-1
http://dev.laptop.org/ticket/10092
Networking broken over suspend/resume on os13 for XO-1
http://dev.laptop.org/ticket/9960
wake-on-WLAN doesn't always work (duplicate)
http://dev.laptop.org/ticket/9967
ibertas suspend fails on XO-1 (fixed)


-- 
These are my opinions, not necessarily my employer's.  I hate spam.



___
Devel mailing list
Devel@lists.laptop.org
http://lists.laptop.org/listinfo/devel

Re: #10363 NORM 10.1.3: Auto-Suspend gets in the way when sharing over Salut

[Daniel Drake]

On 16 September 2010 10:05, Tomeu Vizoso  wrote:
>>  Is there any workaround we can apply -- seems like Salut or the much
>>  maligned Presence Service has some regular event that re-syncs the nodes,
>>  can we make it more often? (Sam suggested this earlier though I didn't
>>  understand what he meant initially.)
>>
>>  Maybe Tomeu can give us a hint on whether such an event exists and what it
>>  is called so we can tune it? He'll have info on whether ths is likely to
>>  be an issue on 0.90 or not...
>
> Bringing this to de...@l.o where we are already discussing this issue.
>
> So the problem is that if you had to resync all state for each machine
> every time they wake up, you would use lots of bandwidth

And it's not even that simple.

Lets say that machines A and B (of owners A and B) want to
collaborate, and they are using salut / multicast.

Both machines are asleep.

Laptop A is woken up as the user starts an activity and shares it. In
person, the owner A tells owner B that the activity is now shared.

Laptop A goes to sleep.

Laptop B is woken up as the user presses the neighborhood view button.
Laptop B broadcasts its state and asks for a resync of other nodes
(under the above questionable idea). Laptop A does not respond because
it is asleep.

Owner B goes over to owner A and says "hey, I don't see it". Owner A
says "OK, I'll try again", and stops and starts a new activity and
shares it on laptop A.

Laptop B goes to sleep during the above.

Laptop A goes to sleep soon after sharing the activity.

Owner of B goes back to laptop B, which is asleep while showing the
neighborhood view. "Hey, I still can't see it"

etc.
___
Devel mailing list
Devel@lists.laptop.org
http://lists.laptop.org/listinfo/devel

Re: Bad interaction between sleep timeouts and Salut?

[John Gilmore]

It's pretty simple, actually.  When in "idle suspend", the system should
remain fully functional, just burning fewer ergs.  It's an optimization,
not a change of behavior.

This means the system should wake up anytime it would've gotten an
interrupt during normal operation.  Which means for any unicast
packet, any ARP packet directed to it, and any multicast packet that
it's listening for.

But people keep insisting on making this simplicity complicated, and
thus trying to figure out "how we can disable idle suspend while doing
multicast collab" or "how we can send more or fewer packets to
suspended laptops" or whatever.  Just fix the bugs and it'll work a
whole lot better.  THEN if you have a performance problem, and only
then, start to optimize it by fiddling with timers and disables and
such.

John
___
Devel mailing list
Devel@lists.laptop.org
http://lists.laptop.org/listinfo/devel

Re: #10363 NORM 10.1.3: Auto-Suspend gets in the way when sharing over Salut

[Richard A. Smith]

On 09/16/2010 05:05 AM, Tomeu Vizoso wrote:

> So the problem is that if you had to resync all state for each machine
> every time they wake up, you would use lots of bandwidth with the
> power consumption associated, so much that it may not have been worth
> sleeping.

Hmmm... /me has questions about this.  Care to give me your breakdown of 
what power you think you are using?

Going in to suspend saves approx 3-4 Watts.  Even if you only suspended 
for 1 second generating enough WLAN traffic to use 3-4 watts _above_ 
what you are already using for idle.  I'm not sure that is what would 
happen.

-- 
Richard A. Smith  
One Laptop per Child
___
Devel mailing list
Devel@lists.laptop.org
http://lists.laptop.org/listinfo/devel

Re: Bad interaction between sleep timeouts and Salut?

[Martin Langhoff]

On Thu, Sep 16, 2010 at 4:24 AM, Tomeu Vizoso  wrote:

...
> So Salut is an implementation of XEP-0174: Serverless Messaging:

Tomeu -- thanks for the exhaustive info.

> Assuming the problem is in the Avahi level, we should make sure that
> the system is coming out from suspend when the radio receives
> multicast activity directed to us so Avahi can properly update its

That is exactly the problem. It's taking forever-and-a-day to get that
sorted. Details at http://dev.laptop.org/ticket/9535

So I am trying to prod things towards finding a workaround -- by
fiddling with timers related to presence service.

cheers,



m
-- 
 mar...@laptop.org -- School Server Architect
 - ask interesting questions
 - don't get distracted with shiny stuff  - working code first
 - http://wiki.laptop.org/go/User:Martinlanghoff
___
Devel mailing list
Devel@lists.laptop.org
http://lists.laptop.org/listinfo/devel

Re: reverse-deadkeys?

[Frantisek Dufka]

I thought this is on purpose to be simpler for kids or something because 
that's how you draw the letter with pencil (first a then ´).

Please note that this is also not real dead keys and causes other issues 
because there are in fact two characters stored with this method. You 
really have a and ´ stored as separate characters and the accent 
character is from some special unicode range which says to overwrite 
previously printed character.

This causes problem e.g. with Speak activity since it cannot speak 
accented characters properly because they are not stored as such even if 
it visually looks so. I was localizing Speak to Czech for my son and 
have to remap dead keys to the usual non-reverse way to have Speak talk 
in Czech properly.

Frantisek


On 15.9.2010 23:14, Gonzalo Odiard wrote:
> I have see this in XO-1 with the english keyboard before.
>
> Gonzalo
>
> On Wed, Sep 15, 2010 at 5:51 PM, Martin Langhoff
> mailto:martin.langh...@gmail.com>> wrote:
>
> Sam brought to my attention that on 10.1.2 our deadkeys arrangement is
> the opposite of the usual implementation. You press a, then ´ to get
> á. The usual order is the reverse, and that's what we had in XO-1.
>
> Is this on purpose, or accident?
>
> cheers,
___
Devel mailing list
Devel@lists.laptop.org
http://lists.laptop.org/listinfo/devel

Re: #10363 NORM 10.1.3: Auto-Suspend gets in the way when sharing over Salut

[Tomeu Vizoso]

On Thu, Sep 16, 2010 at 11:05, Tomeu Vizoso  wrote:
> On Wed, Sep 15, 2010 at 18:50, Zarro Boogs per Child
>  wrote:
>> #10363: Auto-Suspend gets in the way when sharing over Salut
>> ---+
>>           Reporter:  erikos           |       Owner:  erikos
>>               Type:  defect           |      Status:  new
>>           Priority:  normal           |   Milestone:  10.1.3
>>          Component:  telepathy-salut  |     Version:  Development build as 
>> of this date
>>         Resolution:                   |    Keywords:
>>        Next_action:  diagnose         |    Verified:  0
>> Deployment_affected:                   |   Blockedby:
>>           Blocking:                   |
>> ---+
>> Changes (by martin.langhoff):
>>
>>  * cc: greenfeld, tomeu (added)
>>
>>
>> Comment:
>>
>>  Was discussing this with Sam earlier.
>>
>>  Is there any workaround we can apply -- seems like Salut or the much
>>  maligned Presence Service has some regular event that re-syncs the nodes,
>>  can we make it more often? (Sam suggested this earlier though I didn't
>>  understand what he meant initially.)
>>
>>  Maybe Tomeu can give us a hint on whether such an event exists and what it
>>  is called so we can tune it? He'll have info on whether ths is likely to
>>  be an issue on 0.90 or not...
>
> Bringing this to de...@l.o where we are already discussing this issue.
>
> So the problem is that if you had to resync all state for each machine
> every time they wake up, you would use lots of bandwidth with the
> power consumption associated, so much that it may not have been worth
> sleeping.
>
> Another issue with this is that you not only want to resync presence,
> but shared activities also would need to resync their state. Which
> cannot be done without activity-level support which we don't have. It
> would also cause more traffic and power consumption in the network as
> a whole.

Forgot to mention that for gabble, you can tell some servers that you
are going to sleep and it will queue the presence updates for when you
wake up. So you won't be awoke by presence updates, just by direct
IM'ing.

This is right now implemented only in Google's XMPP server, but
there's quite a bit of a chance we could persuade the Prosody hackers
to implement something similar:

http://mail.jabber.org/pipermail/summit/2010-February/000528.html

Telepathy has already done some advances on an interface for such optimizations:

http://telepathy.freedesktop.org/spec/Connection_Interface_Power_Saving.html

Regards,

Tomeu

> Regards,
>
> Tomeu
>
>> --
>> Ticket URL: 
>> One Laptop Per Child 
>> OLPC bug tracking system
>>
>
___
Devel mailing list
Devel@lists.laptop.org
http://lists.laptop.org/listinfo/devel

Re: Bad interaction between sleep timeouts and Salut?

[Daniel Drake]

On 16 September 2010 10:14, Sascha Silbe
 wrote:
>
> Excerpts from Tomeu Vizoso's message of Thu Sep 16 10:24:26 +0200 2010:
>
>> Assuming the problem is in the Avahi level, we should make sure that
>> the system is coming out from suspend when the radio receives
>> multicast activity directed to us [...]
>
> It doesn't, by explicit decision. [1]

Right - thats the key point. Theres an incompatibility between the
design of idle-suspend and between the use of salut collaboration (or
with the use of any multicast-using application).

And even if we did wake up on multicast, we frequently fail to wake up
on network even when we're supposed to
(http://dev.laptop.org/ticket/9960).

Increasing the frequency of "I'm here" communications would help this
issue but you'd end up saturating the network even more that already
happens, and I predict that it still wouldn't be reliable.

Best short term solution would be to disable idle-suspend, or at least
disable it when salut is being used.

Daniel
___
Devel mailing list
Devel@lists.laptop.org
http://lists.laptop.org/listinfo/devel

Re: Bad interaction between sleep timeouts and Salut?

[Sascha Silbe]

Excerpts from Tomeu Vizoso's message of Thu Sep 16 10:24:26 +0200 2010:

> Assuming the problem is in the Avahi level, we should make sure that
> the system is coming out from suspend when the radio receives
> multicast activity directed to us [...]

It doesn't, by explicit decision. [1]

Sascha

[1] http://dev.laptop.org/ticket/10207#comment:8
--
http://sascha.silbe.org/
http://www.infra-silbe.de/


signature.asc
Description: PGP signature
___
Devel mailing list
Devel@lists.laptop.org
http://lists.laptop.org/listinfo/devel

Re: #10363 NORM 10.1.3: Auto-Suspend gets in the way when sharing over Salut

[Tomeu Vizoso]

On Wed, Sep 15, 2010 at 18:50, Zarro Boogs per Child
 wrote:
> #10363: Auto-Suspend gets in the way when sharing over Salut
> ---+
>           Reporter:  erikos           |       Owner:  erikos
>               Type:  defect           |      Status:  new
>           Priority:  normal           |   Milestone:  10.1.3
>          Component:  telepathy-salut  |     Version:  Development build as of 
> this date
>         Resolution:                   |    Keywords:
>        Next_action:  diagnose         |    Verified:  0
> Deployment_affected:                   |   Blockedby:
>           Blocking:                   |
> ---+
> Changes (by martin.langhoff):
>
>  * cc: greenfeld, tomeu (added)
>
>
> Comment:
>
>  Was discussing this with Sam earlier.
>
>  Is there any workaround we can apply -- seems like Salut or the much
>  maligned Presence Service has some regular event that re-syncs the nodes,
>  can we make it more often? (Sam suggested this earlier though I didn't
>  understand what he meant initially.)
>
>  Maybe Tomeu can give us a hint on whether such an event exists and what it
>  is called so we can tune it? He'll have info on whether ths is likely to
>  be an issue on 0.90 or not...

Bringing this to de...@l.o where we are already discussing this issue.

So the problem is that if you had to resync all state for each machine
every time they wake up, you would use lots of bandwidth with the
power consumption associated, so much that it may not have been worth
sleeping.

Another issue with this is that you not only want to resync presence,
but shared activities also would need to resync their state. Which
cannot be done without activity-level support which we don't have. It
would also cause more traffic and power consumption in the network as
a whole.

Regards,

Tomeu

> --
> Ticket URL: 
> One Laptop Per Child 
> OLPC bug tracking system
>
___
Devel mailing list
Devel@lists.laptop.org
http://lists.laptop.org/listinfo/devel

Re: Bad interaction between sleep timeouts and Salut?

[Hal Murray]

> Assuming the problem is in the Avahi level, we should make sure that the
> system is coming out from suspend when the radio receives multicast activity
> directed to us so Avahi can properly update its internal state and also for
> activities using clique (multi-user chat rooms on server-less XMPP). A
> couple more of references: 

I'm pretty sure that XO-1 doesn't wakeup on broadcast packets.  In 
particular, it doesn't wakeup on ARP broadcasts.

Does this work on XO-1.5?

Until that gets fixed, you can set up the ARP table by hand so you can find 
the next layer of bugs.  man arp for the details.

It's not clear that you want to wakeup on generic broadcasts.  That will just 
eat up a lot of battery to throw away junk packets.  On the other hand, you 
probably want to wakeup on ARPs for your IP address and multicast packets if 
your interface is setup to listen to that address.



-- 
These are my opinions, not necessarily my employer's.  I hate spam.



___
Devel mailing list
Devel@lists.laptop.org
http://lists.laptop.org/listinfo/devel

Re: Bad interaction between sleep timeouts and Salut?

[Tomeu Vizoso]

On Thu, Sep 16, 2010 at 05:26, James Cameron  wrote:
> On Wed, Sep 15, 2010 at 08:04:25PM -0400, Martin Langhoff wrote:
>> I am curious -- what is the frequency of "presence broadcasts" when
>> Salut is used? Where is it set?
>
> Three minutes.  Perhaps KEEPALIVE_TIMEOUT in
> gibber-r-multicast-causal-transport.c

So Salut is an implementation of XEP-0174: Serverless Messaging:

http://xmpp.org/extensions/xep-0174.html

In this section of the document is an overview of the different
components used by this protocol:

http://xmpp.org/extensions/xep-0174.html#howitworks

As you can see, basic presence is done with multicast DNS/DNS-SD and
Salut uses Avahi for that.

Gibber is a library internal to Salut that implements the other part
of the protocol: XMPP message passing between nodes.

With that in mind, what I would do next is to try to isolate the
problems within either Avahi or Gibber, that will reduce significantly
the amount of code we need to care about and will be useful in further
debugging and tuning. avahi-browse and avahi-discover are useful tools
for monitoring the state of Avahi, so if you could reproduce the same
issues there, then we could rule out a big chunk of code.

If that's the case, then these two functions in Salut would be most
relevant, the first announces a DNS service for the buddy and the
other does the same for shared activities:

http://git.collabora.co.uk/?p=telepathy-salut.git;a=blob;f=src/salut-avahi-self.c;h=dab2c78247c84bfba7b693251e6ac3703648eb13;hb=HEAD#l220

http://git.collabora.co.uk/?p=telepathy-salut.git;a=blob;f=src/salut-avahi-olpc-activity.c;h=2a3681aca7568d1c8bf4ce97b161f79c11ef6165;hb=HEAD#l157

Assuming the problem is in the Avahi level, we should make sure that
the system is coming out from suspend when the radio receives
multicast activity directed to us so Avahi can properly update its
internal state and also for activities using clique (multi-user chat
rooms on server-less XMPP). A couple more of references:

http://files.multicastdns.org/draft-cheshire-dnsext-multicastdns.txt
http://telepathy.freedesktop.org/wiki/Clique

With Gabble we should see similar effects if the machine is not
resuming when the Jabber server sends us updates.

Regards,

Tomeu

>> With current 10.1.2 using salut over ad-hoc the neighbourhood view
>> never stabilises, and it's very apparent that it's because nodes go to
>> sleep too quickly (before they see others, before they are seen). And
>> when awake, they take a long time to regain a good view of what's out
>> there.
>>
>> If we can experiment with the timeouts (knowing where the knobs are)
>> maybe we can find out...
>>
>> (Tomeu, I bother you because I suspect you'd know... hope it's not an
>> annoyance...)
>
> http://git.collabora.co.uk/?p=telepathy-salut.git;a=blob;f=lib/gibber/gibber-r-multicast-causal-transport.c;h=3cdb2a8d3b88de473ee473da3af15e280d355c26;hb=HEAD
>
> Salut over ad-hoc seems to use multicast packets, according to my
> tcpdump, so this source file appears relevant.
>
> The timers are specified there as constants, without configurable
> settings.  So if you don't mind fiddling with them and recompiling, it
> should be possible to improve the situation, at the expense of increased
> wireless traffic.
>
> Might also detect resume, evaluate time interval lost, and expire the
> timer sooner.
>
> --
> James Cameron
> http://quozl.linux.org.au/
>
___
Devel mailing list
Devel@lists.laptop.org
http://lists.laptop.org/listinfo/devel