Re: System update spec proposal
On Wed, 2007-06-27 at 17:43 -0400, Polychronis Ypodimatopoulos wrote: I wrote some code to deal with both problems, so that you have a qualitative hop count (offering real numbers instead of just integers for hop count) for all nodes in the mesh without broadcasting/multicasting any frames. The following snapshot only shows one neighbor with perfect reception. http://web.media.mit.edu/~ypod/teleporter/dump.png I can clean up the code and upload it somewhere. I would very much appreciate that. ___ Devel mailing list Devel@lists.laptop.org http://lists.laptop.org/listinfo/devel
Re: rsync benchmarking
On 6/28/07, C. Scott Ananian [EMAIL PROTECTED] wrote: I wrote a quick ~60 line script to do non-recursive rsync a directory at a time. Actually, it's a little smarter than that: it generates manifests for each directory, and syncs the tree by first syncing the root (and the root's manifest). It then checks the directory hashes in the roots manifest against the current contents of the directory's manifest, and recurses only if they don't meet (ie, if the directory has been updated). rsync itself does all of that, and it's pretty efficient at it. Oh - I see, your optimisation is to declare a hash of the top-level directory and exchange that first, and only recurse if they differ (like git does). Hmmm. Wouldn't that be a good enhancement to rsync itself? Perhaps there are a few such patches to rsync in existence already...? m ___ Devel mailing list Devel@lists.laptop.org http://lists.laptop.org/listinfo/devel
Re: System update spec proposal
On Wed, 2007-06-27 at 18:37 -0400, Ivan Krstić wrote: On Jun 27, 2007, at 2:57 AM, David Woodhouse wrote: Nevertheless, it's an accurate description of what happened. Let's agree to disagree. Sounds like a fine plan. As long as we're united on the common goal to drop vserver as soon as possible and replace it with something which is viable and supportable, I really don't care enough to argue about whatever else we might have disagreed upon. I certainly didn't mean to place blame at your door -- you needed input from kernel hackers and you didn't get it because we were all busy doing other things. That's not your fault. In any case, it doesn't matter at this point. We have work to do. Indeed. -- dwmw2 ___ Devel mailing list Devel@lists.laptop.org http://lists.laptop.org/listinfo/devel
Re: rsync benchmarking
On Jun 28, 2007, at 3:55 AM, Martin Langhoff wrote: rsync itself does all of that, and it's pretty efficient at it. No it doesn't; such functionality only exists in rsync 3.0. See the comments from Tridge. Right now, if you let rsync 2.x sync a tree, it will go and read (data structures for) the whole tree in memory regardless of how large it is. Scott fixes this by externally breaking down the tree into smaller chunks and then rsyncing those individually, such that the memory consumption during any particular rsync operation remains relatively small. -- Ivan Krstić [EMAIL PROTECTED] | GPG: 0x147C722D ___ Devel mailing list Devel@lists.laptop.org http://lists.laptop.org/listinfo/devel
usage of usb sticks on the laptops
Hi all, we've recently added support for usb sticks in the datastore and the journal activity and I'm a bit worried about the kids pulling out the stick before the data has been fully written into the stick. Perhaps we'll need to do the same as is done everywhere and notify when a device that needs to be safely unmounted is mounted, and complain to the user when the stick is removed unsafely. But I wanted to ask first to more knowledgeable people if there's any way to reduce this problem, for example by mounting the sticks with the mount option 'sync'. Perhaps in some cases (small drives) we can exchange the perf hit for a bit more of safety. Thanks, Tomeu ___ Devel mailing list Devel@lists.laptop.org http://lists.laptop.org/listinfo/devel
Re: usage of usb sticks on the laptops
On Jun 28, 2007, at 5:30 AM, Tomeu Vizoso wrote: Perhaps we'll need to do the same as is done everywhere and notify when a device that needs to be safely unmounted is mounted, and complain to the user when the stick is removed unsafely. Normally, complaining is all you can do because the OS provides unmediated access to the underlying FS on the USB stick. But hey, we're not doing that; we're talking to the datastore on the device first. So you have an elegant way of avoiding this whole problem. When you're about to write a file to the USB device, here's what you do: 1. Start transaction in USB stick datastore. 2. Add a row to the pending_writes table in USB stick datatore specifying file name, size, and path of file to be written. 3. End transaction. 4. Copy file to USB stick. 5. Sync. 6. Begin transaction in USB stick datastore. 7. Remove row from pending_writes table. 8. Add row to normal file table. 9. End transaction. Now, every time when mounting an USB stick, for every row in the pending_writes table of the stick's datastore: 1. Does file size on stick match size in pending_writes table? If so, go to step 6 above. If not, proceed with next step. 2. Unlink file from stick. 3. Begin transaction in stick datastore. 4. Remove row from pending_writes table. 5. End transaction. That's it. I had this implemented and working perfectly in Yellow, and I was using MD5 instead of file size as the validity check. It didn't slow things down because having to even check it is a corner case already. Cheers, -- Ivan Krstić [EMAIL PROTECTED] | GPG: 0x147C722D ___ Devel mailing list Devel@lists.laptop.org http://lists.laptop.org/listinfo/devel
Re: Test Group release notes, build 466
Hello, some notes about the notes... * Search and resume works in sugar-jhbuild. 466 does not have the latest code so let's reevaluate with the next image. * Journal can't be closed anymore, I checked in a fix for that. * I sent a separate mail about Paint, we need to figure out what to do about it. * Activities starting on mouse over. It looks like you can now click on the trackpad which I believe is the reason of the behavior. Might want to tweak the trackpad sensitivity. * We can easily tweak mouse speed. I can work on it with Eben (I assume he is the right person to look into this). * The key related issues blocks on #663 * Power button not shutting down the system is indeed the wanted behavior. * The icon in Read is actually a Save icon. I added a tooltip but the confusion might mean the icon is not quite intuitive. * Your problems opening activities might be related to a journal bug which is now fixed. Let's test again on the next image. Marco ___ Devel mailing list Devel@lists.laptop.org http://lists.laptop.org/listinfo/devel
Re: Test Group release notes, build 466
Thanks Marco! Kim On 6/28/07, Marco Pesenti Gritti [EMAIL PROTECTED] wrote: Hello, some notes about the notes... * Search and resume works in sugar-jhbuild. 466 does not have the latest code so let's reevaluate with the next image. * Journal can't be closed anymore, I checked in a fix for that. * I sent a separate mail about Paint, we need to figure out what to do about it. * Activities starting on mouse over. It looks like you can now click on the trackpad which I believe is the reason of the behavior. Might want to tweak the trackpad sensitivity. * We can easily tweak mouse speed. I can work on it with Eben (I assume he is the right person to look into this). * The key related issues blocks on #663 * Power button not shutting down the system is indeed the wanted behavior. * The icon in Read is actually a Save icon. I added a tooltip but the confusion might mean the icon is not quite intuitive. * Your problems opening activities might be related to a journal bug which is now fixed. Let's test again on the next image. Marco ___ Devel mailing list Devel@lists.laptop.org http://lists.laptop.org/listinfo/devel
Re: rsync benchmarking
On 6/28/07, Ivan Krstić [EMAIL PROTECTED] wrote: regardless of how large it is. Scott fixes this by externally breaking down the tree into smaller chunks and then rsyncing those individually, such that the memory consumption during any particular rsync operation remains relatively small. This has a nice synergy in that the hash of the top-level manifest is all that is required to authenticate the entire directory tree. (That's a Merkle hash, for those playing along at home.) Ivan: is the format of the antitheft server's response documented somewhere? If so, we should throw in the top-level hash along with the relative url; this will save an extra authentication step since the hash can be signed along with the rest of the antitheft response. --scott -- ( http://cscott.net/ ) ___ Devel mailing list Devel@lists.laptop.org http://lists.laptop.org/listinfo/devel
Re: rsync benchmarking
On Jun 28, 2007, at 1:41 PM, C. Scott Ananian wrote: Ivan: is the format of the antitheft server's response documented somewhere? If so, we should throw in the top-level hash along with the relative url; this will save an extra authentication step since the hash can be signed along with the rest of the antitheft response. There's an early prototype spec I wrote floating around internally. I'll work on updating it, but yeah, throwing a hash in there will be absolutely no problem. -- Ivan Krstić [EMAIL PROTECTED] | GPG: 0x147C722D ___ Devel mailing list Devel@lists.laptop.org http://lists.laptop.org/listinfo/devel
Re: object store apis
Hello all, Thibaut is the author of meshboard.xo [1], a mesh community-board app that currently (as a hack) uses its own xml-rpc server in each instance to send messages to others running the activity. Ryan Trinkle is interested in working on message passing and discovery of small pieces of content over the network -- items on a community board, or selections from a set of wiki articles that a group is sharing. Copying Lenny Foner who's been involved in related discussions. What's the right way for activities like meshboard to pass posts or updates? Where should feedback about the object store API or desired API go? SJ [1] http://www.lamadon.com/olpc/ (Thibaut, it would be nice to have a cleaned-up version of meshboard to test over the next couple of weeks. :) ___ Devel mailing list Devel@lists.laptop.org http://lists.laptop.org/listinfo/devel
Re: object store apis
On Thu, 2007-06-28 at 13:59 -0400, SJ Klein wrote: Hello all, Thibaut is the author of meshboard.xo [1], a mesh community-board app that currently (as a hack) uses its own xml-rpc server in each instance to send messages to others running the activity. Ryan Trinkle is interested in working on message passing and discovery of small pieces of content over the network -- items on a community board, or selections from a set of wiki articles that a group is sharing. Copying Lenny Foner who's been involved in related discussions. What's the right way for activities like meshboard to pass posts or updates? Where should feedback about the object store API or desired API go? Tubes, most likely. Given the activity ID, everyone should be able to reconnect to the same tube and then meshboard would sync stuff amongst each buddy's instance. Dan ___ Devel mailing list Devel@lists.laptop.org http://lists.laptop.org/listinfo/devel
Re: System update spec proposal
On Tue, 2007-06-26 at 14:21 -0400, Christopher Blizzard wrote: First about approach: you should have given this feedback earlier rather than later since Alex has been off working on an implementation and if you're not giving feedback early then you're wasting Alex's time. Also I would have appreciated it if you had given direct feedback to Alex instead of just dropping your own proposal from space. It's a crappy thing to do. I owe Ivan an apology here. I should have handled this in private email instead of on a public mailing list. --Chris ___ Devel mailing list Devel@lists.laptop.org http://lists.laptop.org/listinfo/devel
OLPC software: our first release and beyond.
OLPC software efforts have been, from Day 1, a community effort. The extent to which the community has risen to the occasion at every level—from firmware to application and content development—is an inspiration. As we approach our final series of trial software releases this summer and our first release this fall, it is appropriate to reflect on what we have achieved and where we are heading. Starting with firmware, the transition to Open Firmware, led by Mitch Bradley, has given us a powerful, simple, and robust platform upon which to build a stable and open system. Most of the core functionality is present (and debugged). The recent refactoring of the communications protocols used to communicate with our Embedded Controller (EC) better positions us—over time—to rewrite the entirety of the EC code in an open and more streamlined fashion and release it as free software. The efforts of Marvell and Cozybit have brought us to the point where all the core mesh functionality now works. Efforts to track (and help steer) the emerging 802.11s standard continue; and movement towards a free and open software stack to run on the mesh co-processor proceed. We are firmly committed to software freedom and anticipate—as the mesh and EC code become open—offering free software to run all the subcomponents in our machine. At the kernel level, through combined efforts of the OLPC team, Red Hat, AMD, and the Linux community, we continue to track the kernel mainline and contribute upstream all of our improvements and bug fixes. At several places we have diverged—perhaps the most controversial being our choice of VServer as an interim container virtualization solution—but for the most part we have succeeded in leveraging the work of the broader community and keeping our differences to a minimum. Our choice of Fedora—we are almost transitioned to the newly-released Fedora Core 7—as our distribution has also contributed to controversy within the Linux community. There are any number of small-footprint distributions that may well have served our purposes, but Fedora met and continues to meet our needs; and the dedication of the Red Hat team at every level has been extraordinary. Without the likes of Marcelo Tosatti and David Woodhouse, we would be far short of our goals. Red Hat shares our uncompromising dedication to free and open-source solutions and continues to go the extra mile to ensure that neither quality or principles are sacrificed. The user experience through the Sugar interface puts us within reach of many of our goals: simplicity without compromised functionality; discoverability and usability; security and robustness; transparency through layered exploration; and, perhaps most important, support for a learning environment that is both expressive and collaborative. The UI team, led on the design side by Pentagram and OLPC's Eben Eliason and on the software side by Red Hat's Marco Gritti (Bryan Clark and Seth Nickell contributed to some of the early foundational design work), has created a framework that offers powerful simplicity without limiting the richness of interaction that children can have with each other and their teachers. As we expand upon the work of Dan Williams and the Collabora team, we will see more Activities that run across multiple laptops, which enable a new level of collaboration for individual and group projects. Many of these features are built directly into Activities such as Etoys, but a common framework and API is key to making collaboration a system-wide feature. The Presence Service, which governs how children represent and find each other on the network, is essentially complete. Our next software release will include scalable mechanisms for shared activities using Tubes as a data transport, both peer-to-peer within the mesh and within the context of a server. The preceding paragraphs enumerate much of the phenomenal progress that we have made as we prepare to ship our Generation-1 laptops. While we were told repeatedly that many of the problems we faced were unsolvable; we find ourselves vindicated and empowered by the combined efforts of our community, partners, and in-house engineers, who have found solutions to these unsolvable problems. It is important now to set expectations for the software that ships on the XOs in September. The tremendous amount of work to date does not change the fact that our first-release software is very much a work in progress. The software at ship time will not have all the richness of the Mesh view as described in our User Interface Guide, but we are on track to have an extensible framework in place. The Journal, another important component of Sugar, recently appeared in our builds and currently offers bare-bones functionality; however, the first iteration of the data store is near completion and includes support for removable media and network file systems. The Journal is on track to include more features, such as a rich system to tag, search, and
