Re: [RFC] obtaining and using field samples of XO system images

2008-09-06 Thread Martin Dengler
On Fri, Sep 05, 2008 at 03:00:35PM -0300, Erik Garrison wrote:
 -= Question =-
 
 How are we planning on obtaining simple information such as [1]
 which activities are most used/downloaded, [2] which ones generate
 the most data, [3] common software failures, [4] bug manifestation
 rate etc.?
 
 -= Proposal =-
 
 The diagnostic process could be as simple from the country's perspective
 as: 
 
   1) dropping a USB key containing the system-copier script into the
  machine in question booting, and waiting for shutdown, 
 
   2) then inserting the system-copier key (now containing an image of the
  target system) into an XO running an XS build with a diagnostic
  script attached, 
 
   3) which produces a report and automatically sends it to a server on
  our end for further analysis.
[...]
 Thoughts?

How about:

1) Teaching the Sugar Control Panel System updater how to patch Sugar (Glucose)

2) Patching Sugar (Glucose) to collect/maintain [1] and [2] - this
feels like a very minor amount of data that are very useful

3) Developing any number of ways to get those data home to 1cc (new XO
activity, XS script, USB stick with a collector script that copied the
collected data to itself and then was used as in your step #2).

I seem to remember a discussion about automatically sending somethign
back to 1cc, but I think it was just before my time.  Any pointers
to that discussion welcome (so as not to needlessly repeat it...).

 Best,
 Erik

Martin


pgpHCiObHx16l.pgp
Description: PGP signature
___
Devel mailing list
Devel@lists.laptop.org
http://lists.laptop.org/listinfo/devel


[RFC] obtaining and using field samples of XO system images

2008-09-05 Thread Erik Garrison
Devel,

-= Some background =-

Today on [EMAIL PROTECTED] and [EMAIL PROTECTED] There has been a discussion
of the security rammifications of an automatic save-nand usb key script:
http://lists.laptop.org/pipermail/security/2008-September/000488.html

The immediate use for this script was acquiring system images from the
repair center here at LATU in Montevideo for use in tests of upgrade
procedures.  We need to know if certain failure modes arise commonly on
the deployed systems, but presently there are no field samples to test.
Because there was not immediate support for signing the script I am
using the developer-key approach to copy the images.

In the process of this discussion I suggested that a system-copier USB
script would be a valuable point-of-entry tool for data analysis of our
deployed systems.  Currently such a system does not exist, and we
consequently lack valuable information about the usage of our systems
(XO and Sugar).


-= Question =-

How are we planning on obtaining simple information such as which
activities are most used/downloaded, which ones generate the most data,
common software failures, bug manifestation rate etc.?


-= Proposal =-

The diagnostic process could be as simple from the country's perspective
as: 

  1) dropping a USB key containing the system-copier script into the
 machine in question booting, and waiting for shutdown, 

  2) then inserting the system-copier key (now containing an image of the
 target system) into an XO running an XS build with a diagnostic
 script attached, 

  3) which produces a report and automatically sends it to a server on
 our end for further analysis.

Alternatively a future firmware could provide a menu to all users which
included a nand-save script, but this would not be useful until deployed
systems were upgraded to run it.

We could request that, in order to better our software development
efforts, that a repair center executes this diagnostic process randomly
on machines which come in from the field with problems that are
most-likely hardware-related.


-= Comments =-

Such a system would have been extremely useful during the recent NAND
Full crisis.  During this event hundreds of laptops had to be sent back
to the Uruguay's repair center because their NAND Flash filled with junk
data created by http://dev.laptop.org/ticket/5637.  Obtaining
information about the problem an the state of the machines proved to be
a bottleneck in the resolution process.


Thoughts?


Best,
Erik
___
Devel mailing list
Devel@lists.laptop.org
http://lists.laptop.org/listinfo/devel