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

[Gary C Martin]

On 27 Jul 2009, at 18:38, Benjamin M. Schwartz 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.
>
> 2. Technological uniformity is an educational decision.
>
> Sugar, and its activities, are written using a uniform set of
> technologies, centered around pygtk.  This is deliberate.  The goal  
> is to
> crush the barrier to entry, so that a student who learns how to modify
> python activities immediately has enough knowledge to modify Sugar  
> itself.
> This is the incarnation of "low floor, no ceiling".  It is what  
> enables
> the culture of end-user engineering that we strive to create.
>
> Adding more supported technologies for writing Activities raises new
> barriers to entry.  A student who learns how to modify a Qt-based  
> activity
> does not gain knowledge that will help to modify Sugar itself.  A  
> user who
> has learned pygtk still does not have enough knowledge to modify one
> written in Qt.  We risk creating a Tower of Babel, with components  
> written
> in countless frameworks, all different.
>
> One argument made in favor of supporting Qt is to gain access to  
> existing
> KDE applications.  I don't believe this for a second.  Our entire  
> system
> is built with technologies drawn from the Gnome stack, and yet we have
> almost no Activities that consist of wrapped Gnome desktop  
> applications.
> The barriers to compatibility with KDE are considerably higher, and I
> cannot think of a single application from KDE-space whose  
> functionality we
> do not have, or could not get more easily from GTK-land.
>
> Another argument is that it will help to gain support from developers
> already familiar with Qt.  I think this is quite irrelevant.  When I
> started writing Sugar code, I had never seen a single line of gtk (I  
> was
> familiar with Swing).  I read the docs.  It was easy.  Anyone can  
> learn
> gtk, especially if they are already familiar with another toolkit.
>
> More importantly, there just aren't that many Qt developers.  I am  
> willing
> to accept an argument of this type for improving support for  
> activities
> written in javascript+HTML, because there are certainly orders of
> magnitude more developers of javascript and HTML than of python, or  
> any
> other language we might choose to support.  Qt and PyQt, on the other
> hand, are in a niche even smaller than pygtk's.
>
> The many costs of supporting Qt greatly exceed any theoretical value.
>
> Don't do it.

+1, thanks for elucidating this so well.

Regards,
--Gary