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

[Rafael Enrique Ortiz Guerrero]

 Hi All.

I think Benjamin got a point when he refers to

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

but, the real problem that we have to face is (as David) says is
that  duplication is a cost which must be managed.
and a time factor also enters in the scene.

If these duplication costs (over time)  can be covered in order to
have sugar having all it's qualities both running in hardware
constraint environments and reaching out to a broader audience, i
think we can assure ourselves a good growth enviroment. But ONLY if
these two requirements are fulfilled, Sugar community can continue to
have this discussion, if not my opinion is that we must choose quality
over quantity.

following this conceptual point of start, the technical matters should
proceed clarifying the path...










On Mon, Jul 27, 2009 at 3:27 PM, David Farning<dfarning at sugarlabs.org> wrote:
> On Mon, Jul 27, 2009 at 12:38 PM, 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.
>
> Yes, duplication of effort _is_ undesirable.   It is an inherent cost
> in open source projects.
>
> In an hierarchical project, a significant amount of effort is spent by
> managers coordinating, directing, and controlling their subordinates.
> The goal is to insure that workers are effectively spending their time
> on approved projects.
>
> In an open source project their is _no_ way to control the work of
> subordinates.  Nor should a project spend its limited resources on
> managers instead of developers and educators.  The intelligence is in
> the leaves.
>
> The project must establish a culture which attracts participants to
> work towards a common mission and vision.  Open source is
> evolutionary.  Evolution depends on parallelism.  Good lines survive.
> Bad lines die.
>
> We have not moved far enough forward far on the Qt issue for me to
> have a stance.
>
> As this, and other, discussions moves forward I would like shift one
> of the conversation premises from 'duplication of effort is bad' to
> 'duplication is a cost which must be managed.'
>
> Projects which succeed, manage these costs.
>
> david
>
>> 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.
>>
>> - --Ben
>>
>> [1] http://web.archive.org/web/20050324163700/http://laptop.media.mit.edu/
>> -----BEGIN PGP SIGNATURE-----
>> Version: GnuPG v2.0.11 (GNU/Linux)
>>
>> iEYEARECAAYFAkpt5iEACgkQUJT6e6HFtqQzTgCfTWiSLfg1QBGnxKck8zZul3MJ
>> d80AnAnTeT4zIccEPs6kNoiHYkEBjBc8
>> =ayiC
>> -----END PGP SIGNATURE-----
>> _______________________________________________
>> Sugar-devel mailing list
>> Sugar-devel at lists.sugarlabs.org
>> http://lists.sugarlabs.org/listinfo/sugar-devel
>>
> _______________________________________________
> Sugar-devel mailing list
> Sugar-devel at lists.sugarlabs.org
> http://lists.sugarlabs.org/listinfo/sugar-devel
>