[Sugar-devel] [POLL] Non Sugar Platform activities in Activity Library
Gary C Martin
gary at garycmartin.com
Sat Feb 27 19:47:37 EST 2010
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.
>> 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.
> 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.
> 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 (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...
> 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).
> deployment method when all efforts are concentrated around one(several)
> particular sugar distributions like OLPC or SOAS
> but I guess more global approach was chosen since organizing SL
> using more flexible scheme when we have
> * Sugar Platform and majority of fully bundled activities (since
> dependencies were included to SP)
> * minority which have non-SP dependencies, such dependencies could be
> * bundled, if they are small
> * installed on demand from native packaging systems
> * fetched on demand
> ..add your own..
More information about the Sugar-devel