[IAEP] [POLL] Non Sugar Platform activities in Activity Library

[Aleksey Lim]

----- Forwarded message from Aleksey Lim <alsroot at member.fsf.org> -----

From: Aleksey Lim <alsroot at member.fsf.org>
Subject: Re: [Sugar-devel] [POLL] Non Sugar Platform activities in Activity
	Library
To: Gary C Martin <gary at garycmartin.com>
Cc: sugar-devel at lists.sugarlabs.org
Date: Sun, 28 Feb 2010 02:18:39 +0000

On Sun, Feb 28, 2010 at 12:47:37AM +0000, Gary C Martin wrote:
> On 27 Feb 2010, at 16:48, Aleksey Lim wrote:
> 
> > On Sat, Feb 27, 2010 at 04:05:02PM +0000, Gary C Martin wrote:
> >> On 27 Feb 2010, at 07:17, Aleksey Lim wrote:
> >> 
> >>> Hi all,
> >>> 
> >>> Before this moment some binary actitieis on ASLO bundle per architeture
> >>> blobs since binaries didn't weight much. But it doesn't play in case of
> >>> http://www.geogebra.org/ which is Java based application (bundling blobs
> >>> per architecture will mean 50M of dependencies and 5M of geogebra itself).
> >>> 
> >>> Since Sugar Platform can't grow endlessly, some dependencies can't be
> >>> included to SP(here Java). But bundling some of them will be pretty
> >>> overkill(Java, Qt etc). At the same time fetching dependencies on
> >>> demand(on first launch) could not fit to some deployment models.
> >>> 
> >>> So, the question is - how handle such non SP big dependencies in ASLO.
> >>> Possible answers:
> >>> 
> >>> 1) hmm.. what are you talking about, sugar is pure python environment
> >>>  and blobs(not python) is evil, ASLO should handle only python
> >>>  based activities(or activity should bundle all its dependencies)
> >> 
> >> Sorry, but I'm still a +1 for, "Activity should bundle all its needed dependencies, but try to work within the existing platform tool set". I understand it's not always possible, and your 0-install work may provide us a rather graceful way to support random, unexpected architectures or platforms (for the exceptions not the norm); but the last thing Sugar needs is to try and potentially support and run every bit of open source code out there. We should focus on well designed Sugar or Sugarised activities. Otherwise Sugar will loose all useful identity and we would might as well drop it and move over to some other random Linux distro.
> >> 
> >> For me, what makes Sugar special is its consist, system wide attempt to focus on a child centric, and learning centric design.
> >> 
> >> Regards,
> >> --Gary
> >> 
> >> P.S. FWIW: As a Mac OS X developer and user, I almost never have to worry about dependencies or packaging. Almost all OS X applications are self contained bundles, usually containing 'fat binaries' for 32, 64, PPC Intel architectures, and targeted at perhaps the last 2 or 3 OS X version releases (4-5yrs bit rot life time). I just mention this as a working mainstream example.
> > 
> > btw MacOS geogebra package weights 5M (doesn't bundle jre) :)
> 
> :-b But that's because Mac OS includes the Java runtime as part of its platform...
> 
> > I guess we should ask ourself more generic question,
> > 
> >    How we should treat ASLO(and sugar itself)
> >    1) education platform
> >    2) python based education platform
> 
> Of course it's a platform for education, but we are where we are with regards python. I'd be quite happy if someone wanted to go out of their way and write in some other supported and available language/tool set – but right now the easiest path is to create native activities using Python & GTK+. There are heaps of example code, wiki pages, books etc for anyone how wants to learn how.

but in case of geogebra we have already existed project

> > Maybe I'm wrong and this question was already answered for others and
> > this answer is 2) but in my mind it was all time 1).
> > 
> > In case of 2) we will HAVE TO face packaging issues anyway since there
> > is lots of education software that could be proper sugarized (not only
> > running but adding Journal support for example).
> 
> Regarding 'Iots of educational software' I doubt many teams in reality would be willing to properly sugarize, we would end up with a bunch activity carbuncles dotted throughout the user experience. The sugarized successes I see are built on code bases where you can create a separate Sugar friendly UI on top, from scratch (like Write/abiword). I wish I had time to do the same for MatPlotLib and make a nice graphing/charting sand box activity.

and upsterm who are wiling to proper sugarize it (e.g. add Journal
support)

> 
> > Possible ways could be:
> > 
> >    bundle all dependencies
> >    but bundle 50M(if we include ARM support it will be 75M) for every
> >    java based activity looks overkill
> 
> There was a _lot_ of early discussion over having, or not having, Java as part of the tool set

but the question is not about including java to Sugar Platform but
about having a way to run activities that have non SP deps (here java)

> but (and I'm waving my hands a little here) it was considered too large and too resource intensive for the target hardware. I agree given my experience running Java on a 2.66Ghz dual core cpu with 4Gb of ram, it sucks eggs, memory, cpu, and usually drives the fans on and eats the laptop battery – I don't want to imaging the pain on an XO or netbook type hardware. Sure there's a reasonable amount of free Java OSS stuff out there, but even if it runs vaguely OK on the kind of hardware Sugar is aimed at, it would still need heavy sugarising so as not to pollute the Sugar environment and we seem to have very few active developers even maintaining the current set of already developed Sugar python activities...

so, having

* already existed java project(popular in education community) which runs
  on XO-1 well(of course it's not so fast but pretty usable and also we
  are not targeting only to XO-1) w/ icedtea(oss java build) 
* upstream who are eager to proper sugarize it (not only running)

we will say them "well guys, you know, java sucks and if you want to run
your application in sugar (proper sugarized) please rewrite it in
python or forget about sugar" :)

> >    rely only on Sugar Platform
> >    but we can't include all possible dependencies
> 
> +1 we will never have infinite storage space or network bandwidth. We have to draw the line at a practical boundary. The Sugar Platform should be that boundary, and we should build or sugarize activities that fit within that given constraint (understanding that the Sugar Platform will evolve over time).

in other words it will be even less then "python based education platform" -
"Sugar Platform based education platform" because not all python
libraries are included to SP(and won't be included) in comparing with
just "education platform".

--

The last paragraph is pretty important (IMO) and it will be very useful
to know what people who read these mailing lists think about sugar in
that context.

So huge appeal to post your up/down on
http://idea.olpcorps.net/drupal5/ideatorrent/idea/20/
(if text is not properly written, please comment it and/or add your
solutions).

-- 
Aleksey
_______________________________________________
Sugar-devel mailing list
Sugar-devel at lists.sugarlabs.org
http://lists.sugarlabs.org/listinfo/sugar-devel

----- End forwarded message -----

-- 
Aleksey