Re: [Sugar-devel] [POLL] Non Sugar Platform activities in Activity Library
On Sat, Feb 27, 2010 at 07:17:54AM +, 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) 2) activities that don't have bundled all dependencies should be explicitly marked to not mess them w/ fully bundling ones 3) use complicated model when ASLO makes decision for every downloading, should dependencies be included or not or less complicated scheme when there will be per architeture bundles, uploader will push pure 0sugar activity and ASLO will cook .xos with all dependencies bundled per architeture. Please suggest your variants and attach your +/- -- 2) +1 -- Aleksey -- Aleksey ___ Sugar-devel mailing list Sugar-devel@lists.sugarlabs.org http://lists.sugarlabs.org/listinfo/sugar-devel
Re: [Sugar-devel] [POLL] Non Sugar Platform activities in Activity Library
On Sat, Feb 27, 2010 at 3:01 AM, Aleksey Lim alsr...@member.fsf.org wrote: On Sat, Feb 27, 2010 at 07:17:54AM +, 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) 2) activities that don't have bundled all dependencies should be explicitly marked to not mess them w/ fully bundling ones 3) use complicated model when ASLO makes decision for every downloading, should dependencies be included or not or less complicated scheme when there will be per architeture bundles, uploader will push pure 0sugar activity and ASLO will cook .xos with all dependencies bundled per architeture. Please suggest your variants and attach your +/- -- 2) +1 -- Aleksey -- Aleksey ___ Sugar-devel mailing list Sugar-devel@lists.sugarlabs.org http://lists.sugarlabs.org/listinfo/sugar-devel Could we have a scheme where by we make a primary bundle and then secondary bundles with the arch-dep bits, one per arch. and have a way in ASLO to grab from both as needed? -walter -- Walter Bender Sugar Labs http://www.sugarlabs.org ___ Sugar-devel mailing list Sugar-devel@lists.sugarlabs.org http://lists.sugarlabs.org/listinfo/sugar-devel
Re: [Sugar-devel] [POLL] Non Sugar Platform activities in Activity Library
On Sat, Feb 27, 2010 at 08:32:53AM -0500, Walter Bender wrote: On Sat, Feb 27, 2010 at 3:01 AM, Aleksey Lim alsr...@member.fsf.org wrote: On Sat, Feb 27, 2010 at 07:17:54AM +, 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) 2) activities that don't have bundled all dependencies should be explicitly marked to not mess them w/ fully bundling ones 3) use complicated model when ASLO makes decision for every downloading, should dependencies be included or not or less complicated scheme when there will be per architeture bundles, uploader will push pure 0sugar activity and ASLO will cook .xos with all dependencies bundled per architeture. Please suggest your variants and attach your +/- -- 2) +1 -- Aleksey -- Aleksey ___ Sugar-devel mailing list Sugar-devel@lists.sugarlabs.org http://lists.sugarlabs.org/listinfo/sugar-devel Could we have a scheme where by we make a primary bundle and then secondary bundles with the arch-dep bits, one per arch. and have a way in ASLO to grab from both as needed? Yup, I meant the same - developer mentions 0sugar deps in activity.info and upload bundle only with activity itself w/o any deps bundled, later ASLO will prepare proper set of bundles e.g. per architecture for binary dependencies. The issue with this scheme is that we have a mess anyway since .xos are not fully bundled and contain blobs only for one architecture e.g. if someone downloaded .xo from ASLO on x86_64 box then copied it to x86 box. -- Aleksey ___ Sugar-devel mailing list Sugar-devel@lists.sugarlabs.org http://lists.sugarlabs.org/listinfo/sugar-devel
Re: [Sugar-devel] [POLL] Non Sugar Platform activities in Activity Library
On Sat, Feb 27, 2010 at 04:05:02PM +, 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) :) 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 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). 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 rely only on Sugar Platform but we can't include all possible dependencies 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.. -- Aleksey ___ Sugar-devel mailing list Sugar-devel@lists.sugarlabs.org http://lists.sugarlabs.org/listinfo/sugar-devel
Re: [Sugar-devel] [POLL] Non Sugar Platform activities in Activity Library
On Sat, Feb 27, 2010 at 11:36:04AM -0500, Benjamin M. Schwartz wrote: Aleksey Lim wrote: Please suggest your variants and attach your +/- All of the above. ASLO should warn the user if an activity is arch-dependent, generate a bundle appropriate to the user's settings, and make sure that the generated bundle's name indicates the supported architectures. (e.g WatchMe-2.xo.F13-sparc32+Lenny-IA64) this is intermediate option which could only increase mess, since from once side activities bundle something, from other side bundle not all dependencies and use case with download .xo from one box and run it on other won't work (otherwise we should oblige kids understand what IA64 and sparc32 is). Ultimately, though, I think we need to move 0install into Glucose. Then to share an activity bundle with a friend, all I have to do is transfer the package URL. My friend's Sugar install can then use 0share/packagekit/0launch to get whatever components are necessary for her system... possibly even from me via 0share, or possibly from ASLO. and I'm all about this, kid just click on download button on ASLO (or pass link to friends) and all technical stuff (check for deps, arches etc) will be done by 0install. Of course as was already mentioned many times there will be net issue. But are we trying to solve downstream problems on upstream, I mean if there is only *one* XO laptop somewhere in sahara nothing would be useful, but more or less big deployments could have school servers that will provide all useful for this particular dependent dependencies via local network (and users themselves could be peers in local file sharing network). -- Aleksey ___ Sugar-devel mailing list Sugar-devel@lists.sugarlabs.org http://lists.sugarlabs.org/listinfo/sugar-devel
Re: [Sugar-devel] [POLL] Non Sugar Platform activities in Activity Library
On Sat, Feb 27, 2010 at 07:01:35PM +0100, Sascha Silbe wrote: On Sat, Feb 27, 2010 at 04:48:27PM +, Aleksey Lim wrote: bundle all dependencies but bundle 50M(if we include ARM support it will be 75M) for every java based activity looks overkill IMO the only sane way to handle large dependencies, esp. language ones, is relying on distro packages. 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 This looks like the way to go, esp. the installed on demand from native packaging systems part. Rely on distro packages as much as possible, you'll avoid quite some trouble the distributors have already gone through for you (e.g. xulrunner paths differ on distros). Distro packages are also a) easily and transparently cachable on a local server (apt-cacher, squid, ...) b) fetched from the widespread mirror network of distributions rather than the few ones hosting Sugar stuff (APT can even use bittorrent or custom P2P software like apt-p2p) c) usually more trustworthy than random builds from some more or less anonymous source d) actively maintained, including security updates (except for Ubuntu universe/multiverse). +1024 and 0install is so smart that it will check if required dependency * already installed * could be installed from native packages and ask PackageKit to install it * fallabck to prebuilt blobs * fallabck to build from sources in users env * say phew -- Aleksey ___ Sugar-devel mailing list Sugar-devel@lists.sugarlabs.org http://lists.sugarlabs.org/listinfo/sugar-devel
Re: [Sugar-devel] [POLL] Non Sugar Platform activities in Activity Library
On Sat, Feb 27, 2010 at 06:13:22PM +, Aleksey Lim wrote: and 0install is so smart that it will check if required dependency * already installed * could be installed from native packages and ask PackageKit to install it * fallabck to prebuilt blobs * fallabck to build from sources in users env * say phew Sounds great! Sorry I've fallen behind on your 0install/0sugar efforts, I definitely need to try it out - I've put it on my growing list of things to do next month. CU Sascha -- http://sascha.silbe.org/ http://www.infra-silbe.de/ signature.asc Description: Digital signature ___ Sugar-devel mailing list Sugar-devel@lists.sugarlabs.org http://lists.sugarlabs.org/listinfo/sugar-devel
Re: [Sugar-devel] [POLL] Non Sugar Platform activities in Activity Library
On Sun, Feb 28, 2010 at 12:47:37AM +, Gary C Martin wrote: On 27 Feb 2010, at 16:48, Aleksey Lim wrote: On Sat, Feb 27, 2010 at 04:05:02PM +, 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
Re: [Sugar-devel] [POLL] Non Sugar Platform activities in Activity Library
On Sun, Feb 28, 2010 at 02:18:39AM +, Aleksey Lim wrote: On Sun, Feb 28, 2010 at 12:47:37AM +, Gary C Martin wrote: On 27 Feb 2010, at 16:48, Aleksey Lim wrote: On Sat, Feb 27, 2010 at 04:05:02PM +, 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
[Sugar-devel] [POLL] Non Sugar Platform activities in Activity Library
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) 2) activities that don't have bundled all dependencies should be explicitly marked to not mess them w/ fully bundling ones 3) use complicated model when ASLO makes decision for every downloading, should dependencies be included or not Please suggest your variants and attach your +/- -- 2) +1 -- Aleksey ___ Sugar-devel mailing list Sugar-devel@lists.sugarlabs.org http://lists.sugarlabs.org/listinfo/sugar-devel
