Fedora 18 features that could affect xo-1

[John Gilmore]

> 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.

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.

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)?

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.

	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.