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.
signature.asc
Description: OpenPGP digital signature
_______________________________________________ Sugar-devel mailing list Sugar-devel@lists.sugarlabs.org http://lists.sugarlabs.org/listinfo/sugar-devel