[IAEP] XO Special interest group at Sugar Labs
danceswithcars at gmail.com
Thu Sep 24 06:45:17 EDT 2009
I'm not sure about the hardware issues
mentioned below, as new to some of these lists,
but if there is an installed base of XO-1 computers
with special hardware like the touchpad
with 2 extra areas that were never implemented,
why not develop applications for those,
even if the XO-1.5 and XO-2 plans don't
What are you going to tell the kids
with XO-1s when the XO-1.5 come out?
What is the consolation prize?
Knowing more about it, and
being further up the learning curve?
Also, the battery issues will get worse,
as the hardware gets older, so testing
and determining when need new battery,
as a computer without power isn't much
Repairing hardware gets more crucial
as machines get older.
Being more inventive with what you have
instead of this is the shiny new machine,
so going deeper into the system,
maybe programming instead of just
using. Or more time with the learning
Even as a ebook reader, getting new
content, creating new content,
maybe more translating content?
I still think flossmanuals.net
needs indexing and other layout stuff,
under the hood, or however parallel,
LyX makes some assumptions,
and does some of that but not
the wiki and social stuff up top,
so [La]TeX classes and styles might be
a good contribution, finding
objavi and booki source code,
The requirements for testing a new build
is some extra XO-n hardware for testing,
and a high speed connection, if giving
new .isos builds out to the world,
or access to some place that would,
plus the time and knowledge to
make the changes, find bugs,
report them, etc.
And if 'It's An Eduction Project"
are we teaching self reliance
and how to do builds, make your
own constructionist style or
whatever teaching paradigm fits
the locals? Or forcing dependence
My $.02 USD - costs of ownership/
&& giving back.
On Tue, Sep 22, 2009 at 12:33 PM, Yioryos Asprobounitis
<mavrothal at yahoo.com> wrote:
> Now, that's an excellent idea!
> However, the crucial thing before any extensive building/testing starts is to address some major issues that would stop most people from using/testing F11/Sugar.84+. Namely the Xorg geode video driver, the camera and the battery monitor. These will primarily need developers.
> Having these components in place then a daily build bug fixing/reporting system would be more valuable since more people may be willing to give it a try, identifying the "minor" issues that may eventually allow a deployment-quality release.
> If this is going to be an OLPC, Fedora or SL project, I think is irrelevant. XO-1 is an EOL machine that runs an OS/UI developed by "some other" organization. Is literally orphan (besides these limited efforts) so any "adopter" should be welcome. Whoever sets it up should be good to go. With almost a million users is the biggest educational linux/sugar implementation and worths every attention.
> --- On Mon, 9/21/09, David Farning <dfarning at sugarlabs.org> wrote:
>> From: David Farning <dfarning at sugarlabs.org>
>> Subject: Re: XO Special interest group at Sugar Labs
>> To: fedora-olpc-list at redhat.com
>> Cc: "iaep" <iaep at lists.sugarlabs.org>
>> Date: Monday, September 21, 2009, 7:36 PM
>> On Mon, Sep 21, 2009 at 3:41 PM,
>> Peter Robinson <pbrobinson at gmail.com>
>> > Hi David,
>> > On Mon, Sep 21, 2009 at 7:48 PM, David Farning <dfarning at sugarlabs.org>
>> >> For the past several months the OLPC/Sugar Labs
>> ecosystem has been
>> >> getting requests to provide releases of more
>> recent versions of Sugar
>> >> on the XO.
>> >> The leading effort in this direction seems to be
>> the F11-XO1 project.
>> >> I would like to like to invite F11-XO1 to become
>> part of the XO SIG.
>> >> I have been trying to articulate the project goals
>> and gather momentum
>> >> across several groups.
>> >> 1. OLPC as a downstream.
>> >> 2. Sugar Labs as a focus point.
>> >> 3. Various ecosystem leaders to do pilots with
>> current versions of Sugar on XOs.
>> >> 4. Various testers to provide user level testing.
>> >> The goal of this groups is not to _fragment_ the
>> existing efforts.
>> >> The goal is bring the various efforts together to
>> form a critical mass
>> >> to help pull this propel forward.
>> > As far as I'm aware there is no F11-XO1 project, I'm
>> aware of a couple
>> > of different projects to get the latest Sugar releases
>> on the XO.
>> > - The SoaS on XO which is being run my Martin Dengler
>> in conjunction
>> > with SoaS and SL (that's where its all hosted).
>> > - The OLPC project to get Fedora 11 on both the XO-1.5
>> and XO-1 which
>> > is being handled by Steven M. Parrish (and Daniel
>> Drake / Chris Ball)
>> This confusion is part of what I am hoping to clear up by
>> create a
>> single clearly defined project.
>> I have heard back from many of the people working on the
>> projects. the work flow seems to be:
>> 1. Sugar development team creates platform.
>> 2. Fedora packagers package Sugar... and everything else
>> required to
>> make a disto.
>> 3a. SoaS takes packages and turns them into a Soas image.
>> 3b. Soas is getting pretty well test via test days and
>> such as the GPA.
>> 4a. Steven take the Fedora packages adds the XO specific
>> bit and turns
>> them into xo builds.
>> 4b. limited testing for xo builds.
>> Because of time restrictions, the F11 on XO effort seems to
>> reactive. They take the output from cjb and the
>> fedora packages and
>> create builds. I believe that the XO SIG could help
>> generate interest
>> and attract more developers and testers to the project.
>> > Both projects are cross pollinated and use components
>> of work done by
>> > both as well as myself and other Fedora upstream
>> people. I don't
>> > believe there's much difference between them as where
>> possible I
>> > believe most stuff is pushed upsteam. There is no
>> current Fedora based
>> > project working on this directly due to the down
>> stream projects.
>> > I have my own build that I use but that isn't
>> generally published and
>> > is mostly to test core fedora for dependency bloat and
>> Would it be useful if we started by combining your work and
>> into an automatic build system. This could help
>> identify breakages.
>> Then we could create a release cycle of alpha and beta and
>> By creating the daily builds and widely broadcasting the
>> releases, we can engage a larger community of testers.
>> Fedora-olpc-list mailing list
>> Fedora-olpc-list at redhat.com
> Fedora-olpc-list mailing list
> Fedora-olpc-list at redhat.com
leave the wolves behind ;-)
More information about the IAEP