Re: [Sugar-devel] Design meeting (0.86 features) --- Sunday 16.08.2009 14:00 (UTC)
On Fri, Aug 14, 2009 at 06:15:47PM +0200, Simon Schampijer wrote: > Hey, > > next Thursday is Feature Freeze: > http://wiki.sugarlabs.org/go/0.86/Roadmap#Schedule - this is the list of > the current features: http://wiki.sugarlabs.org/go/0.86/Feature_List > > We have some open design questions we want to discuss: > > * New Toolbar Design > http://wiki.sugarlabs.org/go/Features/New_Toolbar_Design > - simple activity issue (see How simple toolbar may look(attached). Tooltip palette being opened on left click(and right click as usual). > http://lists.sugarlabs.org/archive/sugar-devel/2009-August/017939.html) > - labels for subtoolbars > > * Tags in Journal > http://wiki.sugarlabs.org/go/Features/Tags_in_Journal > > * Tabs in Browse > http://wiki.sugarlabs.org/go/Features/Tabs_In_Browse > - look of the tabs > > Date: Sunday 16.08.2009 14:00 (UTC) > Where: irc - #sugar-meeting (freenode) > > See you there, > Simon > ___ > Sugar-devel mailing list > Sugar-devel@lists.sugarlabs.org > http://lists.sugarlabs.org/listinfo/sugar-devel > -- Aleksey <>___ Sugar-devel mailing list Sugar-devel@lists.sugarlabs.org http://lists.sugarlabs.org/listinfo/sugar-devel
Re: [Sugar-devel] [Systems] sunjammer: VM relocated back to old host
El Sat, 15-08-2009 a las 23:38 -0500, Rafael Enrique Ortiz Guerrero escribió: > Relating aslo management, maybe we can ask mozilla folks about it? , > would be nice to know how is their setup. Could someone please approach them? I'd be interested especially in knowing about: * Apache performance tweaks * PHP performance tweaks (opcode caching, etc) * MySQL performance tweaks * ASLO performance tweaks * Why indexes seem to be missing on their schema and how do they cope with it * How many hits they get, and how many machines they have to serve them; so we can make a comparison Feel free to forward this message to the relevant list. -- // Bernie Innocenti - http://codewiz.org/ \X/ Sugar Labs - http://sugarlabs.org/ ___ Sugar-devel mailing list Sugar-devel@lists.sugarlabs.org http://lists.sugarlabs.org/listinfo/sugar-devel
Re: [Sugar-devel] [Systems] sunjammer: VM relocated back to old host
Relating aslo management, maybe we can ask mozilla folks about it? , would be nice to know how is their setup. Rafael Ortiz On Sat, Aug 15, 2009 at 2:52 PM, Bernie Innocenti wrote: > El Sat, 15-08-2009 a las 13:59 +0200, Luke Faraone escribió: >> On Aug 15, 2009, at 12:42, Bernie Innocenti wrote: >> > I enabled mod_mem_cache in the hope it will save some computation, but >> > if it's not effective we might have to reduce the number of Apache >> > processes and start returning "500 server busy" errors. >> >> Maybe pipe downloads through the CoralCDN? It tends to be slow, but >> it'll save us bandwidth... > > We have plenty of bandwidth we don't use. > > Our actual bottlenecks are in interpreting PHP code and executing MySQL > queries related to activities.sugarlabs.org. We're already employing > all the current optimization tricks, including mod_cache, APC and > memcache. There might still indexes we could add to speed up slow > queries. > > -- > // Bernie Innocenti - http://codewiz.org/ > \X/ Sugar Labs - http://sugarlabs.org/ > > > ___ > Systems mailing list > syst...@lists.sugarlabs.org > http://lists.sugarlabs.org/listinfo/systems > ___ Sugar-devel mailing list Sugar-devel@lists.sugarlabs.org http://lists.sugarlabs.org/listinfo/sugar-devel
Re: [Sugar-devel] [Systems] sunjammer: VM relocated back to old host
El Sat, 15-08-2009 a las 13:59 +0200, Luke Faraone escribió: > On Aug 15, 2009, at 12:42, Bernie Innocenti wrote: > > I enabled mod_mem_cache in the hope it will save some computation, but > > if it's not effective we might have to reduce the number of Apache > > processes and start returning "500 server busy" errors. > > Maybe pipe downloads through the CoralCDN? It tends to be slow, but > it'll save us bandwidth... We have plenty of bandwidth we don't use. Our actual bottlenecks are in interpreting PHP code and executing MySQL queries related to activities.sugarlabs.org. We're already employing all the current optimization tricks, including mod_cache, APC and memcache. There might still indexes we could add to speed up slow queries. -- // Bernie Innocenti - http://codewiz.org/ \X/ Sugar Labs - http://sugarlabs.org/ ___ Sugar-devel mailing list Sugar-devel@lists.sugarlabs.org http://lists.sugarlabs.org/listinfo/sugar-devel
Re: [Sugar-devel] Design meeting tomorrow?
Thanks Christian, and sorry all! I would have spoken up sooner, but my vacation plans have been somewhat undefined and only today did I know exactly what time I'd be available. I'm looking forward to chatting with everyone tomorrow. Eben On Sat, Aug 15, 2009 at 9:23 PM, Christian Schmidt wrote: > Hi again > > Eben has to leave at 10:30 EST tomorrow, so why don't we start 30 mins > earlier, at 9:30 EST/3:30 UTC. Hopefully that works for everyone. > > Thanks, > > Christian > > > From: Gary C Martin [mailto:g...@garycmartin.com] > To: Christian Schmidt [mailto:schm...@pentagram.com], Daniel Drake > [mailto:d...@laptop.org] > Cc: Simon Schampijer [mailto:si...@schampijer.de], Sugar-dev Devel > [mailto:sugar-de...@lists.sugarlabs.org], Eben Eliason > [mailto:eben.elia...@gmail.com] > Sent: Sat, 15 Aug 2009 18:42:09 -0400 > Subject: Re: Design meeting tomorrow? > > Hi Christian, > > Looking at your To/Cc list, I think we're all in for the meeting, > excepting I haven't seen a confirmation email from Daniel yet. Given > the feature freeze is on Thursday, we should cover what we can, as > soon as we can, and obviously pick up any additional feedback before > the feature freeze if we can. > > Regards, > --Gary > > On 15 Aug 2009, at 22:58, Christian Schmidt wrote: > >> Hi everyone >> >> I suggested earlier this week that we meet via IRC (#sugar-meeting) >> at 10am EST (2pm UTC) tomorrow to discuss the new toolbars and >> several other current issues before the next feature freeze. Are we >> still on for this? There are a few people I haven't heard back from >> yet. We can also move it to another time during the week if tomorrow >> doesn't work for everyone. >> >> Thanks, >> >> >> Christian > > ___ Sugar-devel mailing list Sugar-devel@lists.sugarlabs.org http://lists.sugarlabs.org/listinfo/sugar-devel
Re: [Sugar-devel] Overlay chat architecture
On Saturday 15 August 2009 06:50:06 pm Benjamin M. Schwartz wrote: > I've been thinking about overlay chat, and I wonder > > 1. Has there been any code written to that end? http://git.sugarlabs.org/projects/sugar-toolkit/repos/sugar-toolkit-chat This was done a while ago, but I was slowed down when trying to make palettes pop-up from the buddy icons in the friends tray (right frame). In any case it may need a rebase, but the bureaucratic code for mapping the different types of channel handles (our addresses in the telepathy channels) with buddy keys (what sugar can easily get from buddy_ps.props.key) worked fine. It also keeps references to all the text channels as a class attribute to avoid looking for them on every activity switch. > 2. Has anyone thought about the necessary architecture? > > Overlay chat requires a number of things working together: per-activity > daemons, spawned when sharing starts, with references to the telepathy > channels for each activity, as well as bidirectional access to the Friends > tray for GUI. It's not clear to me, for example, what code in Sugar could > launch such a daemon. See sugar/src/jarabe/frame/friendstray.py. My idea was to keep it simple and consistent by making the BuddyModel (jarabe/model/buddy.py) hold one of these objects (the owner would hold a ChatPitcher, the rest a ChatCatcher*) and expose a signal/method for events. This would mean both the icons used in the friendstray and in the neighborhood view have access to this service through the BuddyModel. Also, I don't think we need a process for each activity. Since we can only show chats from one activity at a time, and telepathy holds unacknowledged messages. We can just subscribe a class method to 'chat-received' in all channels for notifications. *: These are awful names, someone please come up with something more clever. > --Ben -- -Andrés ___ Sugar-devel mailing list Sugar-devel@lists.sugarlabs.org http://lists.sugarlabs.org/listinfo/sugar-devel
Re: [Sugar-devel] Design meeting tomorrow?
Hi Christian, Looking at your To/Cc list, I think we're all in for the meeting, excepting I haven't seen a confirmation email from Daniel yet. Given the feature freeze is on Thursday, we should cover what we can, as soon as we can, and obviously pick up any additional feedback before the feature freeze if we can. Regards, --Gary On 15 Aug 2009, at 22:58, Christian Schmidt wrote: > Hi everyone > > I suggested earlier this week that we meet via IRC (#sugar-meeting) > at 10am EST (2pm UTC) tomorrow to discuss the new toolbars and > several other current issues before the next feature freeze. Are we > still on for this? There are a few people I haven't heard back from > yet. We can also move it to another time during the week if tomorrow > doesn't work for everyone. > > Thanks, > > > Christian ___ Sugar-devel mailing list Sugar-devel@lists.sugarlabs.org http://lists.sugarlabs.org/listinfo/sugar-devel
[Sugar-devel] Overlay chat architecture
I've been thinking about overlay chat, and I wonder 1. Has there been any code written to that end? 2. Has anyone thought about the necessary architecture? Overlay chat requires a number of things working together: per-activity daemons, spawned when sharing starts, with references to the telepathy channels for each activity, as well as bidirectional access to the Friends tray for GUI. It's not clear to me, for example, what code in Sugar could launch such a daemon. --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] Karma: bundle layout improve
> Can you update the wiki to reflect this new structure?
done. Please take a look of it:
http://wiki.sugarlabs.org/go/Karma/Bundle_layout#Lesson
2009/8/15 Bryan Berry :
> On Fri, 2009-08-14 at 19:10 -0500, Felipe López Toledo wrote:
>> yes, I'm aware, but at the end it's an advantage to separate the content:
>>
>> with the current design and common assets, if the coder is writing the
>> "game" an try to get an image from "exercise" will need to access
>> "assets / {lag-code | generic} / images/ exercise/ {imageFile}",
>> now... let's think, what if I want to take the "game" and merge it
>> with other lesson:
>> I will need to look inside the code and look for the common assets (in
>> order to copy them and move them).
>> and what if the {imageFile} already exists inside the common destiny
>> (exercise) folder?
>> need to rename some image and fix some code :S
>
>> I think keeping things in different folders will bring clearness of
>> what are we coding and where are the files stored. So, we will be able
>> to copy and just paste the whole file and everything will be working.
>>
>
> Let's follow your suggestion then. At this point it is better to make
> things easier for developers than to optimize for a problem we haven't
> actually encountered yet.
>
> Can you update the wiki to reflect this new structure?
>
> --
> Bryan W. Berry
> Technology Director
> OLE Nepal, http://www.olenepal.org
>
>
--
Felipe López Toledo
___
Sugar-devel mailing list
Sugar-devel@lists.sugarlabs.org
http://lists.sugarlabs.org/listinfo/sugar-devel
Re: [Sugar-devel] [IAEP] Yet more feedback from Boston! - Chat and Speak
On 15 Aug 2009, at 19:57, Eben Eliason wrote:
> On Sat, Aug 15, 2009 at 1:35 PM, Gary C Martin
> wrote:
>> On 14 Aug 2009, at 17:11, Eben Eliason wrote:
>>
>>> On Thu, Aug 13, 2009 at 8:28 PM, Caroline
>>> Meeks wrote:
Neither wind nor rain nor flaming emails will deter me from
telling you
about what happened with kids and Sugar today in Boston! You
however are
free to use your delete key at any time.
Today, working with 6th grade students at the Museum of Science
Computer
Clubhouse I learned not to start a Sugar intro session with
chat. It was
hard for us to believe but the kids spent 3 hours really wanting
to do
nothing but use chat to talk to other kids in the same room!! We
did get
them to use other things but
next time I will end with Chat, not start with it :)
We used both Chat and Speak. Chat was more robust.
I suggest that Speak be limited to about 4 participants. It
seemed die a
lot and if someone typed a lot of garbdy gook it would try to say
it all and
get behind. What do other people think of this idea? Should I
ticket it?
I started the lesson by creating a chat, sharing it and showing the
students
how to join from their neighborhood. That worked fairly well.
However, some of the students wanted to create a private chat.
It could
be
done but it was very challenging workflow. The problem is if two
kids
decide they want to chat the natural thing for them to do is both
goto
Home
and click on Chat and share that with the neighborhood. This
results in
two
chats and much confusion. I don't know how to solve this, as I'm
not
gifted
at UI design, but its clearly a problem. Perhaps when you start
chat you
have a UI inside of chat that lets you join other existing chats
directly.
>>>
>>> I think there are a few first-steps to simplify this process that
>>> have
>>> already been designed. First and foremost, it should be possible to
>>> select a sharing scope when starting a new activity. In past
>>> mockups,
>>> we offered this functionality via a "Start with >" option, which
>>> revealed a submenu containing both a list of friends, and a list of
>>> groups. We could build the first part of this today.
>>>
>>> Likewise, the redesign of the sharing controls within the activity
>>> itself provide us the chance to do the same when sharing an ongoing
>>> activity. In addition to listing "private" and "my neighborhood", we
>>> could also introduce "my friends", as well as individuals.
>>
>> Ooohhh, nice one, +1, though I think the actual menu needs some
>> thinking
>> about so we don't conflate the Journal "Resume with -> "
>> and this
>> proposed home view "Start with -> ". Also think "Start with
>> ->
>
> Good point. Perhaps resuming should say "Resume in >" instead, to
> indicate that you're entering into a new activity context.
+1
>> Neighbourhood" should be in that list. There is also the issue of
>> shared
>
> Oh, absolutely. In my mind, "My Neighborhood" and "My friends" should
> act like two implicit groups. I think the best way to order the
> submenu is [my neighborhood, my friends, {list of groups}, {list of
> friends}].
+1
>> activity titles... Currently you have to title your activity before
>> sharing
>> (though that even feature seems somewhat buggy, not sure if this is
>> broken
>> Sugar UI, or an issue with Telepathy), otherwise you just get
>> default "Chat
>> Activity" activities in the neighbourhood.
>
> There have been a number of discussions and ideas around better
> default names for activity titles. Perhaps we could take a small step
> with a potentially large payoff and make the default activity title
> "'s activity" instead, so that at least we'd have
> "Eben's chat activity" and "Gary's chat activity", which is far more
> useful as a default.
+0.2 Downsides... the Journal will fill up with your name duplicated
on many lines. The name suggests possession, when really we want to be
suggesting collaboration/sharing. The 's will be incorrect for folks
with names ending in s, and not sure if this is simple for localisers
to find good equivalents.
>> Tthere is at least one obvious string change to be made to the home
>> activity
>> palettes. "Start" should be "New", or given above possible feature
>> perhaps
>> "Start new" is better, so that "Start new with -> " will
>> read a
>> little better:
>
> I like keeping the distinction between "start" and "resume", both of
> which are verbs. That's important. If we fel the need to make it more
> explicit by appending "new", that could work, but I'm not sure it's
> necessary with the proper uncolored icon.
+1 for "Start new" then. Every time I read "Start" I still mentally
ask my self "start what?"
Perhaps we can confirm consensus at the Sunday IRC
Re: [Sugar-devel] feedback from a teacher in Uruguay
Raul, Thank you. We do maintain SocialCalc at a.sl.o. Unfortunately, we didn't have the updated version over there. Just updated it today. Please have a look at * http://activities.sugarlabs.org/en-US/sugar/addon/4084 *Regards, Manu On Sat, Aug 15, 2009 at 8:28 AM, Raul Gutierrez Segales wrote: > On Fri, 2009-08-14 at 15:31 +0530, Manusheel Gupta wrote: > > Gabriel, please ask the teacher to download the latest SocialCalc > > activity package from here . > > Could we move/copy this to a.sl.o? Makes life easier for deployment > teams to then grab activities and make them available at local > servers.. > > Thanks! > > P.S.: i am assuming it's not available (yet) at a.sl.o because of the > link you provided.. i couldn't check myself since a.sl.o is down at the > moment. > > > ___ Sugar-devel mailing list Sugar-devel@lists.sugarlabs.org http://lists.sugarlabs.org/listinfo/sugar-devel
Re: [Sugar-devel] [IAEP] Yet more feedback from Boston! - Chat and Speak
On Sat, Aug 15, 2009 at 1:35 PM, Gary C Martin wrote:
> On 14 Aug 2009, at 17:11, Eben Eliason wrote:
>
>> On Thu, Aug 13, 2009 at 8:28 PM, Caroline
>> Meeks wrote:
>>>
>>> Neither wind nor rain nor flaming emails will deter me from telling you
>>> about what happened with kids and Sugar today in Boston! You however are
>>> free to use your delete key at any time.
>>> Today, working with 6th grade students at the Museum of Science Computer
>>> Clubhouse I learned not to start a Sugar intro session with chat. It was
>>> hard for us to believe but the kids spent 3 hours really wanting to do
>>> nothing but use chat to talk to other kids in the same room!! We did get
>>> them to use other things but
>>> next time I will end with Chat, not start with it :)
>>> We used both Chat and Speak. Chat was more robust.
>>> I suggest that Speak be limited to about 4 participants. It seemed die a
>>> lot and if someone typed a lot of garbdy gook it would try to say it all and
>>> get behind. What do other people think of this idea? Should I ticket it?
>>> I started the lesson by creating a chat, sharing it and showing the
>>> students
>>> how to join from their neighborhood. That worked fairly well.
>>> However, some of the students wanted to create a private chat. It could
>>> be
>>> done but it was very challenging workflow. The problem is if two kids
>>> decide they want to chat the natural thing for them to do is both goto
>>> Home
>>> and click on Chat and share that with the neighborhood. This results in
>>> two
>>> chats and much confusion. I don't know how to solve this, as I'm not
>>> gifted
>>> at UI design, but its clearly a problem. Perhaps when you start chat you
>>> have a UI inside of chat that lets you join other existing chats
>>> directly.
>>
>> I think there are a few first-steps to simplify this process that have
>> already been designed. First and foremost, it should be possible to
>> select a sharing scope when starting a new activity. In past mockups,
>> we offered this functionality via a "Start with >" option, which
>> revealed a submenu containing both a list of friends, and a list of
>> groups. We could build the first part of this today.
>>
>> Likewise, the redesign of the sharing controls within the activity
>> itself provide us the chance to do the same when sharing an ongoing
>> activity. In addition to listing "private" and "my neighborhood", we
>> could also introduce "my friends", as well as individuals.
>
> Ooohhh, nice one, +1, though I think the actual menu needs some thinking
> about so we don't conflate the Journal "Resume with -> " and this
> proposed home view "Start with -> ". Also think "Start with ->
Good point. Perhaps resuming should say "Resume in >" instead, to
indicate that you're entering into a new activity context.
> Neighbourhood" should be in that list. There is also the issue of shared
Oh, absolutely. In my mind, "My Neighborhood" and "My friends" should
act like two implicit groups. I think the best way to order the
submenu is [my neighborhood, my friends, {list of groups}, {list of
friends}].
> activity titles... Currently you have to title your activity before sharing
> (though that even feature seems somewhat buggy, not sure if this is broken
> Sugar UI, or an issue with Telepathy), otherwise you just get default "Chat
> Activity" activities in the neighbourhood.
There have been a number of discussions and ideas around better
default names for activity titles. Perhaps we could take a small step
with a potentially large payoff and make the default activity title
"'s activity" instead, so that at least we'd have
"Eben's chat activity" and "Gary's chat activity", which is far more
useful as a default.
> Tthere is at least one obvious string change to be made to the home activity
> palettes. "Start" should be "New", or given above possible feature perhaps
> "Start new" is better, so that "Start new with -> " will read a
> little better:
I like keeping the distinction between "start" and "resume", both of
which are verbs. That's important. If we fel the need to make it more
explicit by appending "new", that could work, but I'm not sure it's
necessary with the proper uncolored icon.
Eben
___
Sugar-devel mailing list
Sugar-devel@lists.sugarlabs.org
http://lists.sugarlabs.org/listinfo/sugar-devel
Re: [Sugar-devel] [IAEP] Yet more feedback from Boston! - Chat and Speak
On 14 Aug 2009, at 17:11, Eben Eliason wrote: > On Thu, Aug 13, 2009 at 8:28 PM, Caroline > Meeks wrote: >> Neither wind nor rain nor flaming emails will deter me from telling >> you >> about what happened with kids and Sugar today in Boston! You >> however are >> free to use your delete key at any time. >> Today, working with 6th grade students at the Museum of Science >> Computer >> Clubhouse I learned not to start a Sugar intro session with chat. >> It was >> hard for us to believe but the kids spent 3 hours really wanting to >> do >> nothing but use chat to talk to other kids in the same room!! We >> did get >> them to use other things but >> next time I will end with Chat, not start with it :) >> We used both Chat and Speak. Chat was more robust. >> I suggest that Speak be limited to about 4 participants. It seemed >> die a lot and if someone typed a lot of garbdy gook it would try to >> say it all and get behind. What do other people think of this >> idea? Should I ticket it? >> I started the lesson by creating a chat, sharing it and showing the >> students >> how to join from their neighborhood. That worked fairly well. >> However, some of the students wanted to create a private chat. It >> could be >> done but it was very challenging workflow. The problem is if two >> kids >> decide they want to chat the natural thing for them to do is both >> goto Home >> and click on Chat and share that with the neighborhood. This >> results in two >> chats and much confusion. I don't know how to solve this, as I'm >> not gifted >> at UI design, but its clearly a problem. Perhaps when you start >> chat you >> have a UI inside of chat that lets you join other existing chats >> directly. > > I think there are a few first-steps to simplify this process that have > already been designed. First and foremost, it should be possible to > select a sharing scope when starting a new activity. In past mockups, > we offered this functionality via a "Start with >" option, which > revealed a submenu containing both a list of friends, and a list of > groups. We could build the first part of this today. > > Likewise, the redesign of the sharing controls within the activity > itself provide us the chance to do the same when sharing an ongoing > activity. In addition to listing "private" and "my neighborhood", we > could also introduce "my friends", as well as individuals. Ooohhh, nice one, +1, though I think the actual menu needs some thinking about so we don't conflate the Journal "Resume with -> " and this proposed home view "Start with -> ". Also think "Start with -> Neighbourhood" should be in that list. There is also the issue of shared activity titles... Currently you have to title your activity before sharing (though that even feature seems somewhat buggy, not sure if this is broken Sugar UI, or an issue with Telepathy), otherwise you just get default "Chat Activity" activities in the neighbourhood. Tthere is at least one obvious string change to be made to the home activity palettes. "Start" should be "New", or given above possible feature perhaps "Start new" is better, so that "Start new with -> " will read a little better: http://trac.sugarlabs.org/ticket/314 Regards, --Gary ___ Sugar-devel mailing list Sugar-devel@lists.sugarlabs.org http://lists.sugarlabs.org/listinfo/sugar-devel
Re: [Sugar-devel] Karma: bundle layout improve
On Fri, 2009-08-14 at 19:10 -0500, Felipe López Toledo wrote:
> yes, I'm aware, but at the end it's an advantage to separate the content:
>
> with the current design and common assets, if the coder is writing the
> "game" an try to get an image from "exercise" will need to access
> "assets / {lag-code | generic} / images/ exercise/ {imageFile}",
> now... let's think, what if I want to take the "game" and merge it
> with other lesson:
> I will need to look inside the code and look for the common assets (in
> order to copy them and move them).
> and what if the {imageFile} already exists inside the common destiny
> (exercise) folder?
> need to rename some image and fix some code :S
> I think keeping things in different folders will bring clearness of
> what are we coding and where are the files stored. So, we will be able
> to copy and just paste the whole file and everything will be working.
>
Let's follow your suggestion then. At this point it is better to make
things easier for developers than to optimize for a problem we haven't
actually encountered yet.
Can you update the wiki to reflect this new structure?
--
Bryan W. Berry
Technology Director
OLE Nepal, http://www.olenepal.org
___
Sugar-devel mailing list
Sugar-devel@lists.sugarlabs.org
http://lists.sugarlabs.org/listinfo/sugar-devel
Re: [Sugar-devel] [Systems] sunjammer: VM relocated back to old host
On Sat, Aug 15, 2009 at 09:00, Daniel Clark wrote: > I haven't used it in a while, but a year or two ago > http://codeen.cs.princeton.edu/ was pretty sweet for large file > transfers. > Can we use it without any changes on the users' end? From what I saw on the site, it seems to require proxy configuration in-browser. -- 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] [Systems] sunjammer: VM relocated back to old host
On Aug 15, 2009, at 12:42, Bernie Innocenti wrote: > I enabled mod_mem_cache in the hope it will save some computation, but > if it's not effective we might have to reduce the number of Apache > processes and start returning "500 server busy" errors. Maybe pipe downloads through the CoralCDN? It tends to be slow, but it'll save us bandwidth... -lf ___ Sugar-devel mailing list Sugar-devel@lists.sugarlabs.org http://lists.sugarlabs.org/listinfo/sugar-devel
[Sugar-devel] sunjammer: VM relocated back to old host
Hello, unfortunately our new XEN host cloud9.fsf.org has a hardware stability issue that we could not solve while working remotely. Therefore, yesterday night we decided to migrate Sunjammer back to its old home to avoid further unplanned downtime while we analyze the outstanding issue with cloud9 (which smells like a broken memory bank). The old XEN host has however its share of problems, too: it is overcrowded with other busy VMs, and has already proved itself unable to cope with the amount of traffic that hits activities.sugarlabs.org every day during school time. I enabled mod_mem_cache in the hope it will save some computation, but if it's not effective we might have to reduce the number of Apache processes and start returning "500 server busy" errors. Meanwhile, we're also investigating the possibility to migrate ASLO to a different host altogether. -- // Bernie Innocenti - http://codewiz.org/ \X/ Sugar Labs - http://sugarlabs.org/ ___ Sugar-devel mailing list Sugar-devel@lists.sugarlabs.org http://lists.sugarlabs.org/listinfo/sugar-devel
Re: [Sugar-devel] feedback from a teacher in Uruguay
On Sat, Aug 15, 2009 at 5:03 AM, Tomeu Vizoso wrote: >> 2. Moodle's ejabberd integration. Martin Langhoff developed a system to >> connect Moodle's concept of classes to ejabberd. The result is that each >> user only sees other users in his/her class, as configured through the >> Moodle web interface. > > Is this in use somewhere? Would like to hear how it is being used and > if we can add anything to Sugar to improve integration, maybe a class > browser/selector? Not in use but I've tested it extensively, and I am encouraging deployments to use it. We'll see it in use very soon I expect. >From the PoV of XMPP (not sure how much Telepathy exposes) each 'course' is a separate 'shared roster group'. So clients can see if they have 3 SRGs, and can apply whatever UI to that info. Pidgin shows it as different groups. With this setup, there will be users you just don't see. So one thing I am very keen on is exploring whether we can do the 'search for a user I cannot see' via a standard XMPP call. This is something that has been discussed re Gadget (not sure if Gadget has it implemented) -- it will need some changes in the 'neighbourhood' UI, but will be excellent. I am sure that XMPP supports something like that, and if ejabberd doesn't implement it, I can implement it for the XS. >> 3. Per-class servers. You can run many different ejabberd instances, >> with DNS names like year4classD.schoolserver.local, one for each No no no. Wad was going that way, I studied the idea and it is a big mess if you think of a real school. Teachers are active in more than one class/group, kids often migrate class/groups. Kids may belong to more than one class/group. Many servers is a significant cost. Using VMs is a performance/scalability nightmare. And to segregate each XO to a different class/group you'd need either completely separate wifi/network infra for each class, or to maintain MAC address tables for DHCP to assign different DNS servers to each. Ugh! And that's just the tip of the iceberg. In general, it is a good idea to assume I spent a non-trivial amount of time in my architectural decisions. :-) 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] New sugar meeting channel in Spanish
On Sat, Aug 15, 2009 at 00:50, Pilar Saenz wrote: > Hi, > > Thinking about how to involve more Spanish speakers into IRC meetings, > it's available a transbot between #sugar-meeting and the new > #sugar-reunion channels. > Spanish users can join #sugar-reunion and all sentences will be > translated to english into #sugar-meeting channel and vice versa. > > Documentation in spanish > http://co.sugarlabs.org/go/Transbot It has been suggested as well that the IRC activity would connect automatically to a sugar channel for the current locale, plus #sugar. http://dev.sugarlabs.org/ticket/1165 Regards, Tomeu -- «Sugar Labs is anyone who participates in improving and using Sugar. What Sugar Labs does is determined by the participants.» - David Farning ___ Sugar-devel mailing list Sugar-devel@lists.sugarlabs.org http://lists.sugarlabs.org/listinfo/sugar-devel
Re: [Sugar-devel] Screen Displays (text)
On Sat, Aug 15, 2009 at 01:35, Raul Gutierrez Segales wrote:
> On Fri, 2009-08-14 at 17:28 -0400, Walter Bender wrote:
>> I determine whether or not I am on an XO with:
>>
>> if os.path.exists('/sys/power/olpc-pm'): # then assume you are on an XO
>>
>
> Shouldn't we encapsulate this method (is_xo?()) somewhere? I've seen it
> spread in a couple of places so far..
Added a ticket for this: http://dev.sugarlabs.org/ticket/1183
Thanks,
Tomeu
--
«Sugar Labs is anyone who participates in improving and using Sugar.
What Sugar Labs does is determined by the participants.» - David
Farning
___
Sugar-devel mailing list
Sugar-devel@lists.sugarlabs.org
http://lists.sugarlabs.org/listinfo/sugar-devel
Re: [Sugar-devel] feedback from a teacher in Uruguay
On Fri, Aug 14, 2009 at 19:33, Benjamin M. Schwartz wrote: > Andrés Nacelle wrote: >> We've got good results with the ejabber, but we don't know what >> will happen in a big school where 200 or 300 XO may appear n the >> Neighbourhood view. > > Two solutions have been developed for this problem. Both work by making > sure that each user does not see all 300 other users. > > 1. Collabora's Gadget. Gadget is a Jabber extension that can be run with > ejabberd. It modifies the visibility/roster behaviors so that each user > only sees a restricted number of other users. Who sees who can be > configured programmatically, or even made to be random. Well, actually the user could "see" all users in the same view if we used Gadget properly from the UI side of things, just as the Journal allows browsing thousands of entries from the DS but only retrieves some dozens at a time. > 2. Moodle's ejabberd integration. Martin Langhoff developed a system to > connect Moodle's concept of classes to ejabberd. The result is that each > user only sees other users in his/her class, as configured through the > Moodle web interface. Is this in use somewhere? Would like to hear how it is being used and if we can add anything to Sugar to improve integration, maybe a class browser/selector? > I'll propose a third option, while we're talking about it: > > 3. Per-class servers. You can run many different ejabberd instances, > with DNS names like year4classD.schoolserver.local, one for each > classroom. Users can connect to the one for their classroom. Even if all > the ejabberds are running on the same physical server, this would prevent > overload. Once the servers are set up, no further server-side > configuration is required, and users can choose which class they are in. I have heard this being proposed for LTSP setups. Wonder if the servers could advertise themselves via mDNS and then offer those auto-discovered servers as hints to the jabber server textfield. Regards, Tomeu > --Ben > > > ___ > Sugar-devel mailing list > Sugar-devel@lists.sugarlabs.org > http://lists.sugarlabs.org/listinfo/sugar-devel > > -- «Sugar Labs is anyone who participates in improving and using Sugar. What Sugar Labs does is determined by the participants.» - David Farning ___ Sugar-devel mailing list Sugar-devel@lists.sugarlabs.org http://lists.sugarlabs.org/listinfo/sugar-devel
[Sugar-devel] deployment feedback (was Re: [IAEP] GPA ain't the world (was: [Sugar-news] Sugar Digest 2009-08-11))
On Sat, Aug 15, 2009 at 03:39, Raul Gutierrez Segales wrote: > On Thu, 2009-08-13 at 15:06 -0400, Walter Bender wrote: >> On Thu, Aug 13, 2009 at 2:17 PM, David Van Assche >> wrote: >> [snip] >> > Or are you saying the feedback is getting through and I'm just not seeing >> > it? >> >> We all seem to agree that feedback is important. >> >> We mostly agree that there is value in feedback from all deployments, >> big and small. >> >> We are currently getting valuable feedback from the field: Sur, the >> Ceibal blogs, reports from Nepal, Greg's reports from GPA, et al. >> >> We need more feedback and therefore we are exploring additional means >> of getting it. You ideas are welcome! >> > > Perhaps a section in Sugar Digest with links to highlights of what went > on in deployments during the week? Sounds like a great idea to me. > Wearing a deployer-hat I must confess that we could (Paraguayan > Deployment Team) do a better job filing tickets, giving feedback, etc. > > Will try to keep discipline from now on :-) This will be great. Also, what if each deployment lists somewhere (wiki?) the 10 bugs that would need fixed first and the 10 new features that need most? That way a volunteer developer would be able to relate his work to something actually useful somewhere else, as opposed to something that _he_ just thought was a good idea. I think this could be a powerful motivator to get more people involved. Regards, Tomeu -- «Sugar Labs is anyone who participates in improving and using Sugar. What Sugar Labs does is determined by the participants.» - David Farning ___ Sugar-devel mailing list Sugar-devel@lists.sugarlabs.org http://lists.sugarlabs.org/listinfo/sugar-devel
