Re: [Sugar-devel] [SLOBS] Oversight Board request: Not fully bundled .xo
On Sat, Mar 06, 2010 at 10:36:42AM +0100, Tomeu Vizoso wrote: It may do us good to keep an eye of what Ubuntu is doing about what they call opportunistic developers and Quickly: http://www.jonobacon.org/2009/10/19/ubuntu-and-the-opportunistic-programmer/ Interesting project, even if they evade all the interesting issues we're facing by focussing on a single distro release [1], rebuilding only for a small number of architectures (e.g. not PowerPC [2]). The OpenSuSE build service goes a single step further by enabling uploaders to build for several different RPM-based distros (*), using some template magic. Building spec files for multiple RPM distros is non-trivial. Besides 1. xo bundles without binary blobs and no dependencies outside Sugar Platform and 2. maybe 0install/0sugar (which I still need to give a close look) I have yet to see anything (except for vapourware) that even remotely solves the goal of a) easy sharing of activities b) between any two users (distro and architecture agnostic) c) who can connect to each other, but not to the internet (under the tree scenario) Personally, I won't settle for anything that cannot solve all of a), b) and c) on systems meeting a reasonable baseline (i.e. installed build tools and sufficient storage space). A build service (for multiple distros + architectures) can be quite useful for resource-constrained systems (and is one thing I still intend to provide on our build slaves), but must not be mandatory. [1] https://answers.launchpad.net/soyuz/+question/86040 [2] https://answers.launchpad.net/soyuz/+question/101651 (*) It claims to support Debian as well, but last time I checked it didn't publish Debian _source_ repositories which are mandatory for the service to be useful IMO. 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] [SLOBS] Oversight Board request: Not fully bundled .xo
On Fri, Mar 05, 2010 at 05:59:24PM -0300, Bernie Innocenti wrote: It supports any target we would ever care for, even some arm targets: http://en.opensuse.org/Build_Service/supported_build_targets I don't see MIPS listed. Don't we care about the Lemote Yeeloong? CU Sascha (just trying to point out another reason why a Build Service must not be mandatory) -- 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] [SLOBS] Oversight Board request: Not fully bundled .xo
Hi Aleksey, Can activity bundles on Activity Library [1] be not fully bundled and demand additional (except having .xo) steps (that in most cases will demand network connection) to its launch. Sounds like this should be a Development Team/Deployment Team decision, unless you've already tried hard and failed to reach agreement there. (Do you think that's the case?) Speaking as part of that Devel Team discussion (and not as a SLOB), the current setup of not knowing beforehand whether a .xo bundle is a complete activity or a partial activity is really hard to deal with. I think the current situation is very frustrating for anyone who is downloading activities on a separate machine to the one they run them from, such as XO users who depend on other people to download and bring them activities with sneakernet. I think that these partial activities should not be used until we've found a way to make their dependencies (a) obvious to people who are downloading the activity from ASLO, and (b) easily downloadable at the time as the activity, to enable sneakernet downloading. Thanks! - Chris. -- Chris Ball c...@laptop.org One Laptop Per Child ___ Sugar-devel mailing list Sugar-devel@lists.sugarlabs.org http://lists.sugarlabs.org/listinfo/sugar-devel
Re: [Sugar-devel] [SLOBS] Oversight Board request: Not fully bundled .xo
On Thu, Mar 04, 2010 at 04:11:30PM -0500, Chris Ball wrote: Hi Aleksey, Can activity bundles on Activity Library [1] be not fully bundled and demand additional (except having .xo) steps (that in most cases will demand network connection) to its launch. Sounds like this should be a Development Team but it is mostly not Deployment Team case (afaik Development Team means core team) since requested changing affects general workflow. Deployment Team * would be good to hear any feedback but I guess there weren't many of them * the major issue here that ASLO is not particalr deployment oriented portal, e.g. in OLPC case, mentioned issue is mostly means nothing since OLPC can effectively add/remove any component they think is useful for their users, in contrast, ASLO (afaik) is deployment agnostic decision, unless you've already tried hard and failed to reach agreement there. (Do you think that's the case?) Speaking as part of that Devel Team discussion (and not as a SLOB), the current setup of not knowing beforehand whether a .xo bundle is a complete activity or a partial activity is really hard to deal with. yup, proposed [1] could minimize disadvantages (of course it is not idela) with preserving fully bundled .xo and links to activities when users obviously know that it is a link and they (implicitly) need to download it I think the current situation is very frustrating for anyone who is downloading activities on a separate machine to the one they run them from, such as XO users who depend on other people to download and bring them activities with sneakernet. yup, it is an issue (but shouldn't be on current ASLO) but ASLO could provide (as a main download link) regular fully bundled .xo. The reason to have second downloading link on ASLO for lightweight activities is proper handling situation when there are several Java based activity and several version of each activity and user who has proper java installation. OLPC can add java to XO distro, not sugar if java could be added to Sugar Platform (because it should mean that *every* sugar box should have java) thus every .xo on ASLO will weight +50M (or after adding ARM, +75M), pretty useless if activity itself weights 5M. Another reason against bundling blobs is that we are trying to do pretty ugly thing to pass around GNU/Linux distributions efforts in over words ASLO uploader who bundles blobs will try guess what targeted environment would be. Keeping all these in mind, we can either stop bundling blobs(and say Please do not upload java(e.g.) based activities to ASLO) or use something more reasonable then .xo. Both cases are better then current one when there is not any policy. I think that these partial activities should not be used s/used/uploaded-to-ASLO/ I guess :) and it is also a way which is better then current, we just need to make it clear for other education projects that if they want to add sugar support to their projects, they need to request for inclusion theirs dependencies to Sugar Platform (but we can't add all debian repo to sugar dependencies, thus have to say no for some projects). until we've found a way to make their dependencies (a) obvious to people who are downloading the activity from ASLO not sure if I got it, dependencies could be bunch of .so like libxmls, libcairo etc. , and (b) easily downloadable at the time as the activity, to enable sneakernet downloading. and it could be done by in new scheme Thanks! - Chris. -- Chris Ball c...@laptop.org One Laptop Per Child [1] http://wiki.sugarlabs.org/go/Features/Zero_Sugar_Activities#Detailed_Description -- Aleksey ___ Sugar-devel mailing list Sugar-devel@lists.sugarlabs.org http://lists.sugarlabs.org/listinfo/sugar-devel
Re: [Sugar-devel] [SLOBS] Oversight Board request: Not fully bundled .xo
Aleksey Lim wrote: * the major issue here that ASLO is not particalr deployment oriented portal, e.g. in OLPC case, mentioned issue is mostly means nothing since OLPC can effectively add/remove any component they think is useful for their users I don't understand this claim. ASLO is seeing literally millions of downloads from OLPC deployments. Probably 99% of ASLO traffic is from OLPC's users. As for the rest... I think .xo bundles should be absolutely free of binary executables, or anything else that depends on more than the Sugar Platform. We should then introduce a different (better!) bundle format that supports such dependencies, based on 0bundle, 0install, etc. As a temporary codename, call it .x0. --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] [SLOBS] Oversight Board request: Not fully bundled .xo
On Thu, Mar 04, 2010 at 05:01:54PM -0500, Benjamin M. Schwartz wrote: Aleksey Lim wrote: * the major issue here that ASLO is not particalr deployment oriented portal, e.g. in OLPC case, mentioned issue is mostly means nothing since OLPC can effectively add/remove any component they think is useful for their users I don't understand this claim. ASLO is seeing literally millions of downloads from OLPC deployments. Probably 99% of ASLO traffic is from OLPC's users. Thats another thing I'm willing to make decision about basing on SLOBs answer (since I accepted some of ASLO activities to public), what ASLO is, in my mind it was deployment agnostic thus if we have packages for 0.84 on bunch of distros, ASLO activities that are stated 0.84 ready should just run. But if ASLO is OLPC deployment tool, situation turns to be much simple - we need to support only f11 on x86. As for the rest... I think .xo bundles should be absolutely free of binary executables, or anything else that depends on more than the Sugar Platform. We should then introduce a different (better!) bundle format that supports such dependencies, based on 0bundle, 0install, etc. As a temporary codename, call it .x0. well, and it was the main purpose of SLOBs request, to know how sugar should move forward. And once more it is not my idle curiosity, in my mind ASLO turns to be a garbage heap of blobs when there is no chance to know will particular blob run in particular environment or not i.e. we are trying to do what no one is doing - provide fully bundled binaries for bunch of distros (but I know such examples, proprietary blobs), example w/ MAcOS doesn't work here since it is only one software platform. -- Aleksey ___ Sugar-devel mailing list Sugar-devel@lists.sugarlabs.org http://lists.sugarlabs.org/listinfo/sugar-devel
Re: [Sugar-devel] [SLOBS] Oversight Board request: Not fully bundled .xo
Aleksey Lim wrote: what ASLO is, in my mind it was deployment agnostic thus if we have packages for 0.84 on bunch of distros, ASLO activities that are stated 0.84 ready should just run. I agree. OLPC needs this as badly as anyone. OLPC already supports users on a mix of Fedora 9- and Fedora 11-based systems. For all I know there might still be a few running Fedora 7 and Sugar 0.82. The situation is only likely to get more mixed in the future, and OLPC appears to be moving seriously toward ARM-based laptops, so even individual OLPC schools will be running a mixture of different CPU architectures. As for the rest... I think .xo bundles should be absolutely free of binary executables, or anything else that depends on more than the Sugar Platform. We should then introduce a different (better!) bundle format that supports such dependencies, based on 0bundle, 0install, etc. As a temporary codename, call it .x0. well, and it was the main purpose of SLOBs request, to know how sugar should move forward. And once more it is not my idle curiosity, in my mind ASLO turns to be a garbage heap of blobs when there is no chance to know will particular blob run in particular environment or not I don't think SLOB can help much here. I think we are already approaching consensus. Part of that consensus is: we can't afford to just drop all the incomplete .xo's that require external dependencies or include non-portable executables. Before we can clean up the current mess, we need a solid, supported solution for those Activities. --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] [SLOBS] Oversight Board request: Not fully bundled .xo
On Thu, Mar 04, 2010 at 05:47:17PM -0500, Benjamin M. Schwartz wrote: Aleksey Lim wrote: what ASLO is, in my mind it was deployment agnostic thus if we have packages for 0.84 on bunch of distros, ASLO activities that are stated 0.84 ready should just run. I agree. OLPC needs this as badly as anyone. OLPC already supports users on a mix of Fedora 9- and Fedora 11-based systems. For all I know there might still be a few running Fedora 7 and Sugar 0.82. The situation is only likely to get more mixed in the future, and OLPC appears to be moving seriously toward ARM-based laptops, so even individual OLPC schools will be running a mixture of different CPU architectures. As for the rest... I think .xo bundles should be absolutely free of binary executables, or anything else that depends on more than the Sugar Platform. We should then introduce a different (better!) bundle format that supports such dependencies, based on 0bundle, 0install, etc. As a temporary codename, call it .x0. well, and it was the main purpose of SLOBs request, to know how sugar should move forward. And once more it is not my idle curiosity, in my mind ASLO turns to be a garbage heap of blobs when there is no chance to know will particular blob run in particular environment or not I don't think SLOB can help much here. I think we are already approaching consensus. Part of that consensus is: we can't afford to just drop all the incomplete .xo's that require external dependencies or include non-portable executables. Before we can clean up the current mess, we need a solid, supported solution for those Activities. agree as well, my thought about requesting SLOBs is that there is a fork: * only SP activities * activities w/ non SP dependencies and would be very useful (for everyone) if we explicitly follow one particular thread. --Ben -- Aleksey ___ Sugar-devel mailing list Sugar-devel@lists.sugarlabs.org http://lists.sugarlabs.org/listinfo/sugar-devel
Re: [Sugar-devel] [SLOBS] Oversight Board request: Not fully bundled .xo
On Thu, Mar 04, 2010 at 06:09:43PM -0500, Benjamin M. Schwartz wrote: Aleksey Lim wrote: agree as well, my thought about requesting SLOBs is that there is a fork: * only SP activities * activities w/ non SP dependencies and would be very useful (for everyone) if we explicitly follow one particular thread. I agree. Personally, I would be comfortable with a policy like: In order for a .xo bundle to be marked Public on ASLO, it must depend only on the Sugar Platform. It must not require the installation of any additional software, or depend on a particular Linux distribution or CPU architecture. Activities that have already been marked Public will remain so marked to avoid disruption. Activity authors are welcome to upload new Activities with other dependencies, but they will be marked Experimental. Activity authors are discouraged from adding new dependencies to Activities that have already been marked Public. sounds like the way to go, otherwise we will get bunch of public binary blobs that stated 0.82 only and can start only in XO-1 environment. SLOBs: well, I didn't have FOSS participant experience before sugar and maybe I misuse regular workflows, but I guess ASLO is one of SL's base things and since SLOBs represent SL, would be useful to have similar in form (but it could have opposite in meaning) statement. We intend to produce a well-supported system for distributing Activities that depend on software outside the Sugar Platform. Once this system is in place, Activities that use it may be marked Public on ASLO. and the rest of course is not a task for SLOBs (and there wasn't such intention). What do other people think? --Ben -- Aleksey ___ Sugar-devel mailing list Sugar-devel@lists.sugarlabs.org http://lists.sugarlabs.org/listinfo/sugar-devel
Re: [Sugar-devel] [SLOBS] Oversight Board request: Not fully bundled .xo
On Thu, 2010-03-04 at 17:01 -0500, Benjamin M. Schwartz wrote: Aleksey Lim wrote: * the major issue here that ASLO is not particalr deployment oriented portal, e.g. in OLPC case, mentioned issue is mostly means nothing since OLPC can effectively add/remove any component they think is useful for their users I don't understand this claim. ASLO is seeing literally millions of downloads from OLPC deployments. Probably 99% of ASLO traffic is from OLPC's users. If we want Sugar's user-base to keep growing in the future, we need to keep our platform open and viable to users of different hardware. Hopefully soon, also OLPC is going to switch to a non-x86 architecture. It was clear from the beginning that fossilizing on a single immutable ABI (32bit x86 + Fedora 9 + Sugar 0.82) was going to be a dead-end. As for the rest... I think .xo bundles should be absolutely free of binary executables, or anything else that depends on more than the Sugar Platform. We should then introduce a different (better!) bundle format that supports such dependencies, based on 0bundle, 0install, etc. As a temporary codename, call it .x0. While I've always been advocating for using a package system in Sugar, I've not been doing any work in this direction. I'm enormously grateful to Aleksey for being a doer with his pioneering work on 0install. My only concern is that 0install seems to be itself another prototype packaging format, with plenty of crucial features still missing. For example, Aleksey was telling me last week that people build binaries on their personal desktops because there's not yet a real build cluster like Koji or Suse buildservice. Meanwhile, distros are repackaging our xo bundles into native rpms and debs... Are we sure we couldn't just sit and let the distros do their job? I'm convinced that the unprivileged installation issue is easy to overcome once we agree that native packages don't stink and are not more complicated than they need to be. -- // Bernie Innocenti - http://codewiz.org/ \X/ Sugar Labs - http://sugarlabs.org/ ___ Sugar-devel mailing list Sugar-devel@lists.sugarlabs.org http://lists.sugarlabs.org/listinfo/sugar-devel
Re: [Sugar-devel] [SLOBS] Oversight Board request: Not fully bundled .xo
On Thu, 2010-03-04 at 22:20 -0300, Bernie Innocenti wrote: If we want Sugar's user-base to keep growing in the future, we need to keep our platform open and viable to users of different hardware. Hopefully soon, also OLPC is going to switch to a non-x86 architecture. It was clear from the beginning that fossilizing on a single immutable ABI (32bit x86 + Fedora 9 + Sugar 0.82) was going to be a dead-end. I should have read the thread to the end before answering, so I would have noticed that you made exactly the same point before me :-) -- // Bernie Innocenti - http://codewiz.org/ \X/ Sugar Labs - http://sugarlabs.org/ ___ Sugar-devel mailing list Sugar-devel@lists.sugarlabs.org http://lists.sugarlabs.org/listinfo/sugar-devel
Re: [Sugar-devel] [SLOBS] Oversight Board request: Not fully bundled .xo
Bernie Innocenti wrote: My only concern is that 0install seems to be itself another prototype packaging format, with plenty of crucial features still missing. For example, Aleksey was telling me last week that people build binaries on their personal desktops because there's not yet a real build cluster like Koji or Suse buildservice. 0install is just a specification and some tools. It's not even a distro. Of course there's no central build cluster. If we want to target many different distributions, then we will have to provide our own build machines... many of them (possibly VMs). Meanwhile, distros are repackaging our xo bundles into native rpms and debs... Are we sure we couldn't just sit and let the distros do their job? No distro packager in his right mind would offer packages for 90% of the activities on ASLO. They're crap. This is as it should be. If Sugar is working as intended, 99% of Activities will be crap. This is because the purpose of Sugar is to invite novices to engage actively in software development. Novices make bad stuff, and we want to install and run that stuff. This means we can't rely on any transmission medium that requires human approval. James Simmons has written a book about how to write Sugar Activities. I want novices to read his book and make new, bad Activities. I want to install those Activities as soon as they're written... may even before they're totally written. This is the nature of open collaborative development: you run other people's pre-alpha software. I also want novice developers to be able to install each other's bad activities without having to learn how to produce distro bundles and then shove them into their system package manager. I don't want the developers to have to learn three different bundle formats, and then build six different bundles for different versions of different distributions. I definitely don't want to make them submit their software to five different distro bureaucracies, and then fight through QA five times. I don't want to wait six months before I can try their Activities. I'm convinced that the unprivileged installation issue is easy to overcome once we agree that native packages don't stink and are not more complicated than they need to be. Native package systems are highly tuned for their purpose, not for ours. It's not even really the formats that are the problem. It's the software that processes them, and the bureaucracies that control the repositories. --Ben signature.asc Description: OpenPGP digital signature ___ Sugar-devel mailing list Sugar-devel@lists.sugarlabs.org http://lists.sugarlabs.org/listinfo/sugar-devel
