Re: [Sugar-devel] Bundles with binary requirements (Was: The ARM is near)
0install looks quite promising to me and http://www.osnews.com/story/16956/Decentralised_Installation_Systems is good reading about the general issues involved. Has anyone here experimented with it? Regards, Michael ___ Sugar-devel mailing list Sugar-devel@lists.sugarlabs.org http://lists.sugarlabs.org/listinfo/sugar-devel
Re: [Sugar-devel] Bundles with binary requirements (Was: The ARM is near)
On Sat, Aug 29, 2009 at 05:09:44PM -0400, Michael Stone wrote: 0install looks quite promising to me and http://www.osnews.com/story/16956/Decentralised_Installation_Systems is good reading about the general issues involved. Has anyone here experimented with it? Regards, Michael Yeah, I like 0install(or its concept) more and more. In our case it could solve several issues at once: * lack of sugar packages for non-mainstream distros, we could provide 0install sugar packages in click to install form for any user * arguable questions about what new dependencies we should add to Sugar Platform(e.g. java, Qt, webkit etc.), if activity uses these non Sugar Platform dependencies, just add add them to your activity as 0install dependencies(or so) * binary blobs in activities, all dependencies will be fetched by 0install we have lightweight .xo bundles and external dependencies could be reused by several activities * dependencies between several activities could make sense in some cases e.g. TamTam's common resources(10M) could be fetched as dependency for TamTam activities(now each activity has separate copy of common resources) If there is no interested in people I'll try it after 0.86 release. -- Aleksey ___ Sugar-devel mailing list Sugar-devel@lists.sugarlabs.org http://lists.sugarlabs.org/listinfo/sugar-devel
Re: [Sugar-devel] Bundles with binary requirements (Was: The ARM is near)
On 30 Aug 2009, at 00:17, Aleksey Lim wrote: On Sat, Aug 29, 2009 at 05:09:44PM -0400, Michael Stone wrote: 0install looks quite promising to me and http://www.osnews.com/story/16956/Decentralised_Installation_Systems is good reading about the general issues involved. Has anyone here experimented with it? Regards, Michael Yeah, I like 0install(or its concept) more and more. In our case it could solve several issues at once: * lack of sugar packages for non-mainstream distros, we could provide 0install sugar packages in click to install form for any user * arguable questions about what new dependencies we should add to Sugar Platform(e.g. java, Qt, webkit etc.), if activity uses these non Sugar Platform dependencies, just add add them to your activity as 0install dependencies(or so) * binary blobs in activities, all dependencies will be fetched by 0install we have lightweight .xo bundles and external dependencies could be reused by several activities * dependencies between several activities could make sense in some cases e.g. TamTam's common resources(10M) could be fetched as dependency for TamTam activities(now each activity has separate copy of common resources) If there is no interested in people I'll try it after 0.86 release. It is interesting, but fails horribly badly in the case of no, or low bandwidth Internet. Just imagine the mess when some school on a low bandwidth high cost satellite link downloads Wibble Activity.xo and pops it on there local server, or perhaps kids themselves start to share the bundle, or distribute it on a USB stick from one to another. Think of all those extra nasty yes/no/are your sure dialogues, and subsequent download failures and support calls, and the school or districts bandwidth budget... No insult or disrespect to the original developer, or those trying to make it an activity, but the latest example http://code.google.com/p/sarynpaint/ is an extremely simple/basic bitmap paint program written in Java, that would take less than a day for me (and I am certainly no expert) to duplicate from scratch in Python. Imagine the huge amount of bandwidth, and install failures if this just got uploaded in ignorance of all the duplicate dependancy downloads this would impose on remote communities. Do you want a hand full of activity developers to bare the time effort and cost of producing a quality, efficient, well thought through and designed activity? Or put that cost on to 100,000+ children and their country school systems? How many ebooks could you distribute (and store) for the bandwidth (and nand space) taken up by downloading the required dependancies for Java. And once such a download system is in place, what will be the next unsupported language someone will try to ship an activity in? Apologies for the rant. Regards, --Gary ___ Sugar-devel mailing list Sugar-devel@lists.sugarlabs.org http://lists.sugarlabs.org/listinfo/sugar-devel
Re: [Sugar-devel] Bundles with binary requirements (Was: The ARM is near)
On Sun, Aug 30, 2009 at 12:51:22AM +0100, Gary C Martin wrote: On 30 Aug 2009, at 00:17, Aleksey Lim wrote: On Sat, Aug 29, 2009 at 05:09:44PM -0400, Michael Stone wrote: 0install looks quite promising to me and http://www.osnews.com/story/16956/Decentralised_Installation_Systems is good reading about the general issues involved. Has anyone here experimented with it? Regards, Michael Yeah, I like 0install(or its concept) more and more. In our case it could solve several issues at once: * lack of sugar packages for non-mainstream distros, we could provide 0install sugar packages in click to install form for any user * arguable questions about what new dependencies we should add to Sugar Platform(e.g. java, Qt, webkit etc.), if activity uses these non Sugar Platform dependencies, just add add them to your activity as 0install dependencies(or so) * binary blobs in activities, all dependencies will be fetched by 0install we have lightweight .xo bundles and external dependencies could be reused by several activities * dependencies between several activities could make sense in some cases e.g. TamTam's common resources(10M) could be fetched as dependency for TamTam activities(now each activity has separate copy of common resources) If there is no interested in people I'll try it after 0.86 release. It is interesting, but fails horribly badly in the case of no, or low bandwidth Internet. Just imagine the mess when some school on a low bandwidth high cost satellite link downloads Wibble Activity.xo and pops it on there local server, or perhaps kids themselves start to share the bundle, or distribute it on a USB stick from one to another. Think of all those extra nasty yes/no/are your sure dialogues, and subsequent download failures and support calls, and the school or districts bandwidth budget... No insult or disrespect to the original developer, or those trying to make it an activity, but the latest example http://code.google.com/p/sarynpaint/ is an extremely simple/basic bitmap paint program written in Java, that would take less than a day for me (and I am certainly no expert) to duplicate from scratch in Python. Imagine the huge amount of bandwidth, and install failures if this just got uploaded in ignorance of all the duplicate dependancy downloads this would impose on remote communities. Do you want a hand full of activity developers to bare the time effort and cost of producing a quality, efficient, well thought through and designed activity? Or put that cost on to 100,000+ children and their country school systems? How many ebooks could you distribute (and store) for the bandwidth (and nand space) taken up by downloading the required dependancies for Java. And once such a download system is in place, what will be the next unsupported language someone will try to ship an activity in? Apologies for the rant. hmm.. or I didn't get what you mean or you are messing several things.. * writing one day sugar activity in java instead of python soungs useless, but we can't say Use python or your code won't be sugar blessed because your favorite language is not included to Sugar Platform * case of no or low bandwidth Internet is the common question and could be resolved until we will deploy sugar by Holy Spirit instead of wires, we have this problem now(since we use ASLO) and will have this problem in the future at the same time this problem could be solved now and in future environment by using local servers(or so) 0install doesn't solve previous issues(and shouldn't) but let us decentralise sugar deployments: * we can be distro packages(versions) independent * activities could not be sugar blessed to be runnable(due to various dependencies) -- Aleksey ___ Sugar-devel mailing list Sugar-devel@lists.sugarlabs.org http://lists.sugarlabs.org/listinfo/sugar-devel
Re: [Sugar-devel] Bundles with binary requirements (Was: The ARM is near)
(Regarding 0install): It is interesting, but fails horribly badly in the case of no, or low bandwidth Internet. I'm not convinced, for three reasons. First, there is 0share http://0install.net/0share.html which seems to me to be remarkably similar to our long-stated goal of horizontal distribution of code and translations. Second, there is 0export http://0install.net/0export.html which makes setup.sh install scripts which integrate with the rest of the tools, including 0share, mentioned above. (This sounds rather similar to me to the fancy customization stick that we've previously thought about building.) Third, everything that I've seen in 0install so far is HTTP-based. This means that it should play reasonably well with any XS-based HTTP caching that we wind up organizing and with my work on http://wiki.laptop.org/go/Network2, should that ever amount to anything. Just imagine the mess when some school on a low bandwidth high cost satellite link downloads Wibble Activity.xo and pops it on there local server, or perhaps kids themselves start to share the bundle, or distribute it on a USB stick from one to another. See above. Think of all those extra nasty yes/no/are your sure dialogues I think that this is a matter of programming and integration, not of fundamental design. subsequent download failures and support calls, and the school or districts bandwidth budget... I'm not sure I follow your argument here. Can you elaborate on how this is any better or worse than the other large things people might try to download? No insult or disrespect to the original developer, or those trying to make it an activity, but the latest example http://code.google.com/p/sarynpaint/ is an extremely simple/basic bitmap paint program written in Java, that would take less than a day for me (and I am certainly no expert) to duplicate from scratch in Python. Imagine the huge amount of bandwidth, and install failures if this just got uploaded in ignorance of all the duplicate dependancy downloads this would impose on remote communities. Let's see here: * I'm not sure I understand your point about install failures, so you'll need to clarify that one for me. * As far as the bandwidth goes... I'm actually more concerned about disk space, myself, due to my previous arguments about caching, horizontal distribution, and self-determination. * Finally, doesn't it seem to you that the ease of decentralized software distribution with dependencies and space sharing afforded by this technology might make it a lot easier for you (or for our friends on sugar-desarrollo@) to collaboratively develop and distribute your lean and mean replacement? Do you want a hand full of activity developers to bare the time effort and cost of producing a quality, efficient, well thought through and designed activity? Or put that cost on to 100,000+ children and their country school systems? How many ebooks could you distribute (and store) for the bandwidth (and nand space) taken up by downloading the required dependancies for Java. When possible, I'd rather just provide easy access to both and see which our Learners prefer and I am coming to believe that this sort of decentralized distribution technology might be a good way to achieve this goal. And once such a download system is in place, what will be the next unsupported language someone will try to ship an activity in? Languages will be less expensive to support. Apologies for the rant. No apology needed. I'm not trying to push something over on you; just trying to point out some interesting technology that seems surprisingly well aligned with my understanding of our goals. (And which we could learn a lot about documentation and technical writing from!) :) Regards, Michael ___ Sugar-devel mailing list Sugar-devel@lists.sugarlabs.org http://lists.sugarlabs.org/listinfo/sugar-devel
Re: [Sugar-devel] Bundles with binary requirements (Was: The ARM is near)
Hi Aleksey, On 30 Aug 2009, at 01:23, Aleksey Lim wrote: On Sun, Aug 30, 2009 at 12:51:22AM +0100, Gary C Martin wrote: On 30 Aug 2009, at 00:17, Aleksey Lim wrote: On Sat, Aug 29, 2009 at 05:09:44PM -0400, Michael Stone wrote: 0install looks quite promising to me and http://www.osnews.com/story/16956/ Decentralised_Installation_Systems is good reading about the general issues involved. Has anyone here experimented with it? Regards, Michael Yeah, I like 0install(or its concept) more and more. In our case it could solve several issues at once: * lack of sugar packages for non-mainstream distros, we could provide 0install sugar packages in click to install form for any user * arguable questions about what new dependencies we should add to Sugar Platform(e.g. java, Qt, webkit etc.), if activity uses these non Sugar Platform dependencies, just add add them to your activity as 0install dependencies(or so) * binary blobs in activities, all dependencies will be fetched by 0install we have lightweight .xo bundles and external dependencies could be reused by several activities * dependencies between several activities could make sense in some cases e.g. TamTam's common resources(10M) could be fetched as dependency for TamTam activities(now each activity has separate copy of common resources) If there is no interested in people I'll try it after 0.86 release. It is interesting, but fails horribly badly in the case of no, or low bandwidth Internet. Just imagine the mess when some school on a low bandwidth high cost satellite link downloads Wibble Activity.xo and pops it on there local server, or perhaps kids themselves start to share the bundle, or distribute it on a USB stick from one to another. Think of all those extra nasty yes/no/are your sure dialogues, and subsequent download failures and support calls, and the school or districts bandwidth budget... No insult or disrespect to the original developer, or those trying to make it an activity, but the latest example http://code.google.com/p/sarynpaint/ is an extremely simple/basic bitmap paint program written in Java, that would take less than a day for me (and I am certainly no expert) to duplicate from scratch in Python. Imagine the huge amount of bandwidth, and install failures if this just got uploaded in ignorance of all the duplicate dependancy downloads this would impose on remote communities. Do you want a hand full of activity developers to bare the time effort and cost of producing a quality, efficient, well thought through and designed activity? Or put that cost on to 100,000+ children and their country school systems? How many ebooks could you distribute (and store) for the bandwidth (and nand space) taken up by downloading the required dependancies for Java. And once such a download system is in place, what will be the next unsupported language someone will try to ship an activity in? Apologies for the rant. hmm.. or I didn't get what you mean or you are messing several things.. * writing one day sugar activity in java instead of python soungs useless, Sorry if I wasn't clear but I meant 'spend one day writing that particular activity in Python instead', and avoid the whole 'how do I ship a full Java runtime' for this simple paint app (again no offence intended to those involved in this specific case). but we can't say Use python or your code won't be sugar blessed because your favorite language is not included to Sugar Platform Actually that is *exactly* what we should be saying, otherwise the whole point of having a streamlined blessed platform tuned to reaching Suagr Labs mission is a pointless exercise. What you leave out is as important as what you put in. * case of no or low bandwidth Internet is the common question and could be resolved until we will deploy sugar by Holy Spirit instead of wires, we have this problem now(since we use ASLO) and will have this problem in the future at the same time this problem could be solved now and in future environment by using local servers(or so) If a bundle contains all code an activity needs to run (excepting code available in the Sugar Platform), then individuals/deployments can see up front the requirements of an Activity when they make the decision to download it. When they then share, distribute, and or modify that Activity (another Sugar goal) locally to others (potentially off- line), there is no additional external dependancy checks and download magic needed, everything is in that bundle that the author intended. At the point where we discover we have suddenly N activities all independently using the same library, we can lobby the community to have that library included in the next future release of the platform. Regards, --Gary ___ Sugar-devel mailing list Sugar-devel@lists.sugarlabs.org
Re: [Sugar-devel] Bundles with binary requirements (Was: The ARM is near)
Gary C Martin wrote: How many ebooks could you distribute (and store) for the bandwidth (and nand space) taken up by downloading the required dependancies for Java. A hell of a lot. That's why we need to display prominently exactly how much space each item in the Journal takes, including each Activity. If possible, users also need to know how much space something will use before they download it. Determining space usage is technically easy, but the corresponding UI design problem has not gotten enough attention. Running out of space is a common problem on XO-1s, and will still be a common problem on XO-1.5. We need to help novice users manage their storage by providing a highly visual indication of storage use. And once such a download system is in place, what will be the next unsupported language someone will try to ship an activity in? C#, of course. I think the right way to deal with these things is to let the user decide, but show the user how much space is being used. The users can judge for themselves if they want to spend 100 MB on a Paint program. The ones with terabyte disks and 10 megabit downlinks probably don't care. --Ben signature.asc Description: OpenPGP digital signature ___ Sugar-devel mailing list Sugar-devel@lists.sugarlabs.org http://lists.sugarlabs.org/listinfo/sugar-devel
Re: [Sugar-devel] Bundles with binary requirements (Was: The ARM is near)
Hi all, Feel free to ignore my comments here - after all I am not doing any of the heavy lifting in this field, I just continue to package for Debian from source, independent on what you come up with here... On Fri, Aug 28, 2009 at 04:47:53AM +0100, Gary C Martin wrote: As a long time Mac user (and developer) I was/am all for fat packages (universal binaries), and we certainly don't have the ability to compile binaries on demand for the significant portion of target sugar HW. Activity bundles are a major plus, from where I'm standing, vs. the traditional ./configure, make install, and dependancy requirements. Macintosh universal binaries was binaries that contained both the new stuff and the old stuff. Pretty easy for users to grasp. (Back in the day it meant m68k + powerpc and later, when m68k was officially dead for some years, it meant powerpc + i386 (and possibly amd64 too, but I suspect that to be optional for some years) What would universal be in the Sugar context? i386 + amd64? i686 + amd64? i386 + i686 + amd64? powerpc + i386 + amd64? armel + i386 + amd64? powerpc + armel + i386 + amd64? It is plain ugly IMHO! With my activity author hat on, I've gone out of my way to avoid the hell of binary blobs, it breaks the whole idea of providing code in Python source for others to easily edit, modify, learn from. But I understand (having adopted maintenance of some old projects) that this has not always been possible for authors (though it woul would always be my goal when writing code). So you find it acceptable for old code to contain binary blobs. I am with you on that. I worry about new Activities using binary blobs too, if not explicitly and loudly discouraged by the Sugar project. Kind regards, - Jonas -- * Jonas Smedegaard - idealist og Internet-arkitekt * Tlf.: +45 40843136 Website: http://dr.jones.dk/ [x] quote me freely [ ] ask before reusing [ ] keep private signature.asc Description: Digital signature ___ Sugar-devel mailing list Sugar-devel@lists.sugarlabs.org http://lists.sugarlabs.org/listinfo/sugar-devel
Re: [Sugar-devel] Bundles with binary requirements (Was: The ARM is near)
On Fri, Aug 28, 2009 at 04:47:53AM +0100, Gary C Martin wrote: Hi Benjamin, On 28 Aug 2009, at 03:58, Benjamin M. Schwartz wrote: Bobby Powers wrote: I think having something like: example.activity |-arch/ |-arch/x86/ |-arch/x86/bin/ |-arch/x86/lib/ |-arch/armel/ ... could work. Sugar could set an environmental variable ARCH to the relevant value, and we could have a reference activity_startup.sh which adds the correct lib path to LD_LIBRARY_PATH and launches the appropriate executable (or maybe a flag in activty.info which has sugar do this). This is still somewhat kludgy, but I'm not sure of a better way. Which solution we should choose is a technical discussion that deserves its own thread. I'm personally not enthusiastic about the fat packages approach, in which binaries for many architectures are included in one .xo bundle, because: What would be your recommendation? As a long time Mac user (and developer) I was/am all for fat packages (universal binaries), and we certainly don't have the ability to compile binaries on demand for the significant portion of target sugar HW. Activity bundles are a major plus, from where I'm standing, vs. the traditional ./configure, make install, and dependancy requirements. With my activity author hat on, I've gone out of my way to avoid the hell of binary blobs, it breaks the whole idea of providing code in Python source for others to easily edit, modify, learn from. But I understand (having adopted maintenance of some old projects) that this has not always been possible for authors (though it woul would always be my goal when writing code). Another option is adding 0install[1](or so) to sugar e.g.: * activity bundles dont include any blobs at all * on uploading .xo to journal, sugar popups 0install regular dialog to install all needed by activity dependancies * activity author package(in meaning of packaging in 0install) binary dependancies for all environments/plarforms/architectures that he wants to support Purposes for 0install(or so) in comparing with native packages: * one way to install deps in all environments * non-root install [1] http://0install.net/ -- Aleksey ___ Sugar-devel mailing list Sugar-devel@lists.sugarlabs.org http://lists.sugarlabs.org/listinfo/sugar-devel
Re: [Sugar-devel] Bundles with binary requirements (Was: The ARM is near)
On Fri, Aug 28, 2009 at 09:55:37PM +0200, Elena of Valhalla wrote: On Fri, Aug 28, 2009 at 6:44 PM, Jonas Smedegaardd...@jones.dk wrote: What would universal be in the Sugar context? i386 + amd64? i686 + amd64? i386 + i686 + amd64? i386 would work on all of them, even if not optimally, but then True only if the underlying system is i386 too, of if it at least provides i386 libraries for all of the bindings. powerpc + i386 + amd64? armel + i386 + amd64? powerpc + armel + i386 + amd64? +mips, I guess ...and then when all users have gotten used to Sugar universal meaning that bunch, in comes SuperH hardware and we confuse them yet again. Compare with Apple: Universal means simply contains both new and old, with the exact meaning of new and old shifting tied to a corporate decision and backed by massive marketing. It is plain ugly IMHO! and wasteful and still only addresses arch-differences - not same-arch incompatibilities between different minor versions of libraries and different dependencies linked in (e.g. some distributions using libssl and others using gnutls). Just avoid that mess! It seems difficult to constrain activity developers to only code using arch-independent runtime code, but accepting arch-dependent stuff is an evergrowing hell - it is what distributions spend humongous man-hours handling! - Jonas -- * Jonas Smedegaard - idealist Internet-arkitekt * Tlf.: +45 40843136 Website: http://dr.jones.dk/ [x] quote me freely [ ] ask before reusing [ ] keep private signature.asc Description: Digital signature ___ Sugar-devel mailing list Sugar-devel@lists.sugarlabs.org http://lists.sugarlabs.org/listinfo/sugar-devel
Re: [Sugar-devel] Bundles with binary requirements (Was: The ARM is near)
On Fri, Aug 28, 2009 at 05:04:32PM +, Aleksey Lim wrote: Purposes for 0install(or so) in comparing with native packages: * one way to install deps in all environments * non-root install * requires reliable internet access at install time - Jonas -- * Jonas Smedegaard - idealist Internet-arkitekt * Tlf.: +45 40843136 Website: http://dr.jones.dk/ [x] quote me freely [ ] ask before reusing [ ] keep private signature.asc Description: Digital signature ___ Sugar-devel mailing list Sugar-devel@lists.sugarlabs.org http://lists.sugarlabs.org/listinfo/sugar-devel
[Sugar-devel] Bundles with binary requirements (Was: The ARM is near)
Hi Benjamin, On 28 Aug 2009, at 03:58, Benjamin M. Schwartz wrote: Bobby Powers wrote: I think having something like: example.activity |-arch/ |-arch/x86/ |-arch/x86/bin/ |-arch/x86/lib/ |-arch/armel/ ... could work. Sugar could set an environmental variable ARCH to the relevant value, and we could have a reference activity_startup.sh which adds the correct lib path to LD_LIBRARY_PATH and launches the appropriate executable (or maybe a flag in activty.info which has sugar do this). This is still somewhat kludgy, but I'm not sure of a better way. Which solution we should choose is a technical discussion that deserves its own thread. I'm personally not enthusiastic about the fat packages approach, in which binaries for many architectures are included in one .xo bundle, because: What would be your recommendation? As a long time Mac user (and developer) I was/am all for fat packages (universal binaries), and we certainly don't have the ability to compile binaries on demand for the significant portion of target sugar HW. Activity bundles are a major plus, from where I'm standing, vs. the traditional ./configure, make install, and dependancy requirements. With my activity author hat on, I've gone out of my way to avoid the hell of binary blobs, it breaks the whole idea of providing code in Python source for others to easily edit, modify, learn from. But I understand (having adopted maintenance of some old projects) that this has not always been possible for authors (though it woul would always be my goal when writing code). Regards, --Gary ___ Sugar-devel mailing list Sugar-devel@lists.sugarlabs.org http://lists.sugarlabs.org/listinfo/sugar-devel
Re: [Sugar-devel] Bundles with binary requirements (Was: The ARM is near)
Gary C Martin wrote: Hi Benjamin, On 28 Aug 2009, at 03:58, Benjamin M. Schwartz wrote: Bobby Powers wrote: I think having something like: example.activity |-arch/ |-arch/x86/ |-arch/x86/bin/ |-arch/x86/lib/ |-arch/armel/ ... could work. Sugar could set an environmental variable ARCH to the relevant value, and we could have a reference activity_startup.sh which adds the correct lib path to LD_LIBRARY_PATH and launches the appropriate executable (or maybe a flag in activty.info which has sugar do this). This is still somewhat kludgy, but I'm not sure of a better way. Which solution we should choose is a technical discussion that deserves its own thread. I'm personally not enthusiastic about the fat packages approach, in which binaries for many architectures are included in one .xo bundle, because: What would be your recommendation? As a long time Mac user (and developer) I was/am all for fat packages (universal binaries), and we certainly don't have the ability to compile binaries on demand for the significant portion of target sugar HW. Activity bundles are a major plus, from where I'm standing, vs. the traditional ./configure, make install, and dependancy requirements. With my activity author hat on, I've gone out of my way to avoid the hell of binary blobs, it breaks the whole idea of providing code in Python source for others to easily edit, modify, learn from. But I understand (having adopted maintenance of some old projects) that this has not always been possible for authors (though it woul would always be my goal when writing code). I am very much with you here: I think writing Activities in pure Python is very valuable to minimize the barrier to entry for software modification, and maximize the incentive to learn a bit of software engineering. Sugar now has a number of officially supported languages: python, eToys/Squeak, HTML+Javascript, and bash/shell, at least, and the benefits of editability extend at least somewhat to all of these. When authors ship binary code, not written in one of the above languages, it is either because 1. they are depending on pre-existing software, written in another language, whose presence is not guaranteed by Sugar, or 2. they are writing new software in another language. (or both) These cases seem quite different to me. In particular, we might be able to make use of some existing packages for case 1, whereas no packages yet exist in case 2. Virtually all binaries on Linux are produced by gcc. One way we could resolve our binary issue is to declare gcc to be a blessed dependency of Sugar, and then demand that all XO bundles include all their code and dependencies as source files, to be compiled on the target machine. This would essentially resolve the cross-platform problem, in a way that is nicely aligned with Sugar's emphasis on software freedom and hands-on engineering. I also think that the performance overhead would not be totally outrageous. We are not talking about compiling browsers, kernels, GUI toolkits, or X. Those things are already provided, and developers should not duplicate them. The projects being compiled should be relatively small. Unfortunately, the situation is not quite so nice. A few problems: - Pre-existing applications use a variety of build systems, like autotools and cmake. Unless we bless them all, Activity bundles in Case 1 will have to compile the source code for the build system before they can build the project itself. This is not easy for the bundler to get right. - We will need to provide all the headers against which to compile, the -devel packages in many distros. This may require a significant amount of disk space - Different distros have different library versions. Depending on how we phrase our library version guarantees, we could find that Activities need to ship an obscenely deep dependency tree to be safe. - Building large projects is not always easy. Sometimes complicated, fragile, poorly documented steps are required. I am not sure how to resolve all these problems. My favorite solution so far most nearly resembles Gentoo's Portage. Portage is a sort of dependency-resolving build management system that processes ebuilds which are shell scripts that control package compilation. Portage also supports precompiled binary packages if they are available, as an optimization. Gentoo Prefix provides a set of several thousand ebuilds that can be processed, installed, and run entirely without root privileges. I imagine a system in which For case 1: Activity bundles are required to include source tarballs and ebuilds for any dependencies. Upon installation, these dependencies will be installed from binary packages if matching binaries can be found. Otherwise, they will be compiled from the provided source, using the provided ebuild. For case 2: Authors writing activities in a gcc language must package the activity as a source tarball
