Re: dnshash update.

2011-04-16 Thread Michael Stone
On Tue, 12 Apr 2011 at 18:41:05 -0400, C. Scott Ananian 
On Sun, Nov 15, 2009 at 10:04 PM, Michael Stone wrote:
 I recently taught dnshash to ping potential addresses before returning them
 as results. This isn't a great solution, but it does appear to fix the
 problems observed in the use of the first version of dnshash with ssh and
 firefox and is therefore recommended for further testing.

 Michael -- I'd like to get an update on your work w/ this during my
 mesh week next week.  Could you give me a brief update on code
 status, results of testing, other thoughts re: mesh?


Here's a review of the current status of dnshash, a brief explanation of a
failed alternate design that should inform other design attempts in this area,
and an explanation of how you might go about porting dnshash to Android. Also,
since this email is quite long enough already, I'll respond to your request for
other thoughts re: mesh on another occasion. :)



## Status Review

   1. [Dnshash] is currently implemented as a (e)glibc [NSS] plugin, enabled
  through /etc/nsswitch.conf.

  This approach:

* is usable by programs running on Linux that use e(g)libc's
  getaddrinfo() to do DNS resolution.

* is probably straightforward to port to other operating systems and
  libc implementations with extensible getaddrinfo() implementations.
  (For the details for Android, please see the section below entitled
  Dnshash on Android.)

* is not applicable to programs that do their own DNS resolution.
  (Also, the other obvious design for these programs turns out to be
  unimplementable due to unsatisfiable hard constraints described in the
  section below entitled Alternate design: recursive resolver.)

   2. As mentioned above in November 2009, it turns out to be important, due to
  some popular programs' use of lengthy TCP timeouts, to avoid returning
  addresses without some evidence that the addresses are actually

  The current solution (shelling out to ping6) to this problem is hackishly
  implemented but seems to work okay under very light testing and has the
  great benefit of simplicity compared to the alternate designs of doing the
  pinging in the plugin itself (hard due to the need for CAP_NET_RAW) or in
  a daemon (a complex shared resource).

   3. Regarding testing: dnshash has been tested successfully a handful of times
  in the past 18 months in two network scenarios:

a) a physical network of 2-3 laptops running a mix of
   current-at-the-time versions of the Debian, Fedora, and OLPC
   operating systems all associated with a shared 802.11(g) access point

b) a logical network built on top of Linux's network namespaces
   (CONFIG_NET_NS), ethernet bridges (CONFIG_BRIDGE), and virtual 
   device pairs (CONFIG_VETH) running on a current-at-the-time Debian

  In each network scenario, the Installation, Use, Testing, and Cleanup
  test procedure was performed as described in the dnshash [README]. No
  errors were found.

  Finally, the set of planned but unscheduled testing work currently

* finishing the incomplete automation of the setup procedure for the
  logical network scenario available in the ``, `test_gai.c`,
  and `newnetns.c` helpers in the dnshash git repo,

* extending the logical network scenario to use the `netem`
  (CONFIG_NET_SCH_NETEM) traffic shaper to construct reproducible
  simulations of the effect of various packet loss, delay, and jitter
  processes on dnshash performance,

* testing more client software and more input sequences.


## Alternate design: recursive resolver

The NSS-plugin approach that I wound up implementing was always intended to be
a quick hack on the way to a real implementation in the form of a modified
local recursive resolver (probably based on djbdns' dnscache).

Unfortunately, this backup plan is impossible because the design space is
overconstrained as follows:

   1. IPv6 has only one link-local prefix, fe80::, for all interfaces.

   2. A single link-local address (e.g., fe80::3) may be bound to arbitrarily
  many interfaces so long as it is bound to at most one interface per link.

   3. As a result of (1) and (2), link-local addresses are ambiguous: they
  don't, by themselves, give an IP stack with multiple interfaces enough
  information to figure out which interface to use to emit packets whose
  destination address is link-local.

   4. Problem (3) was fixed in October 1998

Re: Mesh Potatos and OLPCs?

2011-03-23 Thread Michael Stone
On Wed, 23 Mar 2011 at 20:47:44 -0400, Ed McNierney wrote:
 While I am not familiar with the Mesh Potato, I have spent some time trying to
 figure out whether wireless mesh networking is really as hard as the OLPC
 universe seems to find that it is.

tl;dr: Mesh Potatoes might make decent APs for XOs but physical- and
802.11-level constraints will probably prevent them from succeeding in the
densely packed, radio-congested classroom environments where the XO-1's
draft-802.11(s) implementation presently fails.

See below for the gory details.

 I have come to believe that both wired and wireless mesh networks are really
 doing pretty well out there in the world, *provided* the nodes are immobile, 
 relatively so.

The keys to success seem to be unicast, immobile, sparse, proactively
routed, carefully sited, actively managed, and better antennas.

 The examples you point to seem to fall into the immobile wireless category,
 and I think one is likely to find reasonable success in that field.  And I
 don't mean *really* immobile, but rather don't move about very much.  The
 wireless multi-room music systems from Sonos, for example, seem to use 
 mesh pretty successfully, but the nodes are pretty stable.  And they don't get
 very dense (you don't put 30 sets of stereo speakers in one room).

 I have not found any examples of either (a) dense wireless mesh or (b) highly
 mobile wireless mesh.  In case (a) I assume that is normally not a problem, so
 it's not being solved.  In case (b) one encounters the classic OLPC mesh
 problem - 50 laptops scattered about in children's homes at night all want to
 act as mesh nodes, while those same 50 laptops all go into the same classroom
 the next day where they DON'T want to all act as mesh nodes (i.e. they create
 case (a)).  I don't know of anyone who has successfully solved that problem,
 other than by the less-than-satisfactory route of giving the users a switch 
 expecting them to turn mesh on and off as they move.

 So I believe many people are having successes with relatively static wireless
 mesh networks, but I also believe that no one is having success in the 
 OLPC has always wanted to support.  If my latter perception is wrong I would
 love to know of a counterexample (using any hardware, not just XO laptops).

--8-- (the gory details) --8--

Here's what I've learned in the last two years, divided into three sorts of key
points, about why this problem is actually hard:

   a) the media access control algorithm implemented in the XO-1 mesh is a
  jazzed-up version of the 802.11 Distributed Coordination Function (DCF)

   b) the 802.11 DCF was analyzed [2] from first principles, with simulations,
  and with physical measurements at MIT in 2001

   b) this choice of MAC algorithm, independent of /all/ higher-level protocol
  considerations, governs the fundamental behavior of the network, and

   c) the from-first-principles results, the simulations, and the experimental
  measurements cited all agree that per-node capacity:

 1) is bounded above by O(n^-0.5) (with annoyingly small constants)
 2) is inversely proportional to node density
 3) is highly sensitive to network congestion

These physical constraints are exacerbated by three sources of broadcast:

   i)   layer 2 route selection, where routes expired every ~5-15
seconds to cope with a rapidly changing radio environment

   ii)  DHCP broadcast, (and in other designs, IPv6 router advertisements, and
IPv6 duplicate address detection)

   iii) flood-fill broadcast implementations of IP-level multicast, which was
primarily used by mDNS and Salut

and by two differences between ad-hoc broadcast and infrastructure unicast,
which are that

   iv)  broadcasts must be sent at a Supported Basic Rate [e.g., of 1 Mbps]
instead of at the full Transmit Rate [e.g., 54 Mbps], and

   v)   broadcasts are not acked, which forces higher-level protocol retransmit
timers to fire more often, thereby triggering more broadcasts.

Together, these facts appear to me to be sufficient to explain why the OLPC
XO-1's draft 802.11(s) implementation exhibits the behavior we've all observed:
i.e., tantalizing possibilities in lab experiments with small numbers of nodes
in quiet radio environments and congestion collapse in school-like settings.



Devel mailing list

Re: 11.2.0 development build 14 released

2011-03-20 Thread Michael Stone
On Sun, 20 Mar 2011 at 18:46:12 +, Daniel Drake wrote:
 On 20 March 2011 18:05, C. Scott Ananian wrote:
 so fakeroot (at least debian/unstable's version of fakeroot) should be
 able to handle this just fine.
 You're right, this should work.
 But it doesn't, even with fakeroot 1.14.5.
 Test case:
 As root:
 mkdir test
 echo closed  test/closed
 chmod 000 test/closed
 tar -cf test.tar test
 rm -rf test
 As user:
 tar -xpf test.tar
 ls -l test/closed
 cat test/closed
 Last command gives error.
 Now exit from the fakeroot and:
 ls -l test/closed
 The 000 permissions somehow fell through onto the real filesystem, but
 in your more simplistic testcase the 000 permissions stayed only
 within the fake environment of fakeroot.
 So..tar must be doing something different from chmod when applying 

A quick strace with fakeroot-1.14.5-2 and tar-1.25-3 on Debian Squeeze suggests
that tar is running something like:

   umask(022)  = 0
   umask(0)= 022
   mkdirat(AT_FDCWD, test, 0700) = 0
   newfstatat(AT_FDCWD, test, {st_mode=S_IFDIR|0700, st_size=4096, ...}, 0) = 0
   openat(AT_FDCWD, test/closed, 
   write(4, closed\n, 7) = 7
   dup2(4, 4)  = 4
   fstat(4, {st_mode=S_IFREG, st_size=7, ...}) = 0
   utimensat(4, NULL, {{1300653754, 616972565}, {1300653712, 0}}, 0) = 0
   fstat(4, {st_mode=S_IFREG, st_size=7, ...}) = 0
   fchown(4, 0, 0) = -1 EPERM (Operation not permitted)
   close(4)= 0

...and, sure enough, we have a bug [1] entitled fakeroot: handle openat() and



Devel mailing list

Re: Content-Centric Networking.

2011-02-18 Thread Michael Stone
On Fri, 18 Feb 2011 at 11:00:52 -0500, C. Scott Ananian 
 Recapping for the list: Jim Gettys sent me a pair of papers to read
 yesterday, both linked from
 1) V. Jacobson, D. K. Smetters, J. D. Thornton, M. F. Plass, N. H. Briggs,
 R. L. Braynard (PARC) Networking Named Content, CoNEXT 2009, Rome, December,
 2) V. Jacobson, D. K. Smetters, N. H. Briggs, M. F. Plass, P. Stewart, J. D.
 Thornton, R. L. Braynard, VoCCN: Voice Over Content-Centric Networks, ReArch
 '09, Rome, December, 2009.
 This is very interesting work, and offers an alternative to
 In my mind, the best reason to continue to use DNS and IP routing to locate
 resources (as in the Network Principles document) is that deployments
 understand them. 

In my mind, a stronger reason for sticking with XMPP, HTTP, DNS, and IP is that
XMPP, HTTP, DNS, and IP are standardized technologies with multiple
interoperating free implementations. 

CCNx seems unlikely to reach this level of maturity in the near future (e.g.,
the next three years). 

On the other hand, if you're thinking about the problem further out than the
near future, then I have more interest in the suggestion.

 However, the CCNx approach could offer significant
 bandwidth benefits, and potentially works better in the kids go home from
 school case (the Network Principles document requires IPv6 tunnels to solve
 this mobility problem).

CCNx-over-ethernet will likely require ISPs to install new routers, no? 

And won't CCNx-over-IP will have the same mobility problem that your Network
Principles were designed to solve?

 I think the CCNx ideas would be worth exploring, but OLPC would need active
 participation from the PARC CCNx folks.  OLPC role would be
 integrator/deployer, *not* developer or researcher.
 So, with that in mind, the greatest missing piece I see is an HTTP gateway.


 Here's how it would work:  CCNx content bundles with a specially-formed name
 (like http/url/here) would get routed by specially-aware content routers
 over legacy HTTP.  The contents, once fetched, would be stored in the CCNx
 network like all other content, making it a big web cache.  Running such a
 CCNx gateway on the school server would turn it into the web cache we've
 always dreamed of (and which perhaps has been implemented in the past two

Why will a CCNx cache be more effective than a plain old HTTP cache?

(i.e., aren't the constraints on memory usage, disk usage, and network
bandwidth going to be fairly similar?) 

 This would let all of the laptops talk pure CCNx to each other,

This seems too strong. Perhaps you mean that 

   This is one small but important node on the critical path to a functioning
   laptop-borne CCNx network that preserves web access.


 without losing web access, and make the web behave better when machines are
 For bonus points, the CCNx routers would use something like rproxy ( when searching for
 content from other CCNx routers, so that slightly changing content such as
 is found more typically on the web is still highly cacheable, and we get
 even more bandwidth improvement.

This suggestion is worth forwarding to -- I would be
interested to hear their reaction.

 Both rproxy and the HTTP gateway are development projects; they're probably
 even research projects, since it's not immediately clear how HTTP's caching
 semantics (which need to be honored) translate into the CCNx namespace.  I
 don't think it's a good idea for OLPC to do research projects, but if Van
 and his team are enthusiastic about collaboration, I'd hope that OLPC would
 be willing to integrate and deploy his ideas.  The win for OLPC would be
 network bandwidth, which is a huge deal for the developing world; with
 solutions to some resource discoverability issues a secondary

There's also the issue of the communications security story for CCNx. (To their
credit, the CCNx folks have clearly indicated that this story is unfinished.)

 Note that the two papers I've read so far don't really address the resource
 discovery and naming issue. They make some suggestive remarks, such as We
 are also developing higher level name discovery mechanisms that are more
 efficient for exploring large name spaces (Networking Named Content, page
 4).  That's another area of concern for me.  As we learned the hard way,
 just finding your friends and classmates in a large school can be a
 surprisingly difficult problem, and CCNx's reliance on multicast with a
 casual reference to standard multicast suppression techniques (Networking
 Named Content, page 3) causes me concern.  But I'm sure OLPC would be more
 than willing to provide the test cases if they are interesting in proving
 that their name-discovery stuff actually works in the 

Re: Help with signing messages

2011-02-13 Thread Michael Stone

On Thu, 3 Feb 2011 at 15:02:21 -0200, Esteban Bordon wrote:
 2011/1/29 Michael Stone
 On Fri, 28 Jan 2011 at 14:40:54 -0200 Esteban Bordon wrote:

 I trying to make a notification system that reads messages from sqlite3
 database and show them via dbus notifications. I want to store a hash of
 message inside the db to verify each message before show it, but I don't
 know how I do it.

 I think sign the message using sig01 of bios-crypto but I don't know how I
 can verify this hash. Can I use some mfg-data tag to verify it (msg signed
 with masterkey appropiate)?

 Which command I have to use?

 Can you please say a bit more about the system you're building? (The choice
 of the right command almost certainly depends on some further details about
 your goals.)

Hi Esteban,

Thanks for the detailed responses and apologies for my delay in replying to

 In particular:

  * what does a typical message say?

 Institutional or relevant messages about XO and children. For example, New
 OS version is released or Your laptop will be blocked tomorrow, please
 update your blacklist

  * how are messages transmitted?

 Laptop download a XML from their school server with the messages.

  * are the messages addressed to one, many, or all possible recipients?
 (unicast, multicast, broadcast)

 All laptops should receive the same messages

I'm confused here because, above, you said that a typical message might be
Your laptop will be blocked tomorrow, please update your blacklist.

Is this kind of message supposed to be:

   * received and displayed by all laptops?
   * received by all laptops and displayed by one or more addressed laptops?
   * received and displayed only by addressed laptops?

  * are the notifications one-way or will there be replies?

 one-way, for now.

  * are the messages solely intended for humans to read or are they also
machine readable?

 This application is only for humans.

  * do you care if other people read the messages in transit? (secrecy)

 No matter, messages  can be puclic.

  * do you care if the messages are modified in transit? (integrity)

 Yes.  It's one reason for I want sign the messages.

  * is the recipient supposed to know who sent a message? (agreement on
 sender identity)

 Only school server should to send messages

  * is the sender supposed to know who received a message? (agreement on
 receiver identity)

 This feature isn't already implemented

  * do you care if a message is never delivered?
(availability / reliability)

 If XO connect to server should get the XML. I don't think it as independent
 messages, all messages are into XML

  * do you care if a message is delivered multiple times?

 No, laptop application delete duplicate messages

  * do you care if messages are reordered in transit?

 No. the application stores the messages into db file.

  * do you have other security goals not mentioned above?
(availability, resource usage limits, non-repudiation, privacy...)




Okay. Based on what you've told me here, I see three approaches that seem like
they might do what you want at reasonable cost:

   a) Online signing w/ HTTPS: 
  If you trust your school servers and your school-server technicians to
  keep secrets, then you can meet your goals with something like:
curl --cacert ...; 

  The point is to
1) open an HTTPS connection to your school-server,
2) verify the cert-chain that you receive against a previously
   distributed CA cert that you issued, and,
3) download your XML over this authenticated, integrity-preserving

   b) Offline signing w/ OpenSSL:
  If you really want to do offline signatures, for example, because you
  don't trust your school server to keep secrets, then the OpenSSL command
  line tools like openssl rsautl can probably help. 

   c) Offline signing w/ bios-crypto

  If you want to do offline signatures with the same crypto tools used for
  OFW and build signatures, then bios-crypto's cli_tool

  may be what you want.

Do any of these approaches look like they might work for you?


Devel mailing list

Re: Help with signing messages

2011-01-29 Thread Michael Stone
On Fri, 28 Jan 2011 at 14:40:54 -0200 Esteban Bordon wrote:
 I trying to make a notification system that reads messages from sqlite3
 database and show them via dbus notifications. I want to store a hash of the
 message inside the db to verify each message before show it, but I don't
 know how I do it.
 I think sign the message using sig01 of bios-crypto but I don't know how I
 can verify this hash. Can I use some mfg-data tag to verify it (msg signed
 with masterkey appropiate)?
 Which command I have to use?

Can you please say a bit more about the system you're building? (The choice of
the right command almost certainly depends on some further details about your

In particular:

   * what does a typical message say?

   * how are messages transmitted?

   * are the messages addressed to one, many, or all possible recipients? 
 (unicast, multicast, broadcast)

   * are the notifications one-way or will there be replies?

   * are the messages solely intended for humans to read or are they also
 machine readable?

   * do you care if other people read the messages in transit? 

   * do you care if the messages are modified in transit? 

   * is the recipient supposed to know who sent a message? 
 (agreement on sender identity)

   * is the sender supposed to know who received a message? 
 (agreement on receiver identity)

   * do you care if a message is never delivered?
 (availability / reliability)

   * do you care if a message is delivered multiple times?

   * do you care if messages are reordered in transit?

   * do you have other security goals not mentioned above?
 (availability, resource usage limits, non-repudiation, privacy...)


Devel mailing list

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

2010-10-07 Thread Michael Stone
 See for details. The sugar-session
 process in 10.1.2 grows slowly...
 There's some form of leak somewhere. Maybe we are triggerin a real
 python leak, maybe we have reference loops. How do we trace this?

Tomeu wrote some instructions here:  (mirror)

that might be of use to you.

Also, it looks like guppy is now available directly from Fedora, packaged under
the name python-guppy.

Devel mailing list

Re: olpc-update and deletion of old images

2010-09-06 Thread Michael Stone

First and foremost, your approach seems reasonable to me.

Second, here are some more detailed background comments:

 When olpc-update updates you from version A to version B, version A
 remains on the system and can be accessed by booting with the 'O' game
 key held down.
 As far as I know, this functionality is rarely used, 

The functionality is now rarely used because olpc-update is not used as
frequently as it used to be and because the OS image testing process is working
well enough that the fail-safe functionality has not been required at scale.

Both of these, combined with the costs you mention, seem to me to be fine
reasons for retiring the feature, so long as you think that they will continue
to hold true for the foreseeable future.

 and has inherent problems. Specifically it requires Sugar developers to be
 able to predict the future. For example, if the datastore changes in a newer
 sugar version, the new sugar version will boot and convert the
 datastore to the new format. But if you then boot the old OS version,
 you won't see anything in your journal, since the old sugar doesn't
 support the new datastore format. (similar problems could occur in
 other parts of the system)

These issues were thought to be acceptable when we thought the failsafe
functionality was important and when OLPC and its partners were prepared to
help Sugar develop in both backward- and forward-compatible ways.

They are obviously less acceptable now.

(Also, for what it's worth, we had a couple of plans on the back-burner for
filing down the sharp edges here. As I recall, they included:

a) introducing a plugin system for olpc-configure so that
   olpc-configure in the *new* build could inspect what old builds were
   available and could install best-effort downgrade scripts as needed.

b) alternately, using one of the CoW filesystem primitives we were
   experimenting with to snapshot /home as well as the OS.)

 It also brings in more headaches. While the updates are somewhat
 efficient (files that do not change between 2 versions are only stored
 on disk once), there is always a space overhead in having 2 versions
 of the system on disk. And during big updates (e.g. F9 to F11), almost
 every file changes, meaning that little disk space is left after doing
 the update.

Life sometimes requires compromises. Maybe you want to take a backup and to
reflash your system partition instead? (Or to spend for a bigger disk?)

 There is no UI to delete the 2nd stored version, the only way to do it
 at the moment is from the Terminal (not suitable for deployments).

True enough.

As a matter of idle speculation, what sort of UI would be suitable for

 My proposal is to modify the initramfs, removing the code that
 supports alternate boot (O game-key). And if it encounters an old
 version stored on disk, it will delete it during the boot process.

 Having 2 copies remains an integral part of the olpc-update process,
 but the old version would be deleted as soon as its not needed.

Makes sense to me.


Devel mailing list

Re: [support-gang] Fwd: Redesigning: Library, Read, Get-Books, and Content bundles

2010-07-24 Thread Michael Stone
Gary, Yioryos,

Here are a couple of thoughts for you on isolation issues. (I have thoughts on
the Journal issues too but I'll save them for another occasion.)

 Step 3 is to introduce marks (hyperlinks?) in Read and Write where hovering
 over you get the tag opened to tell you what is about, and clicking 
 you to the relevant book/app-mark

 As noted already this would seem to break Sugars's security model, activities
 need to be sand-boxed from each other, one activity is not allowed to resume
 another. Yea, back to Journal, again! ;)  

Let's think about this a bit more deeply. As I see it:

The key idea that Bitfrost offers is that system software needs to make it easy
for the authors of benign apps to protect human interests. (A number of useful
features are then proposed toward this end.)

The key idea that Rainbow offers is that accounts are a good device for
isolating processes.

Within this problem domain, the key idea of Sugar is that people engage in
fairly discrete sessions of activity which may be started, stopped, resumed,
and isolated from one another. 

Significant isolation is possible because data rarely needs to move from
session to another and, when it does, the motion may be orchestrated through a

Note, however, that the idea is that it doesn't matter much what actual
processes run within a given session or whether there are many windows or one,
many documents or none, many hosts contacted or none, etc.

Indeed, we shouldn't worry so much about whether Browse invokes Read in order
to render a downloaded PDF or whether Chat invokes Browse when the human
operator clicks on a hyperlink -- Browse already had complete control over the
contents and distribution of the PDF and Chat already had complete control over
the text of the URI that Browse will see.

Instead, what does matter is the ability to control what happens *when* Browse
or Chat or Read becomes circumstantially malicious. What matters then is the
ability of the human operator and the system supporting them to manage the
mappings of I/O resources to sessions -- that is, crudely, of the start new
vs. resume problem. :)



Devel mailing list

Re: [Sugar-devel] Activity packaging

2010-07-07 Thread Michael Stone
Aleksey wrote:
 On Wed, Jul 07, 2010 at 01:18:04AM -0400, Michael Stone wrote:
 Bernie wrote:
 On Tue, 2010-07-06 at 12:02 -0400, Benjamin M. Schwartz wrote:
  I think you are missing an important requirement: installation without
  elevated permissions.
  Rainbow has been bit-rotting for the past 2 years 
 Ahem. Sugar's integration with rainbow has bit-rotted, been rebuilt, and 
 received no independent testing despite repeated calls for same.

 To be honest I wasn't a fan of rainbow a bit time ago..

 But having Zero Sugar fully implemented and potential possibility to launch
 almost any piece of software... rainbow should be more then essential

Let's be clear: the actual requirement is for something more like safety or

Rainbow is merely one of several reasonable approaches -- and competition and
interoperability would be no bad thing here.


P.S. - Several other isolation shells that might be worth thinking about, if
only to better understand the tradeoffs that rainbow makes, are briefly
described at

P.P.S. - Also, either way, thanks for your encouragement. :)
Devel mailing list

Re: [IAEP] Gnome vs Sugar -- The judgement day

2010-06-25 Thread Michael Stone
 Teachers demand a technological mean to solve a problem of discipline and
 computer literacy.

Launch GNOME under a separate account with a quota and with limited or no sudo
access. This will cut out most of the mayhem, thereby buying you time to work
out a more integrated solution.

Devel mailing list

Re: Help with permissions under Rainbow sought

2010-04-18 Thread Michael Stone
Bert Freudenberg wrote:
On 18.04.2010, at 14:10, Sascha Silbe wrote:
 On Sat, Apr 17, 2010 at 09:26:23PM -0400, George Hunt wrote:

 Rainbow changes UID for every invocation [...]

 Yes, that's the default behaviour. Rainbow can be instructed to use a
 constant UID (Browse does); according to the OLPC wiki [1] you'd need to add 
 file activity/, containing constant-uid on a single line.

 This is the least preferable solution, though.
 Apparently the create mask rainbow uses is 755 and group members do not
 have write access.

 It's not Rainbow that decides this.

But arguably Rainbow could set a better default, no? Making files 

Rainbow actually calls os.umask(0) here:

However, it's entirely possible that some other logic in your program is
setting umask(022) or is creating files with an explicitly specified mode. (You
may recall that xulrunner's behavior here was the reason why constant-uid was

Hmm, how do I test if Rainbow is enabled, in a shell script, again?

If you mean is sugar going to launch the next activity it launches under
rainbow?, then test for the presence of /etc/olpc-security, e.g. with

   if [ -f /etc/olpc-security ]; then ... fi

If you mean is my script currently running under rainbow?, then I don't have a
perfect answer for you this instant. 

(A good but imperfect answer is to test whether whether getuid()  1 and
getgid()  1, e.g. by parsing the output of the id command.) 


Devel mailing list

Re: Help with permissions under Rainbow sought

2010-04-18 Thread Michael Stone
George Hunt wrote:

 I had looked for an input mechanism to Rainbow's CONSTANT_RAINBOW_UID
 without success. So thanks for your pointer.

Where did you look? 

(I'd like to go fix it...)

 I'm curious to know why you think using a constant UID is undesireable.  

Making things constant-uid in the sugar-0.82 + rainbow-0.7.* world removes all
isolation between instances of the activity.

 At this point I'm looking for ways to simplify the next stages of debugging my
 My thinking is as follows: If I can get permissions off the table as a
 source of failure, while I deal with all the other problems I haven't
 foreseen, I can come back and tighten up security when my code is more

Your reasoning seems fine to me. 

(One word of caution, though: rainbow will probably not respond well to seeing
a single activity bundle_id switch between the constant-uid and the (default)
fresh-uid setting. Therefore, you should either use a fresh bundle_id when you
switch or you should clean out rainbow's filesystem state in /etc/passwd,
/etc/group, and /home/olpc/isolation/1/.)



P.S. - I really like ipython, so I'm excited to see your activity. 

Also, if you like ipython, check out bpython.
Devel mailing list

Re: Android, OLPC, and native hosting

2009-12-27 Thread Michael Stone
 Does the XO-1 host its own development tools?  

For all practical purposes, it does not.

First, as you have noted, it takes quite a bit of bandwidth to install the
toolchain and development headers. (And you have to know what they're called.)

Second, to get anything done with C, you really need easy access to the man
pages and you need to know quite a bit about how the system is put together.

Third, you quickly run out of disk space when you try to compile things
locally. I actually got as far as linking vmlinux before I ran out of space on
my on-XO kernel compile. (Nevermind how long it took to get that far with no
swap space! :)

 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.  

The source is available from Fedora CVS and from

Devel mailing list

ANN: rainbow-0.8.6 release.

2009-12-21 Thread Michael Stone

I am pleased to announce the release of rainbow-0.8.6. Rainbow implements
portions of the isolation shell described in the Bitfrost threat model and
security architecture.

The key differences between this release and its predecessor include support
for garbage collection of uids, ui sugar for resuming uids, bug fixes to the
resume logic, and a simplified singly-linked list library.

This release was made possible by encouragement and suggestions from Sascha
Silbe, Bernie Innocenti, and Benjamin Mako Hill. It has been (minimally) tested
on Debian Sid, Ubuntu Karmic, and Fedora Rawhide and has been packaged in
Fedora Rawhide for your convenience.

Interesting links for this release include:


The shortlog from rainbow-0.8.5..rainbow-0.8.6 is:

Bernie Innocenti (1):
   Capture XAUTHORITY.

Michael Stone (19):
   Remove unused flexibility from the spool option parsing code.
   First pass at updated rainbow-gc.
   Clean up group membership.
   Protect sticky uids from garbage collection.
   Clean up some per-uid Xephyr data.
   Improve spool detection checks.
   Install rainbow-gc.
   Add some logging to rainbow-gc.
   Make xephyr usage resumable.
   Teach rainbow to resume uids with more auxiliary groups.
   Add a simple resume subcommand.
   Add INIT() and COPY() operators from dnshash.
   Add a novel singly-linked list implementation.
   Add test_endgrent script.
   Simplify list traversal logic.
   Fix Karmic sudo segfault.
   Tweak warnings and link flags.
   Set default spool location in rainbow-gc.

Kind regards,

Devel mailing list

ANN: rainbow-0.8.5 release.

2009-11-28 Thread Michael Stone

I am pleased to announce the release of rainbow-0.8.5. Rainbow implements
portions of the isolation shell described in the Bitfrost threat model and
security architecture.

The key differences between this release and its predecessor are bug fixes,
preliminary support for network isolation, and a better rainbow-sugarize

This release was made possible by encouragement from Fabian Affolter, Luke
Faraone, Martin Langhoff, and my friends at 

Interesting links for this release include:


The shortlog from rainbow-0.8.4..rainbow-0.8.5 is:

   Michael Stone (10):
   Correct a logging statement.
   Make rainbow-sugarize set up /{data,instance,tmp}.
   Temporarily disable $XAUTHORITY processing in rainbow-sugarize.
   Drop config file management from rainbow-sugarize.
   Add a network option enabling unshare(CLONE_NEWNET).
   Make nss-rainbow's return and error codes more accurate.
   Correctly calculate number of members of a struct group.
   Make getpwent() resume on the correct uid.
   Grant network access to rainbow-easy programs.

Finally, please note that:

   * rainbow-run now calls unshare(CLONE_NEWNET) unless the -o network
 command-line argument is given. This argument is given by the
 rainbow-easy helper since X11 clients are unable start without it.

   * rainbow's nss module must still be activated in /etc/nsswitch.conf in order
 for the software to function correctly. See the setup instructions linked
 to above for details.

Kind regards,

Devel mailing list

DNS Mischief, cont'd: dnshash-0.3.0 released!

2009-11-23 Thread Michael Stone

I am pleased to announce the release of dnshash-0.3.0. dnshash implements the
hash-based DNS resolver described in Scott's Network Principles document. 

The key features of this release are better testing and more reliable results. 

   * Better testing was accomplished via the network containerization features
 of recent kernels.

   * More reliable results are achieved by returning only live addresses:
 i.e., those which successfully respond to a ping within one second.

Many thanks to Bernie Innocenti for his patches, to Cortland Setlow and
Andres Salomon for assistance with testing, and to Aurelian Jarno for his
prompt assistance with (e)glibc bugs.

Interesting links for this release include:


The shortlog from dnshash-0.2.0..dnshash-0.3.0 is:

Bernie Innocenti (2):
   Eat up extra space in nsswitch.conf on 'make disable'.
   Make redirection work in /bin/sh; fix lint.

Michael Stone (8):
   Only return live addresses as results.
   Add newnetns subcommand to ease testing.
   Teach dnshash to answer AF_INET6 queries.
   Add a manual unit-test script based on network namespaces.
   Teach dnshash to specify the proper prefix for addresses it suggests 
   Tuck in modprobe instructions, just in case.
   Add maintainer script.

Kind regards,

Devel mailing list

versioned partitioned upgrading: safety boot configuration

2009-11-04 Thread Michael Stone
Hi Dan,

 I'm working on updating olpc-update and the initramfs to be able to
 work with a partitioned layout where /boot is separate from the rest
 of the system. Thanks for the good documentation at

You're welcome; apologies that it isn't better. :)

 First one, I'm implementing the Create a safety boot configuration
 bit. I guess the purpose of this is to ensure that the current running
 OS is marked as current, and to free up the other OS image (so that
 it can be deleted soon after to make space for the incoming update).


 So onto the bit I have to add:
   (If partitioned: Make /boot/alt point to ../$a.)

 I don't understand this part. Surely the instructions for /boot would be
 equivalent to what was done above, i.e. on the boot partition:
  1. make sure that /boot points at boot-versions/$a
  2. remove /boot/alt

First, understand that Scott+Mitch wrote the logic for updates with
partitions. I am only a secondary source for this scenario. The primary
source is the pre-formatted version of the upgrade procedure, which may
be found here:

Second, unfortunately, the instructions as written are *not* equivalent:
Mitch and Scott decided to simplify the partitioned design by insisting

   a) boot:/boot be a symlink pointing to 'boot-versions/XXX' 
   b) boot:/boot/alt be a symlink pointing to '../YYY'.

 Or have I just answered my own question through writing this mail? Step
 1 is deemed unnecessary (we can assume that it's already pointing to the
 right place), and your instructions are simply making the alternate boot
 configuration point to exactly the same one that is booted (hence there
 is no longer an alternative)

I concur with this answer to your question.



P.S. - Tit for tat: how is the correct root partition identified and
communicated from ??? - OFW - initramfs - ??? - updater - 
Devel mailing list

versioned partitioned upgrading: clean up / config creation

2009-11-04 Thread Michael Stone
 Last question for now:
 This part of the page seems to suggest that you only create
 a /versions/configs entry for systems where an unpartitioned layout is
 being used, and no config would be created for a partitioned layout.
 Am I reading that right?
 I'm having a bit of trouble getting my head around the whole system and
 perhaps I'm missing something obvious .. Perhaps you designed it so that
 boot configs in /versions/configs are not necessary when we are booting
 from a partitioned system, because the current and alt image hashes
 can be deduced from the symlinks on the boot partition at /boot
 and /boot/alt ?

The configs mechanism is only used for unpartitioned systems. 

The linkage from boot data to tree-ids is, as you say, recorded in the
boot:/boot and boot:/boot/alt symlinks.

I don't think the current writeup says where the contents manifests should be
stored on partitioned systems.

Devel mailing list

Re: XO automatic clock setting

2009-08-27 Thread Michael Stone
2009/8/27 Martin Langhoff
 4. sig02 leases are still unsupported in the latest OpenFirmware, but
 it looks like we have renewed interest in getting this finished off,
 so no initramfs changes will be needed in this area.

 Here Daniel skips the fact that there is a homely but IMO valid patch
 that -- when OFW tells us activate -- rechecks the filesystem for a
 valid lease before trying to activate.

 This is a good thing if we assume that the initramfs can evolve faster
 than OFW, =A0and the case OFW doesn't recognise this sig format but
 Initramfs does is a valid one.

Except, unless I missed something in the last discussion, we don't
fully understand why the system was ever designed like this. So I'm
making the assumption that there is something important that we aren't

Here is my recollection of the design thinking at the time:

OFW knows how to examine activation leases as a common-case optimization in
order to try to make booting faster. When OFW doesn't understand or can't find
a lease, it should hand the lease to the (authenicated) initramfs, which is the
last authority on whether or not to hand control to userland.

We picked the initramfs as the site of this authority for three reasons:

   1. because people who can update OFW are scarcer and more frequently on other
  critical paths than people who can update an initramfs

   2. because we have a working limited rollback feature for the
  kernel+initramfs already implemented in the firmware

   3. because it seemed easier to Scott at the time to deal with communications
  with the environment from Linux than from OFW

Regards, and keep up the good work,


P.S. - I will try to make time to assist you with a more serious review per
your earlier request.
Devel mailing list

Re: [Sugar-devel] erasing the journal and config

2009-08-27 Thread Michael Stone
 Luke Faraone wrote:
 James Cameron wrote:

 I've tested this method only on unlocked laptops.  For locked laptops
 some similar method might be used.

 For locked laptops you would *need* to get a developer key, or have OLPC
 sign the file. The latter won't happen.

OFW's recently-added multi-key support:

has been used by several deployments (including Uruguay and Paraguay) who might
be interested in producing a wipe power.

A scheme similar to the activation lease generation scheme could also be used
to rate-limit how quickly such a power could be invoked.

Devel mailing list

Re: DNS Mischief

2009-07-12 Thread Michael Stone
On Sun, Jul 5, 2009 at 8:36 PM, Michael wrote:
 d)  rewrite as an NSS module?

This turned out to be only a few minutes' work and the result is really easy to
compile and install. See

and the accompanying helper scripts

   dnshash_attach   --  add addresses for `hostname --fqdn` to your interfaces
   dnshash_detach   --  remove said addresses
   dnshash_lookup   --  a thin wrapper around getaddrinfo(); eases testing

Enjoy, and please test,

Devel mailing list

Re: FIltering out languages via kickstart

2009-07-10 Thread Michael Stone

I like your answer but I think that it leaves some important goals unstated --
most notably, click2trans, horizontal distribution of translations, and
translation undo.

See and for the writeups 
and for the prototype code.




Devel mailing list

Re: DNS Mischief

2009-07-08 Thread Michael Stone
On Sun, Jul 5, 2009 at 8:36 PM, Michael wrote:
 d) rewrite as an NSS module?
 e) rewrite in an external DNS resolver?
 Either of these would make it much easier to play with your patch,
 eliminating the whole now recompile your C library from scratch
 step. ;-)  

Pff. It got us this far. :)

 (d) would be the cleanest, and the code involved ought to
 be quite short.  With (e) you could make the names available to other
 machines our your local network, which could be cute (or awful, as you

The real advantage of (e) is that you can make it work on many platforms. The
problem with (e) is that it seems to take more than 80 lines of code.

 Network-disconnection issues also bear thinking about -- if you use a
 local IPv6 address for a local resource, can you handle its migration
 to the real network later as it roams off the mesh?  (It might be
 easiest to handle this as a clean disconnect/reconnect rather than
 going down the mobile IP path.)

I've thought a bit about this and, for the time-being, my cost/benefit analysis
(and recent professional experience) argues in favor of making apps better at
tolerating address changes in preference to going down the mobility road.

 Thanks for running with this idea, Michael!

My pleasure; thanks for taking the time to reply to me.

 (Although wearing my security hat I'd have to caution that MD5 has been
 deprecated for 13 years now, and even SHA1 is not recommended for new use.
 Use -- it's just two files to add, tomcrypt
 not required.)

I agree that MD5 and SHA1 are deprecated as /cryptographic/ hash functions,
but I don't think that we care. Here's why:

Cryptographic hash functions are characterized by three notable properties: 

1. preimage resistance

for a fixed result R, how hard is to it to find a message M such that
H(M) == R?

2. second-preimage resistance 

for a fixed message M, how hard is it to find M' != M such that 
H(M) == H(M')?

3. collision resistance

how hard is it to find two distinct messages M, M' such that H(M) ==

My claim is that we only care about second-preimage resistance against a random
attacker (as opposed to an optimal malicious attacker). 

I believe that this is true because I think that second-preimage attacks by
random attackers accurately model the risk that a user types in a domain name
which, /by chance, rather than by malice/, happens to hash to an address that
collides with an address already being provided by a different service on the
network, or, equivalently, the risk that a user randomly chooses a name the
hash of which collides with the hash of an already present name. 

(In my present view, plain DNS was never meant to handle the threats posed by
malicious adversaries and it should not be relied upon to do so. Those risks
are, in my view, more adequately controlled by other tools like petnames,
reputation systems, PGP, SSH, and TLS.)

Am I just plain wrong?

 (Ob code review: I think you just want to fabricate a new link-local
 address entry based on the hash, rather than cloning and altering the
 existing LL address.  Link-local addresses have the prefix fe80::/64,
 with the lower 64 bits constructed from the first 64 bits of

I chose to clone existing addresses because I thought it was a convenient way
to get the addresses' zone ids (called sin6_scope_id in the sockaddr_in6 
right. Have you got a better way to do this part?

 You also should probably make sure that the hostname you're hashing is the
 full canonical host name, ie (note trailing
 dot) not cscott or cscott.skiffserv or some other abbreviation.  

Hmm. I can see why you might want that from a network principles standpoint,
but I'm not sure that I'm convinced by your argument.

I guess: patches welcome. :)


The design issue that I find myself most interested in after having gotten this
far is: 

My current design is not in any way integrated into the recursive name
resolution process. This means that people who want to bind multiple names must
do so by adding an address to all their interfaces/zones for each name they
want to bind.

On the other hand, if I made something that were integrated into the name
resolution process, they could just run a nameserver for their domain and then
everything else should just work. (I think.)


Kind regards,

Devel mailing list

DNS Mischief

2009-07-05 Thread Michael Stone

As many of you know, I've been fascinated for some time by Scott's Network
Principles [1]. 

Several weeks ago, I outlined in a lightly-circulated patch how one might hack
up libc's getaddrinfo() implementation to do the DNS resolution work described
in Scott's paper.

Here is a second copy of that patch, which I have improved to the point where I
am willing to recommend it for further testing, adaptation, and exploration.

(This new version uses libcrypt's MD5 implementation in favor of pulling in
chunks of libtomcrypt and it includes the minimum knowledge of gaih_service
structs necessary to work with ssh, wget, etc.)

To build it, grab your distro's libc6 packaging, apply the patch to
sysdeps/posix/getaddrinfo.c, and make sure that you define 

  crypt-in-libc = yes 
in an appropriate configuration file. Then build normally. Some tests for

getaddrinfo() will fail but you should wind up with a fully functional which you may install or use via LD_PRELOAD like so:

  # calculate an address for sonipes
  LD_PRELOAD=/path/to/ python -c 'import socket; print 
socket.getaddrinfo(sonipes, None)'

  # suppose we get fe80::b3da:e0e7:3bd7:278d%eth0

  # on sonipes:
  sudo ip addr add fe80::b3da:e0e7:3bd7:278d%eth0 dev eth0

  # elsewhere, on another computer on the same link as sonipes
  sudo env LD_PRELOAD=/path/to/ ping6 sonipes
  LD_PRELOAD=/path/to/ ssh sonipes
  (rsync, wget, nc6, ...)




P.S. - Improvements are definitely welcome -- I found the code very satisfying
to use on a local wireless network.

  a) provide a cute one-liner for assigning appropriate addresses to interfaces
 based on the machine's desired hostnames

  b) check the code for endian-neutrality

  c) figure out how to fully build and package the result for easier testing

  d) rewrite as an NSS module?

  e) rewrite in an external DNS resolver?
diff -u eglibc-2.9/debian/changelog eglibc-2.9/debian/changelog
--- eglibc-2.9/debian/changelog
+++ eglibc-2.9/debian/changelog
@@ -1,3 +1,11 @@
+eglibc (2.9-13.1) unstable; urgency=low
+  * Non-maintainer upload.
+  * debian/rules.d/ build libcrypt into libc
+  * debian/patches/any/hack-up-getaddrinfo.diff: install getaddrinfo hack.
+ -- Michael Stone  Sat, 04 Jul 2009 19:06:59 -0400
 eglibc (2.9-13) unstable; urgency=low
   * debian/ fix return code when querying status
diff -u eglibc-2.9/debian/rules.d/ eglibc-2.9/debian/rules.d/
--- eglibc-2.9/debian/rules.d/
+++ eglibc-2.9/debian/rules.d/
@@ -52,6 +52,7 @@
 	rtlddir=$(call xx,rtlddir) ; if test -n $$rtlddir ; then \
 		echo rtlddir = $$rtlddir  $(DEB_BUILDDIR)/configparms ; \
+	echo crypt-in-libc = yes  $(DEB_BUILDDIR)/configparms
 	# Prevent autoconf from running unexpectedly by setting it to false.
 	# Also explicitly pass CC down - this is needed to get -m64 on
diff -u eglibc-2.9/debian/patches/series eglibc-2.9/debian/patches/series
--- eglibc-2.9/debian/patches/series
+++ eglibc-2.9/debian/patches/series
@@ -210,0 +211 @@
only in patch2:
--- eglibc-2.9.orig/debian/patches/any/hack-up-getaddrinfo.diff
+++ eglibc-2.9/debian/patches/any/hack-up-getaddrinfo.diff
@@ -0,0 +1,111 @@
+From 55208c43bbd9ce5e21b7c9b77db6526e688ce612 Mon Sep 17 00:00:00 2001
+From: Michael Stone
+Date: Thu, 11 Jun 2009 21:04:18 -0400
+Subject: [PATCH] Hack up getaddrinfo().
+ sysdeps/posix/getaddrinfo.c |   74 ++
+ 1 files changed, 74 insertions(+), 0 deletions(-)
+Index: eglibc-2.9/sysdeps/posix/getaddrinfo.c
+--- eglibc-2.9.orig/sysdeps/posix/getaddrinfo.c	2009-07-04 19:14:10.0 -0400
 eglibc-2.9/sysdeps/posix/getaddrinfo.c	2009-07-05 13:52:29.0 -0400
+@@ -62,6 +62,7 @@
+ #include nscd/nscd-client.h
+ #include nscd/nscd_proto.h
+ #include resolv/res_hconf.h
++#include crypt/md5.h
+ #ifdef HAVE_LIBIDN
+ extern int __idna_to_ascii_lz (const char *input, char **output, int flags);
+@@ -251,6 +252,81 @@
+ }	  \
+  }
++static void
++hack_dns  (const char *name, const struct gaih_service *service,
++	   const struct addrinfo *req, struct addrinfo **pai,
++	   unsigned int *naddrs, int *ret)
++  /* XXX: Service processing! MS */
++  if (name == NULL
++   || (service != NULL  service-num  0)
++   || ( req-ai_family != AF_INET6
++  req-ai_family != AF_UNSPEC))
++  return;
++  char buf[16];
++  __md5_buffer(name, strlen(name), buf);
++  struct ifaddrs *ifaddr, *ifa;
++  if (getifaddrs(ifaddr) == -1)
++return; /* Should we set *ret? MS */
++  unsigned int old_naddrs = *naddrs;
++  for (ifa = ifaddr; ifa != NULL; ifa = ifa-ifa_next)
++  if (ifa-ifa_addr-sa_family != AF_INET6)
++  struct

Re: [Sugar-devel] Browse.xo -- preserving a downloaded filename?

2009-06-30 Thread Michael Stone
Martin Langhoff wrote:
  On Tue, Jun 30, 2009 at 7:25 PM, Bert 
  What's your use case?
 In the normal course of operation, the XOs will work with the XS over
 wireless, getting their individual leases. This is a fallback rescue
 leases.sig .

Here's a gentle suggestion on how to more quickly (but narrowly) implement this
use case: 

   why not use Pippy to write a minimal activity that downloads the leases.sig
   file [e.g. with urllib2, wget, or curl], tests for mounted USB sticks,
   prompts the user if they're missing, and that copies the leases.sig file to
   the USB stick?

I think this might be a good way to go because 

   * it'll be faster than figuring out how to solve file management,

   * it doesn't depend on anyone else making changes, and

   * it may be of some educational value to people who want to understand how
 the system actually works and how they might automate it for themselves. 


Devel mailing list

Re: overhead in a G1G1 environment

2009-05-29 Thread Michael Stone
A bit of background about olpc-update 'pushes':

 as i recall, there was/is a provision for OLPC to push (via
 that polling mechanism) updates to the g1g1 machines.

Correct. See

for details.

 i don't believe it's ever been turned on, and, in my opinion, is
 unlikely to be.

Actually, it was used, as hinted in item #9 of

to help get people onto 7.1.2 (656) which fixed several hard- and soft-bricking
bugs in previous releases. (See

for details.)

Finally, as I recall, it was not used to push 8.1.* (703) because of and

and it was not used to push 8.2.* because we didn't want to drop the UI
reorganization on people who hadn't asked for it.


Devel mailing list

ANN: rainbow-0.8.4 release.

2009-04-12 Thread Michael Stone

I've put together a new rainbow release, rainbow-0.8.4,

with three tasty new features which I think you might enjoy.

New Features

   1) support for reusing existing containers (uids)

   (this should be particularly useful for sugar since it gives activities
   persistent $HOME dirs where they may save their configuration.)

   rainbow-run option: -r 10001

   2) better data-sharing functionality through isolated topic dirs 

   (these are just groups and matching setgid group-writable directories
   like movies or banking which have both owning uids and isolated uids
   as their members -- think of sugar's per-bundle $SAR/data dirs)

   rainbow-run option: -i movies -i banking
   3) experimental support for generating nested Xephyr X servers

   (mainly as a thought experiment)

   rainbow-run option: -o xephyr

This code is NOT KNOWN TO BE CORRECT [secure]. It just passes my most primitive
smoke tests. Therefore, please try it out and send me bug reports so that it
can one day become production-quality or, if you're feeling adventurous, do
some code-review (patch-level, module-level, whatever...) or test-case
submission (automated or otherwise) yourself so that we can all laugh at my
silly mistakes now instead of crying over them in the future. (Obviously, I'd
be happy to review patches that you send to me as well.)
   tests: mainly the example scripts on the wiki page


This code is definitely not backwards compatible with previous APIs.
The biggest compatibility-breaking changes that I presently know about are:

   a) I no longer generate $HOME/{data,instance,tmp} since there's plugin-like
  functionality which can be used to do so when it's necessary and because:
* data is subsumed by the topic dirs described above.
* instance was a design mistake which is finally fixed by support for
  writable persistent $HOME dirs and container reuse

* tmp was removed because I'm not sure how to implement it correctly
  and because $TMPDIR, /tmp, and /var/tmp are good enough for me at the

  At any rate, I /think/ that Sugar activities which now require these dirs
  can be made to work without modification with a little bit of
  plugin-development by me and the Sugar team; my goal at the moment is to
  make sure that rainbow is generally useful and that new activities can be
  written against a less-contrived API.

   b) I'm sure that I've broken rainbow's options support for things like
  strace, constant-uid, and serial usage. (This should be easy to fix; I
  just decided that I want to ship the rest of this code sooner rather
  than later.)

Regards from Santorini,

Devel mailing list

Rainbow, olpc-update, and olpcrd.

2009-04-08 Thread Michael Stone
 The main and probably most major issues outstanding are the
 kernel/boot process - so
 kernel/initscripts/olpcrd/initscripts/upstart/rainbow collection
 of stuff of which I have no real idea about. Updates?


Your remark does not contain any specific questions so it's a little
hard for me to give you a coherent update. Instead, I'll make some
general remarks in the hope that they will elicit further questions.

1. As has been recently pointed out, Rainbow is not currently in use
on any Sugar platform later than sugar-*-0.84 (i.e. OLPC's 8.2.*).
However, some have wondered whether it might make a reappearance in
sugar-*-0.86. To speed this outcome, I have prepared new versions of
rainbow (0.8.*) which are easy to install and test on many different
platforms. See

for current status information. 

  (I await further rainbow-0.8.* questions, comments, concerns, and
   test results with particular interest.)

2. There is little change in the state of olpcrd and olpc-update.
Daniel Drake did some nice work in February to make the toolchain
support OFW-hosted key overlays and, so far as I know, is happily
serving Paraguay-signed leases and software updates over Paraguay's
test schools' wifi network. 

  (Dan -- could you please update

   with links to a description of how you've deployed these

  (Peter -- Did you have some specific question about the technology or
   about its inclusion [or lack thereof] in Fedora?)

Regards from Athens,

Devel mailing list

Re: [Server-devel] adding custom dns entries on XS

2009-03-17 Thread Michael Stone
On Tue, Mar 17, 2009 at 04:04:06PM -0400, Daniel Drake wrote:
2009/3/17 Martin Langhoff
 It's in my plans to have a means to do what you're doing. I was wondering 

  - a conf.d approach
  - a pre-processor for the .in files that handles ifdef-style blocks
  - whether dnsmasq or djbdns can help us here

 I sure hope BIND won't be with us for ever.

dnsmasq can certainly help. With dnsmasq you just have to add an entry
in /etc/hosts on the server, and then dnsmasq automatically picks it
Michael says that djbdns also can do what we want, and pointed me to
some documentation, but it looked a lot more complicated than dnsmasq.

Here's a rough outline of how you might redirect with
djbdns on Debian Lenny. I can't promise that it's bulletproof, but it seems to
do approximately the right thing in simple testing.

sudo su -
apt-get install djbdns
useradd -s /bin/false dnslog
useradd -s /bin/false tinydns
useradd -s /bin/false dnscache

export YOUR_IP=...

# create empty dnscache and tinydns configurations
dnscache-conf dnscache dnslog /etc/dnscache
tinydns-conf tinydns dnslog /etc/tinydns

# tell dnscache where to bind, when to reply, and to proxy queries for at.l.o
echo $YOUR_IP  /etc/dnscache/env/IP
touch /etc/dnscache/root/ip/10   # answer
echo  /etc/dnscache/root/servers/

# give tinydns a zone containing at.l.o
cd /etc/tinydns/root
./add-ns $YOUR_IP
./add-host $YOUR_IP

# tell supervise to run our services; see also update-service on debian
ln -s /etc/dnscache /etc/service
ln -s /etc/tinydns /etc/service

# check that we're running and bound to proper ports
svstat /etc/dnscache /etc/tinydns
netstat -nulp | grep ':53 '

# read logs
tail -f /etc/dnscache/log/main/current
cat /etc/tinydns/log/main/current | tai64nlocal | less

# optional -- resolve against your local dnscache
echo domain schoolserver  /etc/resolv.conf
echo nameserver $YOUR_IP  /etc/resolv.conf



P.S. - Is there a wiki page where this sort of thing is supposed to go?
Server-devel mailing list

Re: [Server-devel] notes on scaling ejabberd for the XO's

2009-03-17 Thread Michael Stone
On Sun, Mar 15, 2009 at 06:30:17PM -0400, Daniel Drake wrote:
2009/3/15 Martin Langhoff
 Client code for Gadget seems to be integrated in the Telepathy new
 Sugar present on the SoaS images. The server side -- the proper gadget
 code -- isn't on any XS, and I haven't seen or tested it (lack of time
 :-( )

 Even if I had, it's a ton of new code, a lot more adventurous than
 what we're doing w moodle. So short/midterm, following ejabberd+moodle
 is lower risk from the perspective of a deployment today.

One thing I still don't understand about gadget... how does it
actually solve the problem? I'm assuming the problem it solves is lack
of partitioning, and the fact that the neighborhood view becomes kind
of impossible after 50 users, etc. Right?

Wrong. Gadget is primarily intended to reduce the bandwidth consumed by Gabble
under the load generated by Sugar.

So what does gadget do? 

Think of it as a server-side keyword search engine which you can query for
lists of matching people and activities. The purported bandwidth reduction
comes from sending each client only what it asks for instead of everything,
which is what the shared roster hack does.

Is there a new client side UI for electing groups? Who chooses, the kids or
the teachers? etc.

Guillaume filed

eight months ago but the absence of comments in that ticket and the current
paucity of results in

suggests to me that the Sugar folks have completely ignored the necessary UI
work in favor of more pressing issues.




To understand how Gadget works, read

and skim the contents of

paying particular attention to the automated tests. Then, if you're feeling
brave, read the Gabble source code:;a=tree;hb=master

paying particular attention to the files whose names contain 'olpc'.

Server-devel mailing list

Re: [Sugar-devel] Future of Rainbow + Sugar?

2009-03-02 Thread Michael Stone
On Mon, Mar 02, 2009 at 02:08:38PM +0100, Peter Robinson wrote:
The changes to sugar might be minimal but the changes to the
underlying OS are not so simple.

From my (which is very basic) understanding there is patches to at
least the kernel, initscripts, upstart and telepathy and possibly dbus
to support rainbow. 


You're confusing rainbow (the activity isolation component of Bitfrost) with
many other components including olpc-update, olpcrd, OFW, and hardware support.

Please read

and let me know if you're still concerned about what's required to use Rainbow
or about how I intend to make it easier still adopt.

This makes it very hard to use it in a standard distro environment especially
where Fedora (for example) already uses SELinux to implement some of the
features of rainbow.

I can see from reading the selinux-policy sources that lots of hard work has
gone into confining all sorts of system services. Tell me, though -- what
SELinux policy prevents a typical Abiword or Evince process, run by me from my
desktop, from writing to my ~/.bashrc?

Moreover, even supposing this policy exists, is it used by default on any
Fedora spins, let alone on the main Fedora livecds? Rainbow has offered this
safeguard, on by default on XOs, for over a year.

(NB: Perhaps, we would be better served by spending our time wondering how the
two technologies can complement one another, each sustaining guarantees that
are too expensive [in complexity] for the other to maintain?)


Devel mailing list

Re: [Sugar-devel] Future of Rainbow + Sugar?

2009-03-01 Thread Michael Stone
On Tue, Feb 24, 2009 at 10:09:26AM -0800, Carol Farlow Lerche wrote:
 My post was a request to the most knowledgeable person, Michael to do the
 service of taking the time to write a document that clearly lays out

.  the purpose (not in security speak but in terms of the benefits it brings
to end users),

.  the relevance of APIs versus packaging elements versus choices by the
sugar shell/infrastructure developers,

.  things that the activity developers can and can't do (given that I, at
least, hope that new developers will participate, who have preconceptions
from other environments),

. things that are hoped for in future development (well delimited from things
that are there now.)

Good documentation is hard, and wiki pages are only good documentation if
the wiki is maintained with great discipline (which I fear is not the case
at w.l.o).  But for a subtle and complex feature such as Rainbow, good
documentation would be a motivator for use both within and outside the sugar


I can't promise that I've reached clearly lays out yet, but I /have/ worked a
bit on unifying the Rainbow wiki page:

and I think that I could now use some more feedback about which parts are
working for you and which parts aren't.



P.S. - Other sugar folks might be interested to hear that Sascha Silbe (silbe)
managed to launch some activities under rainbow inside sugar-jhbuild. You
should follow up with him if you'd like to improve the system.
Devel mailing list

Future of Rainbow + Sugar?

2009-02-24 Thread Michael Stone
On Tue, Feb 24, 2009 at 01:47:01AM -0500, Mikus Grinbergs wrote:
[Also, I'm hearing whispers of 'no Rainbow' after Joyride.]


In my view, it's up to the SugarLabs folks to use Rainbow or to drop it. I have
tried to clear the way for them to use it on all the platforms they care about
by simplifying it, by making it more generically useful, by writing some basic
.deb and .rpm packaging in order to ease testing, and by writing Sugar patches
which cause Sugar to use it. Unfortunately, in the two months since I
announced this work:

and since I spoke about it at Fudcon Boston in January, I have received no
feedback more serious than a (kind) thank-you note from Walter, let alone
testing, bug reports, or patches. As you might imagine, this overwhelming
response leaves me more than a little bit discouraged.

Now, it could certainly be the case that there's more work that I need to do in
the form of documenting, testing, or pushing my recent rainbows before people
will be excited about trying them out and, if that's the case, someone should
tell me. Since no one has done so to date, despite repeated overtures, I've
mostly come to believe that no one cares.

Do you know differently?


P.S. - I find this state of affairs particularly sad, since I think there's an
/increasing/ amount of awesomeness that Rainbow can provide, e.g., bringing all
the recent hard work the kernel folks have been putting in on network
containerization and memory-resource cgroups to the masses.
Devel mailing list

Re: [Sugar-devel] Future of Rainbow + Sugar?

2009-02-24 Thread Michael Stone
On Tue, Feb 24, 2009 at 05:41:09PM +0100, Sascha Silbe wrote:
 On Tue, Feb 24, 2009 at 11:24:37AM -0500, Michael Stone wrote:
 Thanks for your work!  I sure hope it'll get used instead of dropped,  
 it's the #1 reason I looked into Sugar in the first place and the one  
 thing I miss most on regular desktops (I'm sometimes using vnc running  
 under different UIDs for the same purpose).


Thanks very much for the kind reply; it's really helpful to hear that someone
thinks this work is worth pursuing.

 What exactly do I need to do to try it out within sugar-jhbuild on  
 Ubuntu intrepid (amd64)?

Never having used sugar-jhbuild, it's hard for me to say precisely. My guess is
that you should teach jhbuild to compile and install rainbow, then apply my
patches to sugar (rebasing if needed, since they're now two months stale):

then see what breaks. (Which might be everything, since, as I said, rainbow has
never been tested w/ jhbuild.)

In the mean-time, let's start updating with
what you learn so that it becomes easier for others to assist.


P.S. - Let me know where more help is needed and I'll be happy to try to get
you unstuck.
Devel mailing list

Re: [Sugar-devel] Future of Rainbow + Sugar?

2009-02-24 Thread Michael Stone
On Tue, Feb 24, 2009 at 12:29:57PM -0500, Wade Brainerd wrote:
To me, Bitfrost was just one more lofty windmill OLPC tried to tilt because
it seemed like an interesting challenge.  

So you've said in the past. What of it?

I'm not clear why Sugar needs more protection from rogue activities than a
normal desktop environment has from rogue applications.

The justification which interests me the most goes something like: strong
protections mean that there is less risk that kids and teachers will break
things by installing software on their machines; therefore, educational
innovations will spread faster.

Reinventing the desktop as a constructivist learning environment is a big
enough task for one development team / community to swallow.  Reinventing
security is an altogether separate cause.

There is no reinvention taking place here; instead, we are using both
long-standing OS features (discretionary access control; memory isolation) and
novel OS features (network containerization, cgroup-based memory resource
limits) in new combinations as they become available. What has changed is that
the Sugar UI and user expectations permit concentrated use of these features.

That said, Rainbow exists, so we don't need to do anything to remove it.  So
long as people step up to maintain it and help activity developers fix the
issues they run into.

The issue is that rainbow has been maintained and its downstream users (e.g.
Sugar) need to give some feedback on the intermediate results so that there
will be time for its upstream author to respond to that feedback.

But Michael, what you seem to be asking for - someone to pick up your solo
project and finish it

Thank you, no. I apologize if my writing contributed to this gross
misunderstanding of my purpose.

Devel mailing list

Re: [Sugar-devel] Future of Rainbow + Sugar?

2009-02-24 Thread Michael Stone
On Tue, Feb 24, 2009 at 08:56:06AM -0800, Carol Farlow Lerche wrote:
Michael, I think your work on Rainbow is very important, but I think it is a
bit opaque.  


Thanks you for this detailed critique of my documentation efforts to date. One
thing that I've (obviously) struggled with is understanding which audiences
require which sorts of documentation. Your continued assistance untangling this
mess is most appreciated.

Perhaps you could improve your documentation and as well write
a tutorial about it that would make it more apparent how much is actually
implemented and what an activity can do with it.

I'll see what I can cook up.

So here's an example.  In the Rainbow page on w.l.o you refer to;a=blob;f=rainbow.txt;hb=HEAD for more
information.  Yet this file has several locutions of the form This can be
implemented and I believe but have not confirmed which leave the reader
unclear as to which services have actually been implemented.  

Do you have an example of documentation which you think really nailed the
divide between what is needed, what exists, how good is it?, and how do
I use it?

Hopping over to Low-Level Activity API the information about security doesn't
correlate with the permissions referred to in the txt file.

The purpose of the rainbow.txt document was to argue that a design /existed/
which would satisfy enough of the overall goals to be worth pursuing. The
purpose of the Low-Level Activity API documentation is to explain what features
of rainbow exist and can be twiddled by activities.

As it happens, the main feature which exists is primitive filesystem isolation.

Also you leave ambiguities for the reader by using the passive voice
throughout these articles.  Changing from passive to active voice answers
many questions for the reader.  Here is an example:

All writing to the file system is restricted to subdirectories of the path
given in the SUGAR_ACTIVITY_ROOT environment variable.

Well, we know that isn't true in all cases, because activities get installed
by Sugar outside that subtree.  So possibly you mean Rainbow prevents any
activity launched by the Sugar shell from writing to any directories except
those under SUGAR_ACTIVITY_ROOT.   Or do you?  Any exceptions?  What about
reading files elsewhere in the file system?

For me, these questions are largely answered by the statements, scattered
throughout the system, that rainbow operates by inventing new uids for programs
which it is asked to isolate. However, I can certainly lay things out more
explicitly. Thank you for the reminder about active vs. passive voice.

I think demystifying Rainbow within a comprehensive document containing a
section specifically aimed at the concerns of activity developers would go a
long way toward expanding its use.

What are the concerns of activity developers?

To date, the only one which I have heard clearly articulated is:

   How do I turn rainbow off for testing?

which, in fact, is answered in the For Activity Developers section.

Obviously, a couple of people also found it helpful to tweak the isolation
options in detailed ways as discussed in the API docs you cited earlier.

Devel mailing list

Re: Future of Rainbow + Sugar?

2009-02-24 Thread Michael Stone
On Tue, Feb 24, 2009 at 03:45:33PM -0300, Daniel Drake wrote:
Hi Michael,

2009/2/24 Michael Stone
 In my view, it's up to the SugarLabs folks to use Rainbow or to drop it.

How realistic is it to make rainbow something generic that all environments
and applications could use? 

I consider it a realistic goal, with a few caveats.

The rainbow-0.8.* redesign takes a big step in this direction by introducing an
exec-wrapper interface which can be embedded in fd.o .desktop launchers, used
from the CLI, and used by custom launchers like Sugar with equal ease.
Privilege is acquired from a setuid helper; e.g. sudo. The design and
automated tests now support limited concurrent multi-user operation, though
the implementation needs a bit more work in order to operate securely in a
multi-user environment. The only notable dependencies so far are on python and

The caveats are: 

   a) Usability sucks at the moment. For example, I need to implement some sort
  of garbage collection and some kind of user-facing UI, which might just
  be a simpler CLI wrapper. I probably also need to write a man page and to
  introduce more diverse error codes.

   b) We're going to need recent kernels for the fancier containerization stuff
  that I'd like to work on in the future. (Fortunately, upstream seems to be
  making good progress on the features I want :)
   c) I don't have any good idea how well or poorly the current design scales. 
  think it will work fine for desktop use. I'm just not sure how far beyond
  that it will stretch.)

More questions?

Devel mailing list

Re: [Sugar-devel] Future of Rainbow + Sugar?

2009-02-24 Thread Michael Stone
On Wed, Feb 25, 2009 at 11:33:30AM +1300, Martin Langhoff wrote:
You are now talking about the implementation of rainbow that provides
userland privilege isolation. 

For the record, rainbow only describes the userland privilege isolation part.
The rest is just OFW, olpcrd, olpc-update, OATS (If somebody knows a
better way to explain this stuff, speak up!)

 One thing that I wonder is whether in the push to make our OS more generic it
 would make sense to push rainbow in the direction of things like smack or

I think this would have the effect of making rainbow much less generic than it
currently is. On the other hand, it might still be worth doing if it made it
much easier to implement important features.

 Maybe rainbow could insta-isolate creating selinux profiles for activities?

I've been wondering about this for some time. Basically, while my reaction when
it was initially proposed it was lukewarm, for all the usual reasons [1].
Since then, I've been very gradually warming to the idea, in part as SELinux
matures, in part as I get to know the technology and people [2] better, and in
part as I run up against limitations of the simple Unix approach that I've
taken for the last year. Therefore, while it's not how /I/ intend to proceed in
the near future, I'm happy to try to work with people who feel differently. I
definitely have some ideas on the subject.


Devel mailing list

Re: [Sugar-devel] Future of Rainbow + Sugar?

2009-02-24 Thread Michael Stone
On Tue, Feb 24, 2009 at 06:05:51PM -0500, Benjamin M. Schwartz wrote:
 Sugar/OLPC simply never had SELinux experts 

I'm pretty sure this is false. For instance, I know that ancient OLPC+RH
kernels has SELinux enabled and I know that the SELinux folks at RH have always
been excited to help me to understand their work whenever I took the time to
ask them questions every few months.

It's hard to write a sandboxer like Rainbow, since it must not only appear
to work, but be verified secure to a high degree of confidence.  That's
harder still if one is writing in a system in which one is a novice, so
the developers (principally Michael) have instead stuck to technologies
with which they are already expert.

This is actually not such a big deal, in my opinion. The killer problem, as I
learned from the vserver experience, is that novice activity authors /must/ be
able to debug their work in any system which we might hope to ship. I don't
think that I have very good ideas on how to make this part workable with
technologies that are more complicated or more obscure than Unix DAC.

Devel mailing list

Re: [Sugar-devel] Future of Rainbow + Sugar?

2009-02-24 Thread Michael Stone
On Tue, Feb 24, 2009 at 10:22:07PM +, Gary C Martin wrote:

remind me, Pippy's getting special case hack permission to drive a 8 line
highway through Rainbow security  permissions, right?

Unfortunately, no. No one has yet completed an implementation of the gates
needed to guard access to the DS and the glue needed to know which DS entries
to fork over to which activities. 

(I got partway through an implementation of the gates, which are actually
fairly simple, but didn't get to the glue. [8.2.0 intervened.] Later, Scott
approached the problem from a completely different angle, i.e. with FUSE
filesystems. Hopefully, though, Tomeu's simplified data store will make
further work in this area a bit simpler, if any such work occurs.)

Devel mailing list

RFC: Supporting olpc-ish Deployments - Draft 1

2009-02-18 Thread Michael Stone

Pia Waugh (greebo) and I have spent a fair bit of time in the last month
talking and thinking about what we can do in the next few months to best
support present and future olpc-ish deployments (typically with XOs, typically
running Sugar) and we'd like to share some of our thoughts with you. These
thoughts are presented in draft form in order to solicit your feedback, which
is eagerly awaited, and will likely be incorporated into future drafts.




1. Motivation

We think that many deployment-related needs are not being adequately met,
particularly in the areas of:

* knowledge-sharing and the ability to benefit from others' mistakes.

* volume and quality of aid available for conducting deployments.

* bandwidth, latency, and SNR of channels to other communities which work
  with deployments; e.g. other deployments, educators, software teams,
  distributions, researchers, consultants, and volunteers

2. Use Cases 

We're particularly interested in addressing these situations and needs:

  D1) I'm running a deployment...
a) ...and I need help! Who shares my problem? Who can help me?
b) ...and I want to do more! Who/what can I work with? 
c) ...and I want to share! Where do I go? What is needed?

  D2) I need to talk to people deploying XOs.
a) Where do I go?
b) What can I expect?

  D3) I'm working on a deployment plan.
a) Where to I start?
b) What have I forgotten?
c) Am I using best practices?
d) Can I get a review?
  D4) I need to know...
a) real deployment numbers, 
b) maps, 
c) examples, 
d) photos, 
e) techniques,
f) contact info,

3. Existing Resources for Use Cases

Before we started, there were three basic mechanisms for addressing these use

1) read the Deployment Guide and the Deployments page(s):

2) ask (Only available to large deployments?)

3) poke people on IRC.

These three mechanisms are problematic because none of them can be relied upon,
alone or in combination, to adequately address any of the use cases listed

4. New Resources for Use Cases

So far, we've created two new resources which help bridge the gap: 

4) weekly deployment support meetings, with minutes at

   which get aggregated each month into

5) a Deployment FAQ,

   similar in form and spirit to the G1G1

We think that these two new resources, in combination with the pre-existing
resources, will help us provide the next level of support for our use cases.

4. Projects

We presently have several ongoing (interrelated) projects which you might like
to become (more deeply) involved in:

P1) Keep improving the deployment support meetings

-- so far, so good!

-- your participation in these meetings is our best current source of 
   content for the Deployment FAQ and for...

P2) Organize material captured in the meetings as FAQ entries

-- the meeting minutes are chronological, which is good for minutes, but
   not particularly helpful for random-access reads. 
-- FAQ entries seem like a good compromise between maintenance cost,
   timeliness, and satsifaction of the use cases

P3) Update the Deployment Guide

-- The Guide is now ~1 year out of date 

-- and it leaves too much to the imagination: just look at its advice on
   critical areas like connectivity, content acquisition, and means of
   participation in the larger community of 1-1 educational laptop
   programs in general and XO deployments in specific.

5. Status

Project P1 (meetings) is rolling along quite happily only one month after its
inception but it could use your help in order to become even more vibrant,
dense, and ingrained in the olpc-psyche. 

Project P2 (FAQ) is just beginning -- we've done a first rough-cut which you
should review for us and help us edit down into something awesome!

Project P3 (Guide updates) is just a twinkle in our eyes -- and it needs your
help to fly! In particular, three different mechanisms have been tentatively
proposed for how to accomplish the update(s):

a) By sprints, like the FLOSS Manuals sprints that created the XO and Sugar

b) By accretion, like the rest of the wiki, performed on a piecemeal basis
   by participants in the deployment support meetings.

c) By issue-tracking, like 

[Server-devel] Mass olpc-update via XS?

2009-02-18 Thread Michael Stone
Dear XS folks,

Daniel Drake, currently in Paraguay, wants to try implementing the procedure
described in

via XSen (using DNS to redirect the XOs' theft-deterrence protocol requests to
the local XS.) However, after briefly scanning the wiki, I noticed that we have

but no sign of an XS-ified theft deterrence protocol server. Now, to the best
of my (limited) knowledge, there is one usefully complete implementation of the

which was deployed in production at 


and used to update several thousand G1G1'07 machines.

(The installation of the code on those machines is, as usual, thoroughly
documented internally at Machine:antitheft and Machine:activation pages, for
those with access; some small bits of censorship /are/ needed before

In conclusion, do you currently know any problems that would prevent merging
whatever packages he and I create for his XSen (probably based on Scott's code)
into the main XS tree, assuming that we provide suitable documentation
alongside them?

Anyone got any better ideas about how to accomplish our goal?


Server-devel mailing list

Reminder: Deployment Support Mtg @ UTC 2000; 3:00 PM Boston

2009-02-17 Thread Michael Stone
Hi folks,

Daniel Drake (dsd) asked me to send out an reminder to people who might be
interested in asking and answering questions relevant to XO deployments.

If you'd like to partake, please join us in #olpc-deployment on at UTC 2000 (3:00 PM Boston), which is in about 35 minutes.

If you're unavailable, don't worry -- as always, minutes will appear at the
bottom of

and we'll try to address issues recorded on that page as agenda items or on


Devel mailing list

Minutes from olpc-friends' Feb. 03 and 10 Deployment Meetings

2009-02-10 Thread Michael Stone

Last Tuesday, we held an awesome deployment meeting (at 2000 UTC on
#olpc-deployment on which featured sustained engagement with
the Hernan's deployment troika: logistico, técnico y pedagógico, as well as 
extensive brainstorming of solutions for issues relevant to Peru, Sierra Leone,
and Birmingham.


Today, we had a quiet sharing of knowledge with Wade Brainerd, head of the
Sugar Labs ActivityTeam, a nice Nepal update, some fine exploratory thoughts on
the Rwanda deployment, and a pitch by Richard Smith for help with his
long-awaited Multi-Battery Charger.


Enjoy, and please join us in a few hours 0500 UTC or again next Tuesday at 2000
UTC. As always, please add items to the next meetings' agenda at the bottom of

so that interested folks can prepare questions and remarks or update the

(For extra motivation, be sure to check out dsd's four most recent wishes --
contributed live, directly from Paraguay!)

Voluntarily yours,


P.S. - Sorry that it took me so long to get last week's minutes posted -- they
were hard to disentangle!
Devel mailing list

Re: Please update etoys in 8.2.1

2009-02-06 Thread Michael Stone
so after the 8.2.1 release the plan is to just switch to standard Linux 

Speaking entirely as a volunteer: the answer depends on who you ask. 

Since I think that 8.2.0 wasn't half bad, I'm currently trying to persuade
people who feel similarly to work with me to assemble an 8.2.2 with some useful
bugfixes and software updates, because I think that

   a) it's the right thing to do

   b) it will complement various upstream efforts (both in Fedora, Sugar Labs,
  and the wider FOSS community at large) by helping to concentrate
  deployment-specific testing effort on the most relevant parts of
  their work 

   c) that it's important to deliver a product which directly meets the needs of
  existing deployments even when those needs don't precisely match the needs
  and goals of the larger upstream communities.

Does this help clarify the situation?


P.S. - My current ideal list of changes would include:

   * fix the memory stability issue
   * ship the new gabble w/ support for out-of-band stream tubes
   * ship the latest gnash

and I'd be very happy to discuss shipping various sugar or platform updates as
well; e.g. java.

What do you want to see in a new release?
Devel mailing list

8.2.1 Thoughts

2009-02-05 Thread Michael Stone
Hey folks,

Here are some more unofficial thoughts on how 8.2.1 is progressing:

  1) Daniel Drake discovered some annoying wifi regressions (#9235).

 We need to find root cause here, e.g. by bisecting the kernel patches added
 since 8.2.0 and testing each resulting kernel with both the new and the old

  2) The firmware looks awesome!

 Daniel and I both spent some time testing the new features of OFW q2e30 and
 we liked them so much that we worked together with Scott to implement some
 new initramfs features that make them easier to use.

 However, since they affect security critical code, they could always use
 more eyes. If you'd like to learn about how these components work, then
 please help test and review the patches!

  3) More smoke testing, please!

 TJB did a full smoke test on staging-25, which went well modulo some wifi
 and collaboration concerns, but more exploratory testing is still needed.

 Consequently, we expect to announce a new build within the next day or two
 for you to help test. (The new build will feature an exciting Etoys update
 that missed 8.2.0 by a hair and which has been ripening ever since.)

 I'll announce this new image both by email and on

 as soon as it's ready.

In conclusion, so far so good!



P.S. - A couple of people have asked about the possibility of future releases
beyond 8.2.1, e.g. to offer access to new versions of gnash, telepathy,
cerebro, etc. and to motivate folks to help fix long-standing 8.2.0 bugs like
the memory stability issues.

I'll just mention in passing that I'd be quite interested in facilitating an
8.2.2 release containing these updates, assuming the continued interest of the
folks whose help is needed to actually do the integration, do the testing, and
fix the bugs...


(as a warm-up round toward bigger things?)
Devel mailing list

Re: Joyide on Fedora 11/rawhide

2009-02-04 Thread Michael Stone
On Wed, Feb 04, 2009 at 05:53:14PM -0500, Chris Ball wrote:

This is Fedora's initramfs, right?


Peter's suggestion is to use pilgrim to create rawhide builds,
hence using the olpc initramfs.

That's an interesting idea.  I don't like it long-term, because
no-one's working on pilgrim or our initramfs, but it could help
us get moving.

Two small corrections:

a) the initramfs continues happily under active volunteer development -- it
received two new features and a bugfix contributed by a deployment support
volunteer (dsd) in the last two weeks, along with patch review and volunteer
testing by folks back here in the States.

b) While pilgrim may be a dead-end, the ideas underlying it are not. This week,
I translated pilgrim's ideas into the simplest form yet achieved, namely, a
plain old Makefile:;a=tree;hb=make

and used it to produce builds from the olpc4+joyride tree and the
rawhide+olpc4+joyride tree (with minor edits). 

The former booted happily into Sugar and built on both Debian and Fedora. :) 
(The latter, still using the olpc initramfs, dies because upstart 0.5 still
doesn't know how to run as non-pid-1. olpc4's upstart-0.3.9 has a patch which
implements this feature.)

Peter does not have an XO (g...@contrib program extreme slowness!)
but may be able to help on other issues that surface as the result
of an available public build...

Oh, let's fix that.  Ed, SJ, could one of you take care of sending
Peter some XOs ASAP, please?

Good idea.

Devel mailing list

Deployment Support Mtg -- Today, 2000 UTC, #olpc-deployment

2009-02-03 Thread Michael Stone
Hey folks,

This is just to remind you that we'll be meeting at 2000 UTC today (3:00 PM
Boston) in 


on to chat about deployment support topics. 

Detailed minutes from this meeting will appear at

alongside the minutes from previous meetings, which can be found at

If you'd like to have an agenda, then please write one as indicated on the
meeting notes link above.


Devel mailing list

Summary Minutes from olpc-friends' Tuesday Deployment Meeting

2009-01-29 Thread Michael Stone

We had an awesome deployment meeting this Tuesday at 2000 UTC on
#olpc-deployment on Almost 30 people came, with knowledge of
10 different deployments!

Summary and minutes are now available at

Enjoy, and please join us next Tuesday at 2000 UTC or Wednesday at 0500 UTC.
Also, please feel free to add items to the next meetings' agenda at the bottom

so that interested folks can prepare questions and remarks.

Voluntarily yours,


P.S. - Would some kind English+Spanish-speaking soul be willing to provide a
nice translation of Hernan's remarks:

for interested illiterates like me?
Devel mailing list

8.2.1 Release Status - Thursday, Jan. 29, 2008

2009-01-29 Thread Michael Stone

I just thought I'd offer some unofficial advice on the state of 8.2.1 for
interested listeners:

   a) In the last several weeks, there has been significant package churn at all
  levels of the stack including:

kernel bootanim bootfw olpc-utils libX11 xkeyboard-config sugar-journal
glibc glibc-common
  as described in more detail by and
  As a result, we're bottle-necked on QA.

   b) Some dedicated volunteers -- notably S Page, dsd, TJB, kimquirk, Hal
  Murray, genesee, tiesj, greebo, Mikus, John Ferlito, and ivazquez (thanks
  all!) -- have done some fine work getting us unstuck on QA!

  In particular, their volunteer wifi testing turned up #9222 which dsd
  thinks he fixed this morning from Paraguay! However, I think that there
  might be more wireless regressions -- please keep trying to break things
  with recent staging builds!

   c) Mitch has worked long and hard on #9045, which was one of the tickets
  motivating this release!

  Today, he delivered a new firmware, q2e30, which you should all help
  test.  It's available in staging = 25 and it needs both serious
  regression testing, e.g.

  and some dedicated feature testing according to the test plan laid out by
  Mitch here:

  (I had so much fun making my own keys last night that I stayed up after an
  evening out on the town with Henry  friends to help Mitch test this!)
   d) Somebody needs to provide appropriate activities for our smoke tests
  (preferably via customization stick) and to make sure that those
  activities are properly listed on the usual wiki pages. Help

  Wade -- is this something that your new activity team would like to help

   e) In conclusion, 8.2.1 seems to me to have been put back on track by the
  unrivaled commitment of you, our dedicated Friends in Testing. Thanks!



(P.S. - Thanks also to Chris for keeping things rolling by wrangling builds and
tickets at all hours of the day.) :)

(P.P.S. - If you're looking for something to test this week, please try out my

Devel mailing list

Small DNS questions.

2009-01-25 Thread Michael Stone

I've been conducting some thought experiments with the imaginary DNS server you
describe in

and I've developed a couple of small questions which I'd like your advice on,

  a) When multiple links are present, does the DNS server synthesize an  RR
 for every link?

  b) Presumably the DNS server should report itself as non-authoritative for
 everything except the local hostname(s)?

  c) Presumably the synthesized RRs should be non-authoritative except when
 they answer the local hostname(s)? 

  d) How should the TTL of the synthesized records be set given that the
 records are link-dependent? (on a mobile device?)

  e) When, exactly, should our DNS server synthesize RRs? Some possible
   when you can't get any other results,
   when you didn't find NXDOMAIN, 


P.S. - People who are unfamiliar with the ideas and questions in this note who
would like to contribute to the conversation should probably spend some time
reading RFCs 1034, 1035, and 2460 and Scott's Network Principles document.
Devel mailing list

Re: Backlight control

2009-01-24 Thread Michael Stone
David -- why quibble over ohm when you've got NM and HAL to worry about?

Paul -- why are the /sys nodes only writable by root?


On 1/24/09, wrote:
 On Sat, 24 Jan 2009, Marco Pesenti Gritti wrote:

 On Sat, Jan 24, 2009 at 3:43 PM, wrote:
 but if ohmd is going to be in the middle, then the published
 api for requesting those changes should be more transparent than
 requiring every application be in python and have knowledge of

 There is no python dependency and I personally have no problems with a
 dep on dbus. Leaving aside technical considerations about dbus, pretty
 much everything in the desktop land requires it these days (and ohm is
 heavily based on it afaik). It's not worth to resist the flow ;)

 so is there a standard that says that every desktop must use dbus now? If
 so I missed the memo.

 I don't have much of a problem with any individual desktop deciding they
 want to use dbus (gnome, kde, etc) as I still have the choice to use other
 systems (lxde, windowmaker, etc)

 but to make fundamantal control of the hardware require dbus seems like a
 signficant step.

 David Lang
 Devel mailing list

Devel mailing list

Notes from an impromptu 8.2.1 Release Mtg.

2009-01-22 Thread Michael Stone
Hi folks,

Kim Quirk kindly stopped by #olpc-meeting this evening and precipitated an
impromptu discussion between herself, me, cjb, edmcnierney, mchua, and
garycmartin on how to push 8.2.1 a few inches closer to release.

The main conclusion that we reached after we updated

was that staging-9 [1] needs some testing! In particular, it's got long-awaited
new wireless firmware and wifi kernel drivers which means that we need to know
whether it still associates with your crazy encrypted access points. :)

At any rate, the bottom line is that YOU can personally help 100k kids in
Uruguay get access to 8.2.* faster by helping to test this build. (Guadalupe
and Emiliano in Uruguay have already helped to test fixes for some of the
issues they found in 8.2.0 but more (your!) testing help is still needed!)
So, on that note, thanks very much in advance for any help that you can provide.

Voluntarily yours,


P.S. - Bryan -- would you please update FiT with instructions for staging-9

P.P.S. - I'd like to host a test party at 1cc sometime in the next two weeks to
try to do some large-scale collaboration and wifi testing such as was requested
by dsd [2] in preparation for his trip to Paraguay tomorrow [3]. Would
interested people who might be in Boston in the next two weeks please mail me
to let me know good days and times for them to come help test?

P.P.P.S. - The major coding work left before we can wrap up 8.2.1 is currently
resting on Mitch Bradley's capable shoulders [4]. I'm looking forward to
receiving a new OFW snapshot from him for testing in the not-too-distant

[1]: (
  -- dsd, update you profile!
Devel mailing list

Summary and minutes from Pia's first Deployment Meeting.

2009-01-20 Thread Michael Stone
Bcc: Dulmandakh Sukhbaatar, guadalupe, emiliano
Subject: Summary and Minutes from the Jan 20, 2009 Deployment Meeting

Hi everyone,

Here is the summary and the edited minutes for the first of Pia's new
deployment support meetings:

Enjoy, and please consider joining us later today/tomorrow at 0800 UTC
(0300 in Boston) in 

   #olpc-deployment on

to discuss the questions and comments raised in today's discussion or
left waiting on pages like or



(in his new-fangled volunteer capacity)

P.S. - If you can't attend this week, please come next week instead!
(And do read the minutes; they took forever to prepare... :)
Devel mailing list


2009-01-09 Thread Michael Stone
Like many of my esteemed colleagues, I am parting ways with OLPC.
I will treasure the memory of our collective adventure...

...while naturally looking forward to new opportunities: professional,
educational, and otherwise.


P.S. - (Anyone else wondering what happened to their social life over
the last year? ;)

Devel mailing list

Re: Customized images

2009-01-06 Thread Michael Stone

On Mon, Jan 05, 2009 at 02:27:45PM -0500, Carlos Dario Isaza Zamudio wrote:
I have a fully customized XO and i need to take an image from it to be
installed on several computers inside the project. The thing is i need it to
be separated from the activity pack, like the ones you use to update via

Hi Carlos,

Thanks for the great questions.

1) When i take the image from this one and install it into another, will i
have two computers wchi are exactly the same?

No. Each XO contains unique manufacturing data, stored in a
non-volatile memory which is separate from the main (1GB) non-volatile

Moreover, when you boot an XO, it runs some software which dirties the
filesystem. You'd want to clean the filesystem by undoing some of
these edits before you clone the image onto lots of other machines.

2) In order to do this process does it have to be into a unblocked XO or
with developer key? Because if that's the case, i can't do it since these
are the computers we're gonna use for deployment.

a) Why do you want the computers to be locked?

b) You can temporarily unlock the computers in at least two ways. 

c) We're designing some software changes over at

which might make this easier for you to maintain.

3) Out of the topic question but do you know how can i change the default
page from the Browse activity? 

You need to edit the Browse source code here-ish:

(i.e. search for load_uri in

Thanks for your replies

You're very welcome. Please come back with more questions!

Devel mailing list

Re: Fedora Desktop on XO

2009-01-06 Thread Michael Stone
On Tue, Jan 06, 2009 at 12:19:52PM -0800, Deepak Saxena wrote:
On Jan 06 2009, at 14:42, Chris Ball was caught saying:
 I think I missed the previous conversation, re: estimate , but I'm
 thinking that swap will have significant impact on the lifetime of
 the flash chip.  With only 256MiB of RAM, we are bound to swap a
 lot. I'd feel more comfortable if we did flash-wide wear leveling
 using UBI and created a swap partition on to pof that.
 That's fine with me too.  Are we still planning on moving to UBI for
 9.1?  If not, maybe we can work out how to get swap files working on
 JFFS2 (where they would be wear-leveled)?

At this point, with  2 months to desired release date, 


I don't think I know anyone who can convincingly argue that the March
date is realistic, based on current rates of change and the remaining
distance to the objective. I asked in the last (maybe even the last
two?) status meetings to re-evaluate that date but was blown off. Make
of that what you will.

Devel mailing list

Re: Fedora Desktop on XO

2009-01-06 Thread Michael Stone

I don't mean to be nasty, but I do feel the need to be blunt:

On Tue, Jan 06, 2009 at 04:28:36PM -0500, Greg Smith wrote:
 Hi Michael,

 We are definitely behind where I would like to be at this stage.

How far behind?

 However, we'll only move the date when we must and we'll only do it to  
 improve quality 

What exactly did you think Deepak and Chris were discussing doing? 

Devel mailing list

Re: Customized images

2009-01-06 Thread Michael Stone
On Tue, Jan 06, 2009 at 03:52:44PM -0500, Erik Garrison wrote:
On Tue, Jan 06, 2009 at 03:23:32PM -0500, Michael Stone wrote:
 On Mon, Jan 05, 2009 at 02:27:45PM -0500, Carlos Dario Isaza Zamudio wrote:
 I have a fully customized XO and i need to take an image from it to be
 installed on several computers inside the project. The thing is i need it to
 be separated from the activity pack, like the ones you use to update via
 Hi Carlos,
 Thanks for the great questions.
 1) When i take the image from this one and install it into another, will i
 have two computers wchi are exactly the same?
 No. Each XO contains unique manufacturing data, stored in a
 non-volatile memory which is separate from the main (1GB) non-volatile
 Moreover, when you boot an XO, it runs some software which dirties the
 filesystem. You'd want to clean the filesystem by undoing some of
 these edits before you clone the image onto lots of other machines.

Dirty might be too general a word.  Specifically there are a number of
changes made to system files during the first boot of the machine
which you might not want to copy between machines.  (SSH keys, for
instance, are generated once at first boot on every XO.  Also,
hardware-dependent information from the firmware is cached on the NAND
after first boot.)

We haven't worked on figuring out what pieces of the system are touched,
so, as Michael notes, copying the machines can have unintended side
effects.  It seems that nearly everyone who tries to distribute images
by cloning runs into some oddities.  That said, it also seems that this
method of customization is the most appealing and straightforward.  It
has come up several times recently and I think the time has come to
properly evaluate it.

Perhaps someone here could be tempted into writing a clean-up script
like we discussed the last time this came up?

Devel mailing list

Re: Fedora Desktop on XO

2009-01-06 Thread Michael Stone
On Tue, Jan 06, 2009 at 07:40:07PM -0500, Reuben K. Caron wrote:
 Peter Robinson wrote:
 Hi Chris,

I would remove the old fc9 build from the olpc_development repo (or
even have one for 8.2.0 and one for 9.1.0 so they don't get mixed
up).  Surely it should be pulling cyrus-sasl from the Fedora repos

 I've just pushed a patch to pilgrim's joyride branch to switch the
 baseurl that gets written out in /etc/yum.repos.d/olpc-development.repo
 from to

 (olpc3 is our 8.2/F9 repo, and olpc4 is the 9.1/F10 repo, so Joyride
 should have been switched to write out the olpc4 baseurl when we
 created the new repo.)

 And, after the change, we don't have depsolving problems any more!
 Here's the list of packages to be downloaded -- the next question is
 going to be how to avoid many of these dependencies.  Perhaps instead
 of trying the groupinstall, we should be hand-picking a smaller base
 of GNOME packages from this list?

 Well its the list up to the Installing for dependencies that is
 explicitly requested, all the below is pulled in for deps. I'm not
 sure how pilgrim builds the list but I think if it uses kickstart like
 the other fedora build systems do you should be able to do a specific
 -packagename and its removed from the list.

 Does pilgrim (Puritan?) use kickstart like files? 


 If not, why do we not create builds using what seems to be fedora's
 standard build system?

The short answer is that there has never been consensus among the people
dealing with OLPC's builds that anaconda was the right tool for the job.

The longer answer involves a lot of politics which I'm /really/ not
interested in stirring up but which are unavoidable if you want to
really understand how things came to be the way that they are. In order
to navigate this quandary, I'm going to offer you a series of
thought-questions which, I hope, will lead you to your own answer to
your question. 

(If you want, you can ask me tomorrow for my answers to them but you
should try to construct your own answers first.)

Hope this helps,



a) Requirements.
   1. What do you think a build system for OLPC and for XOs needs to do?

   2. What explorations have been made in the area of XO-related build

   3. What lists of requirements (or audiences) do each of these
  explorations seem to be trying to satisfy? 

b) History  Incumbency of Pilgrim.

   1. Why did davidz write pilgrim?

   2. Why did pilgrim not use anaconda?

   3. Why did davidz later write livecd-tools using anaconda?
   4. What do you have to do in order to get OLPC to use a different
  build system?

c) People  Politics

   1. Who has worked on build-system stuff for XOs? for OLPC?
   2. How might we describe their knowledge, skills, interests, aims, etc
  at the time? 
   3. What demands were placed on them at the time they worked on
  build-system related things?
   4. How should we describe their relationships with one another?
Devel mailing list

Re: Emulating 8.2-767

2009-01-05 Thread Michael Stone
On Mon, Jan 05, 2009 at 01:07:00PM -0500, Wade Brainerd wrote:
I would love to convert my OLPC Installer for Windows over to VMWare.
In my experience it provides a better experience on Windows.  I'd also
like to convert it over to using Bert's image rather than the stock
8.2.0 image.

What would be even better would be for the OLPC guys to set up
emulator builds which mirror the regular Joyride, Staging, etc. builds
and apply Bert's customizations automatically.


Is there something you need access to (e.g. an account?) that prevents
you from doing this yourself?


Devel mailing list

Re: Emulating 8.2-767

2009-01-05 Thread Michael Stone
On Mon, Jan 05, 2009 at 01:18:53PM -0500, Wade Brainerd wrote:
On Mon, Jan 5, 2009 at 1:16 PM, Michael Stone wrote:
 On Mon, Jan 05, 2009 at 01:07:00PM -0500, Wade Brainerd wrote:

 I would love to convert my OLPC Installer for Windows over to VMWare.
 In my experience it provides a better experience on Windows.  I'd also
 like to convert it over to using Bert's image rather than the stock
 8.2.0 image.

 What would be even better would be for the OLPC guys to set up
 emulator builds which mirror the regular Joyride, Staging, etc. builds
 and apply Bert's customizations automatically.


 Is there something you need access to (e.g. an account?) that prevents
 you from doing this yourself?

Knowledge and time.

Well, just be aware that while I can't help much with the time part,
I'm more than happy to help with the knowledge part in any way I can.
Just let me know what works best for you.

Devel mailing list

Re: Please help test our pre-release build of 8.2.1

2009-01-05 Thread Michael Stone
On Fri, Jan 02, 2009 at 11:04:01PM +0100, Bert Freudenberg wrote:
On 02.01.2009, at 17:09, Brian Pepple wrote:

 Hi All,

 A pre-release build of 8.2.1 is now available for testing. It has  
 an initial smoke test and now needs broader testing.

 The build download and problem reporting instructions are here:

 The very early draft release notes are here:

 Please send a note to the list if you try this build even if you don't
 find anything interesting. We want to measure our test capacity.

You should mention that you want people to test the latest staging  
build, not the latest 8.2.1 build (which is exactly the same as  
8.2.0 at this point):

This is a significant change from previous release procedures (e.g., I  
was not even aware that staging builds were meant for testing).


Here's the idea:

   | |
   v v
joyride   staging
   | |
   v v
  \ \ available now.
   \ will be created eventually

(This is the first time we've had two active integration streams.)

Does this help clarify things? 

Devel mailing list

Re: Problems with Adobe Flash player on the XO.

2009-01-02 Thread Michael Stone
On Fri, Jan 02, 2009 at 10:56:59PM +0800, Carlos Nazareno wrote:
Ditto. I've tried Sugarizing newer versions of Opera myself, but we're
out of luck because of the Rainbow Security implemented in newer XO OS
builds don't allow writing of files by Activities to certain
directories that Opera installs to. The Opera dudes will have to
create a special OLPC Opera Activity for us like with 9.12 since Opera
is not open sourced and we won't be able to do the proper
modifications for Rainbow Security compatibility ourselves.

Could you be more specific about what writes are failing?

In the past, we've been able to achieve both isolation and a working
activity (e.g. Scratch) with some easy filesystem tricks...

Also, have you filed a bug? I've tried searching for
opera rainbow but I didn't find any likely tickets...


Devel mailing list

Re: performance work

2008-12-31 Thread Michael Stone
On Wed, Dec 31, 2008 at 09:20:27AM -0700, Jordan Crouse wrote:
The solution to the performance problems is good old fashioned elbow 
grease These are the sorts of things that we need to find and
squash - and yes, it will be very time consuming and a little boring.

Several anecdotes for your amusement and reflection:

* When was the last time someone posted to devel asking: what is the
   right algorithm or datastructure for task ?

* When was the last time someone publicly analyzed the upper or lower
   bounds on the bandwidth, latency, or quantity of messages necessary to
   accomplish task ?

* When was the last time that you published a performance goal for your
   software? Did you hit it? Did anyone notice?


P.S. - Charles Leiserson once remarked that performance is like a
currency which programmers trade for (all) other worthwhile things like
schedule targets, scope of features, other resource consumption, various
kinds of security, etc [1]. This suggests that one would do better to
ask for performance or  but not both. Think of Blizzard.

Devel mailing list

Re: Minutes of Power in 9.1.0 meeting

2008-12-25 Thread Michael Stone
On Thu, Dec 25, 2008 at 12:19:37AM -0800, John Gilmore wrote:
 along similar lines an issue I have been seeing with the network screen 
 (but haven't gotten around to reporting). my home access point is 
 encrypted and sometimes I can reconnect to it without a problem, but 
 sometimes it acts as if it's never been connected to before (asking me for 
 the encryption key). I've had to resort to printing the key and keeping it 
 with me (not convienient or good for security). is this a known issue? is 
 there anything I can do to help track down the issue?

I see this all the time, too.  There are some known bugs with encrypted
access points, but I don't know if this one is clearly reported.  Wireless
is *so* hard to debug, the programmers can never get to the location where
it actually fails repeatably -- and when it's failing, the laptop is by
definition off the net, so they can't login to it remotely to debug it.
Very frustrating.  Access points with encryption have *never* worked
reliably on the XO.  I guess the programmers in Cambridge had better
turn off their open access point, or it'll never be solved.

Like the memory freezeups, I just assume that everyone is seeing this
and nobody cares to work on it.

Daniel Drake has repeatedly offered (and in the past, made good on his
offer) to help debug reproducible association problems involving
wireless encryption. Other members of the wireless team, including
Ricardo Carrano has done the same. Finally, several wireless folks have
reported that direct use of wpa_supplicant with correct flags (rather
than indirect use of wpa_supplicant by means of NM) results in more
frequently successful association attempts [1].

Perhaps they might be interested in working to write up the outline of a
logic tree for debugging failed association attempts such as the one
that Tomeu and Mel created for debugging memory leaks?



Devel mailing list

Re: communication among heterogeneous software versions

2008-12-25 Thread Michael Stone
On Thu, Dec 25, 2008 at 12:41:37PM -0500, Mikus Grinbergs wrote:
It's good that these heterogeneous-software-version XOs were able to 
see each other's presence.  But being shown two different kinds of 
information in the output illustrated a potential exposure --

 What if the systems at a given site do *not* all contain the
 same software version (e.g., from 2008 vs 2009).  Will all those
 systems be able to correctly collaborate among themselves ?

My experience suggests that the presumption should lie nearer to the
idea that the systems will be incompatible until they are tested as
being compatible than it does today.

 If not, do deployments need to be cautioned ?

Yes, though gently, since things frequently work just fine. 

Devel mailing list

8.2.1 Smoke Testing

2008-12-24 Thread Michael Stone
Hey folks.

We could use your help testing our first real 8.2.1 integration build,


You can find it at

The tickets which people think it fixes are here:

If you can't find the testcase for one of these changes, please push it
back into the 'testcase' workflow state. (next action field).
(See for more details.)

Thanks very much!


P.S. - I expect that Brian Pepple, our new Friends-in-Testing (FiT)
coordinator will be improving 
to reflect this information shortly.
Devel mailing list

Re: 8.2.1 Smoke Testing

2008-12-24 Thread Michael Stone
P.S. - I know that Mel  volunteers have done some awesome work on
systematic testing for 8.2.1 here:

and that results from the Old Smokey of OLPC testing,

would be truly appreciated.

P.P.S. - If I forgot anything else important, or if you have questions
or improvements of your own to contribute, don't hesitate one second to

Thanks again!

Devel mailing list

Re: Deployment image customization

2008-12-23 Thread Michael Stone
On Tue, Dec 23, 2008 at 09:18:51PM +0200, Morgan Collett wrote:
On Tue, Dec 23, 2008 at 18:29, Daniel Drake wrote:
 On Tue, Dec 23, 2008 at 2:19 PM, Greg Smith wrote:
 Your suggestion that we allow
 addition of RPMs and get those built into a signed image via pilgrim or
 puritan is certainly valuable and part of the requirement.

 However, it doesn't cover a few added things (language settings was
 specifically requested by Mongolia and others):

 - Updated language packs (I believe we are trying to make this an RPM which
 may solve it)
 - Starting language
 - Date, time and timezone
 - Network settings

Both puritan and pilgrim install many unpackaged hacks; that's actually
the major reason why they exist. 

(Some special indirection needs to be taken if you want to deploy hacks
to /home via olpc-update, since it doesn't touch /home, but for
whole-NAND-reflash tasks, either is certainly adequate.)

It's also possible to combine a compose-tool like puritan or pilgrim
with our existing image-builder technology (which generates mfg-ready
images from customization-stick data.)

Devel mailing list

Re: Deployment image customization

2008-12-23 Thread Michael Stone
On Tue, Dec 23, 2008 at 03:29:08PM -0500, wrote:
daniel wrote:
  On Tue, Dec 23, 2008 at 8:08 PM, wrote:
   ssh host keys are probably generated on first boot as well.
   with partitioning support, it should be possible to have a r.o. root
   overlaid by a unionfs writeable mount, so machine-specific changes
   don't modify the released partition.  this would make cloning quite a
   bit easier, i'd think.  i have no idea what the performance hit of
   a unionfs setup would be, nor how such a partitioning would fit
   into the rest of the update strategy (e.g.  olpc-update).
  unionfs isn't upstream and was quite unreliable last time I use it.
  And it adds the challenge of differentiating state that must be
  discarded for the cloned image, and state that must not be.
  For example, we would want to ssh keys generated during first boot to
  *not* be included in the clonable image, that's obvious. But if the
  user boots the OLPC image, goes into the control panel and sets a
  language, then we *do* want that language change to be included in the
  clonable image that is the output of the process.
  How would the system differentiate between those two?

i dunno.  i guess the lead engineer on the project would have to
decide.  :-)

In my opinion, the simplest way to approach this is to add a
hard-reset script (perhaps named olpc-hard-reset) which cleans up
the image and then prints out a diff from the starting image to the
result for manual review.

Devel mailing list

Problems revealed by a report of detailed changes to 8.2.1 tickets.

2008-12-22 Thread Michael Stone

I made in the image of one
of my old 8.2.0 reports. (TIME is the number of seconds of history that
you want to view so that URL shows you all changes to tickets with
milestone 8.2.1 made in the last 9-10 days).

At the time of this writing, over the past week, 7 out of 16 tickets
have been updated, primarily by Deepak and Scott with some additional
questions and discussion from Sayamindu, Bert, and Simon.

I know that I find this degree of recorded progress less than
satisfactory. Do you feel the same way? If so, you need to know that I
feel neither empowered nor requested to push this along as fast as it
can go. (Does anyone else feel similarly?)

Consequently, if you want my full potential contribution to 8.2.1 to be
realized, I strongly suggest that you, as 8.2.1 release manager, would
do well to provide me with better and more regular instruction, e.g. by 

   * assigning some 8.2.1 tickets to me, (I have none)

   * by requesting me to choose some tickets that I can handle,

   * by _promptly and regularly_ checking in with all of the people in
 the critical path to release to find and remove obstacles to their

   * or by delegating the responsibility and authority to do these things
 to someone else if that's the best way to get the job done.

To summarize, Trac suggests to me that people are either not reporting
their work or are stuck, perhaps because of deadlock, contention,
starvation, challenge, or distraction. How are you going to solve the

Devel mailing list

Re: Problems revealed by a report of detailed changes to 8.2.1 tickets.

2008-12-22 Thread Michael Stone
On Mon, Dec 22, 2008 at 01:57:56PM -0500, Ed McNierney wrote:
 Michael -

 Are we able to promptly and regularly generate 8.2.1 builds that reflect 
 the work being done? 

For basic testing purposes, yes. Scott's weekend report indicated that
he set up a 'staging' build stream on xs-dev. You can see its output at:

Input is provided hourly via the d.l.o package dropbox or via the
local.8.2.1 and koji.dist-olpc3-testing branches of mock.l.o/repos.

   (P.S. - Scott -- you need to push the pilgrim configuration off of
   xs-dev up to pilgrim's main repo.)

True 8.2.1 builds, being under full change control, require trained
manual intervention to create, e.g. by cscott, dsd, or me. 
 From last week's reports I get the impression that various bits of
 progress are being made, but we've had no 8.2.1 builds since the first

What stimulus is supposed to prompt the creation of such a build?
Since some people have refused to follow the workflow I helped write
for 8.2.0 and since you have not reported on the outcome of your
scheduled conversations with those people, it is not at all obvious
how to proceed.

 Please let me know if there is anything I can do to assist. 

In my opinion, more active shepherding of changes and people by the
release manager is clearly called for. For example have you:

   a) clearly broadcast what ticket workflow you are using? 
   b) set any deadlines for the completion of any pending work?
   c) publicly poked people for status updates, or
   d) successfully synchronized people on the status and needs of 8.2.1
  by either email or IRC meetings?

Is there some reason why you feel that none of these forcing functions
is necessary to the release effort or some other commitment that
prevents you from carrying them out?

 If there is anything you (or anyone else) can do to ensure that bug  
 fixes can quickly get into a build for testing, that would be very  
 helpful and an excellent assignment. 

I spent a long time thinking about this remark and about my reaction to
it. On the basis of that reflection, I need to apologize in advance that
my patience has has worn so thin... my reply may be harsher than it
needs to be. It consists of two responses, one outward-facing public
response and one inward-facing critical response.

Outward response: 
Sure, happy to help. I'll go poke the necessary people.

Inward response: 
This remark is unacceptably vague. In order to be the
release manager, you're supposed to know or to be able to figure out
what needs to be done in order to make the release happen. Moreover,
while I'm happy to help with many tasks, I don't really enjoy feeling
like I'm prompting you.  

Example: if 8.2.1 builds concern you, why did you not make more noise
about them last week? (e.g. by sending mail to devel@ or filing a ticket
asking about them.)

Does your process for getting the release unstuck actually consist of
waiting for me to send you questions, then asking me or Scott to fill in
the details of the segment of the critical path that lies immediately


You're welcome.

Devel mailing list

Re: Fixed Puritan bug on F10/Intrepid

2008-12-17 Thread Michael Stone
On Tue, Dec 16, 2008 at 03:03:08PM -0500, Reuben K. Caron wrote:

The build was successfully made on both F10 and Intrepid.

How could I slip in a language pack?
How could I set the Timezone for the build?
How could I set the default language for sugar?

Well, first, figure out how would you normally do these things. Then add
the necessary files to the compilation directory and modify the
'' file (or add a custom stage) to apply the changes.

Would it help for me to work out an example for you in a subsequent
reply? (Would you like to work out one as an example and post it for
others to enjoy?)



P.S. - You should try out the latest version of the ui and 767
compilation -- I worked up a nice automatic caching feature and I
improved the interactive debugging mode too! (Be slightly wary though;
the code is far from well-tested.)

P.P.S. - You can use 'git pull' to pull down the latest versions of the
ui and compilation. If you decide you don't like them, you can go back
to the earlier versions with a combination of 'git log' to find out the
commit-hash identifying the version you want and 'git reset --hard
hash' to move to it. Again, let me know if a more verbose tutorial
would be helpful.
Devel mailing list

Fixed Puritan bug on F10/Intrepid

2008-12-15 Thread Michael Stone

I was able to reproduce and work around the rpmdb version problem you
found today on a new Intrepid vm I created on weka.l.o. Would you mind
retesting with my new 767 compilation? 

(To do so, just wipe the compilation and re-clone it. I modified the
cloning instructions so that, in the future, you'd be able to run 'git
pull' to update.)


Devel mailing list

Re: a build reproducibility test

2008-12-13 Thread Michael Stone
On Sat, Dec 13, 2008 at 03:53:14PM +1100, James Cameron wrote:
On Fri, Dec 12, 2008 at 12:40:37PM -0500, Michael Stone wrote:
 On Fri, Dec 12, 2008 at 03:27:21PM +1100, James Cameron wrote:
 Why can't the build system be replicated so that each developer can test
 their change before releasing it?  What is it about the build system that
 prevents it?  I thought the build system was just a set of downloads and
 put-it-together processes.

 It can, it has been, and no one seems to care. See

 for some historical records of the discussions.



Tried the puritan on Debian, 

Thanks for test-run! (and I'm sorry to hear that you got stuck.)

 stopped at a missing /etc/mock/fedora-9-i386.cfg file

   sudo wget -O /etc/mock/fedora-9-i386.cfg \

should fix you up. I'm not sure why the debian packaging of mock is
missing this file.

 but I thought the build had moved on to Fedora 10 now?

in the sense that joyride's pilgrim configuration is now pulling from
f10 yum repos rather than f9 yum repos. That's just a matter of
changing the obvious lines in the compilation's 'bootstrap' (or
'', in later versions) file.

 Why would it need Fedora 9 configuration file?  

Because I told it to construct the build environment out of F-9
materials regardless of what system you happen to be running on. At the
time, this seemed like a good idea because I thought it would help
achieve more reproducibile results and because I thought it would ease
portability issues; now, I've come to think that it's a better idea just
to run the software bare in whatever environment happens to be

 Where would I get a Fedora 10 configuration file from?  

If you want to set up a build environment with f10 versions of tools,
then you'd want the f10 mock config (available mock on a fedora system
or extractable from Fedora's koji buildserver.)

If you want to try making builds with f10 packages, then you can use
whatever build environment you like so long as you direct the
compilation to pull from f10 package repos:

 Why does the current production build system have this file?  

For the record, puritan is not the current production build system.
Pilgrim is. Puritan is just an expression of some of my ideas about what
is required to make a nice build-system for putting software onto XOs.

Thanks very much for your bug reports and assistance in improving it,

Devel mailing list

Re: 2588 - Journal unusable

2008-12-12 Thread Michael Stone
On Fri, Dec 12, 2008 at 03:27:21PM +1100, James Cameron wrote:
G'day Chris,

I'll give a partial line of reasoning response ... this is not complete,
I'm short of time.

Where I said public, I meant developer builds that can be used by other
developers.  I didn't mean to imply public builds for testing by
non-developers.  I mean the difference between what a developer does and
what a developer releases.  That isn't only OLPC originated code, that's
also the choice of what RPMs to accept from outside.  Accepting lots of
RPMs at once is the same as making lots of code change.

Why don't you have private build streams?  That's what I can do with
debxo, for instance ... build on my desktop, test on an XO, and then
avoid releasing anything to the public until I've verified that what
I've changed actually works.

Why can't the build system be replicated so that each developer can test
their change before releasing it?  What is it about the build system that
prevents it?  I thought the build system was just a set of downloads and
put-it-together processes.

It can, it has been, and no one seems to care. See

for some historical records of the discussions.

Devel mailing list

Re: Free Software Foundation Files Suit Against Cisco For GPL Violations

2008-12-12 Thread Michael Stone
On Fri, Dec 12, 2008 at 11:52:54AM -0800, Edward Cherlin wrote:
On Fri, Dec 12, 2008 at 11:14 AM, John Gilmore wrote:
 OLPC is at risk of similar action unless it gets its act together.
 The project and its customers have skated by on GPL compliance,
 figuring that we're the good guys, and make halfhearted attempts every
 once in a while, so we won't get sued.  That didn't work for Cisco.
 Even a public *allegation* by FSF that OLPC is not compliant would
 have an effect similar to the We're going Microsoft debacle, further
 alienating the free software development community who OLPC depends
 deeply upon.  OLPC has, by distributing binaries under DRM, without
 source code, and with minimal notice, hung a sword over its head that
 just about anybody could unleash.


Some of us are new to one or another part of this issue, and need a
bit more background.

For some basic background, please see


Devel mailing list

Re: Free Software Foundation Files Suit Against Cisco For GPL Violations

2008-12-12 Thread Michael Stone
On Fri, Dec 12, 2008 at 12:34:18PM -0800, Edward Cherlin wrote:
On Fri, Dec 12, 2008 at 12:22 PM, Michael Stone wrote:
 On Fri, Dec 12, 2008 at 11:52:54AM -0800, Edward Cherlin wrote:

That's a lost cursor bug. I assume you meant some other one.

Yes,, thanks.

Sorry for the confusion,

Devel mailing list

Re: Wireless activation improvements.

2008-12-11 Thread Michael Stone
On Thu, Dec 11, 2008 at 03:35:53PM -0200, Martin Langhoff wrote:
On Thu, Dec 11, 2008 at 3:27 PM, Daniel Drake wrote:
 The primary use case that the Ethiopia team is interested in is
 automating/simplifying the lease *renewal* which is done at schools,
 not a warehouse.

Lease renewal is -- unfortunately -- missing big chunks in 8.2 . I
don't think it's doable for 8.2.1. I'm trying to coordinate an effort
(eith Ed's help) to team up with Michael and/or Scott to get this done
as soon as 8.2.1 is out, with a target of 9.1 or (if people make a
strong case for it) 8.2.2.


If you boot a boot-locked machine with no valid lease, it will search
for one on USB, SD, and the mesh. Therefore, while I agree that things
would be nicer if leases were also renewed while the machine was
running, it's obviously not preventing all use of the activation
feature by our deployments. Finally, don't you agree that there are
lots of different ways to solve this problem that are within the reach
of those deployments interested in pushing our activation technology
along faster?

Devel mailing list

Re: 8.2.1 Bug review meeting - 1 PM EST Friday 12/12/08

2008-12-11 Thread Michael Stone
On Thu, Dec 11, 2008 at 01:50:58PM -0500, Ed McNierney wrote:
OK, someone made a boo-boo.  Some time in the last hour or two Trac got
updated with 308 new Milestone=8.2.1 tickets.  I'd appreciate anyone who's
recently made bulk updates reconsider their actions.  Thanks!

Someone closed the 8.2.0 milestone, which auto-pushed all the tickets in
that milestone into the next milestone, which happens to be 8.2.1.


Devel mailing list

8.2.1 builds now underway.

2008-12-11 Thread Michael Stone
Dear world,

I pasted together an 8.2.1 build stream by copying the 8.2 build stream
on, substituting 8.2.1 for 8.2 everywhere
appropriate, adding a branch to's git repository, and
updating the upgrade server's branch-url map.

In short, you can now:

   download 8.2.1 builds from
   olpc-update 8.2.1-790 (and soon more)
   view 8.2.1 trac tickets at

Other comments: 

So far as I know, the is
still in force, though I'm certain that suggestions on ways that it
could be improved would be more than welcome.

I don't know yet what evidence Ed wants to see before accepting packaged
changes into this buildstream but I imagine that we'll work it out soon.



P.S. - People who maintain build-announcers -- please update them;
they're really helpful! Thanks!
Devel mailing list

Re: Way to tell if it is an XO

2008-12-10 Thread Michael Stone
On Wed, Dec 10, 2008 at 09:56:39AM -0200, Marcel Renaud wrote:
Thanks a lot for your answers.

Yes, I think a shared credentials are the best way.

Basically we want to offer a service just for the Xos and are working now on
the authentication model.
We are going to use webservices with
and place a signed key on each XO that is going to use the service, to
authenticate with the webservice provider.


Is it important to keep the credential(s) secret? If so: 

   * why?
   * for how long?
   * against what attack(s)?
   * how?
   * if (when) they leak, what next?

Also, what are the incentives for keeping the credentials secret? for
publishing them?


Devel mailing list

Wireless activation improvements.

2008-12-10 Thread Michael Stone
Ed, Kim, Emiliano, and Guadalupe,

As described in, I've succeeded in
repairing wifi-activation to my satisfaction. However, in its present
form, wifi-activation only makes use of the mesh and does not attempt to
acquire leases over any 802.11b/g networks. Clearly, the wifi-activation
technology would be more widely deployable if it could be used with
access points as well as with the mesh. Therefore: do we have any
interest in developing such a feature? 


(Previous conversations with Emiliano and Guadalupe suggested
to me that LATU would be pleased if we did so.)

(Alternately, is LATU interested in developing such a feature with our
aid, thereby expanding its skills in this area and potentially gaining
access to the feature more quickly?)
Devel mailing list

Re: One instance activity

2008-12-09 Thread Michael Stone
I believe that Browse already works this way. (There are many ways to
implement the feature, given the shared data directory available to
all instances of an activity.)

Devel mailing list

Re: Clone a whole dir from ?

2008-12-09 Thread Michael Stone
How about:

   scp -r [EMAIL PROTECTED]/git/activities .

? (Or were you saying that you need a real shell on dev?)

Devel mailing list

Re: Trac tickets for 8.2.1 release mislabeled

2008-12-09 Thread Michael Stone
My fault; overeager scripting to the rescue. 



P.S. - People interested in improving or reusing said overeager
scripting should examine and improve
Devel mailing list

Re: upgrade

2008-12-05 Thread Michael Stone
On Fri, Dec 05, 2008 at 07:11:04AM -0500, Ed McNierney wrote:
Michael -

Thanks; welcome back!  I have been working on the request you made last
week, and on trying to have something out this week as I said I would.  

Good to hear.

It's been important to me to ensure I'm reflecting OLPC's position as much as
possible rather than simply my own personal opinion, and I've been having
conversations to that effect.  

Absolutely! However, as David rightly points out, if it's going to be a
joint statement then it needs to be developed jointly at some point.

I'd like to see this happen by circulating a series of progressively
better drafts until we're satisfied (or to until we give up). When can
we expect a second draft from you?

(I wrote a first draft last week and circulated it privately under
'distribute to anyone who should read this' terms.)

Thanks again for the help.

My (long-term) pleasure.

Devel mailing list

Re: upgrade

2008-12-04 Thread Michael Stone
On Fri, Dec 05, 2008 at 01:47:02PM +1800, David Farning wrote:
On Fri, Dec 5, 2008 at 10:41 AM, Ed McNierney [EMAIL PROTECTED] wrote:
 David -

 I don't understand that comment.  What several efforts are you talking
 about?  I don't think there were several efforts to publicize this outage -
 if so, the scope of those efforts wasn't sufficient IMHO.

I was speaking of larger communication issues.

Two week ago you said that a statement would be forthcoming about the
relationship between Sugar Labs and OLPC.  If you had _only_ failed to
follow though, that would have been one thing.  

 Instead, you asked one of your employees to to say that a statement
 would be coming.  Thereby putting his reputation, not yours, on the

For the record, I was the one who asked Ed and Kim to assent to
participating in a joint statement; not the other way around. 

I requested this boon because I think that it's really quite important
for the representatives of OLPC and SugarLabs who need to work together
on a daily basis to be able to do so under mutually agreeable and
agreed-upon terms.

Now that I'm back from my visits with friends and family, I'll naturally
do what I can to see that this is put to rest as I hoped was going to
take place in my absence.


P.S. - Ed -- do you have any suggestions or edits that you'd like to
make before I start more broadly circulating, in draft form, the points
that I suggested to you last week?
Devel mailing list

Journal2 patches + timings + notes

2008-12-01 Thread Michael Stone

I spent some more time with Journal2 today and implemented two minor
features; namely, 

   * display of the estimated no. of results 
- (which helps deal with the display of empty result-sets) 

   * incremental display of results 
- (which makes it easier to time things). 

Please review and consider merging my patches, which can be found in

(That repo contains your journal2 code but none of the big pdfs or
screencasts you made since these are very time-consuming to download
onto an XO.)

I also did a bit of timing on my XO, (see the 'timing' branch), wherein
I learned, _anecdotally_ (i.e.  with sample-size n=1) that:

   * startup time seems okay, but the initial query takes about 10s to
 return results. I have about 300 MB of data indexed under
 /home/olpc, plus a bit of other junk. (~/.pinot is ~ 35 MB).
   * it takes around 4.2 seconds to fetch and display each new result
   * the standard deviation in my sample was large, e.g. about 3.3 seconds. 
   * 19 results were fetched.


   * I did not take care to ensure that the indexer had quiesced before
 my test run. (However, I don't think it was working hard since it
 did the bulk of the indexing yesterday; today, it only had to deal
 files changed by my editing and by the test run itself.)

   * With today's code, the search system is effectively unusable while
 the indexer is hard at work.
   * While I have not yet measured it carefully, it seemed to me that
 full indexing of a basic 767 system + activities _on XO_ may have
 taken as long as several hours.

   * With some, but not all queries, I noticed that the query failed
 because pinot failed to reply to journal2's blocking message sends
 within the usual dbus timeout of (30? 60?) seconds. I have no idea
 what was happening inside pinot.


P.S. - Thanks for the stimulating vacation entertainment.
Devel mailing list

Re: will there be an 8.2 update ?

2008-11-29 Thread Michael Stone
On Sat, Nov 29, 2008 at 05:48:17PM -0500, Mikus Grinbergs wrote:
My reason for asking is that I have a problem with Network Manager 
0.6 (ticket #8343).  If there is a chance that 8.2 will be improved, 
I will leave that ticket open.  If 8.2's Network Manager will not be 
updated, then I can close that ticket as 'wontfix', and instead 
write a different ticket against the newer Network Manager.  [What 
Network Manager 0.7 does/does_not_do needs to be described 
differently from what Network Manager 0.6 does/does_not_do.]

Will a 'fixpack for 8.2' be released ?

My rough impression is that if any point releases to 8.2 are made, they
will be created at the behest of a deployment via existing
country-support procedures. Therefore, I suspect your NM-0.7 ticket will
appeal to a larger audience than your 0.6 ticket. 

However, for completeness, you should also be aware that people with
Fedora CVS accounts and access to the joyride drop-boxes can supply new
versions of packages for use with 'yum update' for 8.2. Therefore, while
I am aware of little specific interest in releasing 8.2-bug-fixes before
9.1, it is technically feasible for interested volunteers to do so of
their own accord.

Does this help?

Devel mailing list

Journal2 recipe...

2008-11-29 Thread Michael Stone

I've wanted to see Journal2 running on an XO for some time so I:

1. flashed 767 onto my XO and installed git. 
2. checked out git://
* downloading and recompressing 80 MB of videos is really slow on an
  XO; please stick these in a submodule.
3. built myself a pinot rpm with your patches...
* checkout git://
* saved the diff from your pristine source import commit to HEAD;
  removed debian-specific hunks
* checkout pinot from Fedora cvs and, on the F-9 branch, 
  'cvs up -r pinot_0_85-1_fc9 .'
  to return to pinot-0.85-1(f9 is on pinot-0.89)
* modified the specfile to apply your cumulative patch
* make mockbuild MOCKCFG=fedora-9-i386
* posted the result to
  and installed it by
4. yum install pinot for deps, wget the patched pinot, 
then 'rpm -Uvh --force' updated pinot

5. as olpc, 'mkdir ~/Journal; cd journal2; python'
This is adequate to bring up a nice journal gui but, unfortunately,
searches yield no documents, presumably because none have been indexed.

What should I do in order to try out searching?


Devel mailing list

Re: Journal2 recipe...

2008-11-29 Thread Michael Stone
On Sat, Nov 29, 2008 at 09:18:12PM -0500, Michael Stone wrote:

This is adequate to bring up a nice journal gui but, unfortunately,
searches yield no documents, presumably because none have been indexed.

What should I do in order to try out searching?

Casual inspection of suggested that the main
'pinot' GUI can be used to instruct the pinot-dbus-daemon to start
indexing useful things like /home/olpc. In the future, it would be
helpful if journal2 came with a sample ~/.pinot/config.xml or if its
README instructed users to enable indexing in some other fashion.

Unsurprisingly, indexing on the XO is quite slow. More interestingly,
though, result retrieval and display is slow as well. 

Perhaps result display is blocked on result retrieval which is, perhaps,
competing with an indexing thread in a single low-priority process?

Devel mailing list

Re: [support-gang] G1G1 upgrade question I've received

2008-11-28 Thread Michael Stone
On Fri, Nov 28, 2008 at 10:21:01AM -0500, [EMAIL PROTECTED] wrote:
michael wrote:
  Just for the record, people using the 'olpc-update --usb' offline update
  method are probably going to want to use an 8.2 customization stick,
  e.g. the one archived in the '' file alongside the g1g1
  composite image on, to get recent activities.

i wonder if we could come up with some boilerplate text that could
be displayed at the top of our download pages that could explain
what each file type is, and how one would use it.

i.e., it seems we could make this:
or this:
a lot more user-friendly.

Sure, but we could more easily pull the necessary links into a wiki page
for each release and transclude it into the appropriate release notes. :)

Devel mailing list

Re: [support-gang] G1G1 upgrade question I've received

2008-11-28 Thread Michael Stone
On Fri, Nov 28, 2008 at 10:49:14AM -0500, [EMAIL PROTECTED] wrote:
maybe.  but a README would be pretty easy.  

I like READMEs, but I don't want to be in the business of maintaining
them. Unfortunately, I also don't really want to give the whole world
shell access to download.l.o. Compromise suggestions?

  (e.g. boilerplate text, redirect-to-wiki, create restricted account,
  use a cronjob, ...)

Devel mailing list

Re: Power Management plan for December.

2008-11-28 Thread Michael Stone
On Fri, Nov 28, 2008 at 04:18:11PM -0500, Chris Ball wrote:
Comments welcome.  Are there important power management bugs that I've
left out?

Yes; namely, finding or writing a good technical introduction to the
subject of power management as it applies to our software and hardware.
Such a document will be invaluable in coming months because, without it,
we'll communicate at a fraction of the efficiency we can achieve if
we're all starting from the same basic terminology and facts.

Perhaps this document already exists and I just don't know about it?

Devel mailing list

Re: [sugar] sugar 0.83 in joyride

2008-11-06 Thread Michael Stone
On Wed, Nov 05, 2008 at 03:34:14PM +0100, Simon Schampijer wrote:
 Tomeu Vizoso wrote:
 On Wed, Nov 5, 2008 at 10:31 AM, Tomeu Vizoso [EMAIL PROTECTED] wrote:
 Dear Masters of Joyride,

 have built updated sugar rpms and they seem to work fine on last joyrides.

 Marco pointed me out in #sugar that work fine may need some
 clarification. In fact, the following things are known to be broken

 - no WAP support (simon is working on this)
 - no mesh support (sjoerd has done work on this)
 - rainbow is broken because depends on the old config file being present is the rainbow patch - Michael can you  
 review and release a new rainbow when appropriate?


The patch looks fine to me but I'm headed off to UY, so it would
probably be best if someone else did the packaging.

Devel mailing list

Re: Pycon'09 CFP

2008-11-02 Thread Michael Stone

Turns out that the Pycon'09 deadline for proposal submission is
tomorrow. Are we giving any talks?

Devel mailing list

Re: setup for XO development

2008-10-30 Thread Michael Stone
On Thu, Oct 30, 2008 at 02:55:00PM +0100, Paolo wrote:

I would like to try out the XO software and get started with doing some

As I am a security guy, I am mostly interested in core development,
especially bitfrost/rainbow, and the document store. 

Music to my ears!

If you haven't already found them, please check out and

There are a bunch 'TODOs' on those pages where your assistance would be
most welcome, or if you prefer, you might suggest some topics that
interest you.

I expect an emulated environment would be a good choice for this type
of development.

Actually, for a variety of reasons, I'm working quite hard to make
rainbow usable on stock linux machines like those represented by
Debian and Fedora chroots.

Therefore, if you can show me interesting rainbow patches that work in
those environments, I'm quite likely to take them. 



P.S. - One long-standing request which might interest you is to
integrate rainbow into the sugar-jhbuild system used by many sugar
developers so that they conduct their regular development in an
environment more similar to that found on-XO. A nice side-benefit of
this task is that you would become well-equipped to participate in
further sugar-related and tinderbox-related development in the natural
course of fulfilling the task.

P.P.S. - What are you thinking about document storage?
Devel mailing list

  1   2   3   4   5   >