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

[Gary C Martin]

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 <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?
> 
> 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.