Re: [Sugar-devel] [IAEP] [SoaS] The Future of Sugar on a Stick
I can understand why a teacher may not be interested in this discussion. Still, the debate is also very relevant. It's about how we're going to address your aunt's concerns. The debate is definitely very relevant, and I'm glad we're having it. Think of it this way: nobody wants to know how sausage is made, right? Well, we're the sausage factory! :-) To run with this analogy for a moment - what the conversation with my aunt reminded me of was this: while we sit here talking, there are hungry people out there. And the time we use to discuss the optimization of our sausage-making setup is time we are *not* spending making sausage that those people can eat. It's not a reason to stop having these discussions - they *are* needed - but it is (imo) something we should be painfully aware of every time we do. A sausage factory with beautifully optimized machines, happy skilled workers, etc. is a nice theoretical setup for a great sausage factory - but it's the production of sausage and its consumption by satisfied diners that turns it into an *actual* great sausage factory. So a litmus test for conversations in this thread (and other SLs) might be: Is this action I am about to take the best use of my time towards helping children learn? And on that note, my next post will be a summary of the thread to date so that (hopefully) we can see what's left to do in order to move forward on this. --Mel ___ Sugar-devel mailing list Sugar-devel@lists.sugarlabs.org http://lists.sugarlabs.org/listinfo/sugar-devel
Re: [Sugar-devel] [IAEP] [SoaS] The Future of Sugar on a Stick
There's a lot going on in this thread, so here is my attempt to summarize discussions so far. If I've missed or misstated anything, my apologies - and it's a wiki, so go fix it. ;-) http://wiki.sugarlabs.org/go/Talk:Sugar_on_a_Stick By my count, there are 4 things we need to decide on and then execute in order to wrap up this conversation. Some are already in progress. * 4.1 Make a SoaS mailing list * 4.2 Formalize a SoaS development team * 4.3 Determine what Sugar on a Stick refers to * 4.4 Determine what the code Sebastian is working on is called Only the third one has a clear owner (SLOBs) and can be decided at this time (the 4th seems to depend on the answer to the 3rd). How can we move these forward - and are there any other blocker decisions that aren't listed here? --Mel, the human ticket tracker ___ Sugar-devel mailing list Sugar-devel@lists.sugarlabs.org http://lists.sugarlabs.org/listinfo/sugar-devel
[Sugar-devel] mirror testing request
Sorry for cross posting... Before announcing it, There is an testing request from Adrian Chadd from CacheBoy.net whois providing these mirror's. This mirror system had global mirror's! So please test these link: http://sugarlabs.cdn.cacheboy.net/ And give mee feedback to me: - how it performs - your location/continent. The mirror is added to the monitoring (http+emaillist) http://martenvijn.nl/sugar_mirror.html Thanks, Marten -- Marten Vijn linux 2.0.18 OpenBSD 3.6 FreeBSD 4.6 http://martenvijn.nl http://opencommunitycamp.org http://wifisoft.org ___ Sugar-devel mailing list Sugar-devel@lists.sugarlabs.org http://lists.sugarlabs.org/listinfo/sugar-devel
[Sugar-devel] more mirrors
Hi, Last saturday I (on EuroBSDcon) was talking with folks for ISC. They be willing to mirror sugar as well. Shall I start working on this? Kind regards, Marten -- Marten Vijn linux 2.0.18 OpenBSD 3.6 FreeBSD 4.6 http://martenvijn.nl http://opencommunitycamp.org http://wifisoft.org ___ Sugar-devel mailing list Sugar-devel@lists.sugarlabs.org http://lists.sugarlabs.org/listinfo/sugar-devel
Re: [Sugar-devel] [Debian-olpc-devel] [IAEP] Glucose 0.84 and 0.85 packaged for Debian!
On Sun, Sep 20, 2009 at 07:30:07PM -0500, David Farning wrote: A couple of months ago your packaging systems was pretty new and confusing. Yesterday I was able to build test packages for GnewSense and Ubuntu. Pretty Cool. Yeah, that is certainly great news. The failure for some enthusiastic developers to get a grip about my packaging style back in spring was really frustrating, and I have since then refleced a lot on whether my approach was bad or just needed improvements and better documentation. As you can see, I still believe in the approach :-) When you succeeded now, do you think that is due to you being more familiar with the design now that you work more on it, or do you suspect that it is my tightening of the structure itself and the rewritten README.Source that helped you? It is interesting for me to know if it might make sense to encourage others with take a break, and look at it in 6 months from now, then maybe you'll get a grip or how else to approach the challenge of the dsign being complex. This what I was trying to ask, if rather unclearly. Downstream projects will require minor modification of your /Debian dir to accommodate different policies, build tools, and distro dependency versions, I am wondering, since we are creating fresh downstream package with a new build-tool, how can we create a useful work flow for both upstream and downstream. With down streams using git-buildpackage and cdbs, it seems pretty straight forward to ensure that useful patches make it back to git.debian.org. Indeed. The least complex is if GNewSense (as an example) is downstream of Debian - rather than mix'n'match Debian and Sugarlabs. Perhaps if I draw it... Here's a mapping between Sugarlabs and Debian development: Sugarlabs Debian = == VCS sourceVCS source N.tar.bz2 -o- pristine-tar -o- N.orig.tar.gz \ \ o- upstream o- N.deb /\ / master --- o- N.diff.gz / master -- Here's how I propose to use my packaging structure, for easiest giving back to Debian: Debian GNewSense == = VCSVCS source pristine-tar - pristine-tar -o- N.orig.tar.gz \ upstream - upstream o- N.deb \ / o- N.diff.gz / master -o- master -- The crucial part is the links between VCS'es: only the master branch derives - pristine-tar and upstream branches are mirrored but never ever edited directly. New Sugarlabs upstream releases and Git commits are only pulled through Debian - so that we stay in sync. The reason for mirroring pristine-tar and upstream is for git-buildpackage. It might be possible (I haven't tried) to not mirror, but instead adjust debian/gbp.conf (in master branch) to point to remote branches for pristine-tar and upstream. That would be better, as then GNewSense developers do not accidentally derive further away from Debian (git-import-orig should then fail rather than break the chain). Hope that makes sense, and pleases GNewSense and other potential peers. Regards, - Jonas -- * Jonas Smedegaard - idealist Internet-arkitekt * Tlf.: +45 40843136 Website: http://dr.jones.dk/ [x] quote me freely [ ] ask before reusing [ ] keep private signature.asc Description: Digital signature ___ Sugar-devel mailing list Sugar-devel@lists.sugarlabs.org http://lists.sugarlabs.org/listinfo/sugar-devel
Re: [Sugar-devel] [SLOBS] SoaS: Searching for Decision Panel volunteers.
On Mon, Sep 21, 2009 at 06:41, Bill Bogstad bogs...@pobox.com wrote: On Sun, Sep 20, 2009 at 5:18 AM, Tomeu Vizoso to...@sugarlabs.org wrote: . So, a possible solution could be calling the product marketed by SLs Sugar on a Stick and each individual team and product Fedora Sugar on a Stick, OpenSUSE Sugar on a Stick, etc. From time to time SLs would decide to call and market as Sugar on a Stick a particular release of a particular flavor. This decision process should be very transparent and fair, of course. As far as naming is concerned, I think this is a good idea. It acknowledges what seems to be the defacto situation (Fedora SoaS is SugarLabs primary full system distribution) while allowing for a possibility of change as required. I thought there were was another issue involving what communications channels to use for discussions about SoaS which doesn't seem like it is being addressed in recent messages in this (or related threads). I suppose that can wait until we find out if Feodora SoaS will remain under the SugarLabs umbrella. I would like to add some more thoughts though which are based on some of the messages on related threads coming directly or indirectly from educators. I think at some point SugarLabs may HAVE to switch from a Fedora based system if it wants runnable systems that it champions to be relevant. I base this on a number of messages recently asking more or less for stability (and longer term support). My understanding of stability as defined in these messages was that it was about things continuing to work the same way from week to week, month to month, and even year to year. It's okay if there are known problems as long as there are workarounds. What is bad is not knowing what is going to work (or how to use it). Given the short support window for Fedora releases (typically a bit over a year), it won't matter how long SugarLabs is willing to support a version of Sugar if the underlying distribution has unfixed security problems. It may be a while before Sugar itself is stable enough that this becomes an issue. Maybe some other way to provide full system stability over periods longer then a year can be found. On the chance that this isn't the case and to provide what educators (seem) to want requires a switch, let's leave the door open for change. Yes, the most obvious path is to be based on the next CentOS major release, which in turn will be based on Fedora 11 (AFAIK). Switching to other distros with LTS is of course possible but then it will be most probably carried out by a different team than SoaS Fedora. 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
[Sugar-devel] [Karma] agenda for tomorrow's
Hey guys, here is the meeting agenda I have come up w/ Feel free to change it http://wiki.sugarlabs.org/go/Karma:Meeting_21_Sep_2009 -- 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] mirror testing request
On Mon, Sep 21, 2009 at 09:14, Marten Vijn i...@martenvijn.nl wrote: Sorry for cross posting... Before announcing it, There is an testing request from Adrian Chadd from CacheBoy.net whois providing these mirror's. This mirror system had global mirror's! So please test these link: http://sugarlabs.cdn.cacheboy.net/ And give mee feedback to me: - how it performs - your location/continent. Hi Marten, quick results from just now in Prague, Czech Republic: http://sugarlabs.cdn.cacheboy.net 238K/s 66.175.192.46 (Wisconsin, USA) http://ftp.nluug.nl 536K/s http://vlaai.snt.utwente.nl 402K/s http://download2.sugarlabs.org 567K/s http://download.sugarlabs.org 274K/s Thanks, Tomeu The mirror is added to the monitoring (http+emaillist) http://martenvijn.nl/sugar_mirror.html Thanks, Marten -- Marten Vijn linux 2.0.18 OpenBSD 3.6 FreeBSD 4.6 http://martenvijn.nl http://opencommunitycamp.org http://wifisoft.org ___ Systems mailing list syst...@lists.sugarlabs.org http://lists.sugarlabs.org/listinfo/systems -- «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] [Karma] http://www.thatquiz.org
Hi, a reader in olpc-sur is suggesting the Karma team to give a look to http://www.thatquiz.org. Just downloaded a page and seems to run well offline. The author is Andrew Lyczak who worked as a teacher in rural Nepal: http://www.lyczak.com/andrew/resume/resume.html 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] [IAEP] [SoaS] The Future of Sugar on a Stick
On Mon, Sep 21, 2009 at 08:30, Mel Chua meta...@gmail.com wrote: There's a lot going on in this thread, so here is my attempt to summarize discussions so far. If I've missed or misstated anything, my apologies - and it's a wiki, so go fix it. ;-) http://wiki.sugarlabs.org/go/Talk:Sugar_on_a_Stick By my count, there are 4 things we need to decide on and then execute in order to wrap up this conversation. Some are already in progress. * 4.1 Make a SoaS mailing list * 4.2 Formalize a SoaS development team * 4.3 Determine what Sugar on a Stick refers to * 4.4 Determine what the code Sebastian is working on is called Only the third one has a clear owner (SLOBs) and can be decided at this time (the 4th seems to depend on the answer to the 3rd). How can we move these forward - and are there any other blocker decisions that aren't listed here? Great summary, this is my understanding of how things stand today: 4.1 can be left entirely to the SoaS team for decide 4.2 also depends only on the SoaS team, haven't heard nobody against SoaS qualifying for a project inside SLs. SoaS is already listed as a project in the wiki, btw: http://wiki.sugarlabs.org/go/Category:Project http://wiki.sugarlabs.org/go/Sugar_Labs/Project_Guidelines 4.3 a decision panel has been proposed to help with this 4.4 only depends on the SoaS team, but may depend on 4.3 to avoid name clashes 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] [Systems] 11s ap's
On Mon, Sep 21, 2009 at 09:35, Marten Vijn i...@martenvijn.nl wrote: Hi, FreeBSD 8.0 shipping 802.11s support. As soon I have time (not in the next 2 weeks) 'll start testing. OLPC's mesh standard is (not tested) probably not standard or compatible. If the XO's are not compatible, is Sugar going to follow the 11s standard or OLPC/marvel's standard? Sugar uses NetworkManager to manage the network interfaces and NM is a standard part of most modern linux distros (maybe also *BSD?). So we can safely say that the protocol details are abstracted from Sugar. 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
[Sugar-devel] [Karma] raphaeljs more active than we thought
raphaeljs is actually a lot more active than we thought. Most of the commits happend on 1.0 branch and not master. http://github.com/DmitryBaranovskiy/raphael/commits/1.0 unfortunately, it still appears that all commits have been made by one author :( i am working my way thru the reference portion of the raphjs site, raphael does support function chaining in my limited time playing w/ it so far. I am also going to play w/ google's svgweb later today http://codinginparadise.org/projects/svgweb/docs/QuickStart.html and see what i think of it Do you know a good tutorial for dojox.gfx? -- 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] [Feature Freeze] request for exception for Turtle Art
On Sat, Sep 12, 2009 at 17:49, Walter Bender walter.ben...@gmail.com wrote:
I made a somewhat invasive change to Turtle Art in order to make the
toolbars backward compatible with Sugar 0.82-0.84. Essentially, I
catch an exception when trying to create a ToolbarBox. In the
exception handler, I create the old-style toolbars.
As discussed in IRC, this can be considered a regression fix, so no
exception is required.
Regards,
Tomeu
try:
# Use 0.86 toolbar design
toolbar_box = ToolbarBox()
except NameError:
# Use pre-0.86 toolbar design
self.toolbox = activity.ActivityToolbox(self)
self.set_toolbox(self.toolbox)
I had to add a new toolbar for the help menu in the old toolbar
configuration since I had moved the hover help to a toolbar in the
0.86 configuration:
self.helpToolbar = HelpToolbar(self)
self.toolbox.add_toolbar(_('Help'),self.helpToolbar)
So I will request an exception for String Freeze as well.
(I also did a work-around for a Rainbow-related bug with image save.)
Changes are in:
http://git.sugarlabs.org/projects/turtleart/repos/walters-clone
-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 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] [IAEP] 2 idea's to train people dyslexia
On Wed, Sep 16, 2009 at 09:56, Marten Vijn i...@martenvijn.nl wrote: On Wed, 2009-09-16 at 09:34 +0200, Marten Vijn wrote: Hi, I am not a dyslexia expert, maybe a bit more that average. idea 1 Today I read in a newspaper that it helps people to let them hear what they (words not the characters). __^ type* *Actually I do knwo a lot about dyslexia, like that is really annoying not being capable to write normal emails without make errors. No patches seem to be availible. Training young kids _in time_ prevents a lot frustration, dropouts from school and waste of very creative talented kids. My son would have a 50% change of being born with it too. So having having a good educational toolset seems important. Wonder if we could involve on this an existing dyslexia organization? Regards, Tomeu cheers Marten -- Marten Vijn linux 2.0.18 OpenBSD 3.6 FreeBSD 4.6 http://martenvijn.nl http://opencommunitycamp.org http://wifisoft.org ___ IAEP -- It's An Education Project (not a laptop project!) i...@lists.sugarlabs.org http://lists.sugarlabs.org/listinfo/iaep -- «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] [Karma] impressed by SVGWeb, so far
On Mon, 2009-09-21 at 17:41 +0545, Bryan Berry wrote: I haven't done a example animation w/ svgweb yet but color me impressed! hm, the more I look at it the more it seems that the svg web project page shows off the power of regular svg and doesn't provide high-level drawing functions like raphaeljs does. svg-web is perhaps more focused on cross-browser support. I have sent an email to the svg-web group trying to find out how svg-web relates to projects like raphaeljs -- 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] [Karma] http://www.thatquiz.org
On Mon, 2009-09-21 at 10:55 +0200, Tomeu Vizoso wrote: Hi, a reader in olpc-sur is suggesting the Karma team to give a look to http://www.thatquiz.org. Just downloaded a page and seems to run well offline. The author is Andrew Lyczak who worked as a teacher in rural Nepal: http://www.lyczak.com/andrew/resume/resume.html Regards, Tomeu I like it! very nice. I am a bit concerned about the license though: Copyright Andrew Lyczak.All rights reserved.No HTML pages or Javascript may be reproduced without permission Such licensing has proved to be a big headache in the past. All the same, this exactly what we are trying to do! -- 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] [Karma] http://www.thatquiz.org
On Mon, Sep 21, 2009 at 16:25, Bryan Berry br...@olenepal.org wrote: On Mon, 2009-09-21 at 10:55 +0200, Tomeu Vizoso wrote: Hi, a reader in olpc-sur is suggesting the Karma team to give a look to http://www.thatquiz.org. Just downloaded a page and seems to run well offline. The author is Andrew Lyczak who worked as a teacher in rural Nepal: http://www.lyczak.com/andrew/resume/resume.html Regards, Tomeu I like it! very nice. I am a bit concerned about the license though: Copyright Andrew Lyczak.All rights reserved.No HTML pages or Javascript may be reproduced without permission Such licensing has proved to be a big headache in the past. All the same, this exactly what we are trying to do! Yes, I was rather thinking about joining forces with the author, instead of just reusing code. 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] [SLOBS] SoaS: Searching for Decision Panel volunteers.
El Mon, 21-09-2009 a las 10:14 +0200, Tomeu Vizoso escribió: Yes, the most obvious path is to be based on the next CentOS major release, which in turn will be based on Fedora 11 (AFAIK). Switching to other distros with LTS is of course possible but then it will be most probably carried out by a different team than SoaS Fedora. The only reason you want a distribution to be long-term supported is security updates, but those tend to affect mostly server applications (which we don't have) or multiuser environments (and we have only one user). The only remaining pieces that may contain vulnerabilities are the Activities. Especially the web browser. It's not even clear if *we* would ever be able to afford the cost of long-term support cycles for Sugar itself, which is the part of SoaS that matters the most. At this time, however, we don't offer any way for users to install updates *at all*! This could definitely improve over time; for example, we could integrate a UI for PackageKit. For long-term security and support, we could adopt the Linux model: push this concern down to the distributors and let them do a profitable business out of it. This creates a sustainable market for Sugar. Linux distributors who have successfully built a reputation for offering good customer support, such as Red Hat, *do* make good profits and *do* reinvest a large part of them to contribute back to Linux development. Everyone wins. -- // 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] How to add karma api to api.sugarlabs.org?
I finally looked at the api.sugarlabs.org code last night. It looks pretty straight forward to add karma to api.sl.org. We will need to: 1. add a clause to the api build script to build the karma html docs with jsdocs 2. Add a landing page so users can chose either sugar, karama, apis. 3. Create a ccs style sheet to coordinate the look and feel of the landing page, sugar docs, and karma doc. I don't know any javascript or css so it would be helpful if you could find some one to take 1 and 3. david 2009/9/14 Bryan Berry br...@olenepal.org: On Wed, 2009-09-09 at 14:02 -0500, David Farning wrote: This is going to involve digging into some code that has been running for over a year without being touched--I think I rebooted the build server once in that time. Could u just give us a folder off of api.sl.o? like api.sl.o/karma/ or api.sl.o/projects/karma/ ? We won't be using epydoc but jsdoc instead -- 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] [Karma] http://www.thatquiz.org
On Mon, 2009-09-21 at 16:29 +0200, Tomeu Vizoso wrote: On Mon, Sep 21, 2009 at 16:25, Bryan Berry br...@olenepal.org wrote: On Mon, 2009-09-21 at 10:55 +0200, Tomeu Vizoso wrote: Hi, a reader in olpc-sur is suggesting the Karma team to give a look to http://www.thatquiz.org. Just downloaded a page and seems to run well offline. The author is Andrew Lyczak who worked as a teacher in rural Nepal: http://www.lyczak.com/andrew/resume/resume.html Regards, Tomeu I like it! very nice. I am a bit concerned about the license though: Copyright Andrew Lyczak.All rights reserved.No HTML pages or Javascript may be reproduced without permission Such licensing has proved to be a big headache in the past. All the same, this exactly what we are trying to do! Yes, I was rather thinking about joining forces with the author, instead of just reusing code. Regards, Tomeu Me too, I just emailed him and hope to hear back -- 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] [IAEP] [SoaS] The Future of Sugar on a Stick
On Mon, Sep 21, 2009 at 3:37 AM, Tomeu Vizoso to...@sugarlabs.org wrote: On Mon, Sep 21, 2009 at 08:30, Mel Chua meta...@gmail.com wrote: There's a lot going on in this thread, so here is my attempt to summarize discussions so far. If I've missed or misstated anything, my apologies - and it's a wiki, so go fix it. ;-) http://wiki.sugarlabs.org/go/Talk:Sugar_on_a_Stick By my count, there are 4 things we need to decide on and then execute in order to wrap up this conversation. Some are already in progress. * 4.1 Make a SoaS mailing list * 4.2 Formalize a SoaS development team * 4.3 Determine what Sugar on a Stick refers to * 4.4 Determine what the code Sebastian is working on is called Only the third one has a clear owner (SLOBs) and can be decided at this time (the 4th seems to depend on the answer to the 3rd). How can we move these forward - and are there any other blocker decisions that aren't listed here? Great summary, this is my understanding of how things stand today: 4.1 can be left entirely to the SoaS team for decide 4.2 also depends only on the SoaS team, haven't heard nobody against SoaS qualifying for a project inside SLs. SoaS is already listed as a project in the wiki, btw: http://wiki.sugarlabs.org/go/Category:Project http://wiki.sugarlabs.org/go/Sugar_Labs/Project_Guidelines 4.3 a decision panel has been proposed to help with this 4.4 only depends on the SoaS team, but may depend on 4.3 to avoid name clashes Regards, After reading this thread again, Mel's and Tomeu's summaries are spot on. 1,2, and 4 are SoaS Project level decisions. We could go even one step further and say 4.3 is a marketing team/soas project level decision. This give the marketing team the freedom to identify a marketing strategy base on either the platform of a specific project with the overall project without committing the Sugar Labs to a 'official' position david ___ Sugar-devel mailing list Sugar-devel@lists.sugarlabs.org http://lists.sugarlabs.org/listinfo/sugar-devel
Re: [Sugar-devel] [Debian-olpc-devel] [IAEP] Glucose 0.84 and 0.85 packaged for Debian!
On Mon, Sep 21, 2009 at 2:51 AM, Jonas Smedegaard d...@jones.dk wrote: On Sun, Sep 20, 2009 at 07:30:07PM -0500, David Farning wrote: A couple of months ago your packaging systems was pretty new and confusing. Yesterday I was able to build test packages for GnewSense and Ubuntu. Pretty Cool. Yeah, that is certainly great news. The failure for some enthusiastic developers to get a grip about my packaging style back in spring was really frustrating, and I have since then refleced a lot on whether my approach was bad or just needed improvements and better documentation. As you can see, I still believe in the approach :-) When you succeeded now, do you think that is due to you being more familiar with the design now that you work more on it, or do you suspect that it is my tightening of the structure itself and the rewritten README.Source that helped you? It is interesting for me to know if it might make sense to encourage others with take a break, and look at it in 6 months from now, then maybe you'll get a grip or how else to approach the challenge of the dsign being complex. I think the biggest piece was that modifying upstream 'forced' down streams to make a choice between picking into a choice between adopting the new method(which meant both learning a new sparsely document method and adopting their current packages to that method) or forging on ahead with the old method. You make a decision to break backwards compatibility. Down streams _never_ like that. The last time I did any packaging was during the 'ice weasle/fire fox' dust up. I started with no preconceived ideas about how packing should be done. I pinged Bernie off list how to get started. He pointed me to git.debian.org and told me to grep for sugar. The just try build the packages on the new disto. He warned me that the challenges would be due to build system version mismatches and dependancy issues. I manually added the dependancies from alsroots jhconvert packages and started building. The documentation worked well enough to create a basic build. I don't understand packaging well enough to answer the complexity issues. This what I was trying to ask, if rather unclearly. Downstream projects will require minor modification of your /Debian dir to accommodate different policies, build tools, and distro dependency versions, I am wondering, since we are creating fresh downstream package with a new build-tool, how can we create a useful work flow for both upstream and downstream. With down streams using git-buildpackage and cdbs, it seems pretty straight forward to ensure that useful patches make it back to git.debian.org. Indeed. The least complex is if GNewSense (as an example) is downstream of Debian - rather than mix'n'match Debian and Sugarlabs. Perhaps if I draw it... I scheduled .deb packaging as my fun learning project for the .88 release cycle:) I will try to hack away at it 2-3 hours a night for the next 6 months. So it might be a while before I have time learn about, test, and respond to your recommend work flows. david Here's a mapping between Sugarlabs and Debian development: Sugarlabs Debian = == VCS source VCS source N.tar.bz2 -o- pristine-tar -o- N.orig.tar.gz \ \ o- upstream o- N.deb / \ / master --- o- N.diff.gz / master -- Here's how I propose to use my packaging structure, for easiest giving back to Debian: Debian GNewSense == = VCS VCS source pristine-tar - pristine-tar -o- N.orig.tar.gz \ upstream - upstream o- N.deb \ / o- N.diff.gz / master -o- master -- The crucial part is the links between VCS'es: only the master branch derives - pristine-tar and upstream branches are mirrored but never ever edited directly. New Sugarlabs upstream releases and Git commits are only pulled through Debian - so that we stay in sync. The reason for mirroring pristine-tar and upstream is for git-buildpackage. It might be possible (I haven't tried) to not mirror, but instead adjust debian/gbp.conf (in master branch) to point to remote branches for pristine-tar and upstream. That would be better, as then GNewSense developers do not accidentally derive further away from Debian (git-import-orig should then fail rather than break the chain). Hope that makes sense, and pleases GNewSense and other potential peers. Regards, - Jonas -- * Jonas Smedegaard - idealist
Re: [Sugar-devel] [IAEP] [SLOBS] SoaS: Searching for Decision Panel volunteers.
For long-term security and support, we could adopt the Linux model: push this concern down to the distributors and let them do a profitable business out of it. This creates a sustainable market for Sugar. Linux distributors who have successfully built a reputation for offering good customer support, such as Red Hat, do make good profits and do reinvest a large part of them to contribute back to Linux development. Everyone wins. I'm afraid you cannot « push » anything down to the distributors. Distributions will do what they do: package Sugar and let users do whatever they want to with it. However, as far as I can see right now, there is no identifiable market for Sugar. Yes, there are potentials, but until there is a distinct product, there is no market. Getting Sugar into the distributions, while worthy and necessary, does not guarantee the creation of that product. -- Philippe -- The trouble with common sense is that it is so uncommon. Anonymous ___ Sugar-devel mailing list Sugar-devel@lists.sugarlabs.org http://lists.sugarlabs.org/listinfo/sugar-devel
Re: [Sugar-devel] [Karma] raphaeljs more active than we thought
this is the official dojo.gfx documentation: http://docs.dojocampus.org/dojox/ghttp://docs.dojocampus.org/dojox/gfx/#id25 fx I have not found a great great tutorial, but here are some examples: http://download.dojotoolkit.org/release-1.0.2/dojo-release-1.0.2/dojox/gfx/demos/circles.html 2009/9/21 Bryan Berry br...@olenepal.org raphaeljs is actually a lot more active than we thought. Most of the commits happend on 1.0 branch and not master. http://github.com/DmitryBaranovskiy/raphael/commits/1.0 unfortunately, it still appears that all commits have been made by one author :( i am working my way thru the reference portion of the raphjs site, raphael does support function chaining in my limited time playing w/ it so far. I am also going to play w/ google's svgweb later today http://codinginparadise.org/projects/svgweb/docs/QuickStart.html and see what i think of it Do you know a good tutorial for dojox.gfx? -- 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] [SLOBS] SoaS: Searching for Decision Panel volunteers.
On Sun, Sep 20, 2009 at 5:18 AM, Tomeu Vizoso to...@sugarlabs.org wrote: As a parallel, Linux Caixa Mágica is the name for a product, Caixa Mágica Software the name of the company behind it, and its community is called Caixa Mágica Community. Though the community can submit packages for approval and distribution, my understanding is that most of the distro work is done by employees at Caixa Mágica Software. They have actually changed once from OpenSUSE to Mandriva as the base of their distro, but in that case I would expect that the company just decided it internally and its employees just stopped working on one code base and started using the other. AFAIK, no names were changed, nor for the product, nor the company, nor the community. I bet some people in the community didn't liked it, some might have left it, but that didn't affected the continuity of the project. The crucial difference to our situation is that we have a team for every distro and chances are that those working on one are not going to switch teams and start using another distro as the base of their work. I think there is a more important difference here. In Caixa Mágica the work was done by paid employees, and decisions made by management. The employees have to conform to those decisions to continue getting paid. In a free software community, ideally the decisions are made by those doing the work. When those who aren't doing the work mandate change it often goes very poorly (which is why I think there are decision panels for cases where SLOBs are not intimately familiar with the details and workings of a particular issue..) As Bernie pointed out, it doesn't matter to the end user. However, one must be careful to avoid the trap of thinking that this is like a business and the end user/customer is the only concern. This is a community, and the contributors to the community are pretty important, if not most important in the equation, because without contributors, work tends to cease. I ran through all of that to end up saying, this seems like a non-issue. Other distributions are working on packaging and distributing Sugar, and that's great. However, no one else seems to be putting the same level of work in as Sebastian and the rest of the SoaS contributors are to keep very close to upstream and stay very involved with upstream. As others have noted SoaS is currently the defacto LiveUSB platform for Sugar, and there don't seem to be many competitors, so what's the issue with making it official? When a 'competitor' comes along that is willing to do the same work, perhaps then it will be time to evaluate things (on technical merits). I'll close with another community example - postgresql.org. Postgres has a LiveCD that is based on Fedora. Is it because Postgres is a Fedora project, or that all of the developers use Fedora?? No. Is it because it runs best on Fedora? again no. It's because a member of the postgres community, Devrim Gunduz, is willing to invest the time to build the LiveCD with each subsequent release and does so on Fedora and no one else is doing comparable work (I should note that Devrim did change from Fedora to CentOS for the most recent LiveCD just a few days ago, and as predicted, no on cares, but the point is, the person doing the work made that decision) Is SoaS the official SL.o Live Environment? Might as well be, because it's already the defacto choice, and no one else is stepping up to offer anything different. ___ Sugar-devel mailing list Sugar-devel@lists.sugarlabs.org http://lists.sugarlabs.org/listinfo/sugar-devel
[Sugar-devel] [GIT] how to add an admin?
Hi guys does anyone know how to grant admin/owner privileges on a git project to a contributor user? -- Felipe López Toledo ___ Sugar-devel mailing list Sugar-devel@lists.sugarlabs.org http://lists.sugarlabs.org/listinfo/sugar-devel
Re: [Sugar-devel] [IAEP] 2 idea's to train people dyslexia
Hi Marilyn, What would your feature list be on a small (linux driven) laptop in addition to mine? - audiofeedback (hear what you type (per word basis)) - adapted lessons (multilanguage) for tipptrainer http://freshmeat.net/projects/pingos_tipptrainer/ - may something thats enlarges the cursor area and obviously: - spelling checker (fix/highlight while typing) - large font buttons thanks, Marten On Mon, 2009-09-21 at 09:40 -0500, David Farning wrote: Marten, I would like to introduce you to Marilyn Hagle (CCed). She is active at the intersection of dyslexia and technology based education tools. She has recently written a grant to set up a pilot for researching and using sugar as a platform for helping kids overcome or adapt to their dyslexia. david On Mon, Sep 21, 2009 at 5:37 AM, Marten Vijn i...@martenvijn.nl wrote: On Mon, 2009-09-21 at 12:17 +0200, Tomeu Vizoso wrote: On Wed, Sep 16, 2009 at 09:56, Marten Vijn i...@martenvijn.nl wrote: On Wed, 2009-09-16 at 09:34 +0200, Marten Vijn wrote: Hi, I am not a dyslexia expert, maybe a bit more that average. idea 1 Today I read in a newspaper that it helps people to let them hear what they (words not the characters). __^ type* *Actually I do knwo a lot about dyslexia, like that is really annoying not being capable to write normal emails without make errors. No patches seem to be availible. Training young kids _in time_ prevents a lot frustration, dropouts from school and waste of very creative talented kids. My son would have a 50% change of being born with it too. So having having a good educational toolset seems important. Wonder if we could involve on this an existing dyslexia organization? good idea. http://books.google.nl/books?id=pLvC1kKUWTkCpg=PA47lpg=PA47dq=audio +feedback +dyslexiasource=blots=iMn_I_8efusig=CQhPMzM15_twYh43WTSbKP6qbmMhl=nlei=DlO3Sru8KI_E-QavmsXcCQsa=Xoi=book_resultct=resultresnum=5#v=onepageq=f=false http://www.springerlink.com/content/r33873h07n78j722/ mmm, I 'll keep it on my list for dutch researchers. Not If I will to sucseed. I never know who am talking to tomorrow :) cheers, Marten Regards, Tomeu cheers Marten -- Marten Vijn linux 2.0.18 OpenBSD 3.6 FreeBSD 4.6 http://martenvijn.nl http://opencommunitycamp.org http://wifisoft.org ___ IAEP -- It's An Education Project (not a laptop project!) i...@lists.sugarlabs.org http://lists.sugarlabs.org/listinfo/iaep -- Marten Vijn linux 2.0.18 OpenBSD 3.6 FreeBSD 4.6 http://martenvijn.nl http://opencommunitycamp.org http://wifisoft.org ___ 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 -- this email is sent from my mainframe. http://martenvijn.nlSugar on a Stick http://bsd.wifisoft.org/nek/The Network Event Kit http://opencommunitycamp.org 26th Jul - 2nd August ___ Sugar-devel mailing list Sugar-devel@lists.sugarlabs.org http://lists.sugarlabs.org/listinfo/sugar-devel
Re: [Sugar-devel] [IAEP] [SoaS] The Future of Sugar on a Stick
Hi Mel that wiki page is helpful To my knowledge, Sugar on a Stick has not been trademarked yet by Sugar Labs; my position is that it should be. Sugar on a Stick is the heart of the Sugar Labs strategy for spreading Sugar use beyond OLPC. Although other technical solutions are promising, at this time they don't come close to matching the advantages of the SoaS approach, in particular its conceptual simplicity to nongeeks. SoaS overcomes the single biggest obstacle to easily running any non-Microsoft system software on PCs and netbooks: the installation barrier. Our short definition of SoaS should be immediately intelligible to teachers, in my view. Most teachers won't care if Sugar runs on GNU/Linux, but they will care very much about its cost, reliability, and level of technical competence required to obtain/install/configure/test it and obtain support throughout. How about: Sugar on a Stick is a version of the Sugar Learning Platform for children which runs from an ordinary USB stick. It is meant for 1-to-1 use in schools and at home, providing a coherent and consistent computing experience. Based on GNU/Linux, SoaS is free/libre open-source software focused on reliability, customizability, deployability, and online and local support. If we can agree on this definition, we are on the road to agreeing on what SoaS is from a technical standpoint. As stated previously I think the 'best' liveUSB should represent Sugar Labs. Which doesn't preclude listing other liveUSB Sugars, but teachers will need a dead simple path from homepage to pancake-button download to installer/USB loader to boot and configure. Sean On 9/21/09, Tomeu Vizoso to...@sugarlabs.org wrote: On Mon, Sep 21, 2009 at 08:30, Mel Chua meta...@gmail.com wrote: There's a lot going on in this thread, so here is my attempt to summarize discussions so far. If I've missed or misstated anything, my apologies - and it's a wiki, so go fix it. ;-) http://wiki.sugarlabs.org/go/Talk:Sugar_on_a_Stick By my count, there are 4 things we need to decide on and then execute in order to wrap up this conversation. Some are already in progress. * 4.1 Make a SoaS mailing list * 4.2 Formalize a SoaS development team * 4.3 Determine what Sugar on a Stick refers to * 4.4 Determine what the code Sebastian is working on is called Only the third one has a clear owner (SLOBs) and can be decided at this time (the 4th seems to depend on the answer to the 3rd). How can we move these forward - and are there any other blocker decisions that aren't listed here? Great summary, this is my understanding of how things stand today: 4.1 can be left entirely to the SoaS team for decide 4.2 also depends only on the SoaS team, haven't heard nobody against SoaS qualifying for a project inside SLs. SoaS is already listed as a project in the wiki, btw: http://wiki.sugarlabs.org/go/Category:Project http://wiki.sugarlabs.org/go/Sugar_Labs/Project_Guidelines 4.3 a decision panel has been proposed to help with this 4.4 only depends on the SoaS team, but may depend on 4.3 to avoid name clashes Regards, Tomeu -- «Sugar Labs is anyone who participates in improving and using Sugar. What Sugar Labs does is determined by the participants.» - David Farning ___ 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] Long-term support for Sugar (was: slobs... blah blah)
[cc += mstone] [cc -= everyone else] El Mon, 21-09-2009 a las 12:54 -0400, Bill Bogstad escribió: I agree with your statement about security updates being what is desired here However, you can have bugs elsewhere in the stack which can cause problems even if all anyone ever runs directly are Sugar activities: 1. Single packet DOS attacks against the kernel. Yes, but the vast majority of these actually affect weird network protocols that nobody's using (such as IPX or AFP) or weird IP options that are not normally exploitable with a regular Internet client. 2. Overflow bugs in the DNS resolver libraries of the system which are triggered by simply doing a DNS query from the browser. (Implies no bug in the browser itself.) Yes, those were really scary... the DNS code is as ugly and unsafe as all ancient BSD code is. 3. Overflow bugs in ANY non-Sugar library/program which is used by an Activity and whose parameters come from data which might be obtained from the Internet. Perhaps gnome libraries? Python interpreter/core libraries? I believe Read is a wrapper for evince and/or poppler, Speak is a wrapper for espeak or gst-espeak. Any activity which wraps a standard Linux program is a potential problem. Indeed. This is one more reason why I dislike the notion of drawing a straight line in across a modern distribution and call everything on one side system and everything on the other side applications. We have very advanced package systems in Linux, we don't need to regress to Windows-era tools that can't upgrade the system and its applications consistently. If it were on me, I'd kill the XO bundle format and find a different way to enable unprivileged installation of activities Presently, giving out root to activities would not even constitute an actual regression in security, since we do not have a fully functional version of Rainbow anyway. But I agree we should fix this weakness one day. Sure an activity can attempt to filter out bad data. I see this as getting into the anti-virus signature game though. Every time an activity is modified to filter out some new variant the attacker will just change their data slightly by adding padding, etc. Maybe it wouldn't be as bad as I suggest, but it could get ugly fast and activity performance would suffer as data was parsed in two places (wrapper and core program). We are not yet a target because most Sugar installations (XO-1s) are slow and at the end of really slow network pipes. Always-on Sugar workstations in developed world schools sound like a much better target. Not as nice as ubiquitous Windows boxes, but still of interest. I think partitioning security using native UNIX concepts (uids and permissions) can be done effectively with a negligible performance hit. It's technically feasible, and Michael Stone has a 90% finished implementation of this concept. Now all we need to do is the *other* 90% of the work to make it ready for production :-) Even RedHat's $30 pricing for desktop support for educational users is higher then I believe SoaS (or its equivalent) needs to support. Tomeu's CentOS suggestion is more plausible to me. I wasn't suggesting paying Red Hat to support us. I was suggesting that some companies -- like, for example, Solution Grove -- could offer such long-term support service to schools for a fee. Such companies could decide to create a CentOS based spin of SoaS, or backport the security fixes themselves, or maybe even ensure that major OS upgrades are synchronized with the beginning of the school year and work seamlessly for the all the hardware they support. It's really up to them to figure out what makes their own customers happy. Sugar Labs does not need to spend a single buck on this, exactly the same way the Kernel Hackers don't need to care about linux-2.6.18 today... unless they're employed at Red Hat, of course! ;-) -- // 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] [SLOBS] Long-term support for Sugar (was: slobs... blah blah)
On Mon, Sep 21, 2009 at 19:25, Bernie Innocenti ber...@codewiz.org wrote: [cc += mstone] [cc -= everyone else] El Mon, 21-09-2009 a las 12:54 -0400, Bill Bogstad escribió: I agree with your statement about security updates being what is desired here However, you can have bugs elsewhere in the stack which can cause problems even if all anyone ever runs directly are Sugar activities: 1. Single packet DOS attacks against the kernel. Yes, but the vast majority of these actually affect weird network protocols that nobody's using (such as IPX or AFP) or weird IP options that are not normally exploitable with a regular Internet client. 2. Overflow bugs in the DNS resolver libraries of the system which are triggered by simply doing a DNS query from the browser. (Implies no bug in the browser itself.) Yes, those were really scary... the DNS code is as ugly and unsafe as all ancient BSD code is. 3. Overflow bugs in ANY non-Sugar library/program which is used by an Activity and whose parameters come from data which might be obtained from the Internet. Perhaps gnome libraries? Python interpreter/core libraries? I believe Read is a wrapper for evince and/or poppler, Speak is a wrapper for espeak or gst-espeak. Any activity which wraps a standard Linux program is a potential problem. Indeed. This is one more reason why I dislike the notion of drawing a straight line in across a modern distribution and call everything on one side system and everything on the other side applications. We have very advanced package systems in Linux, we don't need to regress to Windows-era tools that can't upgrade the system and its applications consistently. If it were on me, I'd kill the XO bundle format and find a different way to enable unprivileged installation of activities Presently, giving out root to activities would not even constitute an actual regression in security, since we do not have a fully functional version of Rainbow anyway. But I agree we should fix this weakness one day. Sure an activity can attempt to filter out bad data. I see this as getting into the anti-virus signature game though. Every time an activity is modified to filter out some new variant the attacker will just change their data slightly by adding padding, etc. Maybe it wouldn't be as bad as I suggest, but it could get ugly fast and activity performance would suffer as data was parsed in two places (wrapper and core program). We are not yet a target because most Sugar installations (XO-1s) are slow and at the end of really slow network pipes. Always-on Sugar workstations in developed world schools sound like a much better target. Not as nice as ubiquitous Windows boxes, but still of interest. I think partitioning security using native UNIX concepts (uids and permissions) can be done effectively with a negligible performance hit. It's technically feasible, and Michael Stone has a 90% finished implementation of this concept. Now all we need to do is the *other* 90% of the work to make it ready for production :-) Even RedHat's $30 pricing for desktop support for educational users is higher then I believe SoaS (or its equivalent) needs to support. Tomeu's CentOS suggestion is more plausible to me. I wasn't suggesting paying Red Hat to support us. I was suggesting that some companies -- like, for example, Solution Grove -- could offer such long-term support service to schools for a fee. Such companies could decide to create a CentOS based spin of SoaS, or backport the security fixes themselves, or maybe even ensure that major OS upgrades are synchronized with the beginning of the school year and work seamlessly for the all the hardware they support. It's really up to them to figure out what makes their own customers happy. Sugar Labs does not need to spend a single buck on this, exactly the same way the Kernel Hackers don't need to care about linux-2.6.18 today... unless they're employed at Red Hat, of course! ;-) Well, if we decide that future releases of Sugar should run ok on the next major release of CentOS, we cannot depend on later versions of python, gtk, etc. 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] [SLOBS] Long-term support for Sugar (was: slobs... blah blah)
On Mon, Sep 21, 2009 at 8:45 PM, Tomeu Vizoso to...@sugarlabs.org wrote: On Mon, Sep 21, 2009 at 19:25, Bernie Innocenti ber...@codewiz.org wrote: [cc += mstone] [cc -= everyone else] El Mon, 21-09-2009 a las 12:54 -0400, Bill Bogstad escribió: I agree with your statement about security updates being what is desired here However, you can have bugs elsewhere in the stack which can cause problems even if all anyone ever runs directly are Sugar activities: 1. Single packet DOS attacks against the kernel. Yes, but the vast majority of these actually affect weird network protocols that nobody's using (such as IPX or AFP) or weird IP options that are not normally exploitable with a regular Internet client. 2. Overflow bugs in the DNS resolver libraries of the system which are triggered by simply doing a DNS query from the browser. (Implies no bug in the browser itself.) Yes, those were really scary... the DNS code is as ugly and unsafe as all ancient BSD code is. 3. Overflow bugs in ANY non-Sugar library/program which is used by an Activity and whose parameters come from data which might be obtained from the Internet. Perhaps gnome libraries? Python interpreter/core libraries? I believe Read is a wrapper for evince and/or poppler, Speak is a wrapper for espeak or gst-espeak. Any activity which wraps a standard Linux program is a potential problem. Indeed. This is one more reason why I dislike the notion of drawing a straight line in across a modern distribution and call everything on one side system and everything on the other side applications. We have very advanced package systems in Linux, we don't need to regress to Windows-era tools that can't upgrade the system and its applications consistently. If it were on me, I'd kill the XO bundle format and find a different way to enable unprivileged installation of activities Presently, giving out root to activities would not even constitute an actual regression in security, since we do not have a fully functional version of Rainbow anyway. But I agree we should fix this weakness one day. Sure an activity can attempt to filter out bad data. I see this as getting into the anti-virus signature game though. Every time an activity is modified to filter out some new variant the attacker will just change their data slightly by adding padding, etc. Maybe it wouldn't be as bad as I suggest, but it could get ugly fast and activity performance would suffer as data was parsed in two places (wrapper and core program). We are not yet a target because most Sugar installations (XO-1s) are slow and at the end of really slow network pipes. Always-on Sugar workstations in developed world schools sound like a much better target. Not as nice as ubiquitous Windows boxes, but still of interest. I think partitioning security using native UNIX concepts (uids and permissions) can be done effectively with a negligible performance hit. It's technically feasible, and Michael Stone has a 90% finished implementation of this concept. Now all we need to do is the *other* 90% of the work to make it ready for production :-) Even RedHat's $30 pricing for desktop support for educational users is higher then I believe SoaS (or its equivalent) needs to support. Tomeu's CentOS suggestion is more plausible to me. I wasn't suggesting paying Red Hat to support us. I was suggesting that some companies -- like, for example, Solution Grove -- could offer such long-term support service to schools for a fee. Such companies could decide to create a CentOS based spin of SoaS, or backport the security fixes themselves, or maybe even ensure that major OS upgrades are synchronized with the beginning of the school year and work seamlessly for the all the hardware they support. It's really up to them to figure out what makes their own customers happy. Sugar Labs does not need to spend a single buck on this, exactly the same way the Kernel Hackers don't need to care about linux-2.6.18 today... unless they're employed at Red Hat, of course! ;-) Well, if we decide that future releases of Sugar should run ok on the next major release of CentOS, we cannot depend on later versions of python, gtk, etc. I'm not sure something like sugar which is (and should be) fast moving mixes well with something like CentOS or its parent. At the beginning of the v6 release cycle begins it will be fine but within 12 months I'm sure everyone will want the features that are provided by the latest release of gtk/glib/gstreamer/python/telepathy etc that just won't be available in v6 so we en up in a situation we've been in before where we either need to fork massive amounts of packages to get the features everyone wants or moving back to Fedora. Both which will require lots of work. I know what its like as I've spent lots and lots of hours getting the changes merged upstream. Peter ___
Re: [Sugar-devel] [SLOBS] Long-term support for Sugar (was: slobs... blah blah)
On Mon, Sep 21, 2009 at 4:04 PM, Peter Robinson pbrobin...@gmail.com wrote: I'm not sure something like sugar which is (and should be) fast moving mixes well with something like CentOS or its parent. At the beginning of the v6 release cycle begins it will be fine but within 12 months I'm sure everyone will want the features that are provided by the I read everyone here as programmers and early adopters. It has been suggested that other people (regular teachers for example) might care more about the stability of the total user experience rather then new features. latest release of gtk/glib/gstreamer/python/telepathy etc that just won't be available in v6 so we en up in a situation we've been in before where we either need to fork massive amounts of packages to get the features everyone wants or moving back to Fedora. Both which will require lots of work. I know what its like as I've spent lots and lots of hours getting the changes merged upstream. I don't doubt that it was a royal pain. But I believe the situation we are discussing now is a little different. This isn't a situation where the functionality that is required to provide core use cases isn't available anywhere. From the outside, it seems like most of this has been pushed upstream and will be maintained by others. Now we are talking about what new functionality that comes in from the outside should be made part of the core requirements to run current releases of Sugar. Should Sugar releases really require the latest version of everything (as defined by the latest Fedora) in order to function correctly? Bill Bogstad ___ Sugar-devel mailing list Sugar-devel@lists.sugarlabs.org http://lists.sugarlabs.org/listinfo/sugar-devel
Re: [Sugar-devel] [SLOBS] Long-term support for Sugar (was: slobs... blah blah)
On Mon, Sep 21, 2009 at 9:53 PM, Bill Bogstad bogs...@pobox.com wrote: On Mon, Sep 21, 2009 at 4:04 PM, Peter Robinson pbrobin...@gmail.com wrote: I'm not sure something like sugar which is (and should be) fast moving mixes well with something like CentOS or its parent. At the beginning of the v6 release cycle begins it will be fine but within 12 months I'm sure everyone will want the features that are provided by the I read everyone here as programmers and early adopters. It has been suggested that other people (regular teachers for example) might care more about the stability of the total user experience rather then new features. latest release of gtk/glib/gstreamer/python/telepathy etc that just won't be available in v6 so we en up in a situation we've been in before where we either need to fork massive amounts of packages to get the features everyone wants or moving back to Fedora. Both which will require lots of work. I know what its like as I've spent lots and lots of hours getting the changes merged upstream. I don't doubt that it was a royal pain. But I believe the situation we are discussing now is a little different. This isn't a situation where the functionality that is required to provide core use cases isn't available anywhere. From the outside, it seems like most of this has been pushed upstream and will be maintained by others. Now we are talking about what new functionality that comes in from the outside should be made part of the core requirements to run current releases of Sugar. Should Sugar releases really require the latest version of everything (as defined by the latest Fedora) in order to function correctly? Well it wasn't a royal pain if you didn't have to co-ordinate between about 8 different parties. And most of the the latest releases were in fact defined by the Sugar Development and had nothing to do with Fedora at all so I suggest you do some research to find out the facts before you actually define royal pain. Things like Telepathy Tubes were pushed forward to allow things like abiword (Write activity) collaboration. There are still things that are being merged into mainline that have been used by Sugar for a while and in the case of abiword its only the soon to be released abiword 2.8 that will finally merge those changes Peter ___ Sugar-devel mailing list Sugar-devel@lists.sugarlabs.org http://lists.sugarlabs.org/listinfo/sugar-devel
Re: [Sugar-devel] [GIT] how to add an admin?
On Mon, Sep 21, 2009 at 12:09:53PM -0500, Felipe López Toledo wrote: Hi guys does anyone know how to grant admin/owner privileges on a git project to a contributor user? -- Felipe López Toledo AFAIK in gitorious, only one user can have admin privileges, so you can just pass ownership. Create ticket on bugs.sugarlabs.org for component git.sugarlabs.org or ping bernie or lfaraone on #sugar. -- Aleksey ___ Sugar-devel mailing list Sugar-devel@lists.sugarlabs.org http://lists.sugarlabs.org/listinfo/sugar-devel
Re: [Sugar-devel] [SLOBS] Long-term support for Sugar (was: slobs... blah blah)
[trimmed some cc's - they are probably on these lists anyway] On Mon, Sep 21, 2009 at 5:07 PM, Peter Robinson pbrobin...@gmail.com wrote: Well it wasn't a royal pain if you didn't have to co-ordinate between about 8 different parties. And most of the the latest releases were in fact defined by the Sugar Development and had nothing to do with Fedora at all so I suggest you do some research to find out the facts before you actually define royal pain. Things like Telepathy Tubes were pushed forward to allow things like abiword (Write activity) collaboration. There are still things that are being merged into mainline that have been used by Sugar for a while and in the case of abiword its only the soon to be released abiword 2.8 that will finally merge those changes Is that light at the end of the tunnel or just an oncoming train? i.e. Do you think that it will ever be the case that most Sugar activities won't need special features from the base system to function adequately (note I don't say optimally)? If you think this is possible, what time frame do you see this happening? By Fedora 13? Fedora 14? In your lifetime? If it's more then a year then this conversation is probably premature. If it's less then that, then it's just about the right time to decide if long term support is something that matters to SugarLabs and how to address it if it does. Bill Bogstad ___ Sugar-devel mailing list Sugar-devel@lists.sugarlabs.org http://lists.sugarlabs.org/listinfo/sugar-devel
Re: [Sugar-devel] Long-term support for Sugar
El Mon, 21-09-2009 a las 16:33 -0400, Bill Bogstad escribió: The lack of good dependency reporting and version tracking for Activities makes this difficult. Something like XO bundles could work better for for some scenarios though. If it were on me, I'd just ditch the XO bundle format and use native packages for each distro. Some are already being packaged, and the Python distutils are capable of producing rpms and debs with the same ease of our current setup.py scripts. It's been discussed several time, but the consensus seems to be that the XO format will stay around for a while :-( For example, has anyone ever done anything with the 'host_version' field in the Activities *.info file? Maybe it could be hijacked for Sugar library dependencies. Not as remotely capable as full dependency checking, but core Sugar (glucose) could at least use this for direct Activity dependency issues. Preferentially with a pop-up telling people there may be incompatibilities. Activities that stick with direct Sugar supplied functionality would be safe. Glucose would know what range of values it supports and would alert if an Activity is outside of that range. Activities would request the minimum value that works for them in their info file. Perhaps Activities could also query for the maximum value supported and change their behavior based on it. (This assumes that Glucose functionality is monotonically increasing and the cost of retaining compatibility with older versions of the Glucose API is reasonable for at least a few releases.) Oh, no! Let's not go down this way. Pretty please? It took 10 years for the Linux distros to mature their packaging infrastructure to the point it became really usable by end-users. This includes all the tools for building binaries, dependency solving, repository management, build clusters, QA and, finally, good UIs. Now that the path is clear, it might take only 5 years of development to start over from the XO bundles. I'm unable to estimate how many full-time developers it would take, though. OR, we could pick the native distro packaging systems off the shell and make the necessary changes to make them work slightly differently as needed. So clearly teachers/schools aren't Sugar Labs' target for its' deliverables because their desire for stability is incompatible with the fast changing, (almost) never look back release model of Sugar and Fedora. I'm glad that we cleared that up :-( The word stability in software is mostly a marketing term with no technical substance. It also means wildly different things depending on the user you ask to. Some users would call stable an old version of Windows 98 that blue screens all the time, because it has just the bugs they're familiar with, and none of those they're not yet used to. I have been running CentOS and RHEL on some servers, and they were a complete PITA. For example, my usual backup scripts were hitting an rsync bug that was fixed years ago. Oh, and I had to manually install the web applications I actually needed from source... because the versions bundled with the stable distros were amazingly old. But if you resort to manual installations, don't you also loose all the advertised stability and the benefits of long-term support? Modern distros with 6 months release cycles are getting better at QA. Even Fedora is no longer the bleeding razor blade that it used to be. -- // 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] [SLOBS] Long-term support for Sugar
Hi, If it were on me, I'd just ditch the XO bundle format and use native packages for each distro. Some are already being packaged, and the Python distutils are capable of producing rpms and debs with the same ease of our current setup.py scripts. But then every child in Uruguay (plus other deployments that withhold root from their users) would hate you 'cause they wouldn't be able to install activities anymore. A solution that results in a significant percentage of Sugar's users not being able to download activities anymore is not a solution. If we could switch to .rpm *and* find a good way to install .rpms without being root, though, that would be pretty compelling. Thanks, - Chris. -- Chris Ball c...@laptop.org One Laptop Per Child ___ Sugar-devel mailing list Sugar-devel@lists.sugarlabs.org http://lists.sugarlabs.org/listinfo/sugar-devel
Re: [Sugar-devel] [SLOBS] Long-term support for Sugar
Hi, If it were on me, I'd just ditch the XO bundle format and use native packages for each distro. Some are already being packaged, and the Python distutils are capable of producing rpms and debs with the same ease of our current setup.py scripts. But then every child in Uruguay (plus other deployments that withhold root from their users) would hate you 'cause they wouldn't be able to install activities anymore. A solution that results in a significant percentage of Sugar's users not being able to download activities anymore is not a solution. If we could switch to .rpm *and* find a good way to install .rpms without being root, though, that would be pretty compelling. Its called PackageKit :-) See discussions from previously... And with the good python bindings for it there shouldn't even be too much work to add support for that into the control panel. And the other massive advantage that PackageKit has is that it works with multiple package backends so it will with Debian, Fedora, Ubuntu, SuSE and alot of other distros as well so it should be usable by all distros :-) Peter ___ Sugar-devel mailing list Sugar-devel@lists.sugarlabs.org http://lists.sugarlabs.org/listinfo/sugar-devel
Re: [Sugar-devel] [SLOBS] Long-term support for Sugar
On Mon, Sep 21, 2009 at 10:37:52PM +0100, Peter Robinson wrote: Hi, If it were on me, I'd just ditch the XO bundle format and use native packages for each distro. Some are already being packaged, and the Python distutils are capable of producing rpms and debs with the same ease of our current setup.py scripts. But then every child in Uruguay (plus other deployments that withhold root from their users) would hate you 'cause they wouldn't be able to install activities anymore. A solution that results in a significant percentage of Sugar's users not being able to download activities anymore is not a solution. If we could switch to .rpm *and* find a good way to install .rpms without being root, though, that would be pretty compelling. Its called PackageKit :-) See discussions from previously... Which discussion pointed out how PackageKit could install different rpms for different users? Peter Martin pgpMUlqtn376u.pgp Description: PGP signature ___ Sugar-devel mailing list Sugar-devel@lists.sugarlabs.org http://lists.sugarlabs.org/listinfo/sugar-devel
Re: [Sugar-devel] [SLOBS] Long-term support for Sugar
On Mon, Sep 21, 2009 at 11:14 PM, Bernie Innocenti ber...@codewiz.org wrote: El Mon, 21-09-2009 a las 17:28 -0400, Chris Ball escribió: But then every child in Uruguay (plus other deployments that withhold root from their users) would hate you 'cause they wouldn't be able to install activities anymore. A solution that results in a significant percentage of Sugar's users not being able to download activities anymore is not a solution. Trying to prevent users from gaining superuser privileges seems to be a misguided technical solution based on ignorance of the UNIX security model. However, a solution based on PackageKit would not require root privileges to control installation of software. A simplified UI could be designed to display only Sugar Activities rather than revealing the full complexity of the system. Sure, it would still provide an ideal path to let a clever user escalate to root, but we just need to keep it quiet and those who decided to withhold root access from users would probably never realize that ;-) I agree. I personally believe that if someone wants to get access to root there's going to be any number of ways they can do so. After all the default deployment comes with root access by default but I'm not sure this is the case with a complete deployment. Afterall I thought the whole idea was for the kids to be able to get under the hood! If we could switch to .rpm *and* find a good way to install .rpms without being root, though, that would be pretty compelling. Besides PackageKit, there are many ways we could bend rpm into doing what we need. There's lots of ways to do it. I believe PackageKit has the following advantages rather than having to bend rpm: - distribution and package format independent which means we can engineer once in sugar and have it supported everywhere. - I'm pretty sure it has good python bindings, again simplifying engineering - works across multiple architectures and can deal with them (will be very important with XO-2 going arm based). - mass downstream distribution support Is it a perfect fit? No. But at this point in time I think its the best option that we have and without engineering resources coming out our ears with the time to engineer the perfect solution I think it fits pretty well. I'm also pretty sure some of the PK upstream developers have offered to help out on fedora-olpc before. A 100% non-invasive solution, would consist in writing a suid wrapper that would check the output of rpm -qpl WonderfulActivity-42.rpm for files outside the designated Activity installation path and then run rpm -i --noscripts WonderfulActivity-42.rpm to install it. Another possibility would be playing with --root to create a separate rpm database, and run rpm with user privileges. There are a bunch of other options that may help: --prefix, --reloc and --dbpath. Finally, by resorting to invasive -- but probably upstreamable -- changes to the rpm code, we could make it check dependencies against the system database and perform an unprivileged installation in the user's home and recording the package in a user database. Sounds a bit complicated? Well, think how much code and complexity it would let us drop from the Sugar codebase that we currently have to maintain. Not to mention how much work it would take to improve it to the point of actual maturity. Or you could write a script that extracts the rpm using cpio to the users directory, use the relocate feature of rpm which is little used and likely full of bugs but all of the above options leave us with two problems: - Hacks that generally won't be supported by upstream rpm getting us into the situation we've been in the past with massively forked code that causes other issues - A solution that is only relevant for distributions that use rpm and hence it then needs further engineering resources for other distros. Peter ___ Sugar-devel mailing list Sugar-devel@lists.sugarlabs.org http://lists.sugarlabs.org/listinfo/sugar-devel
Re: [Sugar-devel] [IAEP] [SLOBS] Long-term support for Sugar
El Mon, 21-09-2009 a las 17:15 -0500, Yamandu Ploskonka escribió: Very good point you make. It gets complicated as the users - kids - have not been shown they get it regarding giving their full name, age and address and some even phone number, so it is unlikely they will deal safely with the nuances of untrusted sources. Nothing in the XO bundle's current implementation and specification, nor in Rainbow's current implementation and specification, could ever prevent this from happening. Even unprivileged, sandboxed applications can successfully do a lot of evil, especially with simple social engineering tricks that would work on young children. We could as well use a good package manager, then... It would be sort of a shame that the first massive attack of malware on Linux platforms happened under our watch... Yeah, and you can count that it *will* happen soon or later. The press may even put all the blame on us! I don't think there's much we can do to prevent it. When it happens, we'll just sit and let our great Marketing Team leader Sean do all the talking to defend us ;-) -- // 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] [IAEP] [SLOBS] Long-term support for Sugar
On Mon, Sep 21, 2009 at 05:15:31PM -0500, Yamandu Ploskonka wrote: Chris Ball wrote: Hi, TBH I'm not 100% sure on that as I'm not a PackageKit developer but I believe that is addressed by ConsoleKit and as its in use on Fedora and I'm pretty sure Ubuntu and others (and I'm pretty sure its an external dependency of gnome too) I'm sure that issue has been addressed. My understanding is that the developers consider it addressed by %post runs as root, and if you don't like it then don't install RPMs [from untrusted sources]. So, we need to find out what's up there. - Chris. Very good point you make. It gets complicated as the users - kids - have not been shown they get it regarding giving their full name, age and address and some even phone number, so it is unlikely they will deal safely with the nuances of untrusted sources. It would be sort of a shame that the first massive attack of malware on Linux platforms happened under our watch... The whole point of Rainbow is that what I think you're talking about isn't an issue, and it's encouraged that kids share Activities. Eliminating this sharing ability is one of the problems with the current rpm / PackageKit proposals AIUI. Yama Martin pgp7dhDSxoyd3.pgp Description: PGP signature ___ Sugar-devel mailing list Sugar-devel@lists.sugarlabs.org http://lists.sugarlabs.org/listinfo/sugar-devel
Re: [Sugar-devel] [SLOBS] Long-term support for Sugar
On Mon, Sep 21, 2009 at 11:02:55PM +0100, Peter Robinson wrote: Hi, If it were on me, I'd just ditch the XO bundle format and use native packages for each distro. Some are already being packaged, and the Python distutils are capable of producing rpms and debs with the same ease of our current setup.py scripts. But then every child in Uruguay (plus other deployments that withhold root from their users) would hate you 'cause they wouldn't be able to install activities anymore. A solution that results in a significant percentage of Sugar's users not being able to download activities anymore is not a solution. If we could switch to .rpm *and* find a good way to install .rpms without being root, though, that would be pretty compelling. Its called PackageKit :-) See discussions from previously... Which discussion pointed out how PackageKit could install different rpms for different users? Do you mean different versions of Write for different users? Or one person on a machine have access to Write and another person not to have access to it? Well I meant precisely what I said (sorry to be pedantic). If one replaces rpms with XO bundles, it's what we have now, and what I think's being proposed to be replaced with rpm/PackageKit. Different versions of Write for different users seems to be an example, yeah. Peter Martin pgpxFF91ulkos.pgp Description: PGP signature ___ Sugar-devel mailing list Sugar-devel@lists.sugarlabs.org http://lists.sugarlabs.org/listinfo/sugar-devel
Re: [Sugar-devel] [IAEP] [SLOBS] Long-term support for Sugar
On Mon, Sep 21, 2009 at 11:54:09PM +0100, Peter Robinson wrote: On Mon, Sep 21, 2009 at 11:47 PM, Martin Dengler mar...@martindengler.com wrote: On Mon, Sep 21, 2009 at 05:15:31PM -0500, Yamandu Ploskonka wrote: Chris Ball wrote: Hi, TBH I'm not 100% sure on that as I'm not a PackageKit developer but I believe that is addressed by ConsoleKit and as its in use on Fedora and I'm pretty sure Ubuntu and others (and I'm pretty sure its an external dependency of gnome too) I'm sure that issue has been addressed. My understanding is that the developers consider it addressed by %post runs as root, and if you don't like it then don't install RPMs [from untrusted sources]. So, we need to find out what's up there. - Chris. Very good point you make. It gets complicated as the users - kids - have not been shown they get it regarding giving their full name, age and address and some even phone number, so it is unlikely they will deal safely with the nuances of untrusted sources. It would be sort of a shame that the first massive attack of malware on Linux platforms happened under our watch... The whole point of Rainbow is that what I think you're talking about isn't an issue, and it's encouraged that kids share Activities. Eliminating this sharing ability is one of the problems with the current rpm / PackageKit proposals AIUI. How is the sharing implemented currently? [...] except for the hack to the mime type in the browse activity. Sorry, I wasn't explaining very well. I meant both running lightly-trusted Activities is much safer / encouraged due to Rainbow's protections and because [of that], it's feasible to ask kids to share Activities [that are not rpm packages]. I'm not saying we couldn't move from here (xo bundles, Rainbow-as-currently-implemented) to there (rpm, PackageKit), but that it seems like a step backwards and nobody seems to be doing the work (whereas Rainbow gets worked on from time to time). Peter Martin pgpZh5HgZj3Kd.pgp Description: PGP signature ___ Sugar-devel mailing list Sugar-devel@lists.sugarlabs.org http://lists.sugarlabs.org/listinfo/sugar-devel
Re: [Sugar-devel] [SLOBS] Long-term support for Sugar
El Mon, 21-09-2009 a las 23:53 +0100, Martin Dengler escribió: Well I meant precisely what I said (sorry to be pedantic). If one replaces rpms with XO bundles, it's what we have now, and what I think's being proposed to be replaced with rpm/PackageKit. Different versions of Write for different users seems to be an example, yeah. Why would we care to have concurrent versions of the same activity for different user accounts? Our computing model is inherently single-user. Besides, once you achieve local installation of rpms in ~/Activities, you'd get this feature too. -- // 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] [IAEP] [SLOBS] Long-term support for Sugar
Bernie Innocenti wrote: Why would we care to have concurrent versions of the same activity for different user accounts? Our computing model is inherently single-user. LTSP. NFS with shared clients. Our computing model is not just OLPC. 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] [IAEP] [SLOBS] Long-term support for Sugar
On Mon, Sep 21, 2009 at 07:01:13PM -0400, Bernie Innocenti wrote: El Mon, 21-09-2009 a las 23:47 +0100, Martin Dengler escribió: The whole point of Rainbow is that what I think you're talking about isn't an issue, and it's encouraged that kids share Activities. Eliminating this sharing ability is one of the problems with the current rpm / PackageKit proposals AIUI. Currently, Rainbow is a much weaker protection than, say, the Javascript sandbox of a browser. And, realistically, it will never get close to be that good. Well I'll leave that to the real experts. Besides, the way you *install* a program does not affect the way you *run* it. I could install the same malicious program by unpacking a zip file or an rpm (which is a cpio archive with a header). I believe the statement I was replying to can be summarised by let's think about the usage of rpm so as not to open ourselves up to malware, and so Rainbow is in scope. Admittedly, I was reading into that vague statment. If you are just concerned with the message to which the message I replied to was replying, which was about %post scripts, sure. What could be achieved with the .xo bundles that couldn't be achieved with an rpm? Given both involve Turing-complete languages, nothing. Given that one works now and one involves lots of work, everything. Rhetorically, point taken. Practically, nothing's changed. Actually, I take that back. You're now talking about tieing Sugar activities to rpm, which is a whole set of code / practices, instead of the current XO format, right? So what was a downstream choice (how to package activities) now becomes fixed? Or are you proposing Fructose is distributed in a distro-specific way, and just non-Fructose Activities as rpms? Martin pgpkuNSgC6zTc.pgp Description: PGP signature ___ Sugar-devel mailing list Sugar-devel@lists.sugarlabs.org http://lists.sugarlabs.org/listinfo/sugar-devel
Re: [Sugar-devel] [SLOBS] Long-term support for Sugar
On Mon, Sep 21, 2009 at 07:06:44PM -0400, Bernie Innocenti wrote: El Mon, 21-09-2009 a las 23:53 +0100, Martin Dengler escribió: Well I meant precisely what I said (sorry to be pedantic). If one replaces rpms with XO bundles, it's what we have now, and what I think's being proposed to be replaced with rpm/PackageKit. Different versions of Write for different users seems to be an example, yeah. Why would we care to have concurrent versions of the same activity for different user accounts? Because to do otherwise is to unnecessarily limit what we can achieve and unnecessarily regress from what we have now. I thought that'd be a pretty huge step backward for, well, as I've pointed out elsewhere, less functionality and more work. Our computing model is inherently single-user. Eh? I didn't realised Sugar prescribed that much about the OS it ran upon. In fact, I suspect LTSP people are going to surface in droves and beat you to a pulp in parallel :). Or at least point out that it'd be really nice if Sugar didn't require a whole different OS for a different user's Sugar desktop environment. Besides, once you achieve local installation of rpms in ~/Activities, you'd get this feature too. Indeed - I guess that'd be fine. Your suggestions were interesting. Martin pgpDndPwCU1Us.pgp Description: PGP signature ___ Sugar-devel mailing list Sugar-devel@lists.sugarlabs.org http://lists.sugarlabs.org/listinfo/sugar-devel
[Sugar-devel] Sugar Digest 2009-09-21
=== Sugar Digest ===
1. It was busy week: Simon, Aleksey, Sascha, and Tomeu have been
working around the clock on putting the finishing touches on the new
0.86 release of Sugar while Gary has been trying to keep pace with
testing and documentation. It is looking great. I kept busy too:
chacing a few more bugs in Turtle Art; writing a grant proposal with
help from David, David, and Caroline to the Wal-Mart foundation
(seeking support to run teacher workshops and do outreach); meeting
with a team from Babson who will help us develop a plan for how to
present Sugar to school districts; a panel at the Harvard Kennedy
School to a gathering of entrepreneurs in technology and development,
‘Beyond Mobile: The Next Generation of Technology for Empowerment’; an
article in Groklaw
[http://www.groklaw.net/article.php?story=20090918110925298] (with
lots of help from Sean); and a presentation at Software Freedom Day.
I did have a chance to do some reading: Bahktiar Mikhak posted a link
to an old paper by Seymour Papert, Computer Criticism vs.
Technocentric Thinking
[http://www.papert.org/articles/ComputerCriticismVsTechnocentric.html].
He wrote it almost 30-years ago and I had last read it more than
10-years ago, but it is still relevamt today.
My favorite quote from the paper is: The context for human
development is always a culture, never an isolated technology.
Another gem: If you ask, 'What does a LOGO practitioner need to
know?' the answer goes beyond the ability to use and teach LOGO. The
practitioner needs to be able to talk about LOGO, to criticize it, and
to discuss other people's criticisms. .replace('LOGO','Sugar')
2. I have a bit more to report regarding last week's meeting at the
Interamerican Development Bank. The afternoon discussion ended on an
interesting note: what if anything should we be doing regarding
curriculum development? Again Papert: Science as inquiry rather than
as answers. More concretely, when we first set up the teacher
workshops in Peru we challenged the teachers on the first day to come
up with a way to enhance something from the national curriculum by
using Sugar to be presented on the final day of the workshop. We
didn't give them a curriculum—they already had that from the ministry
of education. Rather, we wanted them to engage in a process of
inquiry. They rose to the challenge and engaged in a collaborative
discussion of discovery throughout the week-long event.
Papert's version: Using the computer not as a 'thing in itself' that
may or may not deliver benefits, but as a material that can be
appropriated to do better whatever you are doing (and which will not
do anything if you are not!)
A final word from Papert: Do Not Ask What LOGO Can Do To People, But
What People Can Do With LOGO. .replace('LOGO','Sugar')
3. A few of us were on IRC Friday evening discussing with Rubén
Rodríguez Pérez his effort to port Sugar to Trisquel. By the time I
got to the venue for the Boston celebration of Software Freedom Day, I
had gotten this email:
:Hello everybody,
:The Sugar+Trisquel beta is ready for testing, many thanks to Aleksey
Lim and everyone in the #sugar and #fsfsys channels who helped us to
get it. The current release is a fully free live CD based in Sugar
0.84, running on top of Trisquel-edu 2.2.1 LTS Robur (which is
itself Hardy based). We will soon build one with Trisquel 3.0, for
better hardware support.
:We are very excited with this collaboration, as it will be a new and
fully libre way to distribute Sugar, and also a powerful tool to
include in our educational operating system Trisquel Edu.
:Highlights:
:-Installable live CD, with MD5 self-checking utility.
:-Persistent user data in live-usb sessions, usb-creator included.
:-Boot menu with 30 selectable languages.
:-LTSP thin client support using a Trisquel Edu server.
:-Sugar style artwork, screenshots attached.
:It is a work in progress, but stable enough to be used and get some
tests. The artwork is also a proof of concept and can be easily
changed. We would be pleased if you send us your impressions and
advices.
:Known bugs in this release:
:-No sound in flash videos
:-No network selector
:The i686 iso image can is here:
:http://devel.trisquel.info/trisquel-sugar_2.2.1-beta_i686.iso
:Enjoy!
:Rubén.
=== Tech Talk ===
4. Bryan Berry announces on behalf of the Karma team that KARMA 0.1
has been released. See
[http://lists.sugarlabs.org/archive/sugar-devel/2009-September/019339.html]
for details.
5. Marten Vijn announced that there is new global mirror for Sugar
available at http://sugarlabs.cdn.cacheboy.net/
===Sugar Labs===
6. Gary Martin has generated a SOM from the past week of discussion on
the IAEP mailing list (Please see
[[:File:2009-Sept-12-18-som.jpg|SOM]]).
--
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] [Karma] impressed by SVGWeb, so far
hm, the more I look at it the more it seems that the svg web project page shows off the power of regular svg ... svg-web is perhaps more focused on cross-browser support. Yes. My understanding is svg-web is mostly a hack to wrap the XML of SVG in a script tag so that the script can make it work in Microsoft's joke browsers. Just get rid of the script tag, maybe add !doctype html at the top, and their examples of SVG in HTML should work fine in decent browsers without that overhead. and doesn't provide high-level drawing functions like raphaeljs does. 1) You should be able to inject new SVG by manipulating the DOM, thereby changing the SVG and making new stuff appear. svg-web includes some DOM manipulation but so do other JS toolkits. 2) There is limited animation capability in SVG+SMIL (careful many of the examples on the Web are stuck using the Adobe syntax for embedding SVG). http://www.kevlindev.com/tutorials/basics/index.htm is a nice intro to both techniques. 3) There are also weird mutants like http://hacks.mozilla.org/2009/06/rendering-svg-canvas-burst/ , where as I understand it the Burst JavaScript framework can read in fragments of drawings from SVG files and then animate them on a canvas. E.g. http://hyper-metrix.com/burst/development/doc/demos/js/GitHub%27s-Octocat.htm Lots of ways to do it! https://www.svgopen.org/2009/papers/54-SVG_vs_Canvas_on_Trivial_Drawing_Application/ is a paper that tries to compare canvas and SVG, but there's no definitive answer. -- =S Page ___ Sugar-devel mailing list Sugar-devel@lists.sugarlabs.org http://lists.sugarlabs.org/listinfo/sugar-devel
[Sugar-devel] Getting around a (sound) device assignment problem in SoaS
For SoaS (Fedora Linux), there remains a problem of device assignment involving audio out and MIDI in. Basically, if you boot SoaS *then* plug in a MIDI controller, audio is assigned C0D0; and MIDI, C1D0 (this is as expected). If you plug in a MIDI controller and then boot SoaS, MIDI gets C0D0 and audio C1D0 (this is *not* as expected!) The latter arrangement generates the following error message (in its Log) when a script is run: Can't open device 'plughw' for audio output. It will be necessary to either do something either in Sugar, its Csound module, or in the python script that runs Csound to work with this issue. So far, I've tried making manual changes to the file names (reflecting the proper device numbers, but the error remains. Suggestions? Especially from the Sugar side? It would seem that Sugar needs to look for and assign *audio* device numbers before *MIDI* device numbers. (Please note that this issue does *not* exist for the native XO-1. Perhaps snooping around in that code would be enlightening.) I'd appreciate the help; I'm absolutely lost here. Art Hunkins ___ Sugar-devel mailing list Sugar-devel@lists.sugarlabs.org http://lists.sugarlabs.org/listinfo/sugar-devel
Re: [Sugar-devel] [IAEP] [SLOBS] Long-term support for Sugar
Bernie Innocenti wrote: How does, for instance, Gimp manage to work perfectly on *all* Linux distributions? And how do all the other 19K packages in my distro manage to find *exactly* all the dynamic libraries they need when they are installed? By having distinct packages built separately for each distribution by experts. This is incompatible with our (or at least my) goal of allowing users to throw packages around as atomic objects, without internet access and without having to understand anything beyond my friend has Sugar, so it will work. It is also incompatible with allowing novices to generate first-class Activities. This is also incompatible with your proposal to choose RPM. The equivalent here would be to choose RPM on Fedora, DEB on Ubuntu, ebuild on Gentoo, tarball on Slackware, etc. We don't have to do anything special, either. Some Sugar activities have already been natively packaged in the main Linux distributions. They work as well as any other packaged application, and none of the original authors need to be concerned about how this magic was performed. What we can do is to create new, special, highly restricted scenarios, and then demand that people package for them. One such scenario that I believe we can support with confidence is Activities written exclusively in Python, using only functions from a static list of blessed modules. Sorry, I find this horribly restrictive. My favorite educational application, XaoS, would not even be possible in this scenario. Neither would Firefox, GCompris and many of the most popular activities that we offer on activities.sugarlabs.org today. With such a limitation, Sugar would be a really sad educational environment. I agree, switching bundle formats would gain us a lot of these features. However, I don't think features such as dependency tracking are of much use to us, because we can't trust system package managers, Why not? Because there is no way to build a single binary that will safely link with all the different distros' libraries and we can't afford to maintain our own complete distro and package database. Why would we have to? Several good distros already exist... just pick one. No, actually, let's pick many! We can't pick one, because we wish to run on them all. We can't pick many, because then users cannot share Activity bundles. 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 around a (sound) device assignment problem in SoaS
On Mon, Sep 21, 2009 at 11:03:25PM -0400, Art Hunkins wrote: Basically, if you boot SoaS *then* plug in a MIDI controller, audio is assigned C0D0; and MIDI, C1D0 (this is as expected). If you plug in a MIDI controller and then boot SoaS, MIDI gets C0D0 and audio C1D0 (this is *not* as expected!) Suggestions? Especially from the Sugar side? This is exactly the problem that udev is designed to solve. Simply add a udev rule that matched on the internal device and rename it to something unique. -- American? Vote on the National Initiative for Democracy, http://votep2.us ___ Sugar-devel mailing list Sugar-devel@lists.sugarlabs.org http://lists.sugarlabs.org/listinfo/sugar-devel
Re: [Sugar-devel] [IAEP] [SoaS] The Future of Sugar on a Stick
Ok - then the situation is this, then: http://wiki.sugarlabs.org/index.php?title=Talk%3ASugar_on_a_Stickdiff=37874oldid=37820 It looks like the SoaS team is unblocked - now all that remains is for the SoaS team members to identify themselves (I'd suggest just requesting and joining a separate mailing list) and go about making these decisions so we can get on with making SoaS. ;-) --Mel ___ Sugar-devel mailing list Sugar-devel@lists.sugarlabs.org http://lists.sugarlabs.org/listinfo/sugar-devel
Re: [Sugar-devel] [Karma] thinking about knavbar
Hi, The pages and code looks clean now. Thank you very much. I think I found few bugs there. Please correct me if I am wrong. 1) In http://www.mpavel.ro/projects/Karma/chakra/grade1english.html I can see 5to8 9to12 13to16 17to20 21to24 25to28 29to32 33to36 37to40 41to44 45to48 49to52 in the end of the page. 2) Can you please make the thumbnails 2X2 instead of 1X4 3) The thumbnails don't link to the correct activity. I think that's it for now. Please let me know what you think. 2009/9/20 Pavel Mocan pomo...@gmail.com New update for Karma CSS and HTML. Live at www.mpavel.ro/projects/Karma/ I had to change quite a lot of the HTML as it was not using the HTML5 syntax. This way the source code brings more semantic to the whole document and the structure of it becomes more obvious. The CSS file has been reduced from 400 lines of code to 200. The 'chakra.css' file was sectioned into areas where css properties apply to. However, I still think there is room for improvement. More general properties should be added and things such as sub navigation menus (months, weeks) and articles (lessons) should have the appearance improved. Some notes about coding: - With HTML5 there is no need to put in the type property for the script tag. It recognises it automatically. Same for CSS. This means you can write scriptjs code here/script and stylecss style here/style in html5 documents and they will be valid. - In HTML, you are only allowed to use the same id value for only one element on that page (it's meant to be unique). So, for example, you can't have two div that have id=myElement. - With CSS it is good to take an object oriented approach. For example, if there are elements who need to be floating to left or right, two classes can be created: floatLeft and floatRight. Elements that need to float to the left will obviously have class=floatLeft. If that element needs a big margin, it can be done in another class .bigMargin with the element having class=floatLeft bigMargin. Hope eveything is fine, email me with anything (feedback, suggestions, critic, etc) Regards, Pavel M. ___ Sugar-devel mailing list Sugar-devel@lists.sugarlabs.org http://lists.sugarlabs.org/listinfo/sugar-devel
[Sugar-devel] [Karma] using svg together w/ k.library.images
It works fine, here is the code I had to add index.html script src=raphael.js/script div id=holder /div lesson.js var r = Raphael(holder, 100, 120); r.image(k.library.images[ball].src, 0, 0, 100, 120); It works nicely except for the fact u have to append .src to images[name] in order to access it now I will test out dojox.gfx -- 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] [Karma] impressed by SVGWeb, so far
On Mon, 2009-09-21 at 19:34 -0700, S Page wrote: hm, the more I look at it the more it seems that the svg web project page shows off the power of regular svg ... svg-web is perhaps more focused on cross-browser support. Yes. My understanding is svg-web is mostly a hack to wrap the XML of SVG in a script tag so that the script can make it work in Microsoft's joke browsers. Just get rid of the script tag, maybe add !doctype html at the top, and their examples of SVG in HTML should work fine in decent browsers without that overhead. and doesn't provide high-level drawing functions like raphaeljs does. 1) You should be able to inject new SVG by manipulating the DOM, thereby changing the SVG and making new stuff appear. svg-web includes some DOM manipulation but so do other JS toolkits. 2) There is limited animation capability in SVG+SMIL (careful many of the examples on the Web are stuck using the Adobe syntax for embedding SVG). http://www.kevlindev.com/tutorials/basics/index.htm is a nice intro to both techniques. tks, I will definitely check out that link 3) There are also weird mutants like http://hacks.mozilla.org/2009/06/rendering-svg-canvas-burst/ , where as I understand it the Burst JavaScript framework can read in fragments of drawings from SVG files and then animate them on a canvas. E.g. http://hyper-metrix.com/burst/development/doc/demos/js/GitHub%27s-Octocat.htm We like Burst but it looks like no work has been done on it since last April Lots of ways to do it! https://www.svgopen.org/2009/papers/54-SVG_vs_Canvas_on_Trivial_Drawing_Application/ is a paper that tries to compare canvas and SVG, but there's no definitive answer. I think canvas is better for drawing apps, but I think it is too much for Karma to support both svg and canvas and too much to ask potential devs to learn both. I am going to do some experiments this week w/ raphaeljs and dojox.gfx . If subzero and I like working w/ them, will consider changing the Karma API to use one of those libraries for everything and not use canvas at all. can u recommend svg libraries besides the ones I mentioned? -- 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] [Karma] http://www.thatquiz.org
I have communicated w/ him and unfortunately he is looking to make a business out of thatquiz.org and will not be open-sourcing it :S -- 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
