On Wed, Feb 16, 2011 at 6:42 PM, Chris Ball <span dir="ltr"><<a href="mailto:cjb@laptop.org">cjb@laptop.org</a>></span> wrote:<br><div class="gmail_quote"><blockquote class="gmail_quote" style="margin:0 0 0 .8ex;border-left:1px #ccc solid;padding-left:1ex;">
Thanks for the proposal, lots of combustible material here. :)<br></blockquote><div><br></div><div>I was hoping "ask interesting questions", as Martin says. </div><blockquote class="gmail_quote" style="margin:0 0 0 .8ex;border-left:1px #ccc solid;padding-left:1ex;">
I wouldn't be very excited about just porting Sugar activities to a<br>
stock Android base. I think our goals for Sugar are mainly to build<br>
educational software that:<br>
<br>
* can be appropriated -- translated, modified, discussed.<br>
* encourages creation rather than mere consumption of content.<br>
* encourages joint collaboration and sharing.<br>
<br>
I don't think stock Android apps can do these things well, so I don't<br>
think we're advancing our goals by creating stock Android apps.</blockquote><div><br></div><div>If Android apps to date have not accomplished this, that just means there's an opportunity!</div><div>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*.</div>
<div><br></div><div>I don't think these things are impossible. I think they haven't been done.</div><div> </div><blockquote class="gmail_quote" style="margin:0 0 0 .8ex;border-left:1px #ccc solid;padding-left:1ex;">
So, we'd have to be modifying the Android base OS, as you suggest.</blockquote><blockquote class="gmail_quote" style="margin:0 0 0 .8ex;border-left:1px #ccc solid;padding-left:1ex;">
I think this idea would make much more sense for OLPC than for Sugar<br>
Labs -- it's fine for OLPC to go hacking around in Android and create<br>
a code editor, and Journal and Collaboration services and so on, but it<br>
would be really hard to get anyone on a non-XO to be able to run them<br>
because Android is so fragmented. Each hardware vendor has their own<br>
Android build (which they aren't obliged to provide source for!), and<br>
most vendors ship devices root-locked to most users. How would Sugar<br>
Labs be proposing that owners of Android devices actually *run* our<br>
patched Android OS, if we don't even have the vendor's source to patch?<br></blockquote><div><br></div><div>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!</div>
<div> </div><div>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.</div>
<div><br></div><div>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?</div>
<div><br></div><blockquote class="gmail_quote" style="margin:0 0 0 .8ex;border-left:1px #ccc solid;padding-left:1ex;">Have you got any ideas on the above? Again, I'm not disagreeing that<br>
someone *could* make a Sugar-like environment by modifying Android,<br>
just that it doesn't seem like Sugar Labs is the right group to be<br>
interested in doing that, because it would be so hard to actually ship<br>
the result without control over a hardware platform. SL would go from<br>
producing software that can run on most machines to producing software<br>
that needs to be hand-tailored for each device.<br></blockquote><div><br></div><div>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.</div>
<div> </div><blockquote class="gmail_quote" style="margin:0 0 0 .8ex;border-left:1px #ccc solid;padding-left:1ex;">How about ChromeOS instead, then? Rumor is it was too slow to get<br>
going, and is either going to be canceled or just merged with Android:<br></blockquote><div><br></div><div>The link you posted is just a wild guess.</div><div><br></div><div>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.</div>
<div><br></div><div>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.</div>
<div> --scott</div><div><br></div></div>-- <br> ( <a href="http://cscott.net/">http://cscott.net/</a> )<br>