Re: [Sugar-devel] OT: determining memory usage of short-lived processes

[Sascha Silbe]

On Sun, Jun 07, 2009 at 12:28:58AM +0200, Martin Langhoff wrote:

[ps_mem.py]
Perhaps you knew it already -- it's a good tool worthy of promotion 
so...
Got to know it only recently and it's indeed very useful, even though it 
requires root access (for obvious reasons).



Run the whole thing under /usr/bin/time, which is different from the
shell's 'time' built-in.
Interesting, always thought they have the same output. Thanks for the 
tip!


The report is actually about the pagefaults, which for relatively 
short runs relate almost linearly to mem usage.

But doesn't it include non-RAM pagefaults (i.e. mmap()ed files) as well?
It's a shame that Linux doesn't support most of the interesting fields 
(only utime, stime, minflt, majflt, nvcsw and nivcsw according to 
getrusage(2)). Even the proc files used by ps_mem.py are empty (in 
zombie state).


CU Sascha

--
http://sascha.silbe.org/
http://www.infra-silbe.de/

signature.asc
Description: Digital signature
___
Sugar-devel mailing list
Sugar-devel@lists.sugarlabs.org
http://lists.sugarlabs.org/listinfo/sugar-devel

Re: [Sugar-devel] I'm looking for a tree...

[James Zaki]

Hey Benjamin,

Taking a guess with the information you've given perhaps a hash
tablecould help?

Fast lookup/retrieval, but just have to consider what you would enumerate as
the key, and loading.

Let me know if you want some help applying this, memories of a uni
assignment have just come flooding back.


James.



2009/6/7 Benjamin M. Schwartz 

> I am looking for a fast data structure with the following properties:
>
> Maintains an indexed list of arbitrary, non-ordered objects (like a python
> List or C array)
> Allows fast:
> Insertion at any location
> Deletion at any location
> Lookup of an object by its index
> Reverse lookup, to determine the index of an object
>
> Python's List has O(1) lookup, but O(N) insert, delete, and
> reverse-lookup.  To make reverse lookup O(1) I could maintain a separate
> Dict mapping objects to indices, but this would cost an additional O(N) on
> every insertion and deletion.
>
> A linked list has O(1) insertion and deletion, but O(N) lookup and O(N)
> reverse lookup.  I could maintain a separate Dict for the forward and
> reverse mappings, but this would cost O(N) on every insertion and deletion.
>
> A standard self-balancing tree cannot be used because the objects are not
> ordered, and self-balancing trees require ordered keys.  I could use the
> index of an object as the sort key, but then insertion and deletion are
> O(N) because all subsequent keys must be altered.  I could fabricate new
> sort keys to ensure that insertions occur at the desired location, but
> then the length of the keys will grow like O(N), making all operations at
> least O(N).
>
> I feel like there should be some kind of standard tree-like data structure
> that meets my requirements, but I can't find one.  Do you know of one?  Am
> I on a unicorn hunt?
>
> --Ben
>
>
> ___
> Sugar-devel mailing list
> Sugar-devel@lists.sugarlabs.org
> http://lists.sugarlabs.org/listinfo/sugar-devel
>
>
___
Sugar-devel mailing list
Sugar-devel@lists.sugarlabs.org
http://lists.sugarlabs.org/listinfo/sugar-devel

[Sugar-devel] personalisation and collaboration

[David Van Assche]

Something has been in the back of my head for a while now, ever since I've
seen the impressive capabilities of being able to share an activity with
your neighbourhood. Being able to cooperatively use applications brings a
new level of playability to it all, and it reminds me of when I first saw
the ability for a computer game to be 'multi-player.'This gave it an extra
dimension, and with it came the idea of awards for completing certain
things, which would be displayed in your dashoard somewhere.The award system
seems even more relevant for education than it did for games. We'v aleady
mentioned the benefits of an award sysem so I'm not going to regugitate
that, but what hasnt''t really been spoken about is, how and what kind of
personal details should the journal store and share. I see this as a
customisable option, something that can be as simple as only sharing first
names, or sharing the name of your pet, your favorite colors and foods, the
languages you speak.

This detailed information about a person is extremely valuable to the
underlying system, as it can potentially match people against each other.
This would allow for some interesting possibilities when it comes to
collaboration, such as the system suggesting users to challenge/collaborate
with based on personal information. I thought about having a robot that
lives on an irc channel capable of helping with the collaboration procedure,
as well as listing achievements, giving data on which users want to
collaborate, giving help on how collaboration works with particular
activities, listing which servers have open collaboration, showing the most
used/highest rated collaborating activities, etc.

I havent thought about this too much in depth, but I know coding a bot is
not too hard. I see it as an extension to the speak AI, and encouragement to
join irc. We can even get the bot to accept uploads of raw learning
materials categorised by subject, which can then be used by content
creators. it itself could give out quizzes based on particular subjects, or
interesting pieces of information/knowledge. It could be taught new
information, by feeding it localised knowledge. It would be important to
know where we set the limits to what it can do.

Just some food for thought...

David (nubae) Van Assche
___
Sugar-devel mailing list
Sugar-devel@lists.sugarlabs.org
http://lists.sugarlabs.org/listinfo/sugar-devel

Re: [Sugar-devel] [IAEP] personalisation and collaboration

[Walter Bender]

On Sun, Jun 7, 2009 at 7:00 AM, David Van Assche wrote:
> Something has been in the back of my head for a while now, ever since I've
> seen the impressive capabilities of being able to share an activity with
> your neighbourhood. Being able to cooperatively use applications brings a
> new level of playability to it all, and it reminds me of when I first saw
> the ability for a computer game to be 'multi-player.'This gave it an extra
> dimension, and with it came the idea of awards for completing certain
> things, which would be displayed in your dashoard somewhere.The award system
> seems even more relevant for education than it did for games. We'v aleady
> mentioned the benefits of an award sysem so I'm not going to regugitate
> that, but what hasnt''t really been spoken about is, how and what kind of
> personal details should the journal store and share. I see this as a
> customisable option, something that can be as simple as only sharing first
> names, or sharing the name of your pet, your favorite colors and foods, the
> languages you speak.
>
> This detailed information about a person is extremely valuable to the
> underlying system, as it can potentially match people against each other.
> This would allow for some interesting possibilities when it comes to
> collaboration, such as the system suggesting users to challenge/collaborate
> with based on personal information. I thought about having a robot that
> lives on an irc channel capable of helping with the collaboration procedure,
> as well as listing achievements, giving data on which users want to
> collaborate, giving help on how collaboration works with particular
> activities, listing which servers have open collaboration, showing the most
> used/highest rated collaborating activities, etc.
>
> I havent thought about this too much in depth, but I know coding a bot is
> not too hard. I see it as an extension to the speak AI, and encouragement to
> join irc. We can even get the bot to accept uploads of raw learning
> materials categorised by subject, which can then be used by content
> creators. it itself could give out quizzes based on particular subjects, or
> interesting pieces of information/knowledge. It could be taught new
> information, by feeding it localised knowledge. It would be important to
> know where we set the limits to what it can do.
>
> Just some food for thought...
>
> David (nubae) Van Assche
>
> ___
> IAEP -- It's An Education Project (not a laptop project!)
> i...@lists.sugarlabs.org
> http://lists.sugarlabs.org/listinfo/iaep
>

In general, the idea of bots living in the Sugar neighborhood is a
theme we haven't explored very much. It would be nice to come up with
a simple, consistent framework for creating such a resource. Making it
available through IRC as well is a cool idea.

-walter

-- 
Walter Bender
Sugar Labs
http://www.sugarlabs.org
___
Sugar-devel mailing list
Sugar-devel@lists.sugarlabs.org
http://lists.sugarlabs.org/listinfo/sugar-devel

[Sugar-devel] Getting data about the upgrading older machines and SoaS responsiveness.

[Caroline Meeks]

This week, thanks for installing the Broadcom drivers separately, we got
Sugar on a Stick up and running on the GPA computers.
http://wiki.sugarlabs.org/go/Gardner_Pilot_Academy#Current_computers_at_GPA

They are older computer and they run faster then an XO but still not that
snappy.

A big part of SoaS is using existing computers and donated computers.  I
wonder what it would take to upgrade  older computers, and make them
snappier.

I don't know if we will get permission to open up these particular
computers, (which are owned by Boston Public Schools) but there are
certainly tons of older computers like them around.

I think there are two things that might make them perform better.

1. Add a USB 2.0 port.  They are almost certainly USB 1 right now.  I see
that if the box has the right slots for it, USB 2.0 cards are less then $10.
http://www.newegg.com/Product/Product.aspx?Item=N82E16815123010
2. Add more RAM.  Earlier this year I worked with a group that specialized
in repairing and recyclying computers. They had lots of RAM they had
scavanged.

It would be very cool if someone had some old computers and could try Sugar,
then do motifications like add a USB 2.0 port and RAM and document the
results.  Caryl, this is another potential project for someone who wants to
help.

-- 
Caroline Meeks
Solution Grove
carol...@solutiongrove.com

617-500-3488 - Office
505-213-3268 - Fax
___
Sugar-devel mailing list
Sugar-devel@lists.sugarlabs.org
http://lists.sugarlabs.org/listinfo/sugar-devel

Re: [Sugar-devel] [IAEP] [Marketing] [SoaS] Request for Artwork: Boot Screen

[Sebastian Dziallas]

Hi all,

looking at the wiki page, I'm really impressed - great work! :)

I also really like the idea of switching the logo color for each release 
- this shouldn't be hard and is an interesting approach.

Has there already been some kind of agreement on which version we're 
going to use for the LinuxTag release? Is the one with the progress bar 
something everyone could agree with?

And could I possibly get the .png files, so that I can compose a new 
snapshot with a preview of the new boot screen (we can still change it 
afterwards, but I'd like to have some snapshot to test it)?

Walter: Have you heard anything regarding the use of the XO in our boot 
screen? Is this okay with OLPC?

--Sebastian

Sean DALY wrote:
> Actually the logo color linked to a version idea was in my long mail
> the other day about communicating the version :-)
>
> I too think 2 changes a year will give us time to cycle through the
> twelve variants.
>
> To make that work, the actual place where the version number is
> communicated (Control Panel / About my computer) would need to have
> the matching color Sugar Labs (not just Sugar) logo.
>
> I like this progress bar boot screen because:
>
> * ultrasimple, unobtrusive, fits perfectly with Sugar HIG
> * bar is universally easy to understand, no possibility of confusion
> with graphic elements.
> * keeping logo around that long=strong branding, which is vital for
> Sugar to be recognized by name rather than just "the system" running
> on XOs, netbooks, etc.
>
> I miss the iconic ring treatment though.
>
> And, no matter how clean we would like it to be, we still need to
> address the questions of school/sponsor co-branding (if they have a
> logo, they won't feel like jst putting their name in grey) and distro
> co-branding.
>
> Perhaps we could solve those problems by putting them in the "About my
> computer" page as well? Awful as far as co-branding goes (partners
> would not be happy), but will keep boot minimalist and functional.
>
> For a shining example of how more-is-less packaging is ruinous, may I
> direct your attention to:
>
> http://www.youtube.com/watch?v=EUXnJraKM3k
>
> Sean
>
>
> On Thu, Jun 4, 2009 at 9:44 PM, Gary C Martin  wrote:
>> On 4 Jun 2009, at 16:35, Gary C Martin wrote:
>>
>>> On 4 Jun 2009, at 15:45, Sean DALY wrote:
>>>
 Yes that would be very helpful I think
>>> I was just going to start tinkering again, I'll make an animated
>>> version of Eben's XO and progress-bar for evaluation.
>> Just uploaded an animated version showing Eben's boot with progress bar
>> treatment:
>>
>>
>>   http://wiki.sugarlabs.org/go/Image:XO-sugar-boot-with-progress-bar.gif
>>
>> FWIW: +1 on Eben's suggestion for changing the colour of the Sugar logo for
>> each major new Sugar release. It nicely avoids what looks like jumping
>> through lot's of technical burning hoops of fire, trying to set up a boot
>> anim that dynamically changes to match the owners own colours (nice idea but
>> I think a big ask at this point in time).
>>
>> FWIW2: Just incase any one was wondering, the colour dot versions were based
>> on the 1-12 official Sugar Logo treatment colour pairs, i.e definitely not
>> not random :-)
>>
>> Regards,
>> --Gary
>>
 If we can reach consensus by tomorrow and finish the actual PNG frames
 over the weekend we will meet the deadline

 but, we need a volunteer to do the frames (unless Gary what you have
 is nearly ready; my stuff is cut/pasted mockup no color control etc)
>>> Sure, getting a series of PNGs from any of my mock-ups is just a "save
>>> for web" away.
>>>
>>> Regards,
>>> --Gary
>>>
 thanks

 Sean


 On Thu, Jun 4, 2009 at 4:40 PM, Christian Marc Schmidt
   wrote:
> I agree with Eben's points below...
>
> Maybe it would help if one of us mocked up the alternative he is
> describing?
>
> Christian
>
>
> On Jun 4, 2009, at 10:35 AM, Eben Eliason
> wrote:
>
>> On Thu, Jun 4, 2009 at 10:31 AM, Eben Eliason> wrote:
>>> On Thu, Jun 4, 2009 at 7:24 AM, Sean DALY
>>> wrote:
 http://wiki.sugarlabs.org/go/Marketing_Team/Boot_Logo

 Christian - I myself prefer the "rays" to dots which I feel too
 closely resemble networks in the Neighborhood view, confusion is
 possible (networks being connected to at startup?)

 Fred - I'm willing to try that sunrise metaphor, tonight if I can
 (travelling today)

 Re splash page with logo: in my next mockup I'll leave off the
 example
 school logo.and move that frame to the end. It might be better to
 "reserve" a frame for customizable logo or message, before or
 after
 the Sugar spash page
>>> Yes, in that mockup the first screen is kind of overwhelming with
>>> several logos and a few pieces of textual information. At the same
>>> time, we tried very hard to eliminate the slideshow effect th

Re: [Sugar-devel] I'm looking for a tree...

[Benjamin M. Schwartz]

James Zaki wrote:
> Taking a guess with the information you've given perhaps a hash
> tablecould help?

Python uses the term "Dict" to describe its built-in hash table.  I do
think a hash table could be helpful, for example, to maintain the reverse
lookup mapping if the forward lookup is stored in a List (which is
actually python's version of a dynamic array, like C++'s Vector).
However, I am still stuck with O(N) performance in this case for insertion
and deletion, because each such modification shifts the position of all
subsequent objects.  This would correspond to changing the value
associated with half the keys in the hash table, on average, for each
insertion.

I was hoping for a structure with log-time performance.

--Ben



signature.asc
Description: OpenPGP digital signature
___
Sugar-devel mailing list
Sugar-devel@lists.sugarlabs.org
http://lists.sugarlabs.org/listinfo/sugar-devel

Re: [Sugar-devel] Getting data about the upgrading older machines and SoaS responsiveness.

[Sean DALY]

Hmmm I'm not sure a BIOS will be wiling to boot from a USB port on a
card. However, combined with a CD boot helper might do the trick.

Reconditioning older PCs (even just adding RAM or a USB card) is a bit
of a thankless job :-(

I'm wondering if there's a way for SoaS to automatically report what
it has booted on. Computer labs are prime candidates for SoaS and are
often populated with a single PC model; it would be great if we could
offer good upgrade advice x30.

Sean




On Sun, Jun 7, 2009 at 3:34 PM, Caroline
Meeks wrote:
> This week, thanks for installing the Broadcom drivers separately, we got
> Sugar on a Stick up and running on the GPA computers.
> http://wiki.sugarlabs.org/go/Gardner_Pilot_Academy#Current_computers_at_GPA
>
> They are older computer and they run faster then an XO but still not that
> snappy.
>
> A big part of SoaS is using existing computers and donated computers.  I
> wonder what it would take to upgrade  older computers, and make them
> snappier.
>
> I don't know if we will get permission to open up these particular
> computers, (which are owned by Boston Public Schools) but there are
> certainly tons of older computers like them around.
>
> I think there are two things that might make them perform better.
>
> 1. Add a USB 2.0 port.  They are almost certainly USB 1 right now.  I see
> that if the box has the right slots for it, USB 2.0 cards are less then $10.
> http://www.newegg.com/Product/Product.aspx?Item=N82E16815123010
> 2. Add more RAM.  Earlier this year I worked with a group that specialized
> in repairing and recyclying computers. They had lots of RAM they had
> scavanged.
>
> It would be very cool if someone had some old computers and could try Sugar,
> then do motifications like add a USB 2.0 port and RAM and document the
> results.  Caryl, this is another potential project for someone who wants to
> help.
>
> --
> Caroline Meeks
> Solution Grove
> carol...@solutiongrove.com
>
> 617-500-3488 - Office
> 505-213-3268 - Fax
>
> ___
> Sugar-devel mailing list
> Sugar-devel@lists.sugarlabs.org
> http://lists.sugarlabs.org/listinfo/sugar-devel
>
>
___
Sugar-devel mailing list
Sugar-devel@lists.sugarlabs.org
http://lists.sugarlabs.org/listinfo/sugar-devel

Re: [Sugar-devel] Getting data about the upgrading older machines and SoaS responsiveness.

[Caroline Meeks]

On Sun, Jun 7, 2009 at 9:49 AM, Sean DALY  wrote:

> Hmmm I'm not sure a BIOS will be wiling to boot from a USB port on a
> card. However, combined with a CD boot helper might do the trick.


I have to use the CD at this point anyway. My goal is to have it boot more
quickly and  respond more quickly once its booted.

>
>
> Reconditioning older PCs (even just adding RAM or a USB card) is a bit
> of a thankless job :-(


But one that makes many high school  and young at heart computer geeks
pretty happy on a Saturday, especially if you add pizza and donuts.  If a
school IT person has to do it, its never financially feasible, but I could
see a lot of volunteers actually enjoying the work, and getting a lot of
satisfaction about getting faster computers into kids hands and keeping
computers out of the land fill.

>
>
> I'm wondering if there's a way for SoaS to automatically report what
> it has booted on. Computer labs are prime candidates for SoaS and are
> often populated with a single PC model; it would be great if we could
> offer good upgrade advice x30.


Ah actually Sebastian already wrote that! I forgot to do it when I was in
the computer lab. I will remember next time.  It would be cool to turn that
into an Activity so its super easy.

My work trying to get a Work Study student for GPA looks like its going to
generate a bunch of volunteers without the correct paperwork to get paid as
Work Study students.

Let me echo Caryl's question. Do we have a page with tasks for new
volunteers?

>
>
> Sean
>
>
>
>
> On Sun, Jun 7, 2009 at 3:34 PM, Caroline
> Meeks wrote:
> > This week, thanks for installing the Broadcom drivers separately, we got
> > Sugar on a Stick up and running on the GPA computers.
> >
> http://wiki.sugarlabs.org/go/Gardner_Pilot_Academy#Current_computers_at_GPA
> >
> > They are older computer and they run faster then an XO but still not that
> > snappy.
> >
> > A big part of SoaS is using existing computers and donated computers.  I
> > wonder what it would take to upgrade  older computers, and make them
> > snappier.
> >
> > I don't know if we will get permission to open up these particular
> > computers, (which are owned by Boston Public Schools) but there are
> > certainly tons of older computers like them around.
> >
> > I think there are two things that might make them perform better.
> >
> > 1. Add a USB 2.0 port.  They are almost certainly USB 1 right now.  I see
> > that if the box has the right slots for it, USB 2.0 cards are less then
> $10.
> > http://www.newegg.com/Product/Product.aspx?Item=N82E16815123010
> > 2. Add more RAM.  Earlier this year I worked with a group that
> specialized
> > in repairing and recyclying computers. They had lots of RAM they had
> > scavanged.
> >
> > It would be very cool if someone had some old computers and could try
> Sugar,
> > then do motifications like add a USB 2.0 port and RAM and document the
> > results.  Caryl, this is another potential project for someone who wants
> to
> > help.
> >
> > --
> > Caroline Meeks
> > Solution Grove
> > carol...@solutiongrove.com
> >
> > 617-500-3488 - Office
> > 505-213-3268 - Fax
> >
> > ___
> > Sugar-devel mailing list
> > Sugar-devel@lists.sugarlabs.org
> > http://lists.sugarlabs.org/listinfo/sugar-devel
> >
> >
>



-- 
Caroline Meeks
Solution Grove
carol...@solutiongrove.com

617-500-3488 - Office
505-213-3268 - Fax
___
Sugar-devel mailing list
Sugar-devel@lists.sugarlabs.org
http://lists.sugarlabs.org/listinfo/sugar-devel

Re: [Sugar-devel] [IAEP] [Marketing] [SoaS] Request for Artwork: Boot Screen

[Gary C Martin]

Hi Sebastian,

On 7 Jun 2009, at 14:37, Sebastian Dziallas wrote:

> Hi all,
>
> looking at the wiki page, I'm really impressed - great work! :)
>
> I also really like the idea of switching the logo color for each  
> release - this shouldn't be hard and is an interesting approach.
>
> Has there already been some kind of agreement on which version we're  
> going to use for the LinuxTag release?

Yes I was wondering this also, given the weekend was the deadline :-)

> Is the one with the progress bar something everyone could agree with?

FWIW, my two current favourites are the grey progress bar, or  the  
grey circle of dots:

http://wiki.sugarlabs.org/go/Image:XO-sugar-boot-with-progress-bar.gif

http://wiki.sugarlabs.org/go/Image:Refined-XO-sugar-boot-with-overlap.gif

> And could I possibly get the .png files, so that I can compose a new  
> snapshot with a preview of the new boot screen (we can still change  
> it afterwards, but I'd like to have some snapshot to test it)?

I don't want to short circuit a decision making process, but let me  
kick out their PNGs and email to you (will do that now). That way you  
at least have a couple of the possible candidates to experiment/test  
with now.

Regards,
--Gary

> Walter: Have you heard anything regarding the use of the XO in our  
> boot screen? Is this okay with OLPC?
>
> --Sebastian
>
> Sean DALY wrote:
>> Actually the logo color linked to a version idea was in my long mail
>> the other day about communicating the version :-)
>>
>> I too think 2 changes a year will give us time to cycle through the
>> twelve variants.
>>
>> To make that work, the actual place where the version number is
>> communicated (Control Panel / About my computer) would need to have
>> the matching color Sugar Labs (not just Sugar) logo.
>>
>> I like this progress bar boot screen because:
>>
>> * ultrasimple, unobtrusive, fits perfectly with Sugar HIG
>> * bar is universally easy to understand, no possibility of confusion
>> with graphic elements.
>> * keeping logo around that long=strong branding, which is vital for
>> Sugar to be recognized by name rather than just "the system" running
>> on XOs, netbooks, etc.
>>
>> I miss the iconic ring treatment though.
>>
>> And, no matter how clean we would like it to be, we still need to
>> address the questions of school/sponsor co-branding (if they have a
>> logo, they won't feel like jst putting their name in grey) and distro
>> co-branding.
>>
>> Perhaps we could solve those problems by putting them in the "About  
>> my
>> computer" page as well? Awful as far as co-branding goes (partners
>> would not be happy), but will keep boot minimalist and functional.
>>
>> For a shining example of how more-is-less packaging is ruinous, may I
>> direct your attention to:
>>
>> http://www.youtube.com/watch?v=EUXnJraKM3k
>>
>> Sean
>>
>>
>> On Thu, Jun 4, 2009 at 9:44 PM, Gary C  
>> Martin  wrote:
>>> On 4 Jun 2009, at 16:35, Gary C Martin wrote:
>>>
 On 4 Jun 2009, at 15:45, Sean DALY wrote:

> Yes that would be very helpful I think
 I was just going to start tinkering again, I'll make an animated
 version of Eben's XO and progress-bar for evaluation.
>>> Just uploaded an animated version showing Eben's boot with  
>>> progress bar
>>> treatment:
>>>
>>>
>>>  http://wiki.sugarlabs.org/go/Image:XO-sugar-boot-with-progress-bar.gif
>>>
>>> FWIW: +1 on Eben's suggestion for changing the colour of the Sugar  
>>> logo for
>>> each major new Sugar release. It nicely avoids what looks like  
>>> jumping
>>> through lot's of technical burning hoops of fire, trying to set up  
>>> a boot
>>> anim that dynamically changes to match the owners own colours  
>>> (nice idea but
>>> I think a big ask at this point in time).
>>>
>>> FWIW2: Just incase any one was wondering, the colour dot versions  
>>> were based
>>> on the 1-12 official Sugar Logo treatment colour pairs, i.e  
>>> definitely not
>>> not random :-)
>>>
>>> Regards,
>>> --Gary
>>>
> If we can reach consensus by tomorrow and finish the actual PNG  
> frames
> over the weekend we will meet the deadline
>
> but, we need a volunteer to do the frames (unless Gary what you  
> have
> is nearly ready; my stuff is cut/pasted mockup no color control  
> etc)
 Sure, getting a series of PNGs from any of my mock-ups is just a  
 "save
 for web" away.

 Regards,
 --Gary

> thanks
>
> Sean
>
>
> On Thu, Jun 4, 2009 at 4:40 PM, Christian Marc Schmidt
>   wrote:
>> I agree with Eben's points below...
>>
>> Maybe it would help if one of us mocked up the alternative he is
>> describing?
>>
>> Christian
>>
>>
>> On Jun 4, 2009, at 10:35 AM, Eben Eliason
>> wrote:
>>
>>> On Thu, Jun 4, 2009 at 10:31 AM, Eben Eliason>> wrote:
 On Thu, Jun 4, 2009 at 7:24 AM, Sean DALY
 wrote:
> http://wiki.sugarlabs.org/go/Marketin

Re: [Sugar-devel] I'm looking for a tree...

[Sean DALY]

Have you looked into an awk associative array? I understand it is
stored internally as a hash table. I remember reading about a
simulated multidimensional array (index,subscript); inserting a record
in that case didn't involve any reindexing.

Older awks were considered slow though, I have no idea if that would
be in the running performancewise.

Sean


On Sun, Jun 7, 2009 at 3:39 PM, Benjamin M.
Schwartz wrote:
> James Zaki wrote:
>> Taking a guess with the information you've given perhaps a hash
>> tablecould help?
>
> Python uses the term "Dict" to describe its built-in hash table.  I do
> think a hash table could be helpful, for example, to maintain the reverse
> lookup mapping if the forward lookup is stored in a List (which is
> actually python's version of a dynamic array, like C++'s Vector).
> However, I am still stuck with O(N) performance in this case for insertion
> and deletion, because each such modification shifts the position of all
> subsequent objects.  This would correspond to changing the value
> associated with half the keys in the hash table, on average, for each
> insertion.
>
> I was hoping for a structure with log-time performance.
>
> --Ben
>
>
> ___
> Sugar-devel mailing list
> Sugar-devel@lists.sugarlabs.org
> http://lists.sugarlabs.org/listinfo/sugar-devel
>
>
___
Sugar-devel mailing list
Sugar-devel@lists.sugarlabs.org
http://lists.sugarlabs.org/listinfo/sugar-devel

Re: [Sugar-devel] [IAEP] [Marketing] [SoaS] Request for Artwork: Boot Screen

[Sean DALY]

Yes Gary by all means, the deadline is this weekend

Sebastian, earlier in the thread we discussed how part of keeping a
clean-looking boot involves getting more information (logos) on the
About My Computer page, is that difficult to do?

Sean


On Sun, Jun 7, 2009 at 4:13 PM, Gary C Martin wrote:
> Hi Sebastian,
>
> On 7 Jun 2009, at 14:37, Sebastian Dziallas wrote:
>
>> Hi all,
>>
>> looking at the wiki page, I'm really impressed - great work! :)
>>
>> I also really like the idea of switching the logo color for each release -
>> this shouldn't be hard and is an interesting approach.
>>
>> Has there already been some kind of agreement on which version we're going
>> to use for the LinuxTag release?
>
> Yes I was wondering this also, given the weekend was the deadline :-)
>
>> Is the one with the progress bar something everyone could agree with?
>
> FWIW, my two current favourites are the grey progress bar, or  the grey
> circle of dots:
>
>
>  http://wiki.sugarlabs.org/go/Image:XO-sugar-boot-with-progress-bar.gif
>
>  http://wiki.sugarlabs.org/go/Image:Refined-XO-sugar-boot-with-overlap.gif
>
>> And could I possibly get the .png files, so that I can compose a new
>> snapshot with a preview of the new boot screen (we can still change it
>> afterwards, but I'd like to have some snapshot to test it)?
>
> I don't want to short circuit a decision making process, but let me kick out
> their PNGs and email to you (will do that now). That way you at least have a
> couple of the possible candidates to experiment/test with now.
>
> Regards,
> --Gary
>
>> Walter: Have you heard anything regarding the use of the XO in our boot
>> screen? Is this okay with OLPC?
>>
>> --Sebastian
>>
>> Sean DALY wrote:
>>>
>>> Actually the logo color linked to a version idea was in my long mail
>>> the other day about communicating the version :-)
>>>
>>> I too think 2 changes a year will give us time to cycle through the
>>> twelve variants.
>>>
>>> To make that work, the actual place where the version number is
>>> communicated (Control Panel / About my computer) would need to have
>>> the matching color Sugar Labs (not just Sugar) logo.
>>>
>>> I like this progress bar boot screen because:
>>>
>>> * ultrasimple, unobtrusive, fits perfectly with Sugar HIG
>>> * bar is universally easy to understand, no possibility of confusion
>>> with graphic elements.
>>> * keeping logo around that long=strong branding, which is vital for
>>> Sugar to be recognized by name rather than just "the system" running
>>> on XOs, netbooks, etc.
>>>
>>> I miss the iconic ring treatment though.
>>>
>>> And, no matter how clean we would like it to be, we still need to
>>> address the questions of school/sponsor co-branding (if they have a
>>> logo, they won't feel like jst putting their name in grey) and distro
>>> co-branding.
>>>
>>> Perhaps we could solve those problems by putting them in the "About my
>>> computer" page as well? Awful as far as co-branding goes (partners
>>> would not be happy), but will keep boot minimalist and functional.
>>>
>>> For a shining example of how more-is-less packaging is ruinous, may I
>>> direct your attention to:
>>>
>>> http://www.youtube.com/watch?v=EUXnJraKM3k
>>>
>>> Sean
>>>
>>>
>>> On Thu, Jun 4, 2009 at 9:44 PM, Gary C Martin
>>>  wrote:

 On 4 Jun 2009, at 16:35, Gary C Martin wrote:

> On 4 Jun 2009, at 15:45, Sean DALY wrote:
>
>> Yes that would be very helpful I think
>
> I was just going to start tinkering again, I'll make an animated
> version of Eben's XO and progress-bar for evaluation.

 Just uploaded an animated version showing Eben's boot with progress bar
 treatment:


  http://wiki.sugarlabs.org/go/Image:XO-sugar-boot-with-progress-bar.gif

 FWIW: +1 on Eben's suggestion for changing the colour of the Sugar logo
 for
 each major new Sugar release. It nicely avoids what looks like jumping
 through lot's of technical burning hoops of fire, trying to set up a
 boot
 anim that dynamically changes to match the owners own colours (nice idea
 but
 I think a big ask at this point in time).

 FWIW2: Just incase any one was wondering, the colour dot versions were
 based
 on the 1-12 official Sugar Logo treatment colour pairs, i.e definitely
 not
 not random :-)

 Regards,
 --Gary

>> If we can reach consensus by tomorrow and finish the actual PNG frames
>> over the weekend we will meet the deadline
>>
>> but, we need a volunteer to do the frames (unless Gary what you have
>> is nearly ready; my stuff is cut/pasted mockup no color control etc)
>
> Sure, getting a series of PNGs from any of my mock-ups is just a "save
> for web" away.
>
> Regards,
> --Gary
>
>> thanks
>>
>> Sean
>>
>>
>> On Thu, Jun 4, 2009 at 4:40 PM, Christian Marc Schmidt
>>   wrote:
>>>
>>> I agree with Eben's points below...

Re: [Sugar-devel] [IAEP] [Marketing] [SoaS] Request for Artwork: Boot Screen

[Sebastian Dziallas]

Sean DALY wrote:
> Yes Gary by all means, the deadline is this weekend
>
> Sebastian, earlier in the thread we discussed how part of keeping a
> clean-looking boot involves getting more information (logos) on the
> About My Computer page, is that difficult to do?
>
> Sean

I don't think that it would be that difficult, but it seems like this 
would need to be done in Sugar itself, not SoaS (which is also, why I'm 
not really sure how to realize it). Maybe one of the Sugar devs has an 
idea...

--Sebastian

> On Sun, Jun 7, 2009 at 4:13 PM, Gary C Martin  wrote:
>> Hi Sebastian,
>>
>> On 7 Jun 2009, at 14:37, Sebastian Dziallas wrote:
>>
>>> Hi all,
>>>
>>> looking at the wiki page, I'm really impressed - great work! :)
>>>
>>> I also really like the idea of switching the logo color for each release -
>>> this shouldn't be hard and is an interesting approach.
>>>
>>> Has there already been some kind of agreement on which version we're going
>>> to use for the LinuxTag release?
>> Yes I was wondering this also, given the weekend was the deadline :-)
>>
>>> Is the one with the progress bar something everyone could agree with?
>> FWIW, my two current favourites are the grey progress bar, or  the grey
>> circle of dots:
>>
>>
>>   http://wiki.sugarlabs.org/go/Image:XO-sugar-boot-with-progress-bar.gif
>>
>>   http://wiki.sugarlabs.org/go/Image:Refined-XO-sugar-boot-with-overlap.gif
>>
>>> And could I possibly get the .png files, so that I can compose a new
>>> snapshot with a preview of the new boot screen (we can still change it
>>> afterwards, but I'd like to have some snapshot to test it)?
>> I don't want to short circuit a decision making process, but let me kick out
>> their PNGs and email to you (will do that now). That way you at least have a
>> couple of the possible candidates to experiment/test with now.
>>
>> Regards,
>> --Gary
>>
>>> Walter: Have you heard anything regarding the use of the XO in our boot
>>> screen? Is this okay with OLPC?
>>>
>>> --Sebastian
>>>
>>> Sean DALY wrote:
 Actually the logo color linked to a version idea was in my long mail
 the other day about communicating the version :-)

 I too think 2 changes a year will give us time to cycle through the
 twelve variants.

 To make that work, the actual place where the version number is
 communicated (Control Panel / About my computer) would need to have
 the matching color Sugar Labs (not just Sugar) logo.

 I like this progress bar boot screen because:

 * ultrasimple, unobtrusive, fits perfectly with Sugar HIG
 * bar is universally easy to understand, no possibility of confusion
 with graphic elements.
 * keeping logo around that long=strong branding, which is vital for
 Sugar to be recognized by name rather than just "the system" running
 on XOs, netbooks, etc.

 I miss the iconic ring treatment though.

 And, no matter how clean we would like it to be, we still need to
 address the questions of school/sponsor co-branding (if they have a
 logo, they won't feel like jst putting their name in grey) and distro
 co-branding.

 Perhaps we could solve those problems by putting them in the "About my
 computer" page as well? Awful as far as co-branding goes (partners
 would not be happy), but will keep boot minimalist and functional.

 For a shining example of how more-is-less packaging is ruinous, may I
 direct your attention to:

 http://www.youtube.com/watch?v=EUXnJraKM3k

 Sean


 On Thu, Jun 4, 2009 at 9:44 PM, Gary C Martin
   wrote:
> On 4 Jun 2009, at 16:35, Gary C Martin wrote:
>
>> On 4 Jun 2009, at 15:45, Sean DALY wrote:
>>
>>> Yes that would be very helpful I think
>> I was just going to start tinkering again, I'll make an animated
>> version of Eben's XO and progress-bar for evaluation.
> Just uploaded an animated version showing Eben's boot with progress bar
> treatment:
>
>
>   http://wiki.sugarlabs.org/go/Image:XO-sugar-boot-with-progress-bar.gif
>
> FWIW: +1 on Eben's suggestion for changing the colour of the Sugar logo
> for
> each major new Sugar release. It nicely avoids what looks like jumping
> through lot's of technical burning hoops of fire, trying to set up a
> boot
> anim that dynamically changes to match the owners own colours (nice idea
> but
> I think a big ask at this point in time).
>
> FWIW2: Just incase any one was wondering, the colour dot versions were
> based
> on the 1-12 official Sugar Logo treatment colour pairs, i.e definitely
> not
> not random :-)
>
> Regards,
> --Gary
>
>>> If we can reach consensus by tomorrow and finish the actual PNG frames
>>> over the weekend we will meet the deadline
>>>
>>> but, we need a volunteer to do the frames (unless Gary what you have
>>> is nearly ready; my stuff i

Re: [Sugar-devel] I'm looking for a tree...

[Lucian Branescu]

This http://www.python.org/dev/peps/pep-0372/ might be interesting.
Perhaps it could get backported to 2.5.

But it still has O(n) deletion.

2009/6/7 Benjamin M. Schwartz :
> James Zaki wrote:
>> Taking a guess with the information you've given perhaps a hash
>> tablecould help?
>
> Python uses the term "Dict" to describe its built-in hash table.  I do
> think a hash table could be helpful, for example, to maintain the reverse
> lookup mapping if the forward lookup is stored in a List (which is
> actually python's version of a dynamic array, like C++'s Vector).
> However, I am still stuck with O(N) performance in this case for insertion
> and deletion, because each such modification shifts the position of all
> subsequent objects.  This would correspond to changing the value
> associated with half the keys in the hash table, on average, for each
> insertion.
>
> I was hoping for a structure with log-time performance.
>
> --Ben
>
>
> ___
> Sugar-devel mailing list
> Sugar-devel@lists.sugarlabs.org
> http://lists.sugarlabs.org/listinfo/sugar-devel
>
>
___
Sugar-devel mailing list
Sugar-devel@lists.sugarlabs.org
http://lists.sugarlabs.org/listinfo/sugar-devel

Re: [Sugar-devel] I'm looking for a tree...

[Benjamin M. Schwartz]

Lucian Branescu wrote:
> This http://www.python.org/dev/peps/pep-0372/ might be interesting.
> Perhaps it could get backported to 2.5.
> 
> But it still has O(n) deletion.

It also doesn't have insertion at all (only append), and indexing (and
reverse indexing) is O(n).

--Ben



signature.asc
Description: OpenPGP digital signature
___
Sugar-devel mailing list
Sugar-devel@lists.sugarlabs.org
http://lists.sugarlabs.org/listinfo/sugar-devel

Re: [Sugar-devel] I'm looking for a tree...

[Carol Farlow Lerche]

hash chaining only approaches order n if the table is very full (because of
collisions).

On Sun, Jun 7, 2009 at 8:07 AM, Benjamin M. Schwartz <
bmsch...@fas.harvard.edu> wrote:

> Lucian Branescu wrote:
> > This http://www.python.org/dev/peps/pep-0372/ might be interesting.
> > Perhaps it could get backported to 2.5.
> >
> > But it still has O(n) deletion.
>
> It also doesn't have insertion at all (only append), and indexing (and
> reverse indexing) is O(n).
>
> --Ben
>
>
> ___
> Sugar-devel mailing list
> Sugar-devel@lists.sugarlabs.org
> http://lists.sugarlabs.org/listinfo/sugar-devel
>
>
___
Sugar-devel mailing list
Sugar-devel@lists.sugarlabs.org
http://lists.sugarlabs.org/listinfo/sugar-devel

Re: [Sugar-devel] Getting data about the upgrading older machines and SoaS responsiveness.

[Frederick Grose]

On Sun, Jun 7, 2009 at 10:07 AM, Caroline Meeks
wrote:

> Let me echo Caryl's question. Do we have a page with tasks for new
> volunteers?
>

http://wiki.sugarlabs.org/go/Sugar_on_a_Stick/TODO has been restored and is
ready to be updated, perhaps restructured to cover this need.

 --Fred
___
Sugar-devel mailing list
Sugar-devel@lists.sugarlabs.org
http://lists.sugarlabs.org/listinfo/sugar-devel

Re: [Sugar-devel] I'm looking for a tree...

[Lucian Branescu]

Would an ordered dictionary otherwise be all right, or am I
misunderstanding your requirements? There are other implementations,
like http://www.xs4all.nl/~anthon/Python/ordereddict/

2009/6/7 Benjamin M. Schwartz :
> Lucian Branescu wrote:
>> This http://www.python.org/dev/peps/pep-0372/ might be interesting.
>> Perhaps it could get backported to 2.5.
>>
>> But it still has O(n) deletion.
>
> It also doesn't have insertion at all (only append), and indexing (and
> reverse indexing) is O(n).
>
> --Ben
>
>
___
Sugar-devel mailing list
Sugar-devel@lists.sugarlabs.org
http://lists.sugarlabs.org/listinfo/sugar-devel

Re: [Sugar-devel] I'm looking for a tree...

[Benjamin M. Schwartz]

Lucian Branescu wrote:
> Would an ordered dictionary otherwise be all right, or am I
> misunderstanding your requirements? There are other implementations,
> like http://www.xs4all.nl/~anthon/Python/ordereddict/

No, an ordered dictionary is not enough.  All these ordered dictionaries
are ordered either by time or by sorting the keys.  Neither will work for
me.  The problem is simple: if I insert something at position 5, I need
the object currently at position 5 to move to position 6, and the object
currently at position 6 to move to position 7, etc.

To accomplish this in an time-ordered odict, I would have to remove all
keys subsequent to the insertion point, make the insertion, and then
re-insert those keys.  That's O(n).

To accomplish this in a sorted-order odict, I would have to generate a new
key that causes my insertion to occur at the right location.  If there are
repeated insertions at the same location, generating such keys becomes an
O(n) operation.  To see this, suppose I am repeatedly inserting at the
second position.  Initially, the keys are (0,1).  The first insertion has
to pick a key between 0 and 1, e.g. 0.5.  The second insertion has to pick
a key between 0 and 0.5: e.g. 0.25.  The number of bits required to store
these keys to sufficient precision increases by one bit on each insertion.
 This means that the length of the keys is O(n), so every comparison is O(n).

--Ben



signature.asc
Description: OpenPGP digital signature
___
Sugar-devel mailing list
Sugar-devel@lists.sugarlabs.org
http://lists.sugarlabs.org/listinfo/sugar-devel

Re: [Sugar-devel] [GSoC] SSB creator

[Lucian Branescu]

1. I don't really want to zip it if I can avoid it. If I do zip it and
get an .xo, how can I add it to the Journal programatically?

2. I've changed that. All SSBs are subdomains to org.sugarlabs.ssb
(like org.sugarlabs.ssb.GMailActivity)

2009/6/7 Bobby Powers :
> On Sat, Jun 6, 2009 at 9:57 PM, Lucian
> Branescu wrote:
>> For my project, I will extend Browse with the ability to create SSBs.
>> Read more here http://honeyweb.wordpress.com/2009/06/06/the-user-experience/
>>
>> I have made a small script that is triggered by a button in the Browse
>> toolbar. It also works from Terminal.
>>
>> Later on this script will do more things, but I'd like some feedback
>> about it as early as possible.
>
> Hi Lucian,
>
> 2 things:
>
> 1) rainbow should prevent you from creating new activities in
> ~/Activities, so I don't think that approach would work on an XO with
> an OLPC build.  Since I think what you want is to create an activity,
> zip it, and add it to the journal, you could probably do something
> like this:
> import tempfile
> ssb_path = tempfile.mkdtmp(dir=activity.get_activity_root())
>
> 2) the bundle_id you create probably should begin with org.laptop , as
> that could cause collisions with other activities.  maybe
> org.sugarlabs.ssb ?
>
> nice start so far!
>
> bobby
>
___
Sugar-devel mailing list
Sugar-devel@lists.sugarlabs.org
http://lists.sugarlabs.org/listinfo/sugar-devel

Re: [Sugar-devel] [IAEP] Getting data about the upgrading older machines and SoaS responsiveness.

[David Van Assche]

When it come to older pcs, it really makes sense to try and use LTSP. We
have created a kiwi-ltsp usb stick for openSUSE, which gives a portable ltsp
server wherever u plug it in. In most cases it would make sense for this to
be the most powerful computer. It is as easy as installing the sugar and
sugar activities meta packages on this usb image and the users on the ltsp
network then have access to Sugar from any computer in the network, and they
are bound to load faster than from a usb image. The advantage is u need one
usb stick per network, as opposed to one for each terminal... that saves
costs, and time. Also, u dont need any of the old hardware, such as cdrom
drives, hard drives, etc. Networking and internet is also no issue as if it
works on the server, it has to work on each of the terminals too...

kind Regards,
David (nubae) Van Assche

On Sun, Jun 7, 2009 at 5:27 PM, Frederick Grose  wrote:

>
> On Sun, Jun 7, 2009 at 10:07 AM, Caroline Meeks <
> carol...@solutiongrove.com> wrote:
>
>> Let me echo Caryl's question. Do we have a page with tasks for new
>> volunteers?
>>
>
> http://wiki.sugarlabs.org/go/Sugar_on_a_Stick/TODO has been restored and
> is ready to be updated, perhaps restructured to cover this need.
>
>  --Fred
>
> ___
> IAEP -- It's An Education Project (not a laptop project!)
> i...@lists.sugarlabs.org
> http://lists.sugarlabs.org/listinfo/iaep
>
___
Sugar-devel mailing list
Sugar-devel@lists.sugarlabs.org
http://lists.sugarlabs.org/listinfo/sugar-devel

Re: [Sugar-devel] [GSoC] SSB creator

[Gary C Martin]

On 7 Jun 2009, at 18:18, Lucian Branescu wrote:

> 1. I don't really want to zip it if I can avoid it. If I do zip it and
> get an .xo, how can I add it to the Journal programatically?
> 2. I've changed that. All SSBs are subdomains to org.sugarlabs.ssb
> (like org.sugarlabs.ssb.GMailActivity)
>
> 2009/6/7 Bobby Powers :
>> On Sat, Jun 6, 2009 at 9:57 PM, Lucian
>> Branescu wrote:
>>> For my project, I will extend Browse with the ability to create  
>>> SSBs.
>>> Read more here http://honeyweb.wordpress.com/2009/06/06/the-user-experience/
>>>
>>> I have made a small script that is triggered by a button in the  
>>> Browse
>>> toolbar. It also works from Terminal.
>>>
>>> Later on this script will do more things, but I'd like some feedback
>>> about it as early as possible.

Just wanted to flag an item that might be of interest to you on the  
0.86 Browse roadmap "export for offline viewing (Web page - HTML only,  
Web page - Complete)":


http://wiki.sugarlabs.org/go/Development_Team/Release/Roadmap/0.86#Browse

I know this doesn't make a first class 'Activity' out of a page, but  
seems to have quite a feature overlap with your project. It would  
allow Browse to keep any page to the Journal so it can be resumed off- 
line and/or distributed to other users (via Journal entry sharing  
already in 0.84). It would also allow content providers an easy way to  
create and distribute more complicates/deep html/css/javascript/flash  
type rich web sites/pages by just zipping them up.

Regards,
--Gary

>> Hi Lucian,
>>
>> 2 things:
>>
>> 1) rainbow should prevent you from creating new activities in
>> ~/Activities, so I don't think that approach would work on an XO with
>> an OLPC build.  Since I think what you want is to create an activity,
>> zip it, and add it to the journal, you could probably do something
>> like this:
>> import tempfile
>> ssb_path = tempfile.mkdtmp(dir=activity.get_activity_root())
>>
>> 2) the bundle_id you create probably should begin with org.laptop ,  
>> as
>> that could cause collisions with other activities.  maybe
>> org.sugarlabs.ssb ?
>>
>> nice start so far!
>>
>> bobby
>>
> ___
> Sugar-devel mailing list
> Sugar-devel@lists.sugarlabs.org
> http://lists.sugarlabs.org/listinfo/sugar-devel

___
Sugar-devel mailing list
Sugar-devel@lists.sugarlabs.org
http://lists.sugarlabs.org/listinfo/sugar-devel

Re: [Sugar-devel] [IAEP] Getting data about the upgrading older machines and SoaS responsiveness.

[David Farning]

On Sun, Jun 7, 2009 at 12:24 PM, David Van Assche wrote:
> When it come to older pcs, it really makes sense to try and use LTSP. We
> have created a kiwi-ltsp usb stick for openSUSE, which gives a portable ltsp
> server wherever u plug it in. In most cases it would make sense for this to
> be the most powerful computer. It is as easy as installing the sugar and
> sugar activities meta packages on this usb image and the users on the ltsp
> network then have access to Sugar from any computer in the network, and they
> are bound to load faster than from a usb image. The advantage is u need one
> usb stick per network, as opposed to one for each terminal... that saves
> costs, and time. Also, u dont need any of the old hardware, such as cdrom
> drives, hard drives, etc. Networking and internet is also no issue as if it
> works on the server, it has to work on each of the terminals too...

SoaS is also working on a slightly different issue.

I didn't understand it until Caroline explained it for about the 100th
time yesterday:)

In addition to all the technical hurdles.  Sugar on a Stick is
tackling the _bureaucratic_ issue of installing and running Sugar (or
any software) on systems which one doesn't have admin access.

In many schools it can be difficult to get the authority to install
software or modify the configuration on their computers.  SoaS
circumvents that problem by replacing  'install a new OS' with 'insert
the stick and turn it on.'

The piece that I was _misunderstanding_ was that all of the
technically hurdles that SoaS introduces are worth the ability to
circumvent the bureaucratic hurdles.

FWIW, at least in developed nations Once you get the bureaucratic
permission to 'install' Sugar, a client-server configuration is most
palatable to the existing generation of elementary school sysadmins.

david

> kind Regards,
> David (nubae) Van Assche
>
> On Sun, Jun 7, 2009 at 5:27 PM, Frederick Grose  wrote:
>>
>> On Sun, Jun 7, 2009 at 10:07 AM, Caroline Meeks
>>  wrote:
>>>
>>> Let me echo Caryl's question. Do we have a page with tasks for new
>>> volunteers?
>>
>> http://wiki.sugarlabs.org/go/Sugar_on_a_Stick/TODO has been restored and
>> is ready to be updated, perhaps restructured to cover this need.
>>
>>  --Fred
>>
>> ___
>> IAEP -- It's An Education Project (not a laptop project!)
>> i...@lists.sugarlabs.org
>> http://lists.sugarlabs.org/listinfo/iaep
>
>
> ___
> IAEP -- It's An Education Project (not a laptop project!)
> i...@lists.sugarlabs.org
> http://lists.sugarlabs.org/listinfo/iaep
>
___
Sugar-devel mailing list
Sugar-devel@lists.sugarlabs.org
http://lists.sugarlabs.org/listinfo/sugar-devel

Re: [Sugar-devel] [GSoC] SSB creator

[Carol Farlow Lerche]

Also something new and related in Mozilla land:

https://jetpack.mozillalabs.com/

On Sun, Jun 7, 2009 at 11:07 AM, Gary C Martin  wrote:

> On 7 Jun 2009, at 18:18, Lucian Branescu wrote:
>
> > 1. I don't really want to zip it if I can avoid it. If I do zip it and
> > get an .xo, how can I add it to the Journal programatically?
> > 2. I've changed that. All SSBs are subdomains to org.sugarlabs.ssb
> > (like org.sugarlabs.ssb.GMailActivity)
> >
> > 2009/6/7 Bobby Powers :
> >> On Sat, Jun 6, 2009 at 9:57 PM, Lucian
> >> Branescu wrote:
> >>> For my project, I will extend Browse with the ability to create
> >>> SSBs.
> >>> Read more here
> http://honeyweb.wordpress.com/2009/06/06/the-user-experience/
> >>>
> >>> I have made a small script that is triggered by a button in the
> >>> Browse
> >>> toolbar. It also works from Terminal.
> >>>
> >>> Later on this script will do more things, but I'd like some feedback
> >>> about it as early as possible.
>
> Just wanted to flag an item that might be of interest to you on the
> 0.86 Browse roadmap "export for offline viewing (Web page - HTML only,
> Web page - Complete)":
>
>
> http://wiki.sugarlabs.org/go/Development_Team/Release/Roadmap/0.86#Browse
>
> I know this doesn't make a first class 'Activity' out of a page, but
> seems to have quite a feature overlap with your project. It would
> allow Browse to keep any page to the Journal so it can be resumed off-
> line and/or distributed to other users (via Journal entry sharing
> already in 0.84). It would also allow content providers an easy way to
> create and distribute more complicates/deep html/css/javascript/flash
> type rich web sites/pages by just zipping them up.
>
> Regards,
> --Gary
>
> >> Hi Lucian,
> >>
> >> 2 things:
> >>
> >> 1) rainbow should prevent you from creating new activities in
> >> ~/Activities, so I don't think that approach would work on an XO with
> >> an OLPC build.  Since I think what you want is to create an activity,
> >> zip it, and add it to the journal, you could probably do something
> >> like this:
> >> import tempfile
> >> ssb_path = tempfile.mkdtmp(dir=activity.get_activity_root())
> >>
> >> 2) the bundle_id you create probably should begin with org.laptop ,
> >> as
> >> that could cause collisions with other activities.  maybe
> >> org.sugarlabs.ssb ?
> >>
> >> nice start so far!
> >>
> >> bobby
> >>
> > ___
> > Sugar-devel mailing list
> > Sugar-devel@lists.sugarlabs.org
> > http://lists.sugarlabs.org/listinfo/sugar-devel
>
> ___
> Sugar-devel mailing list
> Sugar-devel@lists.sugarlabs.org
> http://lists.sugarlabs.org/listinfo/sugar-devel
>
___
Sugar-devel mailing list
Sugar-devel@lists.sugarlabs.org
http://lists.sugarlabs.org/listinfo/sugar-devel

Re: [Sugar-devel] [GSoC] SSB creator

[Lucian Branescu]

Jetpack is not directly related. It is in fact very similar to
Chrome's extension API.

2009/6/7 Carol Farlow Lerche :
> Also something new and related in Mozilla land:
>
> https://jetpack.mozillalabs.com/
>
> On Sun, Jun 7, 2009 at 11:07 AM, Gary C Martin  wrote:
>>
>> On 7 Jun 2009, at 18:18, Lucian Branescu wrote:
>>
>> > 1. I don't really want to zip it if I can avoid it. If I do zip it and
>> > get an .xo, how can I add it to the Journal programatically?
>> > 2. I've changed that. All SSBs are subdomains to org.sugarlabs.ssb
>> > (like org.sugarlabs.ssb.GMailActivity)
>> >
>> > 2009/6/7 Bobby Powers :
>> >> On Sat, Jun 6, 2009 at 9:57 PM, Lucian
>> >> Branescu wrote:
>> >>> For my project, I will extend Browse with the ability to create
>> >>> SSBs.
>> >>> Read more here
>> >>> http://honeyweb.wordpress.com/2009/06/06/the-user-experience/
>> >>>
>> >>> I have made a small script that is triggered by a button in the
>> >>> Browse
>> >>> toolbar. It also works from Terminal.
>> >>>
>> >>> Later on this script will do more things, but I'd like some feedback
>> >>> about it as early as possible.
>>
>> Just wanted to flag an item that might be of interest to you on the
>> 0.86 Browse roadmap "export for offline viewing (Web page - HTML only,
>> Web page - Complete)":
>>
>>
>>  http://wiki.sugarlabs.org/go/Development_Team/Release/Roadmap/0.86#Browse
>>
>> I know this doesn't make a first class 'Activity' out of a page, but
>> seems to have quite a feature overlap with your project. It would
>> allow Browse to keep any page to the Journal so it can be resumed off-
>> line and/or distributed to other users (via Journal entry sharing
>> already in 0.84). It would also allow content providers an easy way to
>> create and distribute more complicates/deep html/css/javascript/flash
>> type rich web sites/pages by just zipping them up.
>>
>> Regards,
>> --Gary
>>
>> >> Hi Lucian,
>> >>
>> >> 2 things:
>> >>
>> >> 1) rainbow should prevent you from creating new activities in
>> >> ~/Activities, so I don't think that approach would work on an XO with
>> >> an OLPC build.  Since I think what you want is to create an activity,
>> >> zip it, and add it to the journal, you could probably do something
>> >> like this:
>> >> import tempfile
>> >> ssb_path = tempfile.mkdtmp(dir=activity.get_activity_root())
>> >>
>> >> 2) the bundle_id you create probably should begin with org.laptop ,
>> >> as
>> >> that could cause collisions with other activities.  maybe
>> >> org.sugarlabs.ssb ?
>> >>
>> >> nice start so far!
>> >>
>> >> bobby
>> >>
>> > ___
>> > Sugar-devel mailing list
>> > Sugar-devel@lists.sugarlabs.org
>> > http://lists.sugarlabs.org/listinfo/sugar-devel
>>
>> ___
>> Sugar-devel mailing list
>> Sugar-devel@lists.sugarlabs.org
>> http://lists.sugarlabs.org/listinfo/sugar-devel
>
>
___
Sugar-devel mailing list
Sugar-devel@lists.sugarlabs.org
http://lists.sugarlabs.org/listinfo/sugar-devel

Re: [Sugar-devel] [GSoC] SSB creator

[Carol Farlow Lerche]

Much more standard and simpler than the xpi framework, I think.  Jetpacks
are html, javascript and css, expect you to use canvas and audio, with the
underlying jetpack packaged with jquery.

On Sun, Jun 7, 2009 at 12:30 PM, Lucian Branescu
wrote:

> Jetpack is not directly related. It is in fact very similar to
> Chrome's extension API.
>
> 2009/6/7 Carol Farlow Lerche :
> > Also something new and related in Mozilla land:
> >
> > https://jetpack.mozillalabs.com/
> >
> > On Sun, Jun 7, 2009 at 11:07 AM, Gary C Martin 
> wrote:
> >>
> >> On 7 Jun 2009, at 18:18, Lucian Branescu wrote:
> >>
> >> > 1. I don't really want to zip it if I can avoid it. If I do zip it and
> >> > get an .xo, how can I add it to the Journal programatically?
> >> > 2. I've changed that. All SSBs are subdomains to org.sugarlabs.ssb
> >> > (like org.sugarlabs.ssb.GMailActivity)
> >> >
> >> > 2009/6/7 Bobby Powers :
> >> >> On Sat, Jun 6, 2009 at 9:57 PM, Lucian
> >> >> Branescu wrote:
> >> >>> For my project, I will extend Browse with the ability to create
> >> >>> SSBs.
> >> >>> Read more here
> >> >>> http://honeyweb.wordpress.com/2009/06/06/the-user-experience/
> >> >>>
> >> >>> I have made a small script that is triggered by a button in the
> >> >>> Browse
> >> >>> toolbar. It also works from Terminal.
> >> >>>
> >> >>> Later on this script will do more things, but I'd like some feedback
> >> >>> about it as early as possible.
> >>
> >> Just wanted to flag an item that might be of interest to you on the
> >> 0.86 Browse roadmap "export for offline viewing (Web page - HTML only,
> >> Web page - Complete)":
> >>
> >>
> >>
> http://wiki.sugarlabs.org/go/Development_Team/Release/Roadmap/0.86#Browse
> >>
> >> I know this doesn't make a first class 'Activity' out of a page, but
> >> seems to have quite a feature overlap with your project. It would
> >> allow Browse to keep any page to the Journal so it can be resumed off-
> >> line and/or distributed to other users (via Journal entry sharing
> >> already in 0.84). It would also allow content providers an easy way to
> >> create and distribute more complicates/deep html/css/javascript/flash
> >> type rich web sites/pages by just zipping them up.
> >>
> >> Regards,
> >> --Gary
> >>
> >> >> Hi Lucian,
> >> >>
> >> >> 2 things:
> >> >>
> >> >> 1) rainbow should prevent you from creating new activities in
> >> >> ~/Activities, so I don't think that approach would work on an XO with
> >> >> an OLPC build.  Since I think what you want is to create an activity,
> >> >> zip it, and add it to the journal, you could probably do something
> >> >> like this:
> >> >> import tempfile
> >> >> ssb_path = tempfile.mkdtmp(dir=activity.get_activity_root())
> >> >>
> >> >> 2) the bundle_id you create probably should begin with org.laptop ,
> >> >> as
> >> >> that could cause collisions with other activities.  maybe
> >> >> org.sugarlabs.ssb ?
> >> >>
> >> >> nice start so far!
> >> >>
> >> >> bobby
> >> >>
> >> > ___
> >> > Sugar-devel mailing list
> >> > Sugar-devel@lists.sugarlabs.org
> >> > http://lists.sugarlabs.org/listinfo/sugar-devel
> >>
> >> ___
> >> Sugar-devel mailing list
> >> Sugar-devel@lists.sugarlabs.org
> >> http://lists.sugarlabs.org/listinfo/sugar-devel
> >
> >
>
___
Sugar-devel mailing list
Sugar-devel@lists.sugarlabs.org
http://lists.sugarlabs.org/listinfo/sugar-devel

Re: [Sugar-devel] [GSoC] SSB creator

[Lucian Branescu]

Yes, VERY similar to Chrome extensions. I was in fact hoping for
something similar for Firefox when I read about Chrome extensions. It
would be very nice if we could get Jetpack working nicely in Browse,
but that's outside the scope of my GSoC.

After a chat with bemasc, I have a much more clear picture about the
life on an SSB. I'll write it up asap.


2009/6/7 Carol Farlow Lerche :
> Much more standard and simpler than the xpi framework, I think.  Jetpacks
> are html, javascript and css, expect you to use canvas and audio, with the
> underlying jetpack packaged with jquery.
>
> On Sun, Jun 7, 2009 at 12:30 PM, Lucian Branescu 
> wrote:
>>
>> Jetpack is not directly related. It is in fact very similar to
>> Chrome's extension API.
>>
>> 2009/6/7 Carol Farlow Lerche :
>> > Also something new and related in Mozilla land:
>> >
>> > https://jetpack.mozillalabs.com/
>> >
>> > On Sun, Jun 7, 2009 at 11:07 AM, Gary C Martin 
>> > wrote:
>> >>
>> >> On 7 Jun 2009, at 18:18, Lucian Branescu wrote:
>> >>
>> >> > 1. I don't really want to zip it if I can avoid it. If I do zip it
>> >> > and
>> >> > get an .xo, how can I add it to the Journal programatically?
>> >> > 2. I've changed that. All SSBs are subdomains to org.sugarlabs.ssb
>> >> > (like org.sugarlabs.ssb.GMailActivity)
>> >> >
>> >> > 2009/6/7 Bobby Powers :
>> >> >> On Sat, Jun 6, 2009 at 9:57 PM, Lucian
>> >> >> Branescu wrote:
>> >> >>> For my project, I will extend Browse with the ability to create
>> >> >>> SSBs.
>> >> >>> Read more here
>> >> >>> http://honeyweb.wordpress.com/2009/06/06/the-user-experience/
>> >> >>>
>> >> >>> I have made a small script that is triggered by a button in the
>> >> >>> Browse
>> >> >>> toolbar. It also works from Terminal.
>> >> >>>
>> >> >>> Later on this script will do more things, but I'd like some
>> >> >>> feedback
>> >> >>> about it as early as possible.
>> >>
>> >> Just wanted to flag an item that might be of interest to you on the
>> >> 0.86 Browse roadmap "export for offline viewing (Web page - HTML only,
>> >> Web page - Complete)":
>> >>
>> >>
>> >>
>> >>  http://wiki.sugarlabs.org/go/Development_Team/Release/Roadmap/0.86#Browse
>> >>
>> >> I know this doesn't make a first class 'Activity' out of a page, but
>> >> seems to have quite a feature overlap with your project. It would
>> >> allow Browse to keep any page to the Journal so it can be resumed off-
>> >> line and/or distributed to other users (via Journal entry sharing
>> >> already in 0.84). It would also allow content providers an easy way to
>> >> create and distribute more complicates/deep html/css/javascript/flash
>> >> type rich web sites/pages by just zipping them up.
>> >>
>> >> Regards,
>> >> --Gary
>> >>
>> >> >> Hi Lucian,
>> >> >>
>> >> >> 2 things:
>> >> >>
>> >> >> 1) rainbow should prevent you from creating new activities in
>> >> >> ~/Activities, so I don't think that approach would work on an XO
>> >> >> with
>> >> >> an OLPC build.  Since I think what you want is to create an
>> >> >> activity,
>> >> >> zip it, and add it to the journal, you could probably do something
>> >> >> like this:
>> >> >> import tempfile
>> >> >> ssb_path = tempfile.mkdtmp(dir=activity.get_activity_root())
>> >> >>
>> >> >> 2) the bundle_id you create probably should begin with org.laptop ,
>> >> >> as
>> >> >> that could cause collisions with other activities.  maybe
>> >> >> org.sugarlabs.ssb ?
>> >> >>
>> >> >> nice start so far!
>> >> >>
>> >> >> bobby
>> >> >>
>> >> > ___
>> >> > Sugar-devel mailing list
>> >> > Sugar-devel@lists.sugarlabs.org
>> >> > http://lists.sugarlabs.org/listinfo/sugar-devel
>> >>
>> >> ___
>> >> Sugar-devel mailing list
>> >> Sugar-devel@lists.sugarlabs.org
>> >> http://lists.sugarlabs.org/listinfo/sugar-devel
>> >
>> >
>
>
___
Sugar-devel mailing list
Sugar-devel@lists.sugarlabs.org
http://lists.sugarlabs.org/listinfo/sugar-devel

Re: [Sugar-devel] [IAEP] Getting data about the upgrading older machines and SoaS responsiveness.

[David Van Assche]

That's a good point, and I understand the thinking behind it, as if you are
not 'changing' anything in an existing setup, people are less afraid that
things might go terribly wrong. That's the reason we have ltsp on a usb
stick... because you can stick in a server, and test it without installing
anything. Think of it as SoaS server with beaurocratic advantages included
(taking care of networking, providing Sugar images, setting up user
accounts, providng collaboration if necessary. It is by no means the XS
server, nor should it try to be that, its just the desktop environment part
with ejabberd, if needed.. of course, it only works in wired environments.

kind Regards,
David (nubae) Van Assche

On Sun, Jun 7, 2009 at 8:19 PM, David Farning wrote:

> On Sun, Jun 7, 2009 at 12:24 PM, David Van Assche
> wrote:
> > When it come to older pcs, it really makes sense to try and use LTSP. We
> > have created a kiwi-ltsp usb stick for openSUSE, which gives a portable
> ltsp
> > server wherever u plug it in. In most cases it would make sense for this
> to
> > be the most powerful computer. It is as easy as installing the sugar and
> > sugar activities meta packages on this usb image and the users on the
> ltsp
> > network then have access to Sugar from any computer in the network, and
> they
> > are bound to load faster than from a usb image. The advantage is u need
> one
> > usb stick per network, as opposed to one for each terminal... that saves
> > costs, and time. Also, u dont need any of the old hardware, such as cdrom
> > drives, hard drives, etc. Networking and internet is also no issue as if
> it
> > works on the server, it has to work on each of the terminals too...
>
> SoaS is also working on a slightly different issue.
>
> I didn't understand it until Caroline explained it for about the 100th
> time yesterday:)
>
> In addition to all the technical hurdles.  Sugar on a Stick is
> tackling the _bureaucratic_ issue of installing and running Sugar (or
> any software) on systems which one doesn't have admin access.
>
> In many schools it can be difficult to get the authority to install
> software or modify the configuration on their computers.  SoaS
> circumvents that problem by replacing  'install a new OS' with 'insert
> the stick and turn it on.'
>
> The piece that I was _misunderstanding_ was that all of the
> technically hurdles that SoaS introduces are worth the ability to
> circumvent the bureaucratic hurdles.
>
> FWIW, at least in developed nations Once you get the bureaucratic
> permission to 'install' Sugar, a client-server configuration is most
> palatable to the existing generation of elementary school sysadmins.
>
> david
>
> > kind Regards,
> > David (nubae) Van Assche
> >
> > On Sun, Jun 7, 2009 at 5:27 PM, Frederick Grose 
> wrote:
> >>
> >> On Sun, Jun 7, 2009 at 10:07 AM, Caroline Meeks
> >>  wrote:
> >>>
> >>> Let me echo Caryl's question. Do we have a page with tasks for new
> >>> volunteers?
> >>
> >> http://wiki.sugarlabs.org/go/Sugar_on_a_Stick/TODO has been restored
> and
> >> is ready to be updated, perhaps restructured to cover this need.
> >>
> >>  --Fred
> >>
> >> ___
> >> IAEP -- It's An Education Project (not a laptop project!)
> >> i...@lists.sugarlabs.org
> >> http://lists.sugarlabs.org/listinfo/iaep
> >
> >
> > ___
> > IAEP -- It's An Education Project (not a laptop project!)
> > i...@lists.sugarlabs.org
> > http://lists.sugarlabs.org/listinfo/iaep
> >
>
___
Sugar-devel mailing list
Sugar-devel@lists.sugarlabs.org
http://lists.sugarlabs.org/listinfo/sugar-devel

Re: [Sugar-devel] [IAEP] Getting data about the upgrading older machines and SoaS responsiveness.

[Caroline Meeks]

Thanks David great explanation.

and David, I totally agree that LTSP is the right technical solution for
this computer lab. Next year, perhaps we will have the level of trust and
political clout to implement it.

There is yet another reason I want to know if we can speed up these
computers and ones like it.

Part of the Sugar on a Stick vision is the kids having a computer at home.
So next year, when we replace the computer lab with LTSP, we will probably
send the existing boxes home with kids who don't have computers.  If for
less then $10 and a hour of volunteer time we can send a kid home with a
snappy system vs a pokey one, I think that is totally worth it and that we
will not have trouble finding the volunteers to do the work.

On Sun, Jun 7, 2009 at 2:19 PM, David Farning wrote:

> On Sun, Jun 7, 2009 at 12:24 PM, David Van Assche
> wrote:
> > When it come to older pcs, it really makes sense to try and use LTSP. We
> > have created a kiwi-ltsp usb stick for openSUSE, which gives a portable
> ltsp
> > server wherever u plug it in. In most cases it would make sense for this
> to
> > be the most powerful computer. It is as easy as installing the sugar and
> > sugar activities meta packages on this usb image and the users on the
> ltsp
> > network then have access to Sugar from any computer in the network, and
> they
> > are bound to load faster than from a usb image. The advantage is u need
> one
> > usb stick per network, as opposed to one for each terminal... that saves
> > costs, and time. Also, u dont need any of the old hardware, such as cdrom
> > drives, hard drives, etc. Networking and internet is also no issue as if
> it
> > works on the server, it has to work on each of the terminals too...
>
> SoaS is also working on a slightly different issue.
>
> I didn't understand it until Caroline explained it for about the 100th
> time yesterday:)
>
> In addition to all the technical hurdles.  Sugar on a Stick is
> tackling the _bureaucratic_ issue of installing and running Sugar (or
> any software) on systems which one doesn't have admin access.
>
> In many schools it can be difficult to get the authority to install
> software or modify the configuration on their computers.  SoaS
> circumvents that problem by replacing  'install a new OS' with 'insert
> the stick and turn it on.'
>
> The piece that I was _misunderstanding_ was that all of the
> technically hurdles that SoaS introduces are worth the ability to
> circumvent the bureaucratic hurdles.
>
> FWIW, at least in developed nations Once you get the bureaucratic
> permission to 'install' Sugar, a client-server configuration is most
> palatable to the existing generation of elementary school sysadmins.
>
> david
>
> > kind Regards,
> > David (nubae) Van Assche
> >
> > On Sun, Jun 7, 2009 at 5:27 PM, Frederick Grose 
> wrote:
> >>
> >> On Sun, Jun 7, 2009 at 10:07 AM, Caroline Meeks
> >>  wrote:
> >>>
> >>> Let me echo Caryl's question. Do we have a page with tasks for new
> >>> volunteers?
> >>
> >> http://wiki.sugarlabs.org/go/Sugar_on_a_Stick/TODO has been restored
> and
> >> is ready to be updated, perhaps restructured to cover this need.
> >>
> >>  --Fred
> >>
> >> ___
> >> IAEP -- It's An Education Project (not a laptop project!)
> >> i...@lists.sugarlabs.org
> >> http://lists.sugarlabs.org/listinfo/iaep
> >
> >
> > ___
> > IAEP -- It's An Education Project (not a laptop project!)
> > i...@lists.sugarlabs.org
> > http://lists.sugarlabs.org/listinfo/iaep
> >
> ___
> IAEP -- It's An Education Project (not a laptop project!)
> i...@lists.sugarlabs.org
> http://lists.sugarlabs.org/listinfo/iaep
>



-- 
Caroline Meeks
Solution Grove
carol...@solutiongrove.com

617-500-3488 - Office
505-213-3268 - Fax
___
Sugar-devel mailing list
Sugar-devel@lists.sugarlabs.org
http://lists.sugarlabs.org/listinfo/sugar-devel

Re: [Sugar-devel] [IAEP] Getting data about the upgrading older machines and SoaS responsiveness.

[Martin Langhoff]

On Sun, Jun 7, 2009 at 7:24 PM, David Van Assche wrote:
> When it come to older pcs, it really makes sense to try and use LTSP. We

LTSP is an excellent path. Note that a happy LTSP adventure is
conditional on a good network infra and a decent TS machine. Wireless
won't do.

Sound and video used to be almost impossible to setup, or plainly
unusable -- I hope that it has improved with the help of pulseaudio
and other bits and pieces.

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
___
Sugar-devel mailing list
Sugar-devel@lists.sugarlabs.org
http://lists.sugarlabs.org/listinfo/sugar-devel

Re: [Sugar-devel] [GSoC] SSB creator

[Lucian Branescu]

I don't really need a separate activity, just a way to show it in the
Home View and a way to share it.

However, I do need a way to allow users to customise the web page
bundles. Users must be able to add userscripts (greasemonkey),
userstyles (custom css) and bookmarklets
http://en.wikipedia.org/wiki/Bookmarklet that are then shown in a
toolbar in Browse.

Since this is site-specific functionality, it would make Browse
needlessly complicated to support it directly. Hence a site-specific
browser. Also, SSBs should work with online websites as well.

I'll contact Simon about this.

2009/6/7 Gary C Martin :
> On 7 Jun 2009, at 18:18, Lucian Branescu wrote:
>
>> 1. I don't really want to zip it if I can avoid it. If I do zip it and
>> get an .xo, how can I add it to the Journal programatically?
>> 2. I've changed that. All SSBs are subdomains to org.sugarlabs.ssb
>> (like org.sugarlabs.ssb.GMailActivity)
>>
>> 2009/6/7 Bobby Powers :
>>>
>>> On Sat, Jun 6, 2009 at 9:57 PM, Lucian
>>> Branescu wrote:

 For my project, I will extend Browse with the ability to create SSBs.
 Read more here
 http://honeyweb.wordpress.com/2009/06/06/the-user-experience/

 I have made a small script that is triggered by a button in the Browse
 toolbar. It also works from Terminal.

 Later on this script will do more things, but I'd like some feedback
 about it as early as possible.
>
> Just wanted to flag an item that might be of interest to you on the 0.86
> Browse roadmap "export for offline viewing (Web page - HTML only, Web page -
> Complete)":
>
>
>  http://wiki.sugarlabs.org/go/Development_Team/Release/Roadmap/0.86#Browse
>
> I know this doesn't make a first class 'Activity' out of a page, but seems
> to have quite a feature overlap with your project. It would allow Browse to
> keep any page to the Journal so it can be resumed off-line and/or
> distributed to other users (via Journal entry sharing already in 0.84). It
> would also allow content providers an easy way to create and distribute more
> complicates/deep html/css/javascript/flash type rich web sites/pages by just
> zipping them up.
>
> Regards,
> --Gary
>
>>> Hi Lucian,
>>>
>>> 2 things:
>>>
>>> 1) rainbow should prevent you from creating new activities in
>>> ~/Activities, so I don't think that approach would work on an XO with
>>> an OLPC build.  Since I think what you want is to create an activity,
>>> zip it, and add it to the journal, you could probably do something
>>> like this:
>>> import tempfile
>>> ssb_path = tempfile.mkdtmp(dir=activity.get_activity_root())
>>>
>>> 2) the bundle_id you create probably should begin with org.laptop , as
>>> that could cause collisions with other activities.  maybe
>>> org.sugarlabs.ssb ?
>>>
>>> nice start so far!
>>>
>>> bobby
>>>
>> ___
>> Sugar-devel mailing list
>> Sugar-devel@lists.sugarlabs.org
>> http://lists.sugarlabs.org/listinfo/sugar-devel
>
>
___
Sugar-devel mailing list
Sugar-devel@lists.sugarlabs.org
http://lists.sugarlabs.org/listinfo/sugar-devel

Re: [Sugar-devel] [IAEP] Getting data about the upgrading older machines and SoaS responsiveness.

[David Farning]

On Sun, Jun 7, 2009 at 2:38 PM, David Van Assche wrote:
> That's a good point, and I understand the thinking behind it, as if you are
> not 'changing' anything in an existing setup, people are less afraid that
> things might go terribly wrong. That's the reason we have ltsp on a usb
> stick... because you can stick in a server, and test it without installing
> anything. Think of it as SoaS server with beaurocratic advantages included
> (taking care of networking, providing Sugar images, setting up user
> accounts, providng collaboration if necessary. It is by no means the XS
> server, nor should it try to be that, its just the desktop environment part
> with ejabberd, if needed.. of course, it only works in wired environments.

Very cool.  I had not heard of LTSP on a usb stick before.  It sound
like another great, low impact  (I am trying to think of a term like
'carbon foot print' to properly reflect the impact) way of bringing
LTSP into the class room.

david

> kind Regards,
> David (nubae) Van Assche
>
> On Sun, Jun 7, 2009 at 8:19 PM, David Farning 
> wrote:
>>
>> On Sun, Jun 7, 2009 at 12:24 PM, David Van Assche
>> wrote:
>> > When it come to older pcs, it really makes sense to try and use LTSP. We
>> > have created a kiwi-ltsp usb stick for openSUSE, which gives a portable
>> > ltsp
>> > server wherever u plug it in. In most cases it would make sense for this
>> > to
>> > be the most powerful computer. It is as easy as installing the sugar and
>> > sugar activities meta packages on this usb image and the users on the
>> > ltsp
>> > network then have access to Sugar from any computer in the network, and
>> > they
>> > are bound to load faster than from a usb image. The advantage is u need
>> > one
>> > usb stick per network, as opposed to one for each terminal... that saves
>> > costs, and time. Also, u dont need any of the old hardware, such as
>> > cdrom
>> > drives, hard drives, etc. Networking and internet is also no issue as if
>> > it
>> > works on the server, it has to work on each of the terminals too...
>>
>> SoaS is also working on a slightly different issue.
>>
>> I didn't understand it until Caroline explained it for about the 100th
>> time yesterday:)
>>
>> In addition to all the technical hurdles.  Sugar on a Stick is
>> tackling the _bureaucratic_ issue of installing and running Sugar (or
>> any software) on systems which one doesn't have admin access.
>>
>> In many schools it can be difficult to get the authority to install
>> software or modify the configuration on their computers.  SoaS
>> circumvents that problem by replacing  'install a new OS' with 'insert
>> the stick and turn it on.'
>>
>> The piece that I was _misunderstanding_ was that all of the
>> technically hurdles that SoaS introduces are worth the ability to
>> circumvent the bureaucratic hurdles.
>>
>> FWIW, at least in developed nations Once you get the bureaucratic
>> permission to 'install' Sugar, a client-server configuration is most
>> palatable to the existing generation of elementary school sysadmins.
>>
>> david
>>
>> > kind Regards,
>> > David (nubae) Van Assche
>> >
>> > On Sun, Jun 7, 2009 at 5:27 PM, Frederick Grose 
>> > wrote:
>> >>
>> >> On Sun, Jun 7, 2009 at 10:07 AM, Caroline Meeks
>> >>  wrote:
>> >>>
>> >>> Let me echo Caryl's question. Do we have a page with tasks for new
>> >>> volunteers?
>> >>
>> >> http://wiki.sugarlabs.org/go/Sugar_on_a_Stick/TODO has been restored
>> >> and
>> >> is ready to be updated, perhaps restructured to cover this need.
>> >>
>> >>  --Fred
>> >>
>> >> ___
>> >> IAEP -- It's An Education Project (not a laptop project!)
>> >> i...@lists.sugarlabs.org
>> >> http://lists.sugarlabs.org/listinfo/iaep
>> >
>> >
>> > ___
>> > IAEP -- It's An Education Project (not a laptop project!)
>> > i...@lists.sugarlabs.org
>> > http://lists.sugarlabs.org/listinfo/iaep
>> >
>
>
___
Sugar-devel mailing list
Sugar-devel@lists.sugarlabs.org
http://lists.sugarlabs.org/listinfo/sugar-devel

Re: [Sugar-devel] [IAEP] Getting data about the upgrading older machines and SoaS responsiveness.

[Jonas Smedegaard]

-BEGIN PGP SIGNED MESSAGE-
Hash: RIPEMD160

On Sun, Jun 07, 2009 at 04:40:31PM -0500, David Farning wrote:
>On Sun, Jun 7, 2009 at 2:38 PM, David Van Assche wrote:
>> That's a good point, and I understand the thinking behind it, as if 
>> you are not 'changing' anything in an existing setup, people are less 
>> afraid that things might go terribly wrong. That's the reason we have 
>> ltsp on a usb stick... because you can stick in a server, and test it 
>> without installing anything. Think of it as SoaS server with 
>> beaurocratic advantages included (taking care of networking, 
>> providing Sugar images, setting up user accounts, providng 
>> collaboration if necessary. It is by no means the XS server, nor 
>> should it try to be that, its just the desktop environment part with 
>> ejabberd, if needed.. of course, it only works in wired environments.
>
>Very cool.  I had not heard of LTSP on a usb stick before.

Great indeed.


>It sound like another great, low impact (I am trying to think of a term 
>like 'carbon foot print' to properly reflect the impact) way of 
>bringing LTSP into the class room.

"polite" or "gentle" perhaps?

or "non-invasive"?  Emphasizing what is avoided: invading - potentially 
taking over, accidentally or on purpose, the computers


Or did I misunderstand the kind of term you had in mind?



Kind regards,

  - jonas

- -- 
* Jonas Smedegaard - idealist og Internet-arkitekt
* Tlf.: +45 40843136  Website: http://dr.jones.dk/

  [x] quote me freely  [ ] ask before reusing  [ ] keep private
-BEGIN PGP SIGNATURE-
Version: GnuPG v1.4.9 (GNU/Linux)

iEYEAREDAAYFAkosQp0ACgkQn7DbMsAkQLhCXQCgnD7wIbtV99DEe6cHJOkcHqQj
djEAnjWsys5SJGSoD9zo1XefN9GpGwP+
=yKke
-END PGP SIGNATURE-
___
Sugar-devel mailing list
Sugar-devel@lists.sugarlabs.org
http://lists.sugarlabs.org/listinfo/sugar-devel

Re: [Sugar-devel] [IAEP] Getting data about the upgrading older machines and SoaS responsiveness.

[Luke Faraone]

On Sun, Jun 7, 2009 at 18:43, Jonas Smedegaard  wrote:

>  >It sound like another great, low impact (I am trying to think of a term
> >like 'carbon foot print' to properly reflect the impact) way of
> >bringing LTSP into the class room.
>
> "polite" or "gentle" perhaps?
>
> or "non-invasive"?  Emphasizing what is avoided: invading - potentially
> taking over, accidentally or on purpose, the computers


Granted, you would *need* to check with your local systems administrator
before implementing LTSP. (as opposed to a lower-risk USB-local-booting
solution) At my school, for example, netbooting a workstation starts the
"recloning" process of loading a new Windows XP image; setting up LTSP
without asking would cause major problems with their work.
-- 
Luke Faraone
http://luke.faraone.cc
___
Sugar-devel mailing list
Sugar-devel@lists.sugarlabs.org
http://lists.sugarlabs.org/listinfo/sugar-devel

Re: [Sugar-devel] [IAEP] personalisation and collaboration

[David Van Assche]

Having pondered this a bit more, I came up with a practical example. Lets
say we have a student in Uruguay, lets call him Fernando, and lets say we
have a student in the UK, lets call her Suzy. Suzy's Spanish is not great,
as she hasn't had the chance to delve into it practically, nor is she
getting the right idea about how everyday Spanish is used in Spanish
countries, having relied on terrible cliched examples of her antiquated text
books. Fernando's English is not very good, seeing as the only English he is
subjected to are pirate movies he buys from the local market, so he's
learned more slang than real English. His school isn't even teaching
English, but he desperately wants to learn it.

Colabot knows both of these users, as it has analysed every willing user's
e-portfolio, and knows they would compliment each other perfectly say by
sharing the Speak activity. Colabot could suggest times at which these 2
students could meet virtually and collaborate in order to improve their
language skills. Colabot could keep track of their on going meetings,
showing the amount of hours spent on language learning. Colabot could even
give out an award or recognition after the students had spent X amount of
hours learning together.

The great thing about this example is that it seems to me to be pure
construcionism with technology at its simplest and its best. The 2 students
are teachers to each other, and colabot is there purely in the capacity a
teacher normally should be, to guide the learning process.

kind Regards,
David Van Assche

On Sun, Jun 7, 2009 at 1:23 PM, Walter Bender wrote:

> On Sun, Jun 7, 2009 at 7:00 AM, David Van Assche
> wrote:
> > Something has been in the back of my head for a while now, ever since
> I've
> > seen the impressive capabilities of being able to share an activity with
> > your neighbourhood. Being able to cooperatively use applications brings a
> > new level of playability to it all, and it reminds me of when I first saw
> > the ability for a computer game to be 'multi-player.'This gave it an
> extra
> > dimension, and with it came the idea of awards for completing certain
> > things, which would be displayed in your dashoard somewhere.The award
> system
> > seems even more relevant for education than it did for games. We'v aleady
> > mentioned the benefits of an award sysem so I'm not going to regugitate
> > that, but what hasnt''t really been spoken about is, how and what kind of
> > personal details should the journal store and share. I see this as a
> > customisable option, something that can be as simple as only sharing
> first
> > names, or sharing the name of your pet, your favorite colors and foods,
> the
> > languages you speak.
> >
> > This detailed information about a person is extremely valuable to the
> > underlying system, as it can potentially match people against each other.
> > This would allow for some interesting possibilities when it comes to
> > collaboration, such as the system suggesting users to
> challenge/collaborate
> > with based on personal information. I thought about having a robot that
> > lives on an irc channel capable of helping with the collaboration
> procedure,
> > as well as listing achievements, giving data on which users want to
> > collaborate, giving help on how collaboration works with particular
> > activities, listing which servers have open collaboration, showing the
> most
> > used/highest rated collaborating activities, etc.
> >
> > I havent thought about this too much in depth, but I know coding a bot is
> > not too hard. I see it as an extension to the speak AI, and encouragement
> to
> > join irc. We can even get the bot to accept uploads of raw learning
> > materials categorised by subject, which can then be used by content
> > creators. it itself could give out quizzes based on particular subjects,
> or
> > interesting pieces of information/knowledge. It could be taught new
> > information, by feeding it localised knowledge. It would be important to
> > know where we set the limits to what it can do.
> >
> > Just some food for thought...
> >
> > David (nubae) Van Assche
> >
> > ___
> > IAEP -- It's An Education Project (not a laptop project!)
> > i...@lists.sugarlabs.org
> > http://lists.sugarlabs.org/listinfo/iaep
> >
>
> In general, the idea of bots living in the Sugar neighborhood is a
> theme we haven't explored very much. It would be nice to come up with
> a simple, consistent framework for creating such a resource. Making it
> available through IRC as well is a cool idea.
>
> -walter
>
> --
> Walter Bender
> Sugar Labs
> http://www.sugarlabs.org
>
___
Sugar-devel mailing list
Sugar-devel@lists.sugarlabs.org
http://lists.sugarlabs.org/listinfo/sugar-devel

Re: [Sugar-devel] [IAEP] Getting data about the upgrading older machines and SoaS responsiveness.

[Jonas Smedegaard]

-BEGIN PGP SIGNED MESSAGE-
Hash: RIPEMD160

On Sun, Jun 07, 2009 at 07:00:28PM -0400, Luke Faraone wrote:
>On Sun, Jun 7, 2009 at 18:43, Jonas Smedegaard  wrote:
>
>> >It sound like another great, low impact (I am trying to think of a 
>> >term like 'carbon foot print' to properly reflect the impact) way of 
>> >bringing LTSP into the class room.
>>
>> "polite" or "gentle" perhaps?
>>
>> or "non-invasive"?  Emphasizing what is avoided: invading - 
>> potentially taking over, accidentally or on purpose, the computers
>
>
>Granted, you would *need* to check with your local systems 
>administrator before implementing LTSP. (as opposed to a lower-risk 
>USB-local-booting solution) At my school, for example, netbooting a 
>workstation starts the "recloning" process of loading a new Windows XP 
>image; setting up LTSP without asking would cause major problems with 
>their work.

non-invasive to the _computers_ but invasive to the network 
infrastructure.


So yes, a better term would be good, to not risk sysadmins feeling 
cheated when learning the hard way that this so-called non-invasive 
system includes a DHCP daemon, breaking their WiFi hotspots, printers 
and what not.


  - Jonas

- -- 
* Jonas Smedegaard - idealist og Internet-arkitekt
* Tlf.: +45 40843136  Website: http://dr.jones.dk/

  [x] quote me freely  [ ] ask before reusing  [ ] keep private
-BEGIN PGP SIGNATURE-
Version: GnuPG v1.4.9 (GNU/Linux)

iEYEAREDAAYFAkosXD0ACgkQn7DbMsAkQLgTYwCeNg687lF4eEXrGw9SqB62AGih
5WQAniL/ZEmBKsZ8zVMCRmPlNnScHmE5
=lu5m
-END PGP SIGNATURE-
___
Sugar-devel mailing list
Sugar-devel@lists.sugarlabs.org
http://lists.sugarlabs.org/listinfo/sugar-devel