Re: [IAEP] [Sugar-devel] Future of Zero Sugar
On Tue, Dec 15, 2009 at 06:09, Daniel Drake wrote: > On Tue, 2009-12-15 at 06:07 +, Aleksey Lim wrote: >> * as a 3rd party developer, I don't see such teachers requests listed >> somewhere on wiki, that let me see what can I do and peek most >> interesting/suitable-for-my-skils/etc task > > There's enough going around that you could work on which would be a huge > benefit to deployments. Here are a few ideas. > [3G, bugs, more] > Documentation: there's very little good documentation on how to deploy > sugar in a classroom scenario. If you were to start some documentation, > not only would it be a huge help for deployments, it would also make you > think more about the real-life challenges which may lead to some > development projects. I'm working on documentation of the points where children will not be able to discover how Sugar works on their own, and how to integrate demonstrations of those points into lesson plans. See http://wiki.sugarlabs.org/go/The_Undiscoverable for an early version of the list. My family and I are currently preparing to move house from California to Indiana. After we get settled there, and after the holidays, I plan to finish a draft of this material and circulate it for trials and comments. I would call everybody's attention to the growing movement to replace printed textbooks with electronic learning materials. Significant amounts of grant money are becoming available from the US Government, the Shuttleworth Foundation, Spain, and elsewhere. [more ideas] -- Edward Mokurai (默雷/धर्ममेघशब्दगर्ज/دھرممیگھشبدگر ج) Cherlin Silent Thunder is my name, and Children are my nation. The Cosmos is my dwelling place, the Truth my destination. http://www.earthtreasury.org/ ___ IAEP -- It's An Education Project (not a laptop project!) IAEP@lists.sugarlabs.org http://lists.sugarlabs.org/listinfo/iaep
Re: [IAEP] [Sugar-devel] Future of Zero Sugar
On Mon, Dec 14, 2009 at 20:31, Bryan Berry wrote: > I strongly agree w/ tomeu on this. > Making Sugar easier to contribute to isn't anywhere near the top of the list > of requested features by our kids and teachers in Nepal. > The far and away most requested feature by teachers in Nepal is a mechanism > for kids to "turn in homework." Can you set up Moodle instances for them? Do we need Nepali or other localizations of Moodle? http://docs.moodle.org/en/Translation#Creating_a_new_language_pack I see nine Moodle sites listed in Nepal, including several at Kathmandu University School of Education Distance Program. There has been talk from time to time about putting a homework submission capability into Journal. I have no idea how far that idea has gotten, but I would give it a high priority if I could. > I am not talking about invasive testing > here. The typical Nepali teacher just wants to know which students out of > 50-70 kids are failing to understand basic concepts. Also, Bryan and his team would like to know which are the critical conceptual and skill blockages for Nepali children so that the team can create appropriate learning software. I have heard Bryan talk about one such program that helped children advance several years in math skill in a few months, catching up in many cases to grade level. > On Tue, Dec 15, 2009 at 12:04 AM, Tomeu Vizoso wrote: >> >> On Mon, Dec 14, 2009 at 11:25, Benjamin M. Schwartz >> wrote: >> > Aleksey Lim wrote: >> >> So, I have >> >> strong intension to switching development focus from core team, >> >> which develops sucrose - glucose(core) and fructose(some core >> >> activities) to wide range of developers/doers thus some kind of >> >> decentralization of development process. >> > >> > I agree. I think this has been a central part of the Sugar design >> > philosophy from the beginning. I think your message is very much on the >> > right track. >> >> While I think this is in the spirit of my vision for Sugar, my >> experience with how Sugar is being used and deployed _today_ makes it >> quite uninteresting and too invasive to consider for the near future. >> >> The current barriers for people to contribute to Sugar development and >> share their work are mostly cultural. We can make the technology a >> thousand times easier to modify, but if people still think that they >> can be only users, we won't gain anything. >> >> If we really want more people to realize their power and modify sugar >> and share their work, we need to, in order: >> >> - show how the community can address some of their needs, as perceived by >> them, >> >> - show how they can better address the rest of their needs by working >> within the community. >> >> The rest is just icing on the top, IMHO. >> >> Regards, >> >> Tomeu >> >> > [snip] >> >> * I hope to see many shell forks with implemented features like new >> >> sugar themes(wallpapers support, new icons etc.), Actions view >> >> implementations from non-core development/doers. The benefit they >> >> will have after 0install integration is more useful method to share >> >> these forks - just a regular entity on Activity Library that brings >> >> new shell to user environment >> > >> > I don't think this part will work as "a regular entity on Activity >> > Library", for security reasons. Any "Activity" that hooks so deeply >> > into >> > the shell is no longer safe to run. It is running with the full >> > authority >> > of the user and can violate the user's privacy or interfere with the >> > user's actions. In orders to encourage users to become doers, Sugar is >> > designed to make sure that Activities are always safe to run (thanks to >> > Bitfrost/Rainbow protections). >> > >> > I would of course support an effort to "wall off" parts of the shell in >> > a >> > secure fashion, but so far almost no work has been done in that >> > direction. >> > >> > --Ben >> > >> > >> > ___ >> > IAEP -- It's An Education Project (not a laptop project!) >> > IAEP@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-de...@lists.sugarlabs.org >> http://lists.sugarlabs.org/listinfo/sugar-devel > > > ___ > Sugar-devel mailing list > sugar-de...@lists.sugarlabs.org > http://lists.sugarlabs.org/listinfo/sugar-devel > > -- Edward Mokurai (默雷/धर्ममेघशब्दगर्ज/دھرممیگھشبدگر ج) Cherlin Silent Thunder is my name, and Children are my nation. The Cosmos is my dwelling place, the Truth my destination. http://www.earthtreasury.org/ ___ IAEP -- It's An Education Project (not a laptop project!) IAEP@lists.sugarlabs.org http://lists.sugarlab
Re: [IAEP] [Sugar-devel] Future of Zero Sugar
Aleksey, I fully support your initiative to make Sugar's handling of activities Work As Designed and I look forward to testing both your upcoming blob-free activities, your PackageKit integration, and your 0install Sugar packaging in coming weeks. Keep pushing. - Bryan, > Making Sugar easier to contribute to isn't anywhere near the top of the list > of > requested features by our kids and teachers in Nepal. A large part of the reason why your feature isn't already implemented is because Sugar's core is stagnating. Sugar's core is stagnating because of some poor decisions made by some well-respected individuals on the core development team. Aleksey's work combats this stagnation. Therefore, if you want to see more features you like more quickly, you would be well advised to help Aleksey advance his vision. Also, doing so will undoubtedly help you build a stronger relationship with Aleksey. Strengthening that relationship seems to me to offer you the best chance of persuading him to adopt your "turn-it-in" feature as his next project. Regards, Michael ___ IAEP -- It's An Education Project (not a laptop project!) IAEP@lists.sugarlabs.org http://lists.sugarlabs.org/listinfo/iaep
Re: [IAEP] [Sugar-devel] Future of Zero Sugar
On Tue, Dec 15, 2009 at 02:01:18PM +, Gary C Martin wrote: > On 15 Dec 2009, at 13:36, Aleksey Lim wrote: > > > On Tue, Dec 15, 2009 at 10:52:56AM -0200, Tomeu Vizoso wrote: > >> On Tue, Dec 15, 2009 at 04:07, Aleksey Lim wrote: > >>> * implementing Zero Sugar initiative, in my mind, is providing > >>> "fishing-rod" for developers/doers instead of "feeding" users > >>> thus has prime priority > >> > >> I don't see things so black and white. I have been working on this > >> same problem for a while now (view source key, extensions, etc) and > >> our users are taking advantage of at least the extensions facility. We > >> are going to see patches very soon for keybindings, device icons and > >> control panel sections. And that code can be already deployed without > >> waiting for upstreaming because of the extensions mechanism. > >> > >> So _today_ we have empowered users that are deploying shell extensions > >> without disrupting the rest of the shell, and simultaneously are > >> working with the community and sharing the fruit of their work. > >> > >> The technical part has been in place since a year ago, but the trigger > >> for this to happen has been actually social interaction. There's no > >> point in making our platform super-hackable if we don't work as well > >> in the non-technical part of the problem. > > > > Just to be clear, the technical part of Zero Sugar is > > http://wiki.sugarlabs.org/go/Activity_Team/Services > > its not something huge, just a set of declared rules how to work with > > external(to activity or SP) dependencies. Code is ready for first > > release usage and I'm going to spend this week(and looks like next) to > > prepare proper docs/tutorials/infrastructure and remove blobs from all > > ASLO activities. > > Woooaaahhh... Removing binary blobs from all ASLO activities!? > > Now I'm no fan of having to include a binary blob (I avoid it if I have any > choice), but Sugar is not targeted at an environment of always on internet > cloud computing. An activity must be a self contained, sharable bundle for > 99% of our users, needing no downloads of eternal resources at first > run/install. I'm most happy to see some smooth fallback mechanism for the 1% > running some hokey-pokey hardware/software platform, but resources (binary or > otherwise) for our majority use cases should live inside activity bundles. Well, our major repository is still ASLO And there is also proposal to support offline mode http://wiki.sugarlabs.org/go/Zero_Install_integration#Support_offline_mode Having these improvements in shell * we don't lose "one download from ASLO, geting self contained budnle" just have freedom to disable offline mode when user have internet (and getting all benefits like online updates) * moreover having 0install featires we can minify disavantages of pure net access - someone downloaded 100M OOo4kid package can share these bytes for other local users(w/o any servers) So, I don't see disavantages -- Aleksey ___ IAEP -- It's An Education Project (not a laptop project!) IAEP@lists.sugarlabs.org http://lists.sugarlabs.org/listinfo/iaep
Re: [IAEP] [Sugar-devel] Future of Zero Sugar
On Tue, Dec 15, 2009 at 12:19, Bert Freudenberg wrote: > On 15.12.2009, at 15:09, Daniel Drake wrote: >> >> I believe there are still various well-known 0.86 regressions (over >> 0.84). For example, Record not working. These regressions are going to >> be a huge headache to anyone who tries to upgrade, perhaps you could >> squash a few of those. > > Speaking of upgrade headaches, the most significant UI change in 0.84 is > resume-by-default, which combined with the still not implemented versioning > is possibly unhealthy in deployments. I can see many Journal entries > overwritten for good. Has there been any experience with kids used to the > 0.82 way who switched to a later Sugar version? And if needed, would it be > easy for deployments to revert to not resuming by default? Good point, reverting would be easy and also adding a setting to switch it on or off. I can work on it if someone takes the task of verifying the need. 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!) IAEP@lists.sugarlabs.org http://lists.sugarlabs.org/listinfo/iaep
Re: [IAEP] [Sugar-devel] Future of Zero Sugar
On 15.12.2009, at 15:09, Daniel Drake wrote: > > I believe there are still various well-known 0.86 regressions (over > 0.84). For example, Record not working. These regressions are going to > be a huge headache to anyone who tries to upgrade, perhaps you could > squash a few of those. Speaking of upgrade headaches, the most significant UI change in 0.84 is resume-by-default, which combined with the still not implemented versioning is possibly unhealthy in deployments. I can see many Journal entries overwritten for good. Has there been any experience with kids used to the 0.82 way who switched to a later Sugar version? And if needed, would it be easy for deployments to revert to not resuming by default? - Bert - ___ IAEP -- It's An Education Project (not a laptop project!) IAEP@lists.sugarlabs.org http://lists.sugarlabs.org/listinfo/iaep
Re: [IAEP] [Sugar-devel] Future of Zero Sugar
On Tue, 2009-12-15 at 06:07 +, Aleksey Lim wrote: > * as a 3rd party developer, I don't see such teachers requests listed > somewhere on wiki, that let me see what can I do and peek most > interesting/suitable-for-my-skils/etc task There's enough going around that you could work on which would be a huge benefit to deployments. Here are a few ideas. We know about projects from Paraguay and Uruguay implementing 3G support. Why not step in early and review their code and send them some patches? Look for bug reports from Soas developers and users, and OLPC too. These people are likely closer to deployments than you are. Here are OLPC ones: http://dev.laptop.org/report/43 (you'll have to filter the list) You could perhaps try and put yourself into a role where you address these needs on an ongoing basis. This would be a dream come true for deployers and distributors. Some more project ideas here: http://www.mail-archive.com/sugar-de...@lists.sugarlabs.org/msg10631.html Documentation: there's very little good documentation on how to deploy sugar in a classroom scenario. If you were to start some documentation, not only would it be a huge help for deployments, it would also make you think more about the real-life challenges which may lead to some development projects. Bryan's point about Sugar not supporting the classroom scenario of handing work to your teacher is a good one. Some things that I think would be of large benefit: Supporting the mass of content that has already been generated: http://wiki.sugarlabs.org/go/Features/Content_support This would help simplify ad-hoc networking: http://lists.laptop.org/pipermail/devel/2009-December/026831.html This is a biggie: http://bugs.sugarlabs.org/ticket/1608 I suspect this flicker is going to be quite disruptive for field users: http://bugs.sugarlabs.org/ticket/1596 F11-for-XO1 work would be of a huge impact to the largest part of sugar's current userbase. Right now they cannot receive any of the improvements you make to sugar because the project is not (quite) stable enough for deployments. It has a buildmaster but not much development progress apart from the bits that can be directly picked up from OLPC's XO-1.5 work. We seem to even lack good diagnosis of the outstanding problems. You could look at Sayamindu's recent tickets on bugs.sugarlabs.org. We have identified various places where sugar cannot gracefully deal with corruption. I believe there are still various well-known 0.86 regressions (over 0.84). For example, Record not working. These regressions are going to be a huge headache to anyone who tries to upgrade, perhaps you could squash a few of those. OLPC mesh: NM-0.8 now supports this, sugar patch needs to be brushed up and merged. And help backporting the patches to NM-0.7 would be useful too. > * I'm feeling huge discomfort as a developer when I need to package > binary blobs to my .xo, w/o instrument which let me unify > installing/upgrading process of such non-SP/specific-to-my-activity > dependencies I feel this too. But you can solve it with less drastic changes. Which you seemed to be doing already. I've read briefly over your various 0install feature proposals and I've yet to form an opinion on the technology. I need to read them again, but at least on my quick reads, I'm still left unaware what the user experience will be like, nor the developer experience, and what the inefficiencies of the system will be. Daniel ___ IAEP -- It's An Education Project (not a laptop project!) IAEP@lists.sugarlabs.org http://lists.sugarlabs.org/listinfo/iaep
Re: [IAEP] [Sugar-devel] Future of Zero Sugar
On 15 Dec 2009, at 13:36, Aleksey Lim wrote: > On Tue, Dec 15, 2009 at 10:52:56AM -0200, Tomeu Vizoso wrote: >> On Tue, Dec 15, 2009 at 04:07, Aleksey Lim wrote: >>> On Tue, Dec 15, 2009 at 10:16:02AM +0545, Bryan Berry wrote: I strongly agree w/ tomeu on this. Making Sugar easier to contribute to isn't anywhere near the top of the list of requested features by our kids and teachers in Nepal. The far and away most requested feature by teachers in Nepal is a mechanism for kids to "turn in homework." I am not talking about invasive testing here. The typical Nepali teacher just wants to know which students out of 50-70 kids are failing to understand basic concepts. >>> >>> I absolutely agree with such points, but: >>> >>> * as a 3rd party developer, I don't see such teachers requests listed >>> somewhere on wiki, that let me see what can I do and peek most >>> interesting/suitable-for-my-skils/etc task >> >> I'm painfully aware of this situation and have been spending my >> energies on this problem for already a good while. Our colleagues at >> Uruguay and Paraguay are already working on upstreaming their >> developments, but are also going to work with us in identifying the >> most pressing needs in deployments. Have already some ideas about what >> to work on, how do you think we should track them? > > Since we have nothing for now, any movements are welcome. > > In my mind having wiki page(one page with links to subpages, or category) > is enough, the major things I'd look for is is having > priority(deployment schedules etc), summary/description and contacts > (having irc contact would big plus). > >>> * I'm feeling huge discomfort as a developer when I need to package >>> binary blobs to my .xo, w/o instrument which let me unify >>> installing/upgrading process of such non-SP/specific-to-my-activity >>> dependencies >> >> I agree this is a problem, but also think that many activities >> shipping binaries don't actually need them. Bindings for libraries can >> be written in ctypes, without need to use a .so. >> >>> * I'm feeling less(but still big) discomfort as a developer when I >>> don't have standard method to share my core related changes, >>> for-testing-purposes/to-show-what-I-have-in-mind, well "please, attach >>> my cloned repos, install them" still works but not so attractive for >>> users >> >> What about generating a SoaS (or Trisquel, etc) image with such >> changes? This is something that can be done today without so much >> trouble. >> >>> * implementing Zero Sugar initiative, in my mind, is providing >>> "fishing-rod" for developers/doers instead of "feeding" users >>> thus has prime priority >> >> I don't see things so black and white. I have been working on this >> same problem for a while now (view source key, extensions, etc) and >> our users are taking advantage of at least the extensions facility. We >> are going to see patches very soon for keybindings, device icons and >> control panel sections. And that code can be already deployed without >> waiting for upstreaming because of the extensions mechanism. >> >> So _today_ we have empowered users that are deploying shell extensions >> without disrupting the rest of the shell, and simultaneously are >> working with the community and sharing the fruit of their work. >> >> The technical part has been in place since a year ago, but the trigger >> for this to happen has been actually social interaction. There's no >> point in making our platform super-hackable if we don't work as well >> in the non-technical part of the problem. > > Just to be clear, the technical part of Zero Sugar is > http://wiki.sugarlabs.org/go/Activity_Team/Services > its not something huge, just a set of declared rules how to work with > external(to activity or SP) dependencies. Code is ready for first > release usage and I'm going to spend this week(and looks like next) to > prepare proper docs/tutorials/infrastructure and remove blobs from all > ASLO activities. Woooaaahhh... Removing binary blobs from all ASLO activities!? Now I'm no fan of having to include a binary blob (I avoid it if I have any choice), but Sugar is not targeted at an environment of always on internet cloud computing. An activity must be a self contained, sharable bundle for 99% of our users, needing no downloads of eternal resources at first run/install. I'm most happy to see some smooth fallback mechanism for the 1% running some hokey-pokey hardware/software platform, but resources (binary or otherwise) for our majority use cases should live inside activity bundles. Regards, --Gary > That's my strong intension and not only as a developer > but also as a ASLO editor - I think we should stop posting bundled > binaries to ASLO as soon as possible. ___ IAEP -- It's An Education Project (not a laptop project!) IAEP@lists.sugarlabs.org http://lists.sugarlabs.org/li
Re: [IAEP] [Sugar-devel] Future of Zero Sugar
On Tue, Dec 15, 2009 at 10:52:56AM -0200, Tomeu Vizoso wrote: > On Tue, Dec 15, 2009 at 04:07, Aleksey Lim wrote: > > On Tue, Dec 15, 2009 at 10:16:02AM +0545, Bryan Berry wrote: > >> I strongly agree w/ tomeu on this. > >> > >> Making Sugar easier to contribute to isn't anywhere near the top of the > >> list > >> of requested features by our kids and teachers in Nepal. > >> > >> The far and away most requested feature by teachers in Nepal is a mechanism > >> for kids to "turn in homework." I am not talking about invasive testing > >> here. The typical Nepali teacher just wants to know which students out of > >> 50-70 kids are failing to understand basic concepts. > > > > I absolutely agree with such points, but: > > > > * as a 3rd party developer, I don't see such teachers requests listed > > somewhere on wiki, that let me see what can I do and peek most > > interesting/suitable-for-my-skils/etc task > > I'm painfully aware of this situation and have been spending my > energies on this problem for already a good while. Our colleagues at > Uruguay and Paraguay are already working on upstreaming their > developments, but are also going to work with us in identifying the > most pressing needs in deployments. Have already some ideas about what > to work on, how do you think we should track them? Since we have nothing for now, any movements are welcome. In my mind having wiki page(one page with links to subpages, or category) is enough, the major things I'd look for is is having priority(deployment schedules etc), summary/description and contacts (having irc contact would big plus). > > * I'm feeling huge discomfort as a developer when I need to package > > binary blobs to my .xo, w/o instrument which let me unify > > installing/upgrading process of such non-SP/specific-to-my-activity > > dependencies > > I agree this is a problem, but also think that many activities > shipping binaries don't actually need them. Bindings for libraries can > be written in ctypes, without need to use a .so. > > > * I'm feeling less(but still big) discomfort as a developer when I > > don't have standard method to share my core related changes, > > for-testing-purposes/to-show-what-I-have-in-mind, well "please, attach > > my cloned repos, install them" still works but not so attractive for > > users > > What about generating a SoaS (or Trisquel, etc) image with such > changes? This is something that can be done today without so much > trouble. > > > * implementing Zero Sugar initiative, in my mind, is providing > > "fishing-rod" for developers/doers instead of "feeding" users > > thus has prime priority > > I don't see things so black and white. I have been working on this > same problem for a while now (view source key, extensions, etc) and > our users are taking advantage of at least the extensions facility. We > are going to see patches very soon for keybindings, device icons and > control panel sections. And that code can be already deployed without > waiting for upstreaming because of the extensions mechanism. > > So _today_ we have empowered users that are deploying shell extensions > without disrupting the rest of the shell, and simultaneously are > working with the community and sharing the fruit of their work. > > The technical part has been in place since a year ago, but the trigger > for this to happen has been actually social interaction. There's no > point in making our platform super-hackable if we don't work as well > in the non-technical part of the problem. Just to be clear, the technical part of Zero Sugar is http://wiki.sugarlabs.org/go/Activity_Team/Services its not something huge, just a set of declared rules how to work with external(to activity or SP) dependencies. Code is ready for first release usage and I'm going to spend this week(and looks like next) to prepare proper docs/tutorials/infrastructure and remove blobs from all ASLO activities. That's my strong intension and not only as a developer but also as a ASLO editor - I think we should stop posting bundled binaries to ASLO as soon as possible. -- Aleksey ___ IAEP -- It's An Education Project (not a laptop project!) IAEP@lists.sugarlabs.org http://lists.sugarlabs.org/listinfo/iaep
Re: [IAEP] [Sugar-devel] Future of Zero Sugar
On Tue, Dec 15, 2009 at 04:07, Aleksey Lim wrote: > On Tue, Dec 15, 2009 at 10:16:02AM +0545, Bryan Berry wrote: >> I strongly agree w/ tomeu on this. >> >> Making Sugar easier to contribute to isn't anywhere near the top of the list >> of requested features by our kids and teachers in Nepal. >> >> The far and away most requested feature by teachers in Nepal is a mechanism >> for kids to "turn in homework." I am not talking about invasive testing >> here. The typical Nepali teacher just wants to know which students out of >> 50-70 kids are failing to understand basic concepts. > > I absolutely agree with such points, but: > > * as a 3rd party developer, I don't see such teachers requests listed > somewhere on wiki, that let me see what can I do and peek most > interesting/suitable-for-my-skils/etc task I'm painfully aware of this situation and have been spending my energies on this problem for already a good while. Our colleagues at Uruguay and Paraguay are already working on upstreaming their developments, but are also going to work with us in identifying the most pressing needs in deployments. Have already some ideas about what to work on, how do you think we should track them? > * I'm feeling huge discomfort as a developer when I need to package > binary blobs to my .xo, w/o instrument which let me unify > installing/upgrading process of such non-SP/specific-to-my-activity > dependencies I agree this is a problem, but also think that many activities shipping binaries don't actually need them. Bindings for libraries can be written in ctypes, without need to use a .so. > * I'm feeling less(but still big) discomfort as a developer when I > don't have standard method to share my core related changes, > for-testing-purposes/to-show-what-I-have-in-mind, well "please, attach > my cloned repos, install them" still works but not so attractive for > users What about generating a SoaS (or Trisquel, etc) image with such changes? This is something that can be done today without so much trouble. > * implementing Zero Sugar initiative, in my mind, is providing > "fishing-rod" for developers/doers instead of "feeding" users > thus has prime priority I don't see things so black and white. I have been working on this same problem for a while now (view source key, extensions, etc) and our users are taking advantage of at least the extensions facility. We are going to see patches very soon for keybindings, device icons and control panel sections. And that code can be already deployed without waiting for upstreaming because of the extensions mechanism. So _today_ we have empowered users that are deploying shell extensions without disrupting the rest of the shell, and simultaneously are working with the community and sharing the fruit of their work. The technical part has been in place since a year ago, but the trigger for this to happen has been actually social interaction. There's no point in making our platform super-hackable if we don't work as well in the non-technical part of the problem. Regards, Tomeu >> On Tue, Dec 15, 2009 at 12:04 AM, Tomeu Vizoso wrote: >> >> > On Mon, Dec 14, 2009 at 11:25, Benjamin M. Schwartz >> > wrote: >> > > Aleksey Lim wrote: >> > >> So, I have >> > >> strong intension to switching development focus from core team, >> > >> which develops sucrose - glucose(core) and fructose(some core >> > >> activities) to wide range of developers/doers thus some kind of >> > >> decentralization of development process. >> > > >> > > I agree. I think this has been a central part of the Sugar design >> > > philosophy from the beginning. I think your message is very much on the >> > > right track. >> > >> > While I think this is in the spirit of my vision for Sugar, my >> > experience with how Sugar is being used and deployed _today_ makes it >> > quite uninteresting and too invasive to consider for the near future. >> > >> > The current barriers for people to contribute to Sugar development and >> > share their work are mostly cultural. We can make the technology a >> > thousand times easier to modify, but if people still think that they >> > can be only users, we won't gain anything. >> > >> > If we really want more people to realize their power and modify sugar >> > and share their work, we need to, in order: >> > >> > - show how the community can address some of their needs, as perceived by >> > them, >> > >> > - show how they can better address the rest of their needs by working >> > within the community. >> > >> > The rest is just icing on the top, IMHO. >> > >> > Regards, >> > >> > Tomeu >> > >> > > [snip] >> > >> * I hope to see many shell forks with implemented features like new >> > >> sugar themes(wallpapers support, new icons etc.), Actions view >> > >> implementations from non-core development/doers. The benefit they >> > >> will have after 0install integration is more useful method to share >> > >> these forks - just a regular entity on Activity Libra
Re: [IAEP] [Sugar-devel] Future of Zero Sugar
On Tue, Dec 15, 2009 at 10:16:02AM +0545, Bryan Berry wrote: > I strongly agree w/ tomeu on this. > > Making Sugar easier to contribute to isn't anywhere near the top of the list > of requested features by our kids and teachers in Nepal. > > The far and away most requested feature by teachers in Nepal is a mechanism > for kids to "turn in homework." I am not talking about invasive testing > here. The typical Nepali teacher just wants to know which students out of > 50-70 kids are failing to understand basic concepts. I absolutely agree with such points, but: * as a 3rd party developer, I don't see such teachers requests listed somewhere on wiki, that let me see what can I do and peek most interesting/suitable-for-my-skils/etc task * I'm feeling huge discomfort as a developer when I need to package binary blobs to my .xo, w/o instrument which let me unify installing/upgrading process of such non-SP/specific-to-my-activity dependencies * I'm feeling less(but still big) discomfort as a developer when I don't have standard method to share my core related changes, for-testing-purposes/to-show-what-I-have-in-mind, well "please, attach my cloned repos, install them" still works but not so attractive for users * implementing Zero Sugar initiative, in my mind, is providing "fishing-rod" for developers/doers instead of "feeding" users thus has prime priority > On Tue, Dec 15, 2009 at 12:04 AM, Tomeu Vizoso wrote: > > > On Mon, Dec 14, 2009 at 11:25, Benjamin M. Schwartz > > wrote: > > > Aleksey Lim wrote: > > >> So, I have > > >> strong intension to switching development focus from core team, > > >> which develops sucrose - glucose(core) and fructose(some core > > >> activities) to wide range of developers/doers thus some kind of > > >> decentralization of development process. > > > > > > I agree. I think this has been a central part of the Sugar design > > > philosophy from the beginning. I think your message is very much on the > > > right track. > > > > While I think this is in the spirit of my vision for Sugar, my > > experience with how Sugar is being used and deployed _today_ makes it > > quite uninteresting and too invasive to consider for the near future. > > > > The current barriers for people to contribute to Sugar development and > > share their work are mostly cultural. We can make the technology a > > thousand times easier to modify, but if people still think that they > > can be only users, we won't gain anything. > > > > If we really want more people to realize their power and modify sugar > > and share their work, we need to, in order: > > > > - show how the community can address some of their needs, as perceived by > > them, > > > > - show how they can better address the rest of their needs by working > > within the community. > > > > The rest is just icing on the top, IMHO. > > > > Regards, > > > > Tomeu > > > > > [snip] > > >> * I hope to see many shell forks with implemented features like new > > >> sugar themes(wallpapers support, new icons etc.), Actions view > > >> implementations from non-core development/doers. The benefit they > > >> will have after 0install integration is more useful method to share > > >> these forks - just a regular entity on Activity Library that brings > > >> new shell to user environment > > > > > > I don't think this part will work as "a regular entity on Activity > > > Library", for security reasons. Any "Activity" that hooks so deeply into > > > the shell is no longer safe to run. It is running with the full > > authority > > > of the user and can violate the user's privacy or interfere with the > > > user's actions. In orders to encourage users to become doers, Sugar is > > > designed to make sure that Activities are always safe to run (thanks to > > > Bitfrost/Rainbow protections). > > > > > > I would of course support an effort to "wall off" parts of the shell in a > > > secure fashion, but so far almost no work has been done in that > > direction. > > > > > > --Ben > > > > > > > > > ___ > > > IAEP -- It's An Education Project (not a laptop project!) > > > IAEP@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-de...@lists.sugarlabs.org > > http://lists.sugarlabs.org/listinfo/sugar-devel > > > ___ > Sugar-devel mailing list > sugar-de...@lists.sugarlabs.org > http://lists.sugarlabs.org/listinfo/sugar-devel -- Aleksey ___ IAEP -- It's An Education Project (not a laptop project!) IAEP@lists.sugarlabs.org http://lists.sugarlabs.org/listinfo/iaep
Re: [IAEP] [Sugar-devel] Future of Zero Sugar
On Mon, Dec 14, 2009 at 07:01:26PM -0500, Sebastian Silva wrote: > I for one would love to learn a new way to hack on my sugar and easily share > patches. > If we can do better than jhbuild does (user experience wise), I would love > it! yeah, some day we can provide 0install glucose e.g. for testing purposes so, users on any distro can install last development release of sugar by trivial gestures - copy past 0install url and click OK > > Icarito > > 2009/12/14 Tomeu Vizoso > > > On Mon, Dec 14, 2009 at 17:01, Aleksey Lim wrote: > > > On Mon, Dec 14, 2009 at 04:19:51PM -0200, Tomeu Vizoso wrote: > > >> On Mon, Dec 14, 2009 at 11:25, Benjamin M. Schwartz > > >> wrote: > > >> > Aleksey Lim wrote: > > >> >> So, I have > > >> >> strong intension to switching development focus from core team, > > >> >> which develops sucrose - glucose(core) and fructose(some core > > >> >> activities) to wide range of developers/doers thus some kind of > > >> >> decentralization of development process. > > >> > > > >> > I agree. I think this has been a central part of the Sugar design > > >> > philosophy from the beginning. I think your message is very much on > > the > > >> > right track. > > >> > > >> While I think this is in the spirit of my vision for Sugar, my > > >> experience with how Sugar is being used and deployed _today_ makes it > > >> quite uninteresting and too invasive to consider for the near future. > > >> > > >> The current barriers for people to contribute to Sugar development and > > >> share their work are mostly cultural. We can make the technology a > > >> thousand times easier to modify, but if people still think that they > > >> can be only users, we won't gain anything. > > >> > > >> If we really want more people to realize their power and modify sugar > > >> and share their work, we need to, in order: > > >> > > >> - show how the community can address some of their needs, as perceived > > by them, > > >> > > >> - show how they can better address the rest of their needs by working > > >> within the community. > > >> > > >> The rest is just icing on the top, IMHO. > > > > > > well, thats all true but it doesn't exclude easy to change and easy to > > > share possibility of doer's changes e.g. if I want to hack Journal by > > > adding wallpaper support(and of course want to expose my changes) the > > > worst way that could be is proposing my changes to core team(e.g. think > > > about proposing your patches to kernel.org team - maybe exaggerating but > > > the same level issue). Having ready to use sugarized 0install > > > environment gives developers easy sharing method. > > > > As I said, I agree with your points of view and also agree something > > should be done in the path you show. But I also think that presently, > > what would bring more users and deployers on board, is by caring of > > their more immediate needs. > > > > 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!) > > IAEP@lists.sugarlabs.org > > http://lists.sugarlabs.org/listinfo/iaep > > > > > > -- > Sebastian Silva > Colectivo FuenteLibre > http://blog.fuentelibre.org/ -- Aleksey ___ IAEP -- It's An Education Project (not a laptop project!) IAEP@lists.sugarlabs.org http://lists.sugarlabs.org/listinfo/iaep
Re: [IAEP] [Sugar-devel] Future of Zero Sugar
I for one would love to learn a new way to hack on my sugar and easily share patches. If we can do better than jhbuild does (user experience wise), I would love it! Icarito 2009/12/14 Tomeu Vizoso > On Mon, Dec 14, 2009 at 17:01, Aleksey Lim wrote: > > On Mon, Dec 14, 2009 at 04:19:51PM -0200, Tomeu Vizoso wrote: > >> On Mon, Dec 14, 2009 at 11:25, Benjamin M. Schwartz > >> wrote: > >> > Aleksey Lim wrote: > >> >> So, I have > >> >> strong intension to switching development focus from core team, > >> >> which develops sucrose - glucose(core) and fructose(some core > >> >> activities) to wide range of developers/doers thus some kind of > >> >> decentralization of development process. > >> > > >> > I agree. I think this has been a central part of the Sugar design > >> > philosophy from the beginning. I think your message is very much on > the > >> > right track. > >> > >> While I think this is in the spirit of my vision for Sugar, my > >> experience with how Sugar is being used and deployed _today_ makes it > >> quite uninteresting and too invasive to consider for the near future. > >> > >> The current barriers for people to contribute to Sugar development and > >> share their work are mostly cultural. We can make the technology a > >> thousand times easier to modify, but if people still think that they > >> can be only users, we won't gain anything. > >> > >> If we really want more people to realize their power and modify sugar > >> and share their work, we need to, in order: > >> > >> - show how the community can address some of their needs, as perceived > by them, > >> > >> - show how they can better address the rest of their needs by working > >> within the community. > >> > >> The rest is just icing on the top, IMHO. > > > > well, thats all true but it doesn't exclude easy to change and easy to > > share possibility of doer's changes e.g. if I want to hack Journal by > > adding wallpaper support(and of course want to expose my changes) the > > worst way that could be is proposing my changes to core team(e.g. think > > about proposing your patches to kernel.org team - maybe exaggerating but > > the same level issue). Having ready to use sugarized 0install > > environment gives developers easy sharing method. > > As I said, I agree with your points of view and also agree something > should be done in the path you show. But I also think that presently, > what would bring more users and deployers on board, is by caring of > their more immediate needs. > > 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!) > IAEP@lists.sugarlabs.org > http://lists.sugarlabs.org/listinfo/iaep > -- Sebastian Silva Colectivo FuenteLibre http://blog.fuentelibre.org/ ___ IAEP -- It's An Education Project (not a laptop project!) IAEP@lists.sugarlabs.org http://lists.sugarlabs.org/listinfo/iaep
Re: [IAEP] [Sugar-devel] Future of Zero Sugar
On Mon, Dec 14, 2009 at 17:01, Aleksey Lim wrote: > On Mon, Dec 14, 2009 at 04:19:51PM -0200, Tomeu Vizoso wrote: >> On Mon, Dec 14, 2009 at 11:25, Benjamin M. Schwartz >> wrote: >> > Aleksey Lim wrote: >> >> So, I have >> >> strong intension to switching development focus from core team, >> >> which develops sucrose - glucose(core) and fructose(some core >> >> activities) to wide range of developers/doers thus some kind of >> >> decentralization of development process. >> > >> > I agree. I think this has been a central part of the Sugar design >> > philosophy from the beginning. I think your message is very much on the >> > right track. >> >> While I think this is in the spirit of my vision for Sugar, my >> experience with how Sugar is being used and deployed _today_ makes it >> quite uninteresting and too invasive to consider for the near future. >> >> The current barriers for people to contribute to Sugar development and >> share their work are mostly cultural. We can make the technology a >> thousand times easier to modify, but if people still think that they >> can be only users, we won't gain anything. >> >> If we really want more people to realize their power and modify sugar >> and share their work, we need to, in order: >> >> - show how the community can address some of their needs, as perceived by >> them, >> >> - show how they can better address the rest of their needs by working >> within the community. >> >> The rest is just icing on the top, IMHO. > > well, thats all true but it doesn't exclude easy to change and easy to > share possibility of doer's changes e.g. if I want to hack Journal by > adding wallpaper support(and of course want to expose my changes) the > worst way that could be is proposing my changes to core team(e.g. think > about proposing your patches to kernel.org team - maybe exaggerating but > the same level issue). Having ready to use sugarized 0install > environment gives developers easy sharing method. As I said, I agree with your points of view and also agree something should be done in the path you show. But I also think that presently, what would bring more users and deployers on board, is by caring of their more immediate needs. 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!) IAEP@lists.sugarlabs.org http://lists.sugarlabs.org/listinfo/iaep
Re: [IAEP] [Sugar-devel] Future of Zero Sugar
On Mon, Dec 14, 2009 at 04:19:51PM -0200, Tomeu Vizoso wrote: > On Mon, Dec 14, 2009 at 11:25, Benjamin M. Schwartz > wrote: > > Aleksey Lim wrote: > >> So, I have > >> strong intension to switching development focus from core team, > >> which develops sucrose - glucose(core) and fructose(some core > >> activities) to wide range of developers/doers thus some kind of > >> decentralization of development process. > > > > I agree. I think this has been a central part of the Sugar design > > philosophy from the beginning. I think your message is very much on the > > right track. > > While I think this is in the spirit of my vision for Sugar, my > experience with how Sugar is being used and deployed _today_ makes it > quite uninteresting and too invasive to consider for the near future. > > The current barriers for people to contribute to Sugar development and > share their work are mostly cultural. We can make the technology a > thousand times easier to modify, but if people still think that they > can be only users, we won't gain anything. > > If we really want more people to realize their power and modify sugar > and share their work, we need to, in order: > > - show how the community can address some of their needs, as perceived by > them, > > - show how they can better address the rest of their needs by working > within the community. > > The rest is just icing on the top, IMHO. well, thats all true but it doesn't exclude easy to change and easy to share possibility of doer's changes e.g. if I want to hack Journal by adding wallpaper support(and of course want to expose my changes) the worst way that could be is proposing my changes to core team(e.g. think about proposing your patches to kernel.org team - maybe exaggerating but the same level issue). Having ready to use sugarized 0install environment gives developers easy sharing method. -- Aleksey ___ IAEP -- It's An Education Project (not a laptop project!) IAEP@lists.sugarlabs.org http://lists.sugarlabs.org/listinfo/iaep
Re: [IAEP] [Sugar-devel] Future of Zero Sugar
Tomeu, I think your point is well taken. As a teacher and project manager for a deployment of about 150 XOs and SOAS, I find the students and teachers really interested in making stuff with their devices and software (we are in the middle of some cool EToys science projects at the moment.). But I think it is another thing to create software. I think being able to propose software and have some contact with developers to realize those proposals would be more a more practical pathway in the meantime. Gerald On Mon, Dec 14, 2009 at 1:19 PM, Tomeu Vizoso wrote: > On Mon, Dec 14, 2009 at 11:25, Benjamin M. Schwartz > wrote: > > Aleksey Lim wrote: > >> So, I have > >> strong intension to switching development focus from core team, > >> which develops sucrose - glucose(core) and fructose(some core > >> activities) to wide range of developers/doers thus some kind of > >> decentralization of development process. > > > > I agree. I think this has been a central part of the Sugar design > > philosophy from the beginning. I think your message is very much on the > > right track. > > While I think this is in the spirit of my vision for Sugar, my > experience with how Sugar is being used and deployed _today_ makes it > quite uninteresting and too invasive to consider for the near future. > > The current barriers for people to contribute to Sugar development and > share their work are mostly cultural. We can make the technology a > thousand times easier to modify, but if people still think that they > can be only users, we won't gain anything. > > If we really want more people to realize their power and modify sugar > and share their work, we need to, in order: > > - show how the community can address some of their needs, as perceived by > them, > > - show how they can better address the rest of their needs by working > within the community. > > The rest is just icing on the top, IMHO. > > Regards, > > Tomeu > > > [snip] > >> * I hope to see many shell forks with implemented features like new > >> sugar themes(wallpapers support, new icons etc.), Actions view > >> implementations from non-core development/doers. The benefit they > >> will have after 0install integration is more useful method to share > >> these forks - just a regular entity on Activity Library that brings > >> new shell to user environment > > > > I don't think this part will work as "a regular entity on Activity > > Library", for security reasons. Any "Activity" that hooks so deeply into > > the shell is no longer safe to run. It is running with the full > authority > > of the user and can violate the user's privacy or interfere with the > > user's actions. In orders to encourage users to become doers, Sugar is > > designed to make sure that Activities are always safe to run (thanks to > > Bitfrost/Rainbow protections). > > > > I would of course support an effort to "wall off" parts of the shell in a > > secure fashion, but so far almost no work has been done in that > direction. > > > > --Ben > > > > > > ___ > > IAEP -- It's An Education Project (not a laptop project!) > > IAEP@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 > ___ > IAEP -- It's An Education Project (not a laptop project!) > IAEP@lists.sugarlabs.org > http://lists.sugarlabs.org/listinfo/iaep > ___ IAEP -- It's An Education Project (not a laptop project!) IAEP@lists.sugarlabs.org http://lists.sugarlabs.org/listinfo/iaep
Re: [IAEP] [Sugar-devel] Future of Zero Sugar
On Mon, Dec 14, 2009 at 11:25, Benjamin M. Schwartz wrote: > Aleksey Lim wrote: >> So, I have >> strong intension to switching development focus from core team, >> which develops sucrose - glucose(core) and fructose(some core >> activities) to wide range of developers/doers thus some kind of >> decentralization of development process. > > I agree. I think this has been a central part of the Sugar design > philosophy from the beginning. I think your message is very much on the > right track. While I think this is in the spirit of my vision for Sugar, my experience with how Sugar is being used and deployed _today_ makes it quite uninteresting and too invasive to consider for the near future. The current barriers for people to contribute to Sugar development and share their work are mostly cultural. We can make the technology a thousand times easier to modify, but if people still think that they can be only users, we won't gain anything. If we really want more people to realize their power and modify sugar and share their work, we need to, in order: - show how the community can address some of their needs, as perceived by them, - show how they can better address the rest of their needs by working within the community. The rest is just icing on the top, IMHO. Regards, Tomeu > [snip] >> * I hope to see many shell forks with implemented features like new >> sugar themes(wallpapers support, new icons etc.), Actions view >> implementations from non-core development/doers. The benefit they >> will have after 0install integration is more useful method to share >> these forks - just a regular entity on Activity Library that brings >> new shell to user environment > > I don't think this part will work as "a regular entity on Activity > Library", for security reasons. Any "Activity" that hooks so deeply into > the shell is no longer safe to run. It is running with the full authority > of the user and can violate the user's privacy or interfere with the > user's actions. In orders to encourage users to become doers, Sugar is > designed to make sure that Activities are always safe to run (thanks to > Bitfrost/Rainbow protections). > > I would of course support an effort to "wall off" parts of the shell in a > secure fashion, but so far almost no work has been done in that direction. > > --Ben > > > ___ > IAEP -- It's An Education Project (not a laptop project!) > IAEP@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 ___ IAEP -- It's An Education Project (not a laptop project!) IAEP@lists.sugarlabs.org http://lists.sugarlabs.org/listinfo/iaep
Re: [IAEP] [Sugar-devel] Future of Zero Sugar
Aleksey Lim wrote: > So, I have > strong intension to switching development focus from core team, > which develops sucrose - glucose(core) and fructose(some core > activities) to wide range of developers/doers thus some kind of > decentralization of development process. I agree. I think this has been a central part of the Sugar design philosophy from the beginning. I think your message is very much on the right track. [snip] > * I hope to see many shell forks with implemented features like new > sugar themes(wallpapers support, new icons etc.), Actions view > implementations from non-core development/doers. The benefit they > will have after 0install integration is more useful method to share > these forks - just a regular entity on Activity Library that brings > new shell to user environment I don't think this part will work as "a regular entity on Activity Library", for security reasons. Any "Activity" that hooks so deeply into the shell is no longer safe to run. It is running with the full authority of the user and can violate the user's privacy or interfere with the user's actions. In orders to encourage users to become doers, Sugar is designed to make sure that Activities are always safe to run (thanks to Bitfrost/Rainbow protections). I would of course support an effort to "wall off" parts of the shell in a secure fashion, but so far almost no work has been done in that direction. --Ben signature.asc Description: OpenPGP digital signature ___ IAEP -- It's An Education Project (not a laptop project!) IAEP@lists.sugarlabs.org http://lists.sugarlabs.org/listinfo/iaep
