[IAEP] [Sugar-devel] Future of Zero Sugar

Tomeu Vizoso tomeu at sugarlabs.org
Tue Dec 15 07:52:56 EST 2009


On Tue, Dec 15, 2009 at 04:07, Aleksey Lim <alsroot at member.fsf.org> 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 <tomeu at sugarlabs.org> wrote:
>>
>> > On Mon, Dec 14, 2009 at 11:25, Benjamin M. Schwartz
>> > <bmschwar at fas.harvard.edu> 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 at 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 at lists.sugarlabs.org
>> > http://lists.sugarlabs.org/listinfo/sugar-devel
>> >
>
>> _______________________________________________
>> Sugar-devel mailing list
>> Sugar-devel at lists.sugarlabs.org
>> http://lists.sugarlabs.org/listinfo/sugar-devel
>
>
> --
> Aleksey
>



-- 
«Sugar Labs is anyone who participates in improving and using Sugar.
What Sugar Labs does is determined by the participants.» - David
Farning


More information about the IAEP mailing list