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

[pbrobinson]

On Thu, Sep 24, 2009 at 4:14 PM, 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.
>
> 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!

Its on my list to review, when I get time.

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

So you propose each device running a web server? Or every device
requiring internet access? The later makes the mesh side of things
completely pointless then.

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

I don't care about what's being done in the field as general I care
about what we need to support centrally. If someone takes the Write
application hacks it to bits and then comes back as says "Its broken
please fix it for me" I doubt we should supoort it. They broke it they
get to keep both bits, or install the clean version and start again.
My point is not what what the world does, its about what we need to do
from a central location for central deployments. Its impossible to
support every self hacked version of every Activity.

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

Again I'm talking about the centrally developer Activities for the
deployments that want something out of the box, not for the local hack
it to bit developers.

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

Which centrally we need to actually do and manage.

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

Well in that case its not our problem. They can distribute and install
it how ever they like!

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

For stuff that's distributed by 3rd parties I know we can't. For stuff
that we host anywhere on sugarlabs.org I believe we have to. Just like
Fedora won't host anything they don't know the history of.

>> How do we verify any binary content they might include?
>
> We don't and we can't. But people will happily use it anyway.

Again for stuff that we host anywhere on sugarlabs.org I believe we
have to. For everything else I couldn't care less.

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

Yes, Its a primary use case, but its not really a primary use case for
stuff hosted at sugarlabs.

> 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's only a problem of interpretation.

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

There has to be some form of minimum requirements other wise stuff
doesn't work. IE you need a reasonably recent version of python.
Otherwise you end up with nothing and you draw pictures in the sand
with a stick. Low enough for you?

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

Sorry, so there's an expectation that we support every version of
every hacked up activity? Sure, you and what army of coders?

>> 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":

I wish I had the time.

>  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

It might work but we have it already basically. Well the first two
bits of it. The third option is probably partially in a.sl.o already
and I though part of what sugar was aiming for was "free unencumbered
software" and if so you can remove the 4th option from that.

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

Well I don't know how many you can provide in 1Gb of storage. They can
add as many as they like themselves, just about every conceivable open
source programming language is already in Fedora.

Peter