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

[Tomeu Vizoso]

On Thu, Sep 24, 2009 at 17:14, Michael Stone <michael at laptop.org> wrote:
> Dear Sugar folks,
>
> I have avoided wading into this discussion for some time because I wanted to
> see where it went without my interference. Therefore, before I say anything
> else, thanks for the entertaining show. :)
>
> Next, here are some thoughts for you, based on my own work, uses of Sugar, and
> past conversations with other principals.

Awesome post, thanks a lot.

Regards,

Tomeu

> Regards,
>
> Michael
>
> --------------------------------------------------------------------------------
>
> Dan wrote:
>
>> 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.
>
> My suggested model, employed all over the real open source world, is that
> people write web pages (the most popular kind of open source software!),
> publish them at URLs, and feed those URLs to interpreters.
>
> Only people with unusual quality or distribution requirements "release" or
> "package" their web pages. Most people just write them and fix problems that
> people yell about.
>
> Consequently, I want to make using activities more like web pages. That's why I
> work on rainbow and on networking design.
>
> NB: ZeroInstall, which was mentioned earlier in this thread by Ben, sure seems
> to me like it comes from the kind of world that I want to live in, even if
> Bernie isn't so sure because the "page" he tried to visit contained an broken
> link. Remember, the web used to be that way too!
>
>> Even though a Sugar system with distro-installed packages is crippled
>> (activities cannot be erased or updated through any realistic means),
>
> Then we should not rely on distros for dealing with activities. (They're
> absolutely a great thing to build Sugar Platforms out of; they're just not so
> useful for this other crazy thing we want to do. This is fine. Browsers are
> also an absolutely great thing which is not right tool, today, for the
> activities problem.)
>
>>> But we also have activity authors that don't want to go through the
>>> hassle of learning git :/
>>
>> This is getting completely ridiculous. So how do they manage the
>> versions and releases of their packages?
>
> They don't. In my opinion, ideally, they click a URL and the software they
> clicked runs most of the time. They don't care what version is underneath. If
> they want to change it, they hit view source and edit. If they want to share
> it, they share the URL, however they like.
>
> If they want to merge their changes with those of other people or if they want
> their software to run on the computers of people with wildly different setups,
> then, eventually, they learn more about the art of building portable software.
>
> The point is that none of version control, packaging, releases, and so on are
> necessary for having fun writing software or for learning; they're just useful
> for engineering.
>
>> Do these get put on a.sl.o?
>
> Probably not. Many of the people doing the work won't even have internet
> access, though they will have local networks. Take Peru as a simple example.
>
>> If so how do we verify the source code and whether it can be
>> distributed?
>
> We don't and we can't. But other people can and will anyway.
>
>> How do we verify any binary content they might include?
>
> We don't and we can't. But people will happily use it anyway.
>
>> What they do privately is their own business but if it appears on
>> a.sl.o it needs to be verify able and trackable.
>
> Sure. Ben's point is that supporting this "personal hacking" is A PRIMARY USE
> CASE. If we're not doing it, we should give up and go home.
>
> However, take heart: there is a DIFFERENT primary use case; namely, supporting
> distro-based engineering efforts useful to deployments, which is quite amenable
> to the sort of solution you're comfortable with.
>
> I believe that these are compatible points of view as soon as we admit that
> different mechanisms are needed for the differing use cases. What's the problem
> here?
>
>> There needs to be a minimum set of requirements.
>
> Your set of "minimum requirements" is a good set of requirements for
> engineering a great distro like Fedora, but that's not the only thing we're
> doing here. In particular, your "minimum requirements" violates Sugar's design
> goal of "low floor, high ceiling." Them's the breaks.
>
>>> And even worse, we want people who are not yet able to create
>>> activities from scratch to do simple modifications to existing
>>> activities and redistribute them.
>>
>> That's fine. Its open source and it then becomes their problem but it
>> shouldn't be a central issue what they want to do with modified
>> activities.
>
> It's a central issue because, as Ben explained, supporting it is a fundamental
> principle of our work. Consequently, we're allowed to solve other parts of our
> problem in different ways, but not in ways that are incompatible with it.
>
>> The activities hosted on a.sl.o should meet a minimum
>> requirement. Otherwise we get into a situation where there's no
>> guarantee of the Activity whether that been the source or the
>> stability of it.
>
> Please read Stuart Cheshire's "law of networkdynamics":
>
>   http://www.stuartcheshire.org/rants/Networkdynamics.html
>
> It explains better than I ever can why we don't want such a guarantee in the
> world at large. *Perhaps*, a.sl.o is the right place for that guarantee to
> exist in the small. Maybe a subsection of a.sl.o would be better, just like
> Ubuntu divides things up into "components":
>
>   http://www.ubuntu.com/community/ubuntustory/components
>
> --------------------------------------------------------------------------------
>
> Lastly, about the idea of shipping everything in Python, or Java, or Smalltalk:
>
> Give up -- this works for mobile phones, not for "things to think with"!
>
> Programming languages are prime examples of "things to think with". We're
> trying to provide people with lots of these, and with the best ones that we can
> find, remember?
> _______________________________________________
> 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