[IAEP] [Sugar-devel] [SLOBS] Long-term support for Sugar

[Benjamin M. Schwartz]

Daniel Drake wrote:
> 4. Sharing of activities between hugely varying systems: The only real
> solution to this that I have seen proposed is for *all* activities to
> switch to some kind of cross-platform VM platform (e.g. Java) 
...
> I feel that the one available solution is not realistic or sensible,

We're already doing almost everything in Python, which is essentially
cross-platform unless you start shipping things that aren't Python.  Java
is a similar story.  This is not unrealistic.

> and I feel this is of very little interest to deployments, who control
> and synchronize the systems (all running the same Sugar version on the
> same distro on the same architecture) and have good distribution
> mechanisms for their users. It's something we'd invest a hell of a lot
> of time into fixing, without benefit in the field.

It's a huge benefit in the field when OLPC starts shipping XO-2, or when
Lemote wants to compete for a contract, or when Intel starts putting
64-bit CPUs in their Classmates, etc.  Even without architecture switches,
distribution upgrades (e.g. F9 to F11) can and will break binary
compatibility, so any deployment with different distro versions will begin
to see a degradation in reliability.

If you want to represent the interests of large, centrally managed,
perfectly homogeneous deployments that never want to collaborate over the
network with other deployments, then that's fine, but this is by no means
our only target type.

> 5. Modifying activities: A noble and interesting goal but unlikely to
> happen in the field (remember, 6-12 years old users!).

0. When did 6-12 become Sugar's target age range? OLPC's documents
typically said 6-16 ... and actually, there were negotiations with the
AARP for use with elderly people.

1. Modifying activities is the reason for Sugar's existence.  Everything
else is just icing.  The system is in Python to encourage user
modification.  The datastore is structured as a version control system so
that it can be used to version control the source code.  The application
security architecture (bitfrost) exists so that users can safely share
their modified programs.  The collaboration system is designed to allow
users to spread their improvements to the Activities.

OLPC put a "view source" key on the keyboard.  To me, OLPC is a trick to
raise a generation of software engineers in developing countries, because
software engineering is the one kind of serious industry that can be
initiated without a huge capital investment, and performed from anywhere.
 It can therefore be used to bootstrap third-world economies.

If you don't care about modifying Activities, and constructionist learning
through software engineering, then I really don't see much appeal in
Sugar.  Surely Moblin, for example, is far more compelling.  I certainly
wouldn't call modifying activities "unlikely to happen in the field",
though, when Bill Kerr has his students modifying SVGs directly as XML in
text editor.

> 6. Ease of creation of activity packages
> Moving to distro-based packaging will not effect the difficulty of
> developing activities, since packaging is something you do after
> development, not before.
> It will affect packaging and distribution. My suggested model (as
> employed all over the open source world) is that the developers would
> release source distributions and let distributions do the packaging
> and distribution.
...
> In many cases it will be enough just to point out to distros that
> you've developed an awesome new activity

Most new activities are not awesome.  They are very basic, because they
are developed by novices, myself included.  In Sugar, software development
is a social endeavor, where people with only a little bit of experience
make small things and pass them around, and quality improves bit by bit.

Only a handful of our Activities, the ones developed under contract by
OLPC, have reached any level of polish that would typically warrant distro
packaging.  There are already hundreds of Activities, many that we have
never even heard of because they are just passed around within deployments
such as Uruguay's.  I haven't even mentioned the language and connectivity
barriers between the users creating modified activities and the packagers
who could add them to some repository.

Activities are considered untrusted code, potentially malicious and likely
insecure, so I would be even more averse to installing them in system
directories, ready to be run by any user.

-------------- next part --------------
A non-text attachment was scrubbed...
Name: signature.asc
Type: application/pgp-signature
Size: 198 bytes
Desc: OpenPGP digital signature
Url : http://lists.sugarlabs.org/archive/iaep/attachments/20090924/ee3dc9de/attachment.pgp