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

[Edward Cherlin]

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.

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