Re: [Server-devel] [UKids] Lightning kills underground Ethernet too; PoE wiring/voltages non-trivial!

2016-01-12 Thread John Gilmore
> Would a PVC pipe protect an ethernet cable that ran between buildings too?

No. PVC pipe won't protect your power cables either, except from
mechanical stresses like a tree limb hitting it.  If the building on
either end of the power cable gets hit by lightning, the lightning
will be conducted to the other building.

The classic electrical code in the US requires "electrical conduit"
rather than PVC.  Conduit is thin walled steel pipe with special
(cheap) connectors between segments.  It is not structurally strong --
you can bend it by using a short lever, for example, and cut it easily
with a hacksaw -- but when installed properly, it provides a complete
grounded path from one end of the conduit to the other end.  This
grounded path is a better conductor for things like lightning (or
short-circuits caused by bare bits of wire, etc), which makes the
whole circuit safer for the nearby humans -- and protects it from
mechanical stresses like a PVC pipe would.

> Sounds like if not, an ethernet switch (to prevent electrical links, like
> Sam suggests) or a wireless repeater (to eliminate the need for cables of
> any kind) are necessary.

If a cat5 or cat6 Ethernet cable is carrying a lightning strike, it
will destroy pretty much any Ethernet switch that it's plugged into.
The best ethernet switches (for this purpose) *might not* conduct that
strike into all the other Ethernet cables plugged into the switch.
But the average cheap one almost certainly will result in everything
that's plugged into any Ethernet cable getting destroyed.  I am not
sure how you would find a "best" switch for that purpose.

What was suggested for between-building use was not just an "ethernet
switch", but a fiber-optic Ethernet link.  Gigabit ethernet switches
that have one or two slots for a fiber interface are available.  You
plug an "SFP transceiver" into one of those slots, plug a fiber into
the SFP, run the fiber to the other building, put a second SFP there,
plug that into a second fiber-enabled switch, and you have a working
Ethernet connection.  The beauty of this for lightning is that there
is NO metal connection between the buildings -- the fiber cable is
plastic and glass, containing no wires at all, and the gigabit data is
carried as pulses of infrared light traveling through the glass fiber.
The plastic and glass will not conduct electricity or lightning.
Another advantage is that you can easily get a fiber to carry gigabit
data over 40 to 80 *kilometers*, while a cat5 ethernet cable only
works for perhaps 100 meters.

The cheapest of those fiber-enabled switches still cost about US$300
the last time I looked.  The GBICs cost about $50 to $100 at best.
The fiber cable itself is finicky and ideally you would buy it from a
supplier who will cut it to the right length and put the right
connectors on it for you (because doing this in the field requires
custom equipment, trained personnel, and is slightly hazardous with
tiny bits of glass fiber that can get under your skin).  Fiber cables
can't be bent as much as cat5 cables (or the glass fibers inside
break) so you have to take some care installing them.  Unfortunately
there are no standards for fiber connectors, or rather there are
dozens, so you'd have to pick one connector type (e.g. "LC"
connectors) and get the cable and the SFP that have those connectors.
There are half a dozen 1000Base-something standards for fiber
ethernet, too, for different kinds of fiber cables and different
distances, so you have to specify which standard your SFP's will use.
You may need a pair of cheap attenuators too, if your fiber run is
short (to reduce the intensity of the light in the fiber).  Compared
to just getting cat5e or cat6 cables and plugging them into a cheap
and standard switch, fiber is much more complicated and expensive.

If there are power cables running between the two buildings, those
power cables will conduct the lightning anyway, so there is zero
reason to use the expense and complication of a fiber optic ethernet.
The thing that fiber ethernet is really good for is connecting places
that are kilometers apart, with a super high speed (gigabit or faster)

> > If you are going to use any cable outdoors or where it may be exposed to
> > the elements, getting cable rated for the desired outdoor use may be as
> > important as its speed rating.  You don't want the cables getting water in
> > them, causing interesting shorts and ground currents.

UV-resistant cables are needed outdoors (the outer cable plastic
doesn't break down when exposed to ultraviolet light from the sun for
a year).

> > Cables routed inside of walls/vents/etc. also often have to be one of a
> > few special types for fire safety and other reasons.

These are called "plenum rated".  Their special property is that when
they burn (e.g. when the building catches fire), they don'

Re: External hard disk testing for use with IIAB (internet in a Box) on XO based XSCE servers

2013-06-24 Thread John Gilmore
 For important systems, I think a USB hard drive will be a better
 choice than an empty enclosure.
 They are also often cheaper than a new empty enclosure and a new hard

Indeed, buying a brand-name external USB2/3 hard drive, which is
invariably implemented as a SATA drive in an enclosure, is often
cheaper these days than buying the exact same drive as a SATA drive.
Check prices at if they sell in your country.

The Internet Archive, with 10+ Petabytes of spinning drives, buys
hundreds of drives at a time, and these days they usually have
hundreds of discarded enclosures and power supplies to recycle to
local hackers. :-/

Devel mailing list

Re: [Server-devel] External hard disk testing for use with IIAB (internet in a Box) on XO based XSCE servers

2013-06-24 Thread John Gilmore
 For important systems, I think a USB hard drive will be a better
 choice than an empty enclosure.
 They are also often cheaper than a new empty enclosure and a new hard

Indeed, buying a brand-name external USB2/3 hard drive, which is
invariably implemented as a SATA drive in an enclosure, is often
cheaper these days than buying the exact same drive as a SATA drive.
Check prices at if they sell in your country.

The Internet Archive, with 10+ Petabytes of spinning drives, buys
hundreds of drives at a time, and these days they usually have
hundreds of discarded enclosures and power supplies to recycle to
local hackers. :-/

Server-devel mailing list

Re: minimizing footprint

2013-03-26 Thread John Gilmore
 We are talking of end users systems, how many kids will add a cron task?

I was more concerned with other Fedora packages that insert cron jobs
when they are installed.  But if Fedora gets the dependencies right,
rpm would install and run cron at the same time the package that needs
cron is installed, so that's not an issue (unless the package
dependencies are set to assume that cron is always part of the base

The packages you're proposing to change are OLPC-specific packages
anyway, so the changes won't mess up any other Fedora installs.

I do see the point of removing unneeded daemons in every
memory-constrained laptop, and this does look like low hanging fruit.
On the Ubuntu system I happen to be typing on, 'cat /proc//status'
shows cron taking 300k of resident RAM and 2.7Mb of virtual memory at
its peak (and I have a place to page out to, which most XO's don't).
The XO system will certainly be more responsive with another 2MB of
memory available for general paging; its worst performance bottleneck
was lack of DRAM when I last looked, and that situation has probably
gotten worse as the system grew.

My thought was that systemd probably wouldn't get much bigger if it
got a parser for cron files.  But your proposed change is less work,
though it only fixes the issue for XO's, not for other
memory-constrained systems.

Devel mailing list

Re: Removing cron in 13.2

2013-03-23 Thread John Gilmore
 As a simple step in reducing base system footprint a little, I'm
 thinking of removing cron in 13.2.0.
 The 2 current users of cron (ds-backup and olpc-update-query) will be
 moved to systemd timer units which have equivalent functionality.

The classic Unix interface for starting processes periodically is
cron; all other packages that need that feature use it, ever since
Unix V7 or so in the 1970s.  If systemd has reimplemented the
equivalent, can you fix systemd to implement the cron interface to
that feature?  That looks like the clean way to shrink the system a

Devel mailing list

Re: [support-gang] Customization Sticks fails on 13.1.0 12.1.0 for XO-1

2013-03-12 Thread John Gilmore
Wad said:
 Please don't redistribute secure laptops --- OLPC's policy since
 early 2009 has been to deprecate the security system.  The
 exceptions have been deployments large enough to have dedicated
 support staff capable of handling their own keys.

Richard said:
 That policy is fine but perhaps needs to be more visible to the people 
 going into areas where secure laptops were distributed ...

Can an upcoming signed software release automatically disable the
anti-owner security system on old lockdown laptops?  Any new, signed
Forth release could look for the original OLPC signing keys and
disable security on laptops that depend on those, avoiding changing
any laptop that has custom signing keys.

Including this code in each new, OLPC-signed release, would tend to
eliminate the problem.


Devel mailing list

Re: [support-gang] gray dots forever: when 12.1.0 13.1.0 never fully boot (XO-1 especially? 11.3.1 too)

2013-03-12 Thread John Gilmore
(1)  If powerd fails when the clock is set to before the Unix epoch,
powerd is buggy, and this bug should be ticketed and fixed.

That bug is independent of the situation that causes the clock to get
set that way (which may well be another bug in another component, which
would deserve another ticket).

(2) Perhaps the reason there is trouble with reflashing some laptops
whose clocks are bad is that the signature on the new release has a
limited validity time period, and the security system is rejecting the
new release because the bad clock looks like it's outside the validity

Devel mailing list

Fedora-18 ARM release: support for OLPC hardware?

2013-01-21 Thread John Gilmore
I'm way outside the OLPC  Fedora development processes nowadays, which
is why I'm asking what may be a dumb question.

The Fedora 18 release is finally out for x86 and x64.  There's a beta
for ARM that supports half a dozen ARM systems.  Oddly, in my mind,
OLPC is not one of them.  It's odd because there are probably more
OLPC systems running Fedora than any other ARM hardware.  In F17, the
ARM release went to GA - General Availability for those half dozen
ARM boards, again not for OLPC hardware.  See:

Is there a good reason that the Fedora secondary architecture release
process never builds releases for the OLPC?  Or is this omission just an
artifact of the history of how OLPC releases have been cut?

Presumably the official Fedora release for OLPC ARM hardware could
relatively simply use the Gnome user interface.  Or even include the
version of Sugar that's packaged to live in (x86) Fedora releases.
Due to differing release schedules, it would not match the Official OLPC
software releases, but that has always been true of Fedora releases,
even on x86 based OLPCs.


Devel mailing list

Re: Will the XO-4 need nonfree firmware

2012-12-04 Thread John Gilmore
 In that case, this machine without that card might be an option
 for people who want laptops they can use in freedom.
 They would need to get an external USB network device.

Yes, or they could even get a different SDIO network device, if they
can find one that's free and that has a compatible antenna connector.

 If someone sells them without the card (NOT with the card separately
 packaged), under another name, and if the cards are not easy to obtain,
 that could be a product we could endorse.

I don't think anybody plans to sell XO-4's anyway.  They're for
whole countries to buy in huge orders.  (I'm way out of the loop
on stuff like that -- maybe things have changed.)

If you personally happen to want one for development, you could get
one through the OLPC developers program.  But there probably won't be
anybody selling them in stores, or over the web.

FSF could advocate that countries should get them only with free
SDIO network cards, and some countries might even listen.  But to do
that effectively, FSF would have to find at least one free network
card that they could actually order and use; test it with the device
to make sure it integrates properly; etc.  I doubt that a country's
education department would buy thousands of XO-4s that depend for
their connectivity on dangling USB network sticks that kids are likely
to lose or break.


PS: If you want to spend time on the freedom of OLPC products, first
get the FSF staff to enforce the GPL on OLPCs.  Major OLPC customer
countries are still providing hundreds of thousands of laptops full of
GPLv3 binary software to kids who can't examine, replace, or get the
matching source for that software.  These laptops are locked down with
Secure Boot, with a remote disable switch (time-limited leases), and
also shipped with root access disabled, so the owner can't even do
simple software edits or upgrades.
Devel mailing list

Re: OwNet

2012-11-02 Thread John Gilmore
 implemented using Microsoft technologies. However=2C this year we are goin=
 g to reimplement it using cross-platform technologies so that it can also b=
 e used under Linux.

Have you heard of the Squid caching proxy for the Web?  Lots of people
at the slow end of an Internet connection use it, including major
ISPs.  It's already written, portable, and debugged.  See:

I also see a Sri Lankan effort called Dalesa, that works in both
Windows and Linux:

Devel mailing list

Re: scamometry

2012-09-18 Thread John Gilmore
 How can an HTML5 app be closed source ?  It may not
 be free, and you may not be able to redistribute it, but it is HTML...

It's a scam.  It is built upon the open source library JSXGraph
(which is LGPL: ), but
sketchometry itself is proprietary (only free to use: ).  They do not mention this fact clearly
anywhere - they're trying to hide its proprietary nature while
mentioning open source in their press release
).  Of course, since they don't let you download it, they can shut off
your access to it on their website at any time, or change the terms
under which they'd offer it.

(Yes, you can snarf a copy of the obfuscated JavaScript, but it won't
be maintainable.  And you can't legally make copies of it, you'd be
violating their license.)

Restrictively, they support storing your drawings in a couple of
varied cloud services -- but not on your own computer.  Its German
authors from the University of Bayreuth don't seem to share OLPC's
mindset and strategies.  I suggest ignoring it...


PS:  It didn't run at all in my Ubuntu Firefox web browser, 
even after I turned on NoScript and RequestPolicy for all
the sites it wanted to download scripts from.
Devel mailing list

Re: OLPC build creation failed

2012-09-13 Thread John Gilmore
 On Thu, Sep 13, 2012 at 3:57 PM, Jose Prous wrote:
  Yes it's a x86 machine, I guess that is the problem. Thanks.
 Glad that we found the reason. We should add an explicit check in OOB
 that gives you a more useful error msg.

Instead, you should fix OOB so it works to cross-compile.  We at
Cygnus spent years making the GNU tools able to cross-compile, and it
all works.  We built a big test infrastructure and made sure that the
resulting executables were bit-for-bit identical no matter what the
build host was.  It's just your builder script that's unable to
do it -- and that is under your control.

Devel mailing list

Re: [Sugar-devel] [DESIGN] Proposal: Contol-Panel packaging

2012-08-10 Thread John Gilmore
  We have no control over the network environment what so ever and need to
  work within the confines of what is available.
 This is our primary constraint: we cannot install servers or proxies.
 Schools in remote areas have latent/slow/expensive Internet links.
 You'd think that a caching proxy is common sense. Unfortunately not :(
 Furthermore, the newer wireless networks treat every client as
 potentially hostile and hence prevent them from communicating with
 each other. This also means that no collaboration can take place.

You *are* sending them XO's or at least XO software loads, yes?

Fix the XO software with a simple control panel checkbox to make it a
cacheing proxy access point.

Tell them to configure one of the XOs as a cacheing proxy, stick it in
a corner on permanent power with its ears up, and have the rest
connect to that one, not to the provided base station.  They'll be
one radio hop further away from the Internet (unless you send 'em a
USB Ethernet dongle for that XO), but they'll be able to collaborate
and share, and get much faster access to things that more than one of
them need.

If there isn't enough storage on those XOs to make a decent cache,
send 'em a 16GB USB stick or a similar SD card too.

Devel mailing list

Re: [Sugar-devel] [DESIGN] Proposal: Contol-Panel packaging

2012-08-01 Thread John Gilmore
 We use yum to provide automatic updates to our XOs in the field, and
 we must be mindful that large RPMs can have an impact on the school's
 Internet connection. If 400 XOs need to download a ~800KB Sugar RPM,
 that's 320MB being downloaded, potentially at the same time.

Isn't there a cacheing yum proxy?  Yes, it turns out:

[Beware the install advice in that page.  It tells you to set gpgcheck=0
to install their packages -- rather than telling you where to get a
public key -- and it neglects to tell you to restore gpgcheck=1 after
you install pkg-cacher.]

Supposedly apt-cache can do it as well, though I don't see a step-by-step

Once one of your local machines is running the proxy, then you point
each of the XOs to the proxy as well as to the standard RPM repos.  I
think yum is smart enough to download it from the first repo that
offers it, which means that if your cache is responding, it'll
download packages from there.  (Warning: I haven't done this myself.)

Devel mailing list

Re: Python bindings based on Phonegap?

2012-06-26 Thread John Gilmore
 Does anyone know if there are Python bindings based off the Phonegap
 API, with similar method calls, etc.?
 I'm developing an HTML5/Javascript activity that I would like to
 eventually port to Android and other mobile platforms. Having a set of
 Phonegap-like Python bindings for Sugar would help considerably.

Sounds like doing a native Linux port of Phonegap would be a useful
addition, with both X11 and Sugar window interfaces.  Then Phonegap
apps could, perhaps, work on both classic Linux machines and on OLPCs.

Hmm, it looks to me like Phonegap isn't a write once, run everywhere
kind of thing.  According to the doc, every platform your app targets
needs tweaks in the app, and/or needs a development tools platform for
that target.  It's more like classic Unix portability: how to build
your app so that you can copy the source to 7 different build
environments and get it to build and run on each one.

Devel mailing list

Re: Fedora 18 features that could affect xo-1

2012-06-23 Thread 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,


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

Re: On XO-1.5 with 11.3.0/11.3.1 -- hang during shutdown?

2012-06-16 Thread John Gilmore
I doubt that this issue is your problem.  But in response to one remark:

  On the theory that these writes may
 be stalling due to the block number, (and we haven't seen any evidence
 yet of this), you can test for that by repeating the writes...

There *is* evidence that accesses to some block numbers in MLC flash
chips are much faster or slower than others (like 5x slower).  They
seem to be designed with fast blocks and slow blocks, though this
is undocumented.  There is no interface for telling the software
which is which (except by actual measurement of the responsiveness of
the chip -- and in microSD cards, accesses are mediated by a Flash
Translation Layer of unknown characteristics).  See:

  Characterizing Flash Memory: Anomalies, Observations, and Applications
  Laura Grupp, Adrian Caulfield, Joel Coburn, Steven Swanson, Eitan Yaakobi and 
Paul Siegel
  UCSD Tech Report CS2009-0946
  August 19, 2009

Unfortunately the amazing people at UCSD fail to put up their archival
tech reports in readily accessible PDFs.  (It seems to be some sort of
half-assed DRM system, since they yammer about copyrights on the same
page.)  They do have a mangled (OCR'd!) abstract here:

and a mangled 18MB PostScript version available here:

The Wayback Machine failed to capture it while it was there.  But I
got the PDF from them when they had published it in 2009.  I have put
up the 1.5MB PDF temporarily here for research purposes:

with the slides here:


Devel mailing list

Re: Switching to randomly generated hostnames

2012-05-01 Thread John Gilmore
 Currently, XO hostnames are set on first boot in the following format:
 Where A, B and C are the last 3 bytes of the MAC address expressed in hex.

 In Nicaragua we are seeing cases where XOs have no hostname set, both
 on XO-1 and XO-1.5. On XO-1 this is presumably because libertas
 usb8388 init was never 100% reliable, and on XO-1.5 its presumably
 because the wireless card was DOA but was replaced after first boot.

Why would we need to get it from the wireless card?  Isn't the
laptop's MAC address stored in the manufacturing data in motherboard

But if for some reason you can't use that...

 I propose we move to generating hostnames in the same format as before
 (xo-A-B-C), but with A, B and C assigned as random hex digits on first
 (If people are worried about collisions, maybe we add a D digit.)

Existing hostnames have three bytes of info (e.g. xo-12-3a-49).  
Particularly if you're going to generate them at random rather than 
by prior assignment like MACs, why reduce the amount of unique
information (e.g. xo-1-a-4 or xo-1-a-4-d)?  Producing three random
bytes of info for the hostname, rather than 1.5 or 2 bytes, would
reduce the chance of collisions; and has the advantage of not
changing either the size or format of the hostnames, in case
anything else is depending on it.

Devel mailing list

AFR: Sony's 2-screen Tablet P: a good idea gone wrong

2012-04-02 Thread John Gilmore
[Summary: 2-screen laptops need fairly deep software support because 2
 screens don't look like 1 screen.  I excerpted freely below; see
the link for the entire story. --gnu]

Sony's tablet a good idea gone wrong
PUBLISHED: 30 Mar 2012

The best thing that can be said about Sony's new $729 Tablet P is that
it means well.

The central idea that must have led to the construction of the Tablet
P -- that iPads are too large -- is pretty sound. iPads are too large,
at least for a lot of users (the staff here at the Digital Life Labs
included), and at least for a lot of applications.

So, yes, Sony was trying to solve a genuine problem when it came up
with the Tablet P, a tablet that folds in half so you can slip it into
your pocket or purse, that's light enough to read e-books on
for hours without your hand cramping, and small enough that you can
use it as a camera without looking like a total tool.

The trouble was, they couldn't make it happen, not with
today's technology. To have a tablet fold in two, you either need one
screen that folds in two, or you need two screens with absolutely no
bezel, so that one screen blends seamlessly with the other screen when
they're placed side by side. Neither of those technologies are
available today, so all Sony's engineers could come up with was two
screens, each with a modest 4 mm bezel that, when placed next to the
other bezel, creates a whopping great 9 mm-wide black bar right in the
middle of the display. (The other millimetre is the gap between the
displays, which can be quite irritating if there's light behind the
display, shining through.)

Now, that wouldn't be completely fatal if the Tablet P were running an
operating system that knew how to handle two screens with a black bar
and a sliver of light in the middle of them. But the Tablet P is
running Android, and neither Android nor most Android apps have a clue
how to use the dual display.

Some apps on the Tablet P, chiefly the ones Sony has rewritten
specifically for the device, work quite well. The email app, for
instance, uses one screen as a virtual keyboard, and the other screen
as a display, when you're creating emails. When you're viewing emails,
one screen is used to list the items in the inbox, and the other
screen is used to preview the highlighted item.

But trouble arises when you use apps other than the ones written to
cope with the black bar. Most apps will just curl up into a ball and
display only on one of the two screens. Neither of those screens is
very large, so you end up with apps displaying little bigger than they
would on a mobile phone. Worse yet, they're both very long and narrow,
far more so than many apps seem able to cope with, and as a result
many apps won't even fully utilise the one small screen they're
on. Amazon's Kindle app, for instance, an app so well written that it
can usually cope with any screen you throw at it, uses only 83 per
cent of one screen, and zero per cent of the other. Almost 60 per cent
of the Tablet P's display is left blank.

It's such a pity, because a tablet that folds in two is such a good
idea.  Perhaps the best thing that can be said about the Tablet P is
not that it means well, but that it's simply ahead of its time.
Devel mailing list

idea: set a niceness value under which a process won't awaken suspended CPU

2012-03-02 Thread John Gilmore
Here's a power-saving idea that's been marinating since 2007 (in an
obscure corner of my mail queue).  When I reviewed it today I didn't
see anything too wrong with it.


To: gnu
Subject: OLPC idea: set a niceness value under which a process won't awaken 
suspended CPU
Date: Wed, 24 Oct 2007 02:12:01 -0700
From: John Gilmore

An easy lever for CPU consumption management (power mgmt) would be to
define a set of user processes that won't be scheduled in a
power-suspended system.  They won't wake the CPU even if their timer
goes off, their packet arrives, or their fairy godmother calls.  But
if something else wakes the CPU, and it's going to stay running a bit
while some higher priority process is waiting for flash or packets or
something, these processes can run in the background.

My idea is to tie this to nice.  So if you nice -20, it puts you into
this range.  Say everything below -15, which lets you set a few priorities
among the low priority background stuff.

So if you nice things all the way down, they run when the CPU is powered,
in the cracks when there's nothing else to do, but they don't cause the CPU
to wake up to service them if nothing else is going on.

For example, code that polls and updates the battery status once a
minute in HAL.  Or a system activity monitor that shows CPU state
graphs or how many MHz we're running.  Or an RSS feed reader.  Or the
thing that clears out Mozilla's cache.  Or the incremental backup
daemon that copies the machine's state to the school server.  (If that
ran with scavenged electricity, cool!  It can raise its priority once
a day or so, to make sure that a backup gets done one way or another.)

The GUI could have a way to throw a process into this state or out of it.
E.g. push your mail reader there, polling every once in a while for email,


--- End of Forwarded Message

Devel mailing list

Re: Impacts of disabling Automatic Power Management

2012-02-11 Thread John Gilmore
 waking up on all multicast frames, apparently even ones that wouldn't
 normally be sent from the hardware to the driver

There's a flag for that, ifconfig wlan0 allmulti, which should NOT
be set.  That configuration tells the hardware that we want to receive
all multicasts, not just the ones we have software listening for.  (It
shows up in capital letters, in the flags line of ifconfig wlan0 if

If that's off, waking on all multicasts is pretty unlikely.  Multicast
reception hardware (for every Ethernet as well as every WiFi) is
designed so that it doesn't see packets unless they match the address
filter, which the Linux drivers already know how to set.  This is easy
to test.  Run ip maddr, it will tell you all the addresses that the
driver is listening for, on each interface.  It lists link-level (MAC)
address, IPv4 addresses, and IPv6 addresses.

To test it, let the laptop auto-suspend.  Then from another node on
the same network (AP or adhoc or ethernet), ping a multicast address
that the node should NOT wake up for, e.g. the all routers on this
link address in IPv6 (ff02::2):

  ping6 -I wlan0 ff02::2

This should NOT wake up the autosuspended laptop.  You can try pinging
various other multicast addresses, e.g. ff02::f, or ipv4's

After confirming that, try sending a multicast that SHOULD wake up the
laptop.  You have a list of them from the ip maddr output.  An easy
one that's always there is the all nodes on this link multicast
address in IPv6 (ff02::1):

  ping6 -I wlan0 ff02::1

This should wake up the laptop (and get you a ping response sent back
to the second node).  However, old bugs like may prevent the ping response
(packets that wake the laptop from suspend are often lost).

If we're still dropping some packets that wake the laptop from suspend,
then that could be one of the problems with collaboration.  Four years
ago, I commented:

  Yes, the real test will be how it integrates in the whole system:
  With the presence service running, with ethtool -s msh0 wol uma,
  and with auto-suspend: Will we drop the unicast or multicast packet
  that wakes us up (#6528), or will it actually reach the application
  that's awaiting it?

  And, secondarily, can we stay suspended long enough to save power?
  Or will the application level multicast traffic be so constant that
  we always wake a few seconds after we suspend (in which case we need
  to fix the applications so they aren't so chatty)?

Devel mailing list

Re: Impacts of disabling Automatic Power Management

2012-02-11 Thread John Gilmore
 The first problem I see is that machines don't wake on ARP.
 Ultimately I believe we don't want our machines to wake on ARP, we
 really want firmware that can handle ARP and only wake when our
 address is ARP'd.  I don't know how unreasonable a request that is.

It's completely reasonable, and we've put together most or all of the
parts to get it working for IPv4.  See:

If we fix the wake-on-multicast problem then we'll fix IPv6 ARP as
well (it uses multicast for neighbor discovery packets that replace
the ARP protocol):

 Another problem appears to be lost wakup packets while collaborating.

 This should be able to be fixed by using an iptables queue.  If we
 queue collaboration traffic that isn't responded to, we can quick of a
 script when the queue gets X long that tries various methods to wakeup
 the machine on the other end.

We should fix the real problems, which are low-level, straightforward,
and easy to reproduce, rather than building crazy workarounds at
higher levels.

 Be smarter about how we track network traffic.  Other than just
 checking if there is network traffic, we should be tracking where this
 network traffic is from or to.

We shouldn't need to check whether there is network traffic when
desiring to suspend.  If no process has run in N milliseconds, the
kernel should autosuspend.  N should be tuned to avoid constantly
suspending and then immediately reawakening, e.g. between packets in
an active HTTP connection.


Devel mailing list

Re: Impacts of disabling Automatic Power Management

2012-02-10 Thread John Gilmore
On Sat, Feb 4, 2012 at 10:26 AM, Samuel Greenfeld wrote:
 Disabling suspend during collaboration was discussed a year ago, but as far
 as I know this has not made it into any 11.3.x build:

There are longstanding bugs from four to five years ago, all the way
back to the XO-1, that prevent collaboration from working when
aggressive power management (suspend) is enabled.  Most of those
never got fixed, as far as I know.  Lots of circumventions were
attempted.  Some bugs were closed despite not actually getting the
right fix implemented.  They're all still in trac.  E.g.: (closed because it still fails!)

Back then, we were barely able to do the bugfixes needed to get to
minimal power when suspending the XO-1 when you close the lid.  Making
exotic features like collaboration work was way beyond what the team
was able to do.  Perhaps now is different?

Devel mailing list

Re: RTC anti-rollback testing

2011-10-14 Thread John Gilmore
 I added the rt tag, but when I run command
 ok rtc-rollback? .
 the laptop powers off.
 Is it a normal behaviour?

It's normal for DRM to make your system do obscure, non-intuitive things.
Did nobody explain that to you when you asked for this?

Devel mailing list

Re: open datasheets

2011-09-19 Thread John Gilmore
 John touches upon a sore subject around OLPC here.   On both 1.5
 and 1.75, OLPC obtained assurances from the companies that the
 data sheets for the processor/companion chips/SoC would be
 publicly availably by the time the laptop reached production.
 In both cases, the companies lied to get the designs
 started and have no intention of ever releasing critical
 documentation outside of an NDA.
 As a company with extremely limited means, what is OLPC to do ?

Trying to do business with people who lie is a classic reason
for contract law.

Write a contract before you start, which permits YOU to release the
specific documents that you care about (which you have received under
NDA).  You clearly have them in-house.  If your contract with the
company permits YOU to post them, then no amount of later lying by the
company can prevent you from posting them when the laptop goes
into mass production.

If the company refuses to sign that contract, don't use their chip;
use someone else's -- BEFORE you spend the multiple million dollars.
Since you tend to like ARM these days, there seem to be about 20
ARM chip vendors around; ONE of them should be smart or stupid enough
to sign such a contract to get your business.

In what form were the existing assurances from the companies
provided?  In writing?  If they are, or could be interpreted as, part
of the contract negotiations or committments, then OLPC may already be
free to post these documents.  Or, more likely, to sue the companies
to force them to honor their contract.  (That's why a better
construction for future contracts is one that lets you release it
yourself, without needing a lawsuit.)

Devel mailing list

Re: hardware crypto

2011-09-17 Thread John Gilmore
  Is it worth looking at enabling the HW crypto devices for the various
  platforms? I have a Fit-PC that I use as a FW with a geode and the HW
  crypto is pretty good on that, the Via chip has one on the 1.5 and
  there's also some form of HW on the 1.75 too. last time I looked we
  weren't enabling them,
 We disabled it for XO-1.5 early in the development cycle because it
 caused kernel crashes. Could be reevaluated now, if someone tests it
 and tells us that it works then we could enable it again.

Last time I looked at the hardware crypto in XO-1 Geode, it was
designed by people who didn't consider any of the system or software
aspects.  Using the crypto hardware was actually slower than doing it
all in software, for 99% of use cases.  The one useful thing they
might have provided, that we couldn't do well in software already, was
a random number generator -- but they didn't.

The Via chip spec for XO-1.5 is still not available, despite OLPC's
suggestion that they wouldn't ship a processor without an open manual.

I haven't looked at the ARM chip in the XO-1.75. Is the spec even
available?  The Hardware Specification 1.75 page doesn't exist in the
wiki yet.

Devel mailing list

Re: 11.3.0 build 4 released, for *XO-1.75*, XO-1.5 and XO-1

2011-09-10 Thread John Gilmore
 a mess. I made the suggestion on adding an a/i to the build so it
 would be os4i.zd4 or os4a.zd4. 

You couldn't put the model number into the file?  Rather than
a cryptic a or i, how about 1, 1.5, or 1.75?  Teachers and kids
aren't going to know who designed the processor inside their laptop.
We'll be lucky if they DO know the model number, since it isn't
printed on the device.  (Perhaps inside the battery compartment?)


Devel mailing list

Re: Sad face

2011-09-10 Thread John Gilmore
  Uruguay replaces the OLPC key with theirs.   There is nothing we can
  do.  You must talk to Uruguay support.
 Ah, thanks.  I'll stop thinking about it then.

Don't stop thinking about it.  

OLPC always has the choice to stop making DRM-locked machines.  Your
next machine should not offer a DRM option.  I strongly suspect that
the countries would buy it even without that feature - and the kids
and teachers would be better off.


Devel mailing list

Re: License files - L10n

2011-08-16 Thread John Gilmore
The theory was to provide, in flash, the unofficial license
translations in the languages primarily used in deployments,
e.g. Spanish.  That way the kids can actually tell what rights they
have without having to (1) learn English, or (2) access a perhaps
nonexistent or very slow Internet connection.

Providing the English language license is a requirement of the
licenses themselves; if you ship the software, you must provide them.
Providing the unofficial translations is not a requirement of the
licenses.  But how can you teach kids the principles of free software
without them ever being able to read how they can apply those principles
in their own life with the software right in front of them?

(Indeed some of the deployments appear to have never read nor
understood the licenses -- or to just be corrupt -- since they violate
the TiVoization clause.  Having locally readable licenses may help fix
that, too.)

The license translations are tiny -- a couple of kbytes each -- so
flash space isn't a big issue.

   I'm just hoping
 to close a simple ticket here and this is the easiest and most correct
 solution I could devise.

Easiest, certainly.  Most correct, no.

Devel mailing list

Re: powerd-dbus network extension

2011-08-03 Thread John Gilmore
What kind of idle-suspend are we talking about here (and on what XO
hardware)?  Shouldn't a proper idle-suspend be resumed when the system
isn't idle any more, i.e. when a packet comes in or a timer expires in
NetworkManager?  Fixing that would eliminate having to build a
separate kludge for every time-sensitive protocol.

Devel mailing list

Re: Sugar Commander

2011-07-24 Thread John Gilmore
  I'm sorry, I don't mean to ruffle any feathers, but the flat journal
  is a really broken model when you stick in a USB stick with 2000+

The flat journal worked great on 8 floppies.  It was obsoleted
in 1982 or so.

The whole emphasis on the journal as filesystem interface was
another of those grand OLPC experiments.  Unfortunately, unlike the
mesh, its failure was not followed by junking it and replacing it with
what every other computer does -- what works.  This journalism
religion is also a major reason why kids can't read or edit the source
code of the OLPC -- because it isn't visible in a journal, and if it
was in there, it would be painful or impossible to find or organize.

 The new Unity 2D UI that Ubuntu defaults to makes the same decision,
 and it works well.

It works so well that I won't be using Ubuntu in the next release,
because they are forcing everyone to run Unity, I think on the theory
that if they force enough people to use it, some of them will fix all
the bugs and misfeatures in it.  Unfortunately for them, this is not
a market where they have any power to compel users; we'll just go

Devel mailing list

Re: XO-1 touchpad once more [Devel Digest, Vol 64, Issue 28]

2011-06-23 Thread John Gilmore
  Anyway to quantify touchpad use and behaivor in F9 builds?
 I don't know of any way that involves only the laptop or software.
 Quantifying use and behaviour would require a video camera on both the
 touchpad and the screen.  Or accurate reporting from both people who
 experience a problem and those who do not.  Self selected reporting from
 community enthusiasts isn't as reliable.

It might be possible for testers to tape a small mirror on their XO
camera (perhaps 1cm square), so it can see the touchpad.  Run a test
program in the background that records the video into a circular RAM
buffer, and saves a chunk of it whenever it sees the pointer jump.
Then go on doing what you usually do on the XO.  An engineer can later
look at those saved videos to see how many of the pointer jumps
happened without a corresponding finger motion.


Devel mailing list

Re: [IAEP] Turtles All The Way Out

2011-06-06 Thread John Gilmore
I had to think about this some before having a useful response.

 I cannot speak for every Sugar developer, but the approach I have tried to
 take with Turtle Art is a bit different than you are describing. The
 block-based programming environment is not meant to be a substitute for real
 tools; it is meant to be a place to get started; to learn that you can write
 and modify code; and to provide multiple motivations and launch pads for
 getting into the real thing. I've worked pretty hard to make the
 structured thing behind the view more approachable, and have provided
 multiple ways in and out: exporting your fluffy view into Logo that can be
 run in Brian Harvey's text-based Logo environment; direct, in-line
 extensions written in Python; the ability to create new blocks by importing
 Python; a plugin mechanism for making major interventions; and a refactoring
 of the underlying structures to make the code more approachable. (The source
 code is peppered with comments and examples of how to make modifications.)
 None of these interventions are intended to keep the kids programming in
 Turtle Art. They are all intended to get the kids started down the path of
 real programming. But I content that we need to engage them; let them
 discover that they can write code; and make changes; and that it is not
 something just for others but for everyone. 

Walter, this is a worthwhile approach.

But it was all invisible from an OLPC user's point of view (i.e. a
child's).  All they get is a GUI in which they can hook blocks
together and see graphics.

Even finding the library of fun looking pre-existing designs was hard
(it's hiding behind a bizarre looking icon that you can't even see
until you go to a different tab in the Frame than the default one).
If you show a kid how to find one of those designs, they get the idea
of TurtleArt, and can modify them to see how the design changes.
Until they see a complete, working design in 10 blocks including a
loop, TurtleArt is a morass where new users can drag things around but
it doesn't do anything fun.

(Note I'm working from memory of a several-year-old TurtleArt.  Perhaps
it's better now.)

(Also, it's hard to make the leap from a slow turtle leaving marks
behind as it goes two steps and turns, to the whole screen being
filled with colors in a flash.  Most things in the world don't have
the many-orders-of-magnitude speedups that we in computing have become
blase about.  It wouldn't occur to us that to paint an entire wall in
a second, we should tell the painter to move the brush one inch and
then repeat that over and over until done.  We'd look for a spray gun,
or toss a whole bucket of paint, or recruit a crowd of painters, or
something.  Fast things and painstaking things aren't disjoint in
computing, as they are elsewhere; how do you teach that powerful insight?)

 I am open to suggestions as to how to get more kids to move on from Turtle
 Art to ___ (insert you favorite real programming environment here).

First, have Turtle Art start up not with a blank slate, but by
bringing in one of the predefined designs -- preferably at random, so
they'll see more of the corpus as they run it over and over.

Second, I suggest that if some blocks are implemented in short bits of
Python, that there be a user interface for seeing and modifying those
short bits of Python (by examining the block in the GUI).  This will
provide a bridge for exploring kids to notice that the blocks are
built out of short bits of structured text -- and that they can
understand and modify those texts.  If they've already figured out
that they can modify the numeric blocks, then they'll try modifying
these too.  The thing that pops the blocks open shouldn't be too hard
to find -- perhaps a double-click, or something else that they'll do
by accident sometime.

If you can implement more blocks in such bits of Python, do it, so
they'll have more blocks they can open up and examine and modify from
the GUI.

How to get them beyond the TurtleArt GUI into the actual Python source
code of the body of TurtleArt is a challenge that nobody seems to have
insight on.  The View Source concept seems to have been much harder
to implement than we all expected.

Don Hopkins worked on a PostScript-based window system (HyperLook)
that would let you flip over an object on the screen to see behind
it a control panel with the guts of its implementation visible.  You
could modify those, then flip it back and it would resume running.
See: and .

Looking back at HyperLook, it looks a lot like the etoys environment,
full of object oriented code with direct manipulation gui editor
interfaces.  It's dead now; a historical curiosity of interest only to
prior-art searchers defeating too-obvious software patents.  It's hard
to keep such self-contained and self-referential environments alive
and relevant in the world at 

Re: Prelink

2011-05-20 Thread John Gilmore
 Using a well-behaved olpc-update, minor updates should be really
 lightweight and low-risk to deploy.

The standard solution to that is called package managers - rpm in
your case.  Unfortunately its network version, yum, is really
heavyweight and too clumsy to run in many XOs.  Installing updates
with rpm, and fixing or rewriting yum to be low impact in XOs would be
much better for the community than continuing to evolve your own sui
generis tool.  Though it's much more fun to reinvent the wheel, the
subsequent maintenance load is substantial, as you're noticing.


Devel mailing list

Re: [IAEP] Turtles All The Way Out

2011-05-20 Thread John Gilmore
 Recently, I finished my dissertation on mobile development
  directly from mobile devices. Something like this might've been very
  useful, although I did target experienced developers, not beginners.

Mobile development would work great on mobile devices like the XO-1,
XO-1.5, XO-1.75, and perhaps even the XO-3, if only we'd teach the
kids a few simple paradigms like files, hierarchical file systems
and text editors.

(Efforts to teach computers to compile or interpret large programs
that aren't written in collections of files are doomed to niche
uselessness, though it sure makes a fun research/masturbation topic.
I spent years paid to write big programs in APL that way in the '70s --
those programs are all unportably dead today, and APL is a tiny niche.)

These are not hard concepts.  Kids learn them daily, but not from XOs.

Since OLPC can't seem to be dissuaded from this fundamental error, the
question for me is whether it can be influenced to minimize the amount
of learning that kids go through which is unique to this useless
programming model.  There *is* usefulness in teaching kids how to
write tiny programs that can never scale up to useful, portable,
supportable programs.  But once they get the basic concepts, they
should be transitioned to industry best practices pretty quickly,
writing a real Hello World and then evolving it to be more useful.

Rather than getting stuck by e.g. trying to make substantial programs
fit on one screen by moving tiles around visually.  As in the
model-view-controller paradigm, the kids need to learn that the view
is not the model, but the model is a simply structured thing that
lives behind the view.  If you don't teach the abstract structures
that the model is based on, the kids can't learn to make that
separation.  This is why they never learn to modify the real programs
that hide behind the fluffy interfaces on their real XO computers.

Devel mailing list

Re: Disabling prelink in software builds

2011-05-17 Thread John Gilmore
  Any objections to prelink being disabled?

I object.  You are running a diskless, swapless system.  The whole
point of prelink is to make your read-only binaries actually remain
read-only, rather than requiring the dynamic linker to modify them
in memory.  This allows large numbers of pages of executables, their
data, linkage tables, etc, to be paged out by merely throwing them
away, whenever there's memory pressure -- which under Sugar and Browse
is all the time.  They can be paged in merely by reading them from
the prelinked executable files on flash.

If you don't run prelink, all these pages are stuck in RAM, because
they are modified by the linker before main() is ever called, and there's 
no way to page them out, so those page frames are permanently in use
even if the program never needs or uses any CPU time.  This reduces
the memory available for the programs that ARE trying to run.

In ordinary Linux systems that have swap space, non-prelinked
processes that are inactive can swap out their modified pages, onto a
small partition on the hard drive, freeing those page frames in DRAM
for use by active processes.  The XO doesn't have that luxury.

Measurements made immediately after booting, when there's little or no
memory pressure, won't tell you anything about this aspect of prelink.
You have to look at /proc/XX/smaps in a running system that IS
under memory pressure, to notice that much more of the memory of the
inactive processes has been released from DRAM, than in a
non-prelinked system under memory pressure.

Devel mailing list


2011-04-14 Thread John Gilmore
 Currently, when installing software, OLPC firmware erases the entire
 disk then writes the entire disk contents, even if most of that is
 zeroes. I am looking at an optimization where we can simply avoid
 writing those 0 blocks, greatly speeding up the flashing process. In
 my test case of 1 SD card, DATA_STAT_AFTER_ERASE=0 and the vendor is
 not lying about this, so I managed to cut down the time needed to
 install an OS image by more than 50%. Hopefully this can apply on a
 wider basis...

I suggest writing paranoia into your code.  Check the flag bit if you
like, but also, read back an erased block and see if it's 1's or 0's.
Hmm!  You can make it perfectly symmetrical: Erase the drive, read
back a block, then compare each block (that you consider writing), to
that block which you read back.  If it erases to all ones, you won't
write any all-one blocks to the drive.  If it erases to all zeroes,
you won't write any all-zero blocks to the drive.

(Of course, when doing these writes, don't do one-block writes to the
drive; accumulate a bunch of them into a single larger write.  If you
know the erase block size, the code could seek to do writes of that
size, aligned on that boundary - particularly after recovering from a
series of blocks it doesn't need to write to.  But some cards may be
able to erase several blocks simultaneously, and may thus prefer a
write of N erase blocks.  Or cards may or may not care whether your
writes are aligned (since they're remapping the blocks anyway through
the flash translation layer), and may just prefer that you always
write one or more erase-blocks' worth of data, no matter what the

Since reading flash is much faster than writing (and since one of the
nasty aspects of flash is that writing block X can screw up the
contents of block X-1 or X+1), would you consider reading back the
entire drive after you're done, making sure the whole thing checksums
properly?  (And also making sure that your checksum detects substitutions
of entire all-1 blocks for entire all-0 blocks and vice verse!)


Devel mailing list

Mesh Potatos and OLPCs?

2011-03-23 Thread John Gilmore
Has anyone used the Mesh Potato devices from to
provide mesh connectivity to a network of OLPCs?

Eben Moglen's Freedom Box mailing list has been exploring whether to
include mesh in their boxes.  My experience with OLPC's mesh has led
me to question the risk/reward payoff of doing wireless mesh, though I
think a wired mesh of Ethernet cables could be very interesting.  But
others have turned up who are building wireless meshes, who claim to be
making them work in production.

Here's one such, the Mesh Potato from
It's a $119 (retail) box with 802.11b/g and a wired phone jack, plus
Ethernet.  It meshes over 802.11, provides an access point, and lets
you make phone calls to other Mesh Potatos or any SIP phone reachable
on the net.  It is open hardware, runs open software, and is designed
to live outdoors and run on rough rural power.  It unfortunately needs
detailed sysadmin with Linux shell commands now.  This 1-minute
embedded YouTube video explains their goals:

I've edited the enclosed message down to the relevant part:

  Date: Mon, 21 Mar 2011 14:51:59 -0500
  From: Charles N Wyble

  On 3/20/2011 8:44 AM, James Vasile wrote:
   Meshing is hard.  Nobody I met knows anybody who is nailing mesh
   networks.  I'm going to get all the mesh heads together soon for a
   real conversation to see if we can work towards a recommendation on
   the most promising avenue.

  Um *waves*.  I guess I need to get out more. I've built a few mesh
  networks over the past year. It's not that hard (it used to be quite
  difficult, but the underlying bits have really matured).  Us mesh
  heads hang out at and a few other places (, :) We have an annual gathering already,

  Join the mailing list and say hi. Mesh is moving along, slowly and
  steadily.  Mesh is the underpinning of an open network. Open networks
  are the underpinning of everything else.

  I feel that mesh networks have reached the point of maturity, that
  they can stand on their own. I feel they are readily and rapidly
  deployable (plug and play) due to the work of

Has OLPC seen these before?  If so, what's your experience?

Devel mailing list

Re: Harvesting Sugar Trees.

2011-02-08 Thread John Gilmore
 Over time, most embedded system developers have pushed their work
 upstream.  This happened gradually as system developers learned that
 it was more expensive to maintain their customizations locally then to
 work with upstream.  The tipping point was often found as system
 developers tried to rebase their customization when upstream rebased.

At Cygnus in the 1990s we were in the middle of some of that.  We were
paid to clean up the work of several big companies on the GNU
compilers, and integrate it into the master sources.  For example,
Intel had built COFF object file support as well as a GCC code
generator for the i960.  Their support of Cygnus led to BFD, which
allowed the binary utilities to support many, many file formats
simultaneously.  Wind River had their own GDB debugger interface to
their embedded operating system, and custom binary utilities.  We
merged all their stuff too.

While pitching one company on our merging and development services,
Michael Tiemann told them we'd do their job for $X this year or for
$2X next year.  He failed to close the deal.  But indeed, the company
came back a year later, and paid twice as much.  They had spent the
year trying to do their own integration and patching, while the GNU
compilers evolved furiously underneath them, and were ready to leave
that job to the professionals and go back to doing what their own
company was good at.

Our best GCC developer, Jim Wilson, often spent more than half his
time merging Cygnus's GCC changes (created by himself and dozens of
other employees) into the master GNU GCC sources, and vice verse.  It
was frustrating but necessary, to avoid forks that would lose access
to major capabilities built by other teams.


Devel mailing list

F15 glibc again fails on AMD Geode LX

2011-02-04 Thread John Gilmore
FYI: Early Fedora 15 builds don't run on the Geode, again.  This time,
people seem to be on the issue, and may resolve it without much work
from OLPC.  But I think it would be worth spending some testing time
to make sure it's really resolved, so the final F15 can be used as
a basis for an OLPC release for the XO-1.

--- Comment #33 from Andre Robatino 2011-02-04 
02:31:39 EST ---
The most recent glibc.i686 build for Rawhide ( ) appears to have
reintroduced the NOPL instruction. See .

--- Comment #34 from Peter Robinson 2011-02-04 03:06:02 
EST ---
Re-opening and adding as a F15 Alpha blocker

Devel mailing list

Re: Feature requests for 11.2.0 - seeking deployment and community input

2011-01-26 Thread John Gilmore
 Please post any ideas here, and they'll be considered when we come to
 plan which features we'll aim to include.

Well, the obvious one is to actually implement the real idle suspend
that happens in between keystrokes, turning off the CPU to save massive
amounts of power, while keeping the screen as it was.  This was
targeted for 9.1.0:

but it isn't clear how many of the numerous requirements actually
got done.  This particular bit is requirement 15 in the Improved
battery life feature.

This is one of the laptop's key innovations, designed to save massive
power, allowing kids to use their laptops all day, even with the small
and cheap battery that's designed in.  It required significant
rethinking, engineering, and testing of the hardware (DCON, etc)
compared to other laptops, and OLPC actually did that.  And yet to
this day the software that would implement it for end users has never
been delivered.


Devel mailing list

Re: os351 on XO-1 - Browse memory pressure

2010-11-04 Thread John Gilmore
 Do a df and see if any temp file systems are chewing up a lot of memory.
 yum is known to just barely work and leave a lot of junk files in memory.

Perhaps someone could produce a patch to yum to remove these junk
files before it exits?  That would benefit all yum users, not just
tmpfs-constrained OLPC users.

John (not a yum user)

Devel mailing list

Re: Aggressive suspend vs NM/DHCP

2010-10-20 Thread John Gilmore
 (nor for the first time) I spot an XO that goes into suspend in the
 middle of the DHCP conversation. In this case, it was with a bad WEP
 key so we never heard back from the DHCP server.
 But if you look at /var/log/messages, you see dhclient's DHCPDISCOVER
 and 12s later PM: Syncing filesystems... done.

Normally you'd get a response from a working DHCP server in much than
12 seconds.

 Do we wake up on broadcast DHCP responses properly? (Am I worrying 

If the client sent a broadcast DHCP request, any response will
NOT be a broadcast -- it'll be sent directly to the MAC address of
the requester.  (I co-designed the BOOTP protocol that DHCP is based on.)

 Otherwise, is there a way for powerd to wait a bit longer when
 NM/dhclient are... active?

I guess I have to post this once a month:  stop dumping more kludges into 
the kludged autosuspend implementation.  If you fix it properly, once,
then you'll never have to kludge anything again.  An autosuspended
laptop should awaken when it gets a packet addressed to it.  Fix all
bugs around that and you won't need kludges.

Devel mailing list

Re: [Sugar-devel] Memory leak in Sugar -- how to dump Py data structures?

2010-10-13 Thread John Gilmore

Fedora 14 (imminent) includes GDB updates for debugging heap allocation
issues.  It's python friendly.  You can probably backport it into
whatever Fedora you're running Sugar on.  See:

Devel mailing list

Re: Power down USB when suspending

2010-10-05 Thread John Gilmore
It would be better if you could explain WHY you need to take a photo
quickly after resuming.  Is the idea that the laptop will save power?
It could remain suspended for a long time, wake and take a picture,
then suspend again until the next picture is needed.  In that case,
you can wake it a bit early, and it can still take the picture on
time.  If suspend in the OS was working properly, you could just
sleep() as long as you require, and the OS would automatically suspend
and resume at the right times.  (Though if you have a USB peripheral
plugged in, it shouldn't be suspending at all, since that cuts the power
to the peripheral, which might not be able to deal with that.)

Is there some other reason why you need the laptop to suspend?

(Even if it could power the USB bus during suspend -- or if you use
an external USB hub with power -- the camera will burn power constantly
rather than saving power while suspended.)

The built-in XO-1 camera is not connected via USB, so it should be
available more quickly after resuming from a suspend, if you can use it
instead of a USB webcam.


Devel mailing list

Re: Bad interaction between sleep timeouts and Salut?

2010-09-16 Thread John Gilmore
It's pretty simple, actually.  When in idle suspend, the system should
remain fully functional, just burning fewer ergs.  It's an optimization,
not a change of behavior.

This means the system should wake up anytime it would've gotten an
interrupt during normal operation.  Which means for any unicast
packet, any ARP packet directed to it, and any multicast packet that
it's listening for.

But people keep insisting on making this simplicity complicated, and
thus trying to figure out how we can disable idle suspend while doing
multicast collab or how we can send more or fewer packets to
suspended laptops or whatever.  Just fix the bugs and it'll work a
whole lot better.  THEN if you have a performance problem, and only
then, start to optimize it by fiddling with timers and disables and

Devel mailing list

Re: backups

2010-08-12 Thread John Gilmore
 If a USB olpc-update isn't possible, I'll have to flash my XO-1 and
 lose my work.  Release notes say only, Make a copy of any data you
 wish to keep... how?

 I don't know of a guide.

It's because being forced to manage your ongoing work via the Journal
is so much easier and more intuitive than using the file systems that
the rest of the world uses.


Devel mailing list

Re: [Sugar-devel] Killing activities when memory gets short

2010-08-10 Thread John Gilmore
I didn't do as detailed an analysis as NoiseEHC - I looked at dirty
page frames, and realized that a large part of RAM was filling with
dirtied pages (even dirtied pages of executables, which get patched to
fill in shared library linkages).  Without swap, this left very few
page frames for read-only executable code to live in -- so it would
tend to get paged out (destroyed) on the theory that it's easy to
bring it back in again.  The result was slow execution.

My theory on how to improve on that from the high Python app level was
to have the Python apps save their state when obscured (like Android
apps) and also provide a fast start path from a saved state to a
resumed process in that state.  Any process which had saved its state
this way (probably in a little xml file or binary file -- something
quick and not memory-intensive to parse) could then terminate, which
would free up all of its dirty pages.  When it needed to be visible
again, it would be re-invoked by the shell and would jump to the same
place in the GUI without stirring up a lot of memory references.  This
high level kludge would allow even interpreted Python programs to
effectively reduce their working set.

This strategy was never built and tested, however.  I could barely get
people to look at the /proc/smaps results that pointed to dirty pages
stuck in RAM as the slowness culprit, and was also unsuccessful in
convincing OLPC to prelink the shared libraries before shipping a
release, thus allowing read-only pages to not get dirtied with shared
library linkage relocations.

Devel mailing list

Re: Killing activities when memory gets short

2010-08-08 Thread John Gilmore
 As long as activities are saving and restoring properly it could be
  made pretty much transparent to the user. Of course that's easier
  said then done...

Android has a whole mechanism for this:

That explains the problem, but doesn't explain the Android answer
to it, which is here:

The section Component Lifecycles gives the summary.  They call each
app's onPause() method when it is obscured from visibility on the
screen, and that method is responsible for recording everything the
app needs to restart itself and get back to the same screen display
(what file it was working on, how far down the file it was, etc).
Then, any process whose onPause() method has been called is considered
a cache, and can be killed without warning by the kernel.

(I'm not advocating using this system -- I've only barely been
exposed to it.  But it's useful to see how others have solved the
problem you're facing, before making your own solutions.)

Devel mailing list

Re: Suspend: RTC wakeup, sleep

2010-08-05 Thread John Gilmore
  There is no 1-second ambiguity in the RTC.  The CPU can only read out
  a value accurate to 1 second, but the CPU can tell precisely when the
  RTC ticks from one second to another, which gives it much higher
  precision if it's willing to wait.  Its precision is greater than its
 But now each resume can have up to 1 second of delay while you wait for 
 the tick to occur.

No need to wait; you can ask the RTC to interrupt you on ticks.  That
will get you very close to knowing the accurate RTC time (based on
your interrupt latency).  Then set up the kernel to awaken 0.
seconds from the previous tick, and when you're there, read the RTC
registers continuously until it actually changes.  Then you're within
a microsecond or better of knowing when it ticked, without creating
much delay.  Your estimate of the time will be OK on resume, get
better after the first tick, and be completely accurate at the second
tick.  And you can arrange your estimate so that as you improve it,
time never moves backwards, only forwards, to avoid strange effects.

 OLPC is in the market for a dedicated (and local) kernel hacker to work 
 on things like this but right now we don't have one.  Until we get one 
 or until someone in the community works on it this will just be ideas.

Right.  But ideas that will, in theory, double your battery life --
and finally put to use all the incredible effort that went into making
hardware that would reliably suspend and resume, tickless kernels,
user mode programs that don't awaken unnecessarily, etc.

 We have also veered off thread...The original questions/responses were 
 on what happens _now_, not what we should be doing.  I'd like to 
 understand the existing issues first.

I'm sorry I don't have insight into those to offer :-/

Devel mailing list

Re: [IAEP] Recommend build for XO-1.0 deployment

2010-08-02 Thread John Gilmore
 On Sun, Aug 1, 2010 at 8:59 PM, Tabitha Roder wrote:
  Does anyone have a build they would recommend? I believe the laptops
  are locked, so it will have to be signed.
 At this point I would recommend the 10.1.2 development builds -- but
 as James points out, they are not signed.

But it's so easy to unlock locked laptops, and then you can run any
build you like.  OLPC has for more than a year recommended that
everyone run unlocked laptops unless their particular country has a
need to lock them.  Unlocked OLPC laptops are just like ordinary
laptops that you might buy in a store; no more and no less secure.
There is no reason to lock a laptop, and no reason to keep laptops
locked, unless you have a major theft issue in your country's laptop

I think the whole reason many early laptops went out locked was that
the local projects thought that somehow a locked laptop was more
secure or better than an unlocked one.  Field experience has proven
the opposite.  Unlocked laptops give the project more control, easier
support, and more options.

Devel mailing list

Re: Suspend: RTC wakeup, sleep

2010-07-29 Thread John Gilmore
 My power logging scripts originally used 'sleep'.  But what I found was 
 that if the time-to-suspend was shorter than sleep then the script would 
 have cases where it would never run.

Are we experiencing confusion between autosuspends and lid-close suspends?

By design, autosuspends should not change the timing behavior of programs;
the idea is for the computer to act the same, but do so using less power.

I seem to recall a lot of discussion about what happens to sleeps and
other interval timers during the POSIX standardization process.  They
ended up with POSIX clocks which offer both realtime and monotonic
timers, so programs can specify which behavior they want.  These were
designed to deal with time warps when a clock is moving unusually --
either via settimeofday() or via adjtimex().  A manual suspend such as
a lid-close suspend acts like a forward time warp, in that user
processes get no chance to run, then suddenly the time is much later.
This book about internal Linux kernel architecture discusses this

My suspicion is that POSIX punted, i.e. the old Unix calls such as
sleep() have undefined behavior during time warps.  If you want
better defined behavior, use the new POSIX calls.

Devel mailing list

Re: Suspend: RTC wakeup, sleep

2010-07-29 Thread John Gilmore
  By design, autosuspends should not change the timing behavior of programs;
  the idea is for the computer to act the same, but do so using less power.
 Autosuspend and lid-close suspends are identical in function.  The only 
 difference is the allowed wakeup source.  The CPU is turned off.  All 
 timing save the RTC (and EC [1]) is stopped.  

These two suspends are only identical in function in the EC.  They 
need not be identical in the kernel.

 With the RTC you have a 1 second ambiguity

There is no 1-second ambiguity in the RTC.  The CPU can only read out
a value accurate to 1 second, but the CPU can tell precisely when the
RTC ticks from one second to another, which gives it much higher
precision if it's willing to wait.  Its precision is greater than its

As man 8 hwclock says, The control program can read or set this clock to a
whole second, but the control program can also detect the edges of the
1 second clock ticks, so the clock actually has virtually infinite
precision.  See also the discussion in the initial comments in

 and the timing precision of the EC is not suitable for 
 accuracy over longer periods or temperature changes. (its RC based)

If it's within 10% or 20%, the EC's resistor-capacitor based timing is
accurate enough for the kernel's purposes in doing short suspends of
the CPU invisibly.  It's unlikely that the kernel will decide to
suspend for more than an hour, say; probably some daemon or kernel
code will be scheduled to wake up before then.  (The invisible suspend
code can set an upper limit and force a wakeup every 10 minutes, for
example, if it thinks that's prudent.)  The kernel can initially err
on the side of waking early.  After each resume, it can accurately
measure the inaccuracy of the RC-based timer on that suspend.  Then it
can improve its estimates to let it the next suspend wake later and
thus waste less power.  Of course it will always need to keep waking
early enough that a temperature change that alters the timer's
inaccuracy won't make it miss a deadline, but for the expected short
sleeps of under a minute, there isn't much time for the temperature
to change while suspended, even if the laptop moves from sun to shade
or vice verse during that minute.

The kernel in XO-1 has at least two ways to accurately measure the
duration of an EC timer based suspend.  One is to use the CPU clock to
count subseconds since power-up, and then watch for an RTC clock tick.
When the RTC ticks, subtract the subsecond count from the CPU clock,
and you'll know exactly when the CPU resumed.  A second way is to
leave an MFGPT timer running during suspend.  There are one or two
timers that can't wake the system, but which can count while suspended,
and at high accuracy.  See
and subsequent comments.

I haven't examined the XO-1.5 timer situation.

 So with the system as it stands there is really no (good) way to 
 accomplish a zero timing impact suspend.

There are clever ways to do it despite the limitations of the

When the CPU restarts after a suspend, the kernel can decide how to
treat sleeping processes.  In a suspend that's intended to be
invisible, the kernel already knows it asked to be powered down for a
shorter time than any pending userspace sleep() call or kernel timer
queue entry.  The kernel can figure out how long the suspend actually
was, to high precision, and can then awaken the user process or kernel
task at the proper time.

A lot of this is explored in (Clock
drift during suspend/resume), (XO
can't resume from suspend at a particular time set by software), and .  These are 3-year-old
bugs, so it's unsurprising if you've forgotten their contents, but
since I did a lot of the analysis of how we COULD do invisible
suspends, I remembered where to look for the details.


PS:  Invisible suspends will work much better if you fix #9054 as well,
pulling 700ms out of the resume path and making it effective to suspend
the system even if it needs to reawaken a few seconds later.
Devel mailing list

Re: Idle suspend instabilities on XO-1

2010-07-24 Thread John Gilmore
 I'm happy that we experimented but I think it's too early to turn on
 idle suspend on the XO-1 builds, like we have attempted for 10.1.2.

You've enumerated the downsides -- what are the upsides?  Does it double
battery life in normal use?

Devel mailing list

Uruguay violates GPL by deleting root on OLPCs

2010-07-07 Thread John Gilmore
  Ignoring the fact that some deployments ship without root access.
 Is the practice of completely locking-down the laptops something we'd
 even want to encourage? 

Shipping the laptops TiVoized like Uruguay does has put them into serious
legal trouble.  OLPC should definitely not encourage anybody else to do this.
Why bankrupt your project by losing a copyright enforcement lawsuit?

Shipping the laptops without root access is a direct violation of the
GPLv3 license on a dozen packages (probably 50+ packages in later
Fedoras).  They have shipped binaries, while using technological means
to deny the recipient the practical ability to upgrade or replace them
with versions modified or chosen by the recipient.

Only an idiot would distribute hundreds of thousands of units while
setting themselves up to pay the Free Software Foundation any amount
of money they demand.  (Given the way OLPC and Uruguay have
ignored the notice that they're in violation, for years, I do hope FSF
extracts both future compliance, and its next ten years of operating
expenses, from these scofflaws.)

Or does Uruguay think, Sue us for copyright violation in our own
courts -- we'll make sure you lose??  In other words, do they
just brazenly steal the GNU Project's software, knowing it's wrong?

John Gilmore

Devel mailing list

Eben Moglen: Re: Uruguay violates GPL by deleting root on OLPCs

2010-07-07 Thread John Gilmore
[I didn't see a copy of this come through on devel, so assumed
 that it bounced because he's not a recipient.  --gnu]

Date: Wed,  7 Jul 2010 12:47:26 -0400
Subject: Re: Uruguay violates GPL by deleting root on OLPCs
In-Reply-To: Martin Langhoff's message of Wed, 07 Jul 2010 11:21:27 -0400
From: Eben Moglen

I don't know what the technical details are, but it sounds as though
the right people are present in the conversation.  For GPLv3
programs-- which would include bash, tar, and Samba as well as the
toolchain, to take some examples--the requirement is for installation
information to be provided to anyone who requests or receives source
code.  Installation information is defined as any methods,
procedures, authorization keys, or other information required to
install and execute modified versions of a covered work in [the
laptop] from a modified version of its Corresponding Source.  That
requirement can be satisfied, for some programs, by informing the user
how to run a replacement copy, without root privilege, out of the
primary user's home directory.  Some programs might require escalated
privileges in order to install and run a modified version (of a
daemon, for example).  Side-stepping the OS on the hard drive, booting
a system on removable media, and then installing the new version on
the fixed disk would be a method within the meaning of the license
in those cases.

Details are crucial.  Working with relevant parties to ensure
compliance is SFLC's purpose in a situation such as this.  We'd be
happy to help if there is interest.

Devel mailing list

Re: Uruguay violates GPL by deleting root on OLPCs

2010-07-07 Thread John Gilmore
 Please explain your statement that lack of root violates GPLv3.   Couldn't
 the owner of the system insert a SD card with a developer's version of
 Linux, mount the internal drive of the XO, and tinker with the installed
 packages as root from the external OS?  Does GPLv3 expressly mention root

The laptops refuse to boot a developer's version of Linux.  They
require a signed kernel and initrd.  Some people call this DRM;
it's definitely TiVoization (check Wikipedia if you don't know the term).

 I think Ubuntu disables root logins, but allows sudo access for root
 permissions.   Is that a violation of the GPLv3?

As Eben explained, the GPLv3 doesn't require root, it just requires
that you be provided all the info you need to install modified
software of your choice, in the environment in which the binaries were
shipped.  su is fine, if documented, and it is.


PS: Get a clue, folks.  This is bigger than OLPC.  You've been spoiled
by 50+ years of general purpose computers without cryptographic access
controls.  Four big oligopolies (Intel, Microsoft, Hollywood, and NSA)
are all trying to wipe out the general purpose computer and replace it
with one that only allows running approved software.  They've
jiggered the law to make it illegal to circumvent such controls,
even if you own the hardware and all the software is free.  All the
Apple products except the Macintosh are already this way (and they
produce more revenue for Apple than the Macintosh), and their
customers have barely noticed or complained.  It gets harder in every
generation of iPhones to jailbreak them, even if it was legal; they're
closing in on shipping products that close *all* the exploitable
holes, leaving the buyer totally at Apple's mercy.  If even the free
software community shuts up and demurs when one of our flagship
projects locks down the hardware to disallow freedom, why should *any*
evil empire delay going right ahead and screwing every consumer, every
curious questioner, and every tinkerer?
Devel mailing list

Re: AIR + Flash/AIR issues wikis

2010-06-07 Thread John Gilmore
 There's a long standing hard bug of non-accelerated video on Linux
 (not just XO). That hurts hurts HURTS any Linux device. There is some
 backstory on that -- it's whether to use Xv or not, whether the video
 frames can be grabbed from the Xv pipeline to overlay stuff on top or
 not - early Flash9 used Xv, then stopped, and vid performance sucked
 ever since.

Prerelease versions of gnash now have accelerated video on Linux.  It
uses the terrible Intel-designed vaapi (it only accelerates video
codecs that Intel approves of, and is not readily extensible).  But
it's better than nothing.  Is there a vaapi accelerated video
implementation for the XO-1.5?


Devel mailing list

Re: Alternative option for solving Fedora i686 vs geode problems

2010-06-07 Thread John Gilmore
I looked at the kernel patch for emulating the missing instruction
(long NOP).  It looks like it works, and only needs minor patching-up
for security enforcement.  The big argument on the Linux kernel list
was about not having a little kludge like this, which is likely to
grow to emulate many other things and become unmaintainable; some
people would rather use the whole virtual-CPU emulation mechanism for
this, which is much more heavyweight, but also a lot easier to test
and validate.

If having to maintain a 20- or 50-line kernel patch is the price of
being able to move forward onto using unmodified modern Fedora release
repositories, I'd say the choice for OLPC is very clear - do it.

The change that introduced the use of this instruction was in the
binutils (assembler) rather than in gcc.  I believe it is used when a
.align directive is given in an executable segment.  When optimizing,
GCC has been aligning some loops on cache line boundaries for some
time (by inserting nop padding BEFORE the loop), but previously, the
assembler was filling with various N-byte NOPs that would work on any
x86.  It has been improved to pick faster ones on modern hardware.
The relevant code is in gas/config/tc-i386.c, function
i386_align_code().  I haven't pinned down the actual code change that
bit us, and perhaps it's just the change in -march and/or -mtune
options used by Fedora when calling gcc.  Gas is careful to only use
NOPs that are compatible with the specified instruction set, if one is
specified -- but Fedora is specifying the wrong one for our purposes.


Devel mailing list

Re: Alternative option for solving Fedora i686 vs geode problems

2010-06-07 Thread John Gilmore
 2) FESCo (Fedora Engineering Steering Committee) is dealing with the
 issue upstream [1][2] in Fedora with the view of getting it fixed
 upstream for F-14 or at the very least clarified. It was agreed in
 F-12 that the Geode LX would be supported and that decision wasn't
 discussed otherwise. Please add to the conversation on the ticket or
 the list. It might be worth seeing the outcome of this before we go
 and reinvent the wheel again.
 (but thread goes back to April)

It's nice to know we have the attention of the right folks.  But there's
some useful info we could give them for tomorrow's FESCo meeting.

Do we know which i386/i686 packages in F13 actually contain NOPL
instructions?  Apparently, glibc does contain them, due to the report
here from the beta:

If fixing F13 would only require rebuilding five, ten, or twenty
packages, then fixing it in the F13 repos (for everybody, not just for
OLPC) is totally doable.  If it requires a total rebuild, then the fix
could only occur in the next Fedora release.

This message suggested that the NOPL instruction doesn't appear in any
of the coreutils programs:

To figure this out, I downloaded and booted the F13 i686 LiveCD and
did this:

  for x in {,/usr}{/bin,/sbin,/lib}/* ; do
echo $x
objdump -d $x | grep nopl

It shows nopl's in:


There are no nopl's anywhere under /lib/modules.  objdump couldn't
examine the mashed kernel image in /boot, but I bet it's free or
almost free of nopl's.

Virtually all of these files are generated from the libc sources
(except two executables statically-linked with libc).  In short, this
is almost exclusively a glibc problem.  It's probably just a bug
introduced into the glibc configuration or makefile in F13.

Fedora Bug 579838 should be reopened -- it was inappropriately closed
by Andreas Schwab on 2010-04-07.  (Jakub's comment wasn't pretty, but
he didn't close the bug - Andreas did.  But closing bugs
inappropriately to make your bug stats look good is rampant in every
development org - e.g. I regularly complain to Ubuntu about this.)
This is not a dead issue for F13, and we should seek solutions within
F13 as well as outside it.

Oddly, F13 offers release CDs and DVDs only for i386 (and x86-64),
but offers live CDs only for i686 (and x86-64).  It is completely
unclear from the documentation (which suggests using these
interchangeably) whether the i386 DVD is really compiled for i686 or
i386.  See:
(hover over the Download Now buttons to see which ISO image each
 one offers.)

Devel mailing list

Re: What's the current status of suspend/resume?

2010-06-04 Thread John Gilmore
 I've lost track of this area.  Could somebody please give me/us a review 
 and/or update.

On which hardware?

XO-1 had a lot of niggling bugs around the edges (all documented in
trac).  The largest was that the Linux kernel does busy-waits for the
USB bus's startup delays for sequencing power and signalling.  It took
about 900ms to resume, instead of the expected 100-200ms.  As far as I
know, nobody is working on fixing that.  Turning on the USB bus is on
the critical path to receive any packets that the WiFi chip has for
us, but it can be done with timers and interrupts, allowing the rest
of the system to come up more quickly, run user processes, handle
keyboard/mouse input, etc, in parallel with bringing up the WiFi
interface.  This is

The next worst of those was that we could only wake up on 1-second
boundaries because the system was only wired to wake up when the
realtime clock ticked (in classic MSDOS style: Wake this machine at
8AM please).  That's  We had a fix
planned, which was for the EC to support sub-second timing and wake
the CPU when instructed.  I believe that Richard wrote the EC support,
but the Linux kernel has never used it.

Fixing these two problems would allow the system to suspend even when
user processes are running and expecting to wake up in a few seconds,
without messing up the user processes.  Currently, when it suspends,
it goes down hard and only comes back up when a key, mouse, or packet
arrives (and takes almost 1s to come back).  This causes various
troubles like the screen brightness not being changeable during
suspend because the machine can't wake up to dim it, and suspend
not being viable unless the machine is very idle.

There is also a layer of bugs, most of which were never chased down to
a fix, most of which relate to I/O devices screwing up when we
suspend.  For example, Packets that
wake the laptop from suspend are often lost; or #3732, arp broadcasts
don't wake up autosuspended laptop.

There were numerous bugs producing dozens to hundreds of useless
wakeups per second.  The most egregious was #4680, Sugar apps' pygtk
main loop polls 10 times a second, always.  Many of these, including
that one, have been fixed somewhere upstream.  I don't know whether
modern Fedora (or any OLPC release) has all those fixes, but have heard
that new releases only make small numbers of wakeups per second.

Fixing all of the above would let the kernel invisibly autosuspend
whenever it had no processes to schedule for half a second or so (and
based on recent history, expected no TCP packets to arrive for a
similar period).

I'm not up on the XO-1.5 suspend/resume status at all.

Devel mailing list

Free software for an ARM tablet?

2010-05-29 Thread John Gilmore
If somebody gets Android running on a tablet and that somebody actually
honors the GPL, it's likely that much of the work of a real Linux
port has been done.

Except that I've heard from a very credible source that in existing
Android *phones* there are 9 pieces of essential yet proprietary
software, which they have shoehorned into the GPL kernel by writing a
GPL'd dummy driver that lets the real (proprietary) drivers run in
user space.

One, for example, calibrates the accelerometer, and is considered
highly proprietary by the *%%## who build the chip.

OLPC has dealt with this problem before (honorably), and it would be a
real shame for OLPC to give millions of units of chip sales to a
company that would do that to its customers and developers.  (But: the
VIA cpu chip and its companion chip in the XO-1.5 still don't have
published specs.  Nor the codec chip.)

Then you'd have to throw away the deliberately-differently-encoded
Android Java runtime and hacked-to-be-incompatible libc and such.  But
that part isn't much work at all.

Devel mailing list

Re: Idle-suspend a little too intrusive to user experience?

2010-05-12 Thread John Gilmore
  ...the biggest
 problem area in terms of suspending and not coming back is the
 network, and without wake-on-precisely-what-i'm-waiting-for,
 that's problematic.

Most wireless and Ethernet chips can be configured to interrupt or
wake on precisely what you're waiting for.  They discard all packets
for other network addresses.  They discard 98% of multicasts that
you aren't listening for.  They even discard broadcasts if you ask
them to.  The really smart ones can ignore all broadcasts except for
ARPs that are for this machine (there's already a kernel interface for
this, ethtool -s wol a, which we got working late in the XO-1.)

I don't know what wireless chip made it into the XO-1.5 (the XO-1.5
hardware spec wiki page just says a QMI WLAN module with no data
sheet, and the PDF page is even less informative), so I don't know
just how fancy its wake-on-lan configuration is.

If our new chip is not fancy, it might even be possible to cheat with
a mite of code to the resume sequence in Open Firmware.  This would
look for an incoming ARP that wasn't for us, and quickly put us back
to sleep before turning on the DRAM and video and such.  Before going
to that premature optimization, we should see how many times our
suspend-on-idle kernel wakes up and then immediately decides to go
back to sleep.  If it's uncommon, no need to bother.

Devel mailing list

Re: #10045 HIGH 1.5-sof: XO-1.5 Record audio/video are out of sync with each other

2010-05-11 Thread John Gilmore
There's a classic Unix problem with distribution of disk access times
that relates to how older Unixes did sync -- every 30 seconds there was
an instant traffic jam at the interface to the drives.  This has been
studied to death; here are some assorted papers:
Has graphs from old DEC hardware that look similar to XO-1.5.
Good references section.
Studies ext3 performance in depth.

Most such studies looked at read() times because the usual workload has
far more reads than writes.  Odd delays in write() times are interesting.

Devel mailing list

Re: Idle-suspend a little too intrusive to user experience?

2010-05-11 Thread John Gilmore
Is OLPC's Idle-Suspend not waking up the machine when the next process
wants to run?  No wonder you're having all these problems where it suspends
and doesn't come back.  Don't fix it with 27 kludge patches (to audio
players, to network managers, etc), just fix the kernel so the suspend
ends when the next process wants to run.

Devel mailing list

Re: the old keypad behavior gets too sensitive

2010-04-16 Thread John Gilmore
 I have been running into this with the XO-1.5 prototype but thought it
 was either a prototype issue or my fat fingers.. however I noticed it
 with my kid also. Pretty much the same behaviour you list below.. in
 low humidity the cursor will move without touching the keyboard. Is
 there anything I can do to help debug/fix this for people (New Mexico
 is pretty much always low humidity)

I have seen a symptom in several Ubuntu Jaunty and Karmic machines in
which the cursor runs to the upper right corner of the screen, for no
reason.  This is with different input devices (HP mice, Acer laptop
trackpad).  It occurs both while scrolling by mousing a scrollbar, and
when typing (the active window loses focus and the typing goes where
it doesn't belong).  My tentative conclusion is that it's caused by a
longstanding Linux kernel bug.  If true, this bug is also likely to be
in the XO operating system, and may be confounding your ability to
detect and debug hardware or firmware problems with the XO trackpad.


Devel mailing list

Re: resizing rootfs to fit the disk

2010-03-10 Thread John Gilmore
  but again:  where should such a flag go?  is there a precedent
  for such things?
 /.i-am-a-hidden-flag ?

Safety would argue for doing the opposite:

* Build the installation images to contain a file like /.resize-root-once.
* If that file is present
**  Remove the file
**  Sync the disk
**  Attempt the online resize
**  Sync the disk again
* If that file is not present
**  Do nothing.  Leave the filesystem alone!

The idea of a Linux system that, when it boots, resizes the root filesystem
every time to try to fill up the entire drive it's on, fills me with horror.
I prefer to partition my disks myself, thank you.

Devel mailing list

Re: surprisingly early suspend

2010-03-08 Thread John Gilmore
 Perhaps the suspend/sleep process should be disabled until the laptop is
 assigned a child's name and color preference on first boot.  I find  
 sleep to
 be more disorienting, as the screen is turned off (my laptop broke!)  
 and it
 takes a press of the power button, not the keyboard, to wake the  
 laptop up.

What ever happened to making suspend invisible on the XO, and happen 
between keystrokes?  I thought the new hardware was going to fix all the
issues that prevented us from enabling that in the old hardware.

(Suspend -- turning the CPU off -- should be separate from dimming the
screen, and should also be separate from sleeping.  If you can suspend and
can dim, maybe you should sleep after an hour or something, but with the
CPU and RAM off and the backlight off, how much does sleep really save?)

Devel mailing list

Re: XO-1.5 keyboard

2010-03-05 Thread John Gilmore
 :-)  you're right -- it _is_ awesome.  wad seems to have mastered
 the art of getting the laptop to really go together right after
 the conversion.

One of the things I asked wad to improve when he was looking for
things to fix for the XO-1.5 was the incredible flakey keyboard.
Everyone knows when I type an email message on an XO, because it's
always so full of typos that it's just not worth going back to fix
them all.  One of my XOs has a CTRL key that would press itself at
random intervals, which was really fun under Sugar.  One would think
that a keyboard designer would make very sure that the shift-keys were
more reliable than the letter keys (since they get pressed a lot more
often), but in the XO-1 it was the opposite.  I eventually tried to
batter my way through the alleged OLPC parts-and-repair process (and
failed); but somebody nice took pity on me and mailed me a spare

Wad said improving the keyboard wasn't on the main program for 1.5 but
he'd see what he could do.  Did anything happen?


Devel mailing list

Re: OLPC hardware: what if there was an SDR modem / chipset?

2010-01-26 Thread John Gilmore
This whole discussion has been happening on the wrong mailing list.
Please move it to (subscribe at  They use and
maintain the GNU Radio free software that does SDR, and also design
and build the USRP hardware that's the cheapest and most capable
hardware currently available for SDR.  They'd be happy to hear about
new chips that make cheap and more capable SDR's possible.

At one point I tried to get someone to design an SDR for a new
generation OLPC -- something that would cost less than 15c per
deployed unit, perhaps using a few analog components and a spare
A-to-D/D-to-A on a sound chip.  For example, something that would
receive AM or FM radio, or transmit AM or FM at low power.  For a
super stretch goal, receive analog TV signals, making the laptop
capable of being a TV set.  And be another sensor that the kids can
learn about the world through.  The biggest cost would probably be
the additional connector for an external antenna.

Even that initiative went nowhere at OLPC (mostly because no
experienced analog engineers stepped up to design such a cheap
circuit).  OLPC can't afford to include even a $2 chip (plus analog
components, power supply, connectors, wires, antennas, etc) for such a
marginal use in their low cost product.  So please move the discussion
to a place where you'll find researchers *happy* to build SDR chips into
their next hardware project.

John Gilmore

Devel mailing list

Re: [Sugar-devel] New release of F11 for the XO-1 - Build11

2010-01-10 Thread John Gilmore
 2GB SD card in my XO, and I have Firefox on it.   I installed the ePubReader
 plug-in for Firefox.   This runs nicely and allows you to view eBooks in
 ePub format, which is the up-and-coming open format for books.   You can
 get  free ePub eBooks from several free sites, including,, and

Also, the Internet Archive ( has more than a million
books scanned and available in ePub.  You can also reach them through
a possibly nicer interface at  (All of those books
are also available in PDF, plus other formats, and are also readable
using a Javascript-based online reader that should work in most

Devel mailing list

Re: New release of F11 for the XO-1 - Build11

2010-01-05 Thread John Gilmore
 Keyboard and mouse will not wakeup from sleep.  Can be fixed by disabling 
 power management in Sugar.

Is there any reason for cutting release after release that don't work
unless end users disable power management (sometimes twice!)?

Surely if you can't fix the bugs, you could at least ship the release
with power management disabled by default, so it works out of the box.
Or, one step up from that, have it figure out which hardware it can
reliably suspend on, and only have it enable suspend by default on
that hardware.

Devel mailing list

Re: Android, OLPC, and native hosting

2009-12-28 Thread John Gilmore
  Since when did it take more than a GB of RAM and 4GB of disk to host
  an IDE ?
 I think that was Emacs 23.

No, that was Eight Megs and Continuously Swapping.  I.e. in an
amazingly large and expensive Sun Workstation with 8 *megabytes* of
RAM, emacs would still make the system page-fault at a high rate.

Those young 2nd-graders just don't know what they're missing...  Why
in my day, we had to disassemble 6502 machine language just to peek
and poke the screen into high-resolution character graphics mode.
We had to put little pieces of tape over the holes in our punch-cards
to save paper.  Solar powered gigabyte WiFi Linux machines?  Our
school's calculators had neon NIXIE tube displays!

Devel mailing list

Re: Android, OLPC, and native hosting

2009-12-27 Thread John Gilmore
 I would argue that an operating system that doesn't
 natively host its development tools is not appropriate for OLPC's
 target audience.

Does the XO-1 host its own development tools?  I don't think anyone
has ever rebuilt the system from source code on an XO-1.  I don't even
know anyone outside the OLPC office who *has* the source code for an
XO-1 software release.  (At least Fedora and Ubuntu and Debian cut a
source release to match each of their binary releases, and hundreds
or thousands of people download it.)

Could the XO-1.5 host its own development tools?  More likely, but
again I don't think anyone ever has.  Perhaps someone rebuilt a few
packages from source, natively, while debugging.  Must have been
someone with great Internet access to download compilers and such, and
great knowledge of where to *find* the source code in the wilds of the
Internet.  Still that's a step forward.

Does Android not host its development tools because it doesn't run the
X Window System?  Since X already runs on most of the hardware that
Android does, that wouldn't be too hard to remedy -- and would benefit
the whole Android community.

Devel mailing list

Re: XO-3 super-o-fficial

2009-12-24 Thread John Gilmore
 What makes you think that this will be a proprietary version of Android?
 Android is licensed Apache 2.0 with kernel patches as GPLv2[1], although
 there have been some proprietary apps and customizations on top.

I hadn't looked closely enough to see the detailed licensing.  But I'd
seen the news stories about Google cease-and-desists to the guys making
improved free versions.  Is a useful fully-free version readily
available, as a practical option?

(This is mostly off-topic for OLPC, unless there's a plan to try
Android on XO hardware, which might be amusing.  20,000 apps and an
active developer base might be an attraction, versus the hundred or
two Sugar apps.)

Devel mailing list

Re: XO-3 super-o-fficial

2009-12-23 Thread John Gilmore
 We don't necessarily need to build it, Negroponte told Forbes. We just
 need to threaten to build it.

Looks like Notion Ink has already done so, sort of:

The OS is proprietary (android), it would probably fail it you dropped
it in a puddle and it has too many radios (GSM, UMTS, GPS, and
Bluetoot, besides WiFi) -- but at least it has connectors!  Remote
villages shouldn't waste power with inductive charging, and can you
imaging debugging a cranky XO-3 via multitouch?

See also:

  $99 NVIDIA Tegra MIDs in development

Devel mailing list

Re: XO-3 official

2009-12-23 Thread John Gilmore
 I would take it all with a large dose of salt.

Also, as usual, the left hand at OLPC doesn't know what the right hand
is doing.  The press release isn't on, nor is there
anything in or about the XO-3 (or even
the XO-1.75).  The press release (which is on Business Wire) links to
30 megs of nice publicity photos -- which nobody can download any more,
because they're on a foolish hosting site that has reached its
download limit.  Etc.


Devel mailing list

Re: [Server-devel] XO 1.5 to XS-onXO1 behavior

2009-12-19 Thread John Gilmore
  as Fall semester finishes) but I have a XS-on-XO1 running at home and when a
  XO1 associates with it, the XO1 gets a address (school mesh
  portal). When the XO1.5 associates with school-mesh-0 (I have to click on it
  in the Neighborhood view) the association happens, but the XO1.5 gets address, and beyond that the network is unusable.

 that's expected, unfortunately. The XS-on-XO runs an active antenna
 / mesh gateway in the sense of 802.11s. As the current XO-1.5
 drivers/firmware don't talk 802.11s, it won't work. In that sense, the
 XO-1.5 is the same as any other 802.11a/b/g device.
 There are two paths to address this
  - get the hostap / thinfirm driver+firmware combo working again. It
 was last seen working on a 2.6.17 i think.
  - get 802.11s on XO-1.5 going. this is not trivial...

The least common denominator in the XO-1 and XO-2 clients is a
connection to an access point.  So making the XS (on any hardware)
provide a standard 802.11 access point would probably be the easiest
path forward.

As I recall there was some step in the XO-specific school
provisioning (antitheft DRM?) that only works over the mesh.  So if
that hasn't been fixed, either deployments would have to turn off the
DRM, or OLPC would need to revise the firmware and/or initrd to handle
this interaction via ordinary 802.11 access.  Or they could just throw
away their DRM-choked devices, as many others have had to do when the
big DRM server in the sky went away, and take a lesson from that.

Devel mailing list

Re: possible progress on XO-1 camera issues

2009-12-18 Thread John Gilmore
 #10 0xb67fae59 in gst_xvimagesink_xvimage_put (xvimagesink=0x8364160)
 at xvimagesink.c:864
 src = {x = 134867456, y = 140758336, w = -1259457208, h = 1}
 dst = {x = 137730309, y = 3, w = 0, h = 137691184}
 result = {x = 0, y = 0, w = 322, h = 241}
 draw_border = 322
 __PRETTY_FUNCTION__ = gst_xvimagesink_xvimage_put
 The src.w value is in the same range as the Xlib function addresses;
 -1259457208 is 0x4B11CAB8 and as can be seen from the call frame #9
 the XSync function is at 0x4b0eccf7.  The other values seem
 irrational.  This may be evidence that the stack has been corrupted
 somewhere else, or the values not initialised.

Just to rule out going too far down a blind alley...

Try adding a printf of these values to the code there, rather than or
in addition to using GDB.  GDB may not be 100% reliable when accessing
variables from optimized code.  (I used to maintain GDB, and I worked
very hard to make it never lie to you, but that precept hasn't always
been followed in the intervening decade, and optimizations have also
gotten a lot more complicated.)

Or try compiling that code without -O and see if that changes either
its behavior, or what the debugger reports.

Devel mailing list

Re: 1.5 - gnome-packagekit?

2009-12-08 Thread John Gilmore
  One disadvantage of doing this is that it would harm the use of
  olpc-update -- pristine updates would fail. And also the software
  would be silently lost when an olpc-update happens, which is now

Good thing we reinvented the wheel here.  RPM packaging was too
complete and flexible for kids or teachers (or school administrators).
They're so much better off NOT being able to install any of 5,000
packages freely contributed by talented programmers all over the

John  :-(
Devel mailing list

Re: About 8.2.2 unlocking

2009-12-03 Thread John Gilmore
 I think for the case of Cambodia with many small deployments 
 (educational NGOs got XOs donated from G1G1/OLPC or other donors), no 
 signed builds probably means that the XOs don't get updated anymore.

Are you trying to say that the Cambodian OLPC recipients don't have
any serious chance of jailbreaking their laptops?  Installing an OS
release is a fifteen minute process, whether it's signed or not, once
you disable the DRM.  The DRM is the only constraint (other than losing
all the data you had in the laptop).

Perhaps instead of coming with a signed build, new releases should
come with a monster keyring that will unlock any known laptop and then
install the release on it.  Hmm, another way to do this would be for
OLPC to sign one last build, which installs new firmware that unlocks
any laptop except those built for specific large-scale deployments
(which have internally decided to continue the DRM and sign their own

But whether the unlock is automatic or must be done manually, at least
every new installation on a random XO will leave that machine
unlocked, thereby reducing the long-term problem.

Devel mailing list

Re: OS and Firmware testing for XO 1.5 B2: gnash

2009-11-17 Thread John Gilmore
 Gnash and youtube is a no go. No error now, just a black screen

Within the last month, Youtube changed their default player to require
Adobe Flash 10, including ActionScript 3.  Gnash does not yet implement 
AS3 properly -- that's why you got a black rectangle.

The (shrinking) gnash team is working on this, but they won't have
even an internal version that plays today's youtube before the end of
November -- maybe much longer.

There's a hack though:  rewrite the URL from:


That uses the old player.  (The videos themselves are unchanged, it's
just the stupid stuff around the edges, like the Play/Pause button,
that's causing the trouble.)


Devel mailing list

Re: Information on XO-1 power efficiency

2009-11-17 Thread John Gilmore
 How well does sleep-between-keystrokes work if I ignore USB?

Pretty well -- but check  That's where our institutional
memory of the bugs that prevented full blown suspend exists.  Search for
power or suspend or sleep.

If you're serious about working on this, I can spend some time looking
in there for the next low hanging fruit.  I remember there were some
high priority bugs we were trying to shoot.  When OLPC had to fire most
of the software team for lack of money, and focus down its efforts
on what its country partners wanted, Chris and I stopped working on
improving power consumption.

 Has anything interesting changed in this area for XO-1.5?

Lots, though as far as I know, auto-suspend on XO-1.5 is not working

 Is USB device discover inherently slow?  Or is the sloth just handling 
 strange cases?  Can I speed things up if I only need to verify that devices I 
 knew about are still there?

Bringing up the USB bus is apparently *designed* to take a large
fraction of a second.  After you turn on USB bus power, you have to
wait for X hundred milliseconds for the power to stabilize and for any
devices to come out of power-on reset.  Ditto after you turn on USB

The way to play with this is to unload the USB module from the XO-1
kernel.  Then it won't play any part in suspend/resume.  (This will lose
you the WiFi.)  You'll be left with something that suspends in ~250 ms
and resumes in ~400 ms as I recall.  Resume time with USB is 900 ms.

To fix this, refactor the USB startup code so that it runs
asynchronously on resume (i.e. it doesn't prevent the kernel from
starting to run user programs).  This should produce a kernel that
resumes in about the same amount of time, whether or not you have a
USB module loaded.  The trick is probably to manage this in a way that
upstream will accept.


Devel mailing list

Re: wlan interface (was: first play with new XO 1.5 machines)

2009-10-30 Thread John Gilmore
  I mean the clock in the 802.11 MAC sublayer. This defines the basis of
  the timing synchronization function (TSF) which is a core part of
  802.11. Without synchronized clocks, nodes cannot communicate.
 I talked with one of the 802.11 experts I know. He's quite sure
 that there should be no problem on Atheros hardware at least.
 He has no problem transmitting arbitrary packets at arbitrary
 times and no problem receiving packets either.
 is that you get just one channel at a time.
 The TSF stuff  looks like an optimization that you don't really need,
 except perhaps when sending to a receiver that stops listening
 at certain times. Lame hardware misses out, no surprise.

It's for power saving.  When 802.11 is used with an access point, the
access point can be asked to buffer up frames for battery powered
stations, and send an indication in its periodic beacons.  The station
wakes up for each beacon and can sleep the rest of the time.  In
addition, 802.11e provides more power-save modes (APSD).  See this

I don't think that XO-1 WiFi chips ever did any power saving.  Don't
know about XO-1.5.


Devel mailing list

Re: the importance of providing swap space

2009-10-23 Thread John Gilmore
 I happened to have an SD card with me that had a swap partition 
 defined on it.  The XO's SD slot was already in use, so I attached 
 an USB card reader (with my card in it), and issued the appropriate 
 'swapon /dev/...' command.

I'd suggest a small enhancement:  that when a removable medium with a
valid swap partition is plugged in, start swapping to it immediately.

That would cause a problem when trying to remove it, though, since
Linux doesn't provide a dismount all partitions in preparation for
ejecting operation in the GUI.  Perhaps this is one area where Sugar
could improve on the general Linux GUIs.

Devel mailing list

Re: tap-to-click feedback

2009-10-22 Thread John Gilmore
 we tried the synaptics driver initially (when we got the new
 touchpads) but by itself it caused extremely erratic (perhaps not
 erratic, exactly, but just way-too-fast) mouse cursor behavior. 

There seems to be something wrong with general Linux mouse behavior.
Even on ordinary optical mice (like the HP I'm using now), the mouse
works fine about 98% of the time; then it jumps to the top of the
screen inappropriately.  (Running Ubuntu Jaunty with 2.6.28-11-server

I'd noticed this with touchpads and assumed it was a buggy touchpad,
but it seems to be a more generic bug somewhere in Linux.

The latest Ubuntu (karmic beta) disables tap-to-click by default,
which is a regression (see
with it's more-than-a-dozen duplicates and see also #441013).  It
turned out that there was a lot of complicated interaction behind the
scenes that would make it work, fail, work, fail, ... with different
versions of various packages.


Devel mailing list

Re: [Testing] first play with new XO 1.5 machines

2009-10-21 Thread John Gilmore
 On Oct 20 2009, at 19:04, Tabitha Roder was caught saying:
  no mesh network showing in neighbourhood
 My understanding is that mesh is not currently supported in the 
 WLAN firmware for the new chips. I am not sure what the plan of
 action is in regards to mesh support for 1.5.

For laptops to communicate when they're nearby, no mesh is needed.
The usable range will be shorter than with a mesh, but on the positive
side, XO's should be able to communicate with every kind of device,
not just themselves.

But I don't know if NetworkManager and Sugar are fully organized to do
Ad Hoc networking, presence, messaging, file sharing, etc in the
absence of an access point.

The mesh channels in the GUI could be converted to ad hoc
channels, unless ad-hoc WiFi networking has a protocol for searching
all the channels for nearby machines.  (Channel-less operation would
be simpler for users -- one less setting.)

Devel mailing list

Re: OFW access from linux - kgdb

2009-09-16 Thread John Gilmore
 it sounded like there was also some thought that the emphasis
 should be on tools, like kgdb, which can be more general purpose,
 and more widely used and maintained.  to which i'd say, the more
 the merrier -- i'd love to use kgdb regularly, but it requires a
 second machine, and it ties up scarce serial ports.  so OFW is a
 win, for my current uses.

In theory we could make one OLPC kernel debuggable by another OLPC,
just using the WiFi interfaces and a simple matter of software.

kgdb should be able to use an ethernet, if the Ethernet driver
implements the NETPOLL interface.  I think WiFi counts as Ethernet, at
least if you use ad-hoc mode, or if you can get the interface brought
up (by the usual means) before you need the debugger.  You still need
two machines, unless the kernel you're debugging is running in a
virtual machine.  The machine you run GDB on can be any computer, it
doesn't have to match the one you're debugging.


which was readily findable via Wikipedia's kgdb entry.

For all I know, OFW has a gdb debug stub in it somewhere, too...

(I used to maintain gdb, in the distant past.)
Devel mailing list

Re: OFW access from linux

2009-09-15 Thread John Gilmore
 there's no SysRq key on the XO keyboard, so you'll need to use a
 break on the serial console to invoke it...

Please.  If you're going to put this hook in, which I think is a great
idea, at least make it work on the standard hardware!  And when the
operating system is not very responsive.  That's when you'll need it
for debugging or resetting the system.  Without taking the plastic
apart, finding a part with no known suppliers, and soldering it to
your motherboard.

On Sun workstations, the L1-A key combination (pressed in exactly
that order, with no intervening keys or key-ups) got you into OFW or
its predecessor.  (L1 was the top left key in the keypad to the left
of the main keyboard.)  We shipped it that way for decades without

There are some pretty obscure keys on the XO keyboard -- howabout
something like holding down the leftmost and rightmost gradually
increasing sized dots keys in the top row, and then pressing the
M-for-Mitch key?


Devel mailing list

Is Project Ceibal violating the GNU General Public License?

2009-08-24 Thread John Gilmore
Re: [Sugar-devel] RFH - Journal corruption reports fom 8.2.1 users in Uy 
 Remember that Ceibal XOs have root access locked-down. And I recently found 
 out that since the key-delegation stuff was implemented, we can't request 
 developer keys. Not from OLPC at least, and LATU is not providing that 
 that I know...

Could someone please clarify this?

It sounds like Project Ceibal is explicitly violating the GNU General
Public License on much or all of the software that it ships:

  *  It provides binaries without source code, and without a written
 offer of source code.

  *  It provides binaries in a physical form (laptop) which is
 protected against modification by the end-user, so that those
 users cannot replace the GPLv3-licensed software on the laptop
 with later versions.  More than 20 packages shipped are GPLv3
 licensed, as of 12 months ago, including the Coreutils (most
 shell commands), tar and cpio (used for software updates), and
 gettext (internationalization).  GPLv3 requires that the relevant
 passwords or keys must be supplied to the end user -- including
 both the developer key and the root password.

  *  Some programs are modified, but the modified versions are not
 marked to distinguish them from the original GPL-licensed

There are other less important violations as well (most are documented
at; search for GPL).

I would be happy to learn that the children receiving these laptops
have full access to source code, ability to upgrade their laptops
at will, and can tell modified from unmodified software.  Please let
me know what is really happening in the schools of Uruguay.

John Gilmore
Devel mailing list

Re: Power, time keeping, networking...

2009-08-11 Thread John Gilmore
Hal, you're asking a lot of great questions.  Basically, we could
never turn on the original power management design by default, because
of too many bugs in the periphery (USB, timers, clocks, network, etc).
The bugs are well documented in Trac.  The final XO-1 software release
added the ability to turn off the WiFi chip when you close the lid,
which meant suspended laptops would last ~40 hours instead of ~8.  It
was hard in the trenches to focus on those bugs (among all the other
bugs and feature requests), because each one seemed like a who-cares
nit.  But from a strategic level, they were in the way of doubling
battery life.  The team was gradually knocking off those disabling
bugs, when OLPC ran out of money and had to lay off most of the
software team.

They then noticed that it was getting hard to buy some almost-obsolete
XO-1 components, and OLPC performance wasn't going up every year like
most PC vendors' products.  So OLPC put all their power-related
efforts into making the XO-1.5, picking a Via CPU chipset with a much
better chance of being able to suspend buglessly for subsecond
intervals, and improving the charger's solar panel efficiency.  The
chip and board are working in prototype, production is coming, but
they haven't had time (as far as I know) to actually debug deep
subsecond suspends on it.  So, if you have serious time to be able to
help, ask for a prototype board and help with that work.

Nobody at OLPC understood the clock goes bad if you suspend problem;
they wanted to fix it by slamming in a new clock value every once in a
while (like at reboot, or re-association with a school server).  Yes,
I think the problem is that they're reinitializing with the value from
the RTC, without accounting for the subseconds.  The XO-1.5 hardware
keeps the clocks and interrupts running during suspend, so it should
not need that kludge.  I encourage you to run NTP on it for long-term
testing, and document and/or fix any clock anomalies that you find.

Devel mailing list

Re: Disk layout for XO-1.5 (LVM reliability)

2009-08-04 Thread John Gilmore
LVM has a level of appeal.  But it caused me a lot of trouble once.
I'd built a striped ext2 filesystem using it, so I could get enough
disk bandwidth to record raw sampled HDTV radio signals in realtime,
using Mandrake Linux and GNU Radio.  When I upgraded that system to
Fedora a few years later, the new LVM wouldn't read the old LVM's
partitions, making that filesystem inaccessible.

Turned out there was a bug in the old Mandrake LVM that put the wrong
metadata onto the second and subsequent stripes of a partition.  The
new Fedora LVM checked that bad metadata and barfed.  It ended up
impossible to fix without going under the hood, understanding the
block layout and the metadata, and doing some hand editing of the
disk.  It was also impossible to copy the data out while keeping the
old disks read-only, violating another of my long-standing sysadmin
strategies.(*) Ultimately there wasn't that much under the hood --
LVM is a simple format -- but it didn't provide the bulletproof
reliability that I've come to expect from, say, MSDOS partition

John Gilmore

(*): ext3 filesystem recovery also has this dubious property -- even
if you mount such a filesystem read-only, ext3 will scribble on it, if
if finds an unclean journal, rather than just recovering into its
own in-memory data structures.  And it gets harder every year to find
disk drives (or flash drives) with hardware write-protect switches or
jumpers; you end up having to use 'forensic' interface tools to truly
prevent software from writing to a drive whose contents you cherish.
Every flash drive I stick into a Mac, for example, just so it can read
something off the drive, ends up with a root directory full of trash
files created by the Finder.  The OLPC's Finder used to do the same,
and perhaps still does.
Devel mailing list

Re: Sugar as operating system

2009-07-21 Thread John Gilmore
  More seriously, I don't know if it is possible, but getting Nicholas
  to stop making a scrambled egg out of the software stack with his
  omelet analogy would go a long ways to reducing the confusion in the
  media as well. His continued insistence that Sugar is an operating
  system--the problem--is being spoken out of ignorance and does not
  reflect well on either project. As you know better than most, the bulk
  of the software engineering effort at OLPC has been in support of
  getting the hardware to boot, drivers, security, power management,
  etc. All critical tasks, whether or not this is an education project.
  Sugar (or any other user-facing) bits have always been and still are
  almost entirely separate from these engineering necessities, as is
  content development and the bulk of the deployment work.

I heard a ring of truth from Nicholas's last remarks, even if you
didn't, Walter.  OLPC needed to pull off too many miracles to ship
the XO-1, and one of those miracles that didn't work was the total
rewrite of the GUI.

Not just rewriting all the applications, ignoring the hundreds of
useful ordinary Linux GUI programs that still don't work on the XO.
But making your own window manager and insisting that any program had
to be sugarized to run on the machine was Icarus-style hubris.  That
then required rewriting all the ancillary control panels including
power management settings, WiFi selection and passwords (which had
endless bugs), two or three brand new software update mechanisms, the
DRM, the worm security model, building your own Linux distro releases,
etc.  It was all fun research, of course.  But doing all that stuff
*before* being able to ship hardware was makework that OLPC could ill
afford.  There's still a lot of hardware potential in the XO-1 that
the software never got its chops together to exploit -- but three
years have gone by and all the work is going into new hardware.

The other major challenges were plenty hard enough.  Netbook companies
figured out that they could ship tens of millions of laptops without
all that makework.  Some of OLPC's most important innovations (like
auto-suspend) have never recovered because they didn't get enough
attention.  (It's shipping, but not on by default, because of too many
serious bugs -- so battery life is half what it ought to be).

I'm glad that the team learned those lessons, painful as it has been.
The XO-1.5, installing a standard Linux release, with Sugar as an
option, will take an order of magnitude less software work, if
those lessons have really been taken to heart.

Devel mailing list

Re: New kernel branch for XO-1 and XO-1.5 development

2009-07-09 Thread John Gilmore
 Given that
 we are building the for completely different CPU core, we will need 
 different kernel RPMs to make sure our kernel is optimized for the 
 given machine.

Optimization is one thing; functioning is another.

Fedora *functions* on just about any x86 system you boot it on.  A
Fedora kernel with OLPC's patches should also *function* when you boot
that kernel on any x86.  Including XO-1 and XO-1.5.

I don't know many people who actually recompile their Fedora kernels
and flip all the hundreds of config switches to optimize their
kernel for their hardware.  The vast majority just run the stock
kernel, which optimizes the human cost of sysadmin, future upgrades,
security patches, etc.

There was a long debate on the Fedora list about desupporting the
586 so the stock distro could be compiled for the 686.  The problem is
that it breaks *function* for a cheezy optimization of way less than 5%

A tiny number of features (e.g. PAE kernels that use more than 3 GB
of DRAM) require a kernel reconfig/recompile; the rest just happen at
runtime.  OLPC's chip and board support should happen at runtime, like
everybody else's.

With regard to optimization, OLPC is in a tighter position than most
Fedora users, particularly on the XO-1 at 256MB of DRAM.  It might be
worth shipping a custom-configured kernel for the XO-1 to save a meg
of RAM (if it actually did save that much).  A better but harder
approach would be to fix the stock kernel so it can discard more
portions of itself that aren't used on the running hardware.


PS: Someone on the kernel list reported that compiling with
-march=atom made his Geode faster than compiling with -march=geode.
The theory that each board's kernel would be faster when recompiled
for Via vs. Geode should be tested.
Devel mailing list

Re: [Sugar-devel] poor man's mmap sliding window on Python 2.5.x

2009-07-08 Thread John Gilmore
 The process is doing a linear read through the file, and is slow
 enough that it appears only to grow. But if I run another process that
 allocates a lot of memory, then the kernel does discard pages pages.

So are you saying that two identical processes that mmap large amounts
of memory, (much larger than the DRAM and with no swap space), then
walk sequentially through the memory, will split the memory evenly
among them, and will complete in a reasonable amount of time.  But one
process will get very slow and never complete?

Sounds like a reproducible test case like that would be worth
reporting to the linux-kernel mailing list, to see if anybody
recognizes the bug, or wants to go hunting it.

Devel mailing list

Re: New kernel branch for XO-1 and XO-1.5 development

2009-07-08 Thread John Gilmore
Congratulations on the merge.

 Note that currently there is nothing keeping anyone from installing a
 kernel meant for one gen machine on a different gen machine. Just 
 don't do that. :)

Eventually if both machines are going to run a standard Fedora
release, the same binary kernel will have to be able to run on both
(and figure it out at runtime, like it does with most other x86-based
systems).  I'm presuming from your message that that's scheduled to
happen some time ... later ...

Devel mailing list

Touch-screen OMAP3-based netbook as XO-2 prototype?

2009-07-07 Thread John Gilmore
The new Touch Book by Always Innovating looks interesting as a
possible prototype for the XO-2.  It looks vaguely like an ordinary
netbook, but the electronics are behind the screen as in the XO-1, as
is one of the batteries.  So the keyboard half can detach from the
screen/electronics package.  The two are connected via USB (and the
keyboard provides a second battery, doubling life to 10 hrs).  $299 in
quantity one ($399 with keyboard).  Fanless, uses TI OMAP3, internal
SDHC card for storage, internal USB slots for connectivity.  Open
source oriented company, running Linux, XFCE, etc (Ångström Distro,
which started from OpenEmbedded).  They are willing to license the
hardware design, or even give it away to open-source-oriented
projects.  Motherboard is tiny; photo below.

What it doesn't have that the XO-2 wants:

  *  Multi-touch or all-fingers touch-screen-keyboard.
  *  Mary Lou's screens.
  *  Camera
  *  Two screens (however I bet you could attach two of them to each
 other with a little bit of USB host/host connection glue).


Devel mailing list

Re: XO-1.5 microphone testing

2009-07-03 Thread John Gilmore
 Basically, for each configuration (external microphone plugged in, and
 external microphone not plugged in), I'd like to know the following:
  - which of the 8 microphones is the one to use
  - which ports we can turn off

In reading the generic Intel HDA codec spec, and comparing it to the, it seems that the
Configuration Default registers aren't being set up properly by OFW.
These registers define the physical location, color, and type of
device connected by motherboard wiring to each pin on the codec.
E.g. Internal Mic Inside Lid versus External Green Headphone Output
1/8 Jack on Left side.  It's also easy to specify Not Connected
here.  Normally these would be set at power-on by the BIOS, and then
read by the software in order to properly label the various audio
controls.  This design avoids needing separate software driver mods
(kernel quirks) for every single model of motherboard or laptop.
(These register contents are not retained over a full codec
power-down, so the kernel would probably want to save a copy from boot

I hope you'll test with both mono and stereo external microphones.
The new hardware supports analog stereo input (and mic).  It'd be a
shame to turn that capability off in software because it was only
tested with an analog mic.

I think it should be possible to turn the mic bias on and off in
software (allowing the mic port to be used as Line In).

It should be possible to turn the headphone output into an unamplified
Line Out.

Testing the OLPC-specific analog sensor input mode would be very
useful.  Given the stereo input jack, this would give experimenters
TWO analog inputs.  (Somebody should tell XXX who's uploading
a bunch of instructions for making analog sensors on the wiki;
e.g. XXX).

It would also be useful to test the higher sample rates and larger
sample sizes (24-bit samples, at 192 ksamples/sec outbound or 96
ksamples/sec inbound).  I've had trouble with those settings on an
Acer netbook, for example.

If the microphone LED is on a GPIO under software control, independent
of the hardware's actual ability to listen on the internal mic, then
the LED isn't providing any useful function.  (In which case that LED
hole might as well be used for sensing the brightness of the light
falling on the screen; one of the audio ADC's might be useful for

Devel mailing list

Re: Journal and filenames on USB disks - more leases.sig problems

2009-06-30 Thread John Gilmore
 Is there a better way to do this?

Don't use Browse as if it was a real web browser.  Don't use the
Journal as if it was a real file system.

Run Firefox, not Browse.
Open up a terminal and do what needs doing.

You've just stumbled on one tiny corner of the problem that the Sugar
tools don't teach kids about real hierarchical file systems, and don't
provide access to real hierarchical file systems.  So kids don't get
access to source code (for reading or writing) because they can't grok
the structure in which it's stored.  Nor access to anything else, like
lease signature files.

Devel mailing list

Re: giving kids a platform to create their future

2009-06-11 Thread John Gilmore
  Personally, I feel it is a mistake for the OLPC project to continue with the
  concept of the Sugar platform as its exclusive model for an educational
  computer.  The Sugar applications (activities) could just as well be run
  from the Ubuntu desktop.  Then students would actually be learning in an
  environment that can take them into the real-world that grown-ups occupy on
  computers, when they are ready to go beyond the Sugar applications.
 Instead of making children do what *we* think is right (I am running
 34 years behind my daughter), how about giving *them* a platform and
 asking *them* to create what they think will be their future?

Sounds like a great idea.  OLPC hasn't done that.

Kids who have never heard of a file or a file system are not going
to be able to edit source code.  Source code exists in files which
exist in file systems.  The Sugar interface deliberately obscures the
file system in favor of blog-like chronological ordering of activities.
No source code control system or interpreter works like that --
including the one the OLPC software is written in, Python.

If Sugar taught the kids how to navigate among and examine the
thousands of files already sitting on their laptops -- or merely
enabled the kids to explore it on their own -- then there might be
some case for the Sugar XO being a platform for kids to create their
own software.  Today that promise remains unfulfilled.


PS:  The kids can hack in little, quirky, restrictive environments
like TurtleArt or eToys, and what they learn there is useful.  But
it certainly doesn't prepare them to hack the Python GUI (or any
other conventional interpreted or compiled program), nor to take
over some or all of the job of evolving the XO operating software.
Devel mailing list

  1   2   3   >