[Sugar-devel] Duplication of Effort: Don't do it.

[Tomeu Vizoso]

On Mon, Jul 27, 2009 at 20:52, Edward Cherlin<echerlin at gmail.com> wrote:
> On Mon, Jul 27, 2009 at 10:38 AM, Benjamin M.
> Schwartz<bmschwar at fas.harvard.edu> wrote:
>> -----BEGIN PGP SIGNED MESSAGE-----
>> Hash: SHA1
>>
>> I have lately seen a lot of duplication of effort in Sugar.  I think this
>> is bad.  The success of Sugar demands discipline and careful planning from
>> its developers.
>>
>> In particular, I am arguing that supporting Qt or Webkit would be a
>> terrible idea, and that neither should be permitted to be a dependency of
>> the Sugar platform.  However, my argument is certainly more general.
>>
>> 1. Bloat is bad.
>>
>> Efficiency is one of the main goals of Sugar.  Sugar was created to
>> fulfill a vision of the original Hundred Dollar Laptop Project:
>>
>> "We will get the fat out of the system.  Today's laptops have become
>> obese. Two-thirds of their software is used to manage the other third,
>> which mostly does the same functions nine different ways." [1]
>>
>> It's true.  99.99% of all deployed computers running Sugar are XO-1's, and
>> will soon be XO-1.5's. These are strongly resource-constrained machines,
>> and they cannot tolerate inefficiency in the use of disk, CPU, or RAM.
>> Outside of OLPC, we continue to target low-end hardware where efficiency
>> is key.
>>
>> If we allow Read to depend on Webkit, but Browse uses Gecko, then to use
>> them both, the operating system must load two entirely separate rendering
>> engines into memory.  On an XO-1 this may be impossible; it will certainly
>> lower the threshold for OOM behavior.  Similarly, loading both the Qt and
>> GTK libraries into memory at once dramatically increases memory usage, and
>> wastes valuable disk space.
>>
>> Don't do it.
>
> I can see the points on both sides of this issue.
>
> Putting on my market research hat, I evaluate possible futures for XOs
> on the basis of a four-year lifetime. Many XOs will be replaced after
> three years, but it would be a problem to leave children on an XO-1
> for five years. Nevertheless, XO-1s will not simply disappear when
> replaced in the classroom. Some will be put to use by other people,
> perhaps pre-schoolers, or may be put into data acquisition and control
> applications such as environmental monitoring, irrigation, and the
> like.
>
> So we can certainly raise the floor on core Sugar capabilities with at
> most a four-year delay from any Moore's law increment in capacity and
> speed. In that context, I would say not to add any large frameworks to
> the core until we and the countries agree that everybody will have
> room for them.
>
> On the other hand, if an activity would require functions not present
> in Sugar as it is now, I don't mind introducing new package
> dependencies that would not have to be on every XO. I would still
> argue that those should be kept to a minimum. If it's a necessity,
> fine. If it's a nice-to-have, maybe not.
>
> Any argument about recruiting developers should focus on educational
> needs, not maybes.
>
> So let's hear from those who want to bring in Qt.

To be clear, I'm not positively pushing for Qt, but I have invested my
own time so that people that have a value proposition can bring it on
more easily. A feeling I have developed during my work on Sugar is
that people block because think things are harder than they really
are. Those who have a good idea of the difficulty can make a first
step showing how it can be done.

One more thing I want to make very clear is that our platform allows
activity developers to distribute whatever they want without the
platform developers having a say. If someone wants to upload an
activity based on, say, KStars to ASLO for 0.84 people to use, that
person can do it today without any cooperation from our part nor any
special action from the user.

If a deployer in, say, Nepal wants to run their HTML-based activities
in QWebKit-based activites, can do it without any involvement from the
global community.

We are in a quite good situation to take the best decision, there's no
need to exclude people from our mission because of this.

> o What specifically does it let us do that we can't do now?
>
> o What does that add for the education mission?
>
> o Would we be better off adding those functions within gtk, say by
> modifying a Python library for Qt?

Well, those questions seem more relevant to me if we were discussing
replacing Gtk+ with Qt.

Regards,

Tomeu

> --
> Silent Thunder (默雷/धर्ममेघशब्दगर्ज/دھرممیگھشبدگر ج) is my name
> And Children are my nation.
> The Cosmos is my dwelling place, The Truth my destination.
> http://earthtreasury.org/worknet (Edward Mokurai Cherlin)
> _______________________________________________
> Sugar-devel mailing list
> Sugar-devel at lists.sugarlabs.org
> http://lists.sugarlabs.org/listinfo/sugar-devel
>