On Wed, Feb 16, 2011 at 6:42 PM, Chris Ball <cjb at laptop.org> wrote:
> Thanks for the proposal, lots of combustible material here. :)
>
I was hoping "ask interesting questions", as Martin says.
> I wouldn't be very excited about just porting Sugar activities to a
> stock Android base. I think our goals for Sugar are mainly to build
> educational software that:
>> * can be appropriated -- translated, modified, discussed.
> * encourages creation rather than mere consumption of content.
> * encourages joint collaboration and sharing.
>> I don't think stock Android apps can do these things well, so I don't
> think we're advancing our goals by creating stock Android apps.
If Android apps to date have not accomplished this, that just means there's
an opportunity!
I think the infrastructure is what's missing here: reusable libraries for
collaboration/sharing. Something Pippy-like or Java-compiler-like that
makes it possible to distribute your app's source along with the app
itself--*and do something with the source on the device*.
I don't think these things are impossible. I think they haven't been done.
> So, we'd have to be modifying the Android base OS, as you suggest.
I think this idea would make much more sense for OLPC than for Sugar
> Labs -- it's fine for OLPC to go hacking around in Android and create
> a code editor, and Journal and Collaboration services and so on, but it
> would be really hard to get anyone on a non-XO to be able to run them
> because Android is so fragmented. Each hardware vendor has their own
> Android build (which they aren't obliged to provide source for!), and
> most vendors ship devices root-locked to most users. How would Sugar
> Labs be proposing that owners of Android devices actually *run* our
> patched Android OS, if we don't even have the vendor's source to patch?
>
Yes, interesting questions. I still maintain this is the home turf for
SugarLabs, who is responsible for getting Sugar's ideas to as many platforms
as possible. OLPC should only concern itself with running Android on OLPC
hardware -- not enough resources to do everything!
I think most of what you are asking about is the old "upstreamability"
question. Ideally such an effort would start with an approach to Google and
cooperation. If adding XYZ hook to Android really helps make Sugar
possible, then upstreaming that hook will eventually cause it to appear in
all the millions of new phones/tablets/etc.
I don't have answers to all of your questions -- again, I'm mostly
interesting in posing the question. Is the interesting part of Sugar really
Linux? Or it is the activity layer? If it's the activity layer, what's
keeping us from more aggressive ports?
Have you got any ideas on the above? Again, I'm not disagreeing that
> someone *could* make a Sugar-like environment by modifying Android,
> just that it doesn't seem like Sugar Labs is the right group to be
> interested in doing that, because it would be so hard to actually ship
> the result without control over a hardware platform. SL would go from
> producing software that can run on most machines to producing software
> that needs to be hand-tailored for each device.
>
It all depends on what SugarLab's target market is. If Sugar is intended
only to run on desktop Linux systems, well sure, upstreaming the packages
into Fedora and ignoring the rest is a fine strategy. If Sugar is intended
to run on mobile systems, then SL needs to start thinking about how to make
it available. Yes, it's a hard problem. If it was easy, it probably
wouldn't need to be done.
> How about ChromeOS instead, then? Rumor is it was too slow to get
> going, and is either going to be canceled or just merged with Android:
>
The link you posted is just a wild guess.
Consider ChromeOS just a fancy name for Chrome the browser. Chrome the
browser has Apps and lots of extension hooks. You can make sugar activities
run entirely inside the browser. ChromeOS is convenient, because it
embodies build tools and hardware configurators and all the other details,
freeing SugarLabs to work on the "education stuff". It's basically Fedora
to Sugar-on-Linux. It's replaceable.
Think instead of what a truely "web enabled" version of Sugar would look
like. Sugar which could run in any Chrome browser -- although you might
have to install a chrome extension first.
--scott
--
( http://cscott.net/ )
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://lists.sugarlabs.org/archive/iaep/attachments/20110216/ff6921ab/attachment.html>