[Sugar-devel] Bundles with binary requirements (Was: The ARM is near)

Aleksey Lim alsroot at member.fsf.org
Sat Aug 29 20:23:44 EDT 2009


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


More information about the Sugar-devel mailing list