Fedora 18 features that could affect xo-1

[Walter Bender]

On Sat, Jun 23, 2012 at 3:32 AM, John Gilmore <gnu at toad.com> wrote:
>> The outcome of our discussion was that we don't want this size
>> increase, not on any of our platforms. But actually we see it as a
>> significant downside for all small systems, not just ours. The wiki
>> page mentions 43mb growth - that would be really painful.
>
> And foolish me thought a few years ago that with a million+ machines
> in the field, under relatively common management, that there would
> be time & effort allocated to make those old machines run even more
> efficient software over time -- running faster, using less power,
> and taking less space.

I cannot speak directly for OLPC, but there are several assumptions
you made that are not true, relatively common management being one of
them. The deployments call the shots and they are very diverse in
their management (or lack thereof). OLPC's ability to get them to
adopt new releases is very limited.

>
> And to add high leverage features to the old machines, like sharing a
> cache of their infrequently used files automatically among the network
> of machines, backstopped by a local or global server.  (We could put
> 43MB of constant debug info into 43 machines, one megabyte in each
> one, if we had a protocol for each machine to get the part it wants
> when it wants them.  And could do the same for the entire Wikipedia
> dump, or the entire library of ebooks, or thousands of free videos
> both educational and entertaining, from all the places in the world
> that are doing free-curriculum development).  Where are the audio chat
> programs that turn these laptops into phones for the kids, or let them
> hear the day's lessons from home when they're sick and can't get to
> school (when nearby Internet access is available)?  We have 95% of the
> deep infrastructure built, and nobody's bothering with the other 5%
> of polish and interface that makes those capabilities usable by the kids.

All of this assumes a level of network reliability that is not case in
most OLPC deployments.

>
> OLPC itself was likely to get sucked into new product development,
> paying less attention to the older platform, and indeed that did
> happen.  But what about the in-country education departments?  Do they
> simply not have the expertise (nor enough gifted high-school or
> college students to put in the human labor) to look through their
> software release with a finer comb than OLPC's always-rushed release
> teams could do?  To toss the irrelevant or useless, to recompile with
> optimization for space, to pare away configuration options, to
> actually investigate what happens in DRAM as you run low and improve
> on the sketchy kernel behavior?  Or even to stick a 1-gig SD card into
> the old laptops as $2 a midlife kicker (and improve the software so it
> can effectively use both the internal and external storage without
> requiring kids to do sysadmin)?

It is not that simple. Yes, there are many talented middle-school kids
who are doing serious development, in country, but for the most part,
these kids are working more closely with OLPC (and Sugar) than with
their own ministries of education, who tend to either be dismissive of
them or uninterested in making changes to their infrastructure (for
reasons that have little technical grounding).

>
> I really don't think it is the nature of software to always get
> bigger and slower.  I think a focused effort can pare it back.
> The country education departments would get clear benefit from such
> an effort (as well as giving their older kids a serious education
> in how modern operating systems work inside).  But no?  Clue me in,
> please.

I agree, although it takes great diligence to prevent bloat. It has
been a constant struggle even within the small world of OLPC/Sugar.
Here is a simple example (the name of the offending parties omitted):

Country XYZ was sold some proprietary software to support a reasonable
interesting educational initiative. That software litrally consumes
about 30% of the available user space on an XO 1.0. There is
equivalent Free Software that does the same thing (and more) and
consumes almost no resources, as it was written specifically for Sugar
by some community members. And yet, the government still distributes
the proprietary software. Why? I can only speculate, but having talked
to the pedagogists on the the project, they prefer the FOSS version.
But these are the sorts of issues that OLPC confronts in trying to
reduce bloat.

-walter

>
>        John
>
> PS: Many improvements made by an efficiency improvement team would be
> welcomed back into the upstream global Linux code base, too.  So it
> shouldn't be too hard to backstop the older kids with country teams
> and the country teams with global developers.
> _______________________________________________
> Devel mailing list
> Devel at lists.laptop.org
> http://lists.laptop.org/listinfo/devel



-- 
Walter Bender
Sugar Labs
http://www.sugarlabs.org