Re: New, more realistic multi-hop network testbed
On Sat, Jun 7, 2008 at 2:31 AM, Polychronis Ypodimatopoulos <[EMAIL PROTECTED]> wrote: > C. Scott Ananian wrote: > > Last I checked, Poly wasn't an employee of OLPC. > I don't think this is a valid argument either: Not being an employee of OLPC does not mean I 'm willing to waste my > time on something OLPC has no interest in. Like most other volunteers, > work at OLPC is interesting because it's technically challenging and > globally significant. If the work is not in OLPC's radar of interest, > then something's wrong and it should be discussed. > I'm glad you said this; I was going to chime in with the same thought. Providing a global sense of significance and priority -- through accurate and complete transmission of feedback, and through review of all ideas being offered or tested -- is one of the most valuable things OLPC can offer its contributors and supporters. SJ ___ Devel mailing list Devel@lists.laptop.org http://lists.laptop.org/listinfo/devel
Re: VGA external on OLPC
By not too hard, I meant, not completely impossible. I was given a little bit of info on the board because I promised Wad that I wouldn't get other people to bother him about it :S At least I didn't post the hardware list to my blog! Seth btw, I'm whyxo.com On Tue, May 13, 2008 at 5:26 PM, Paul Fox <[EMAIL PROTECTED]> wrote: > martin wrote: > > On Wed, May 14, 2008 at 3:40 AM, John Watlington <[EMAIL PROTECTED]> > wrote: > > > > http://wiki.laptop.org/go/Remote_display#Binaries > > > Can you be more specific as to what USB video adapters > > > this might work with ? > > > > It's packaged in most distros (F7, recent Ubuntus), so `man sisusb` or > > `man sisusbvga` should give an passable overview. The author keeps a > > good page: > > > > http://www.winischhofer.eu/linuxsisusbvga.shtml > > > > > how would one go about influencing which driver modules, for > "accessory" peripherals like this, get built as a matter of > course for new kernels? > > it seems to me that there's a (perhaps minor, but real) need for > builds of drivers that don't necessarily get packaged on every > XO, but which are available somewhere, for every kernel. this > usb vga thing is a good example. others which keep coming up on > the forums are things like bluetooth support, and the full set of > usb serial dongles. i built and made available the bluetooth and > usb serial modules for the use of some G1G1 folks, but that > tarball will go stale pretty quickly when the kernel moves on. > > there are other equally "optional" modules (like usb audio > support) which _do_ get built and installed by default. seems like > there might be a win-win possible by separating "what to build" > from "what to install" -- the default install could shrink, and > the flexibility for users would go up. > > (there may be a trac item already on this -- i admit to not > looking.) > > paul > =- > paul fox, [EMAIL PROTECTED] (arlington, ma, where it's 53.6 > degrees) > ___ > Devel mailing list > Devel@lists.laptop.org > http://lists.laptop.org/listinfo/devel > ___ Devel mailing list Devel@lists.laptop.org http://lists.laptop.org/listinfo/devel
Re: [Fwd: Re: #7116 NORM Never A: Possible European G1G1 program needs appropriate keyboards]
Hi Kim, On Tuesday 03 June 2008 21:48, Kim Quirk wrote: > Agreed, Ed. The legalities of each country need to be determined and > met before we can include that country in a Give One Get One program. > > Some of the things we need to understand are: Certifications, > language/keyboard requirements, messaging, non-profit status, > shipping, customs, support and warranties. I believe these issues (and > perhaps more) will be different for almost every country. What can we, as OLPC Germany association, do to help you to understand the legal situation (and anything else) in Germany? Also, what can we do, to make a german keyboard reality? We have keyboard layouts available on http://wiki.olpc-deutschland.de/organisation/beirat/hardware regards, Holger pgpBQgLoaF65r.pgp Description: PGP signature ___ Devel mailing list Devel@lists.laptop.org http://lists.laptop.org/listinfo/devel
Re: New faster build 2024
'olpc-update -f joyride-2024' does not work for me (from 653 or 708). Error message : 'I don't think the requested build exist'. updating to 2018 seems to work fine. Simon Build Announcer v2 wrote: > http://xs-dev.laptop.org/~cscott/olpc/streams/faster/build2024 > > Changes in build 2024 from build: 2019 > > Size delta: 0.00M > > -sugar 0.81.2-1.gitc2f847c2d4.olpc2 > +sugar 0.81.3-1.olpc2 > -sugar-base 0.79.1-1.olpc2 > +sugar-base 0.81.1-1.olpc2 > -sugar-toolkit 0.81.3-2.gitfcc468a323.olpc2 > +sugar-toolkit 0.81.4-1.olpc2 > -Journal 90 > +Journal 91 > > --- Changes for sugar 0.81.3-1.olpc2 from 0.81.2-1.gitc2f847c2d4.olpc2 --- > + Search in the activity list (Tomeu) > + Add installation date in the activity list (Tomeu) > + Improve performance of the activity list (Tomeu) > + Sort activities in the list and ring by installation date (Tomeu) > + Speaker device (Martin Dengler) > + Graphical frontend for the control panel (Simon) > + Rotate the dpad keys when the screen rotate button is pressed (Erik > Garrison) > > --- Changes for sugar-base 0.81.1-1.olpc2 from 0.79.1-1.olpc2 --- > + Fix logging (Tomeu) > > --- Changes for sugar-toolkit 0.81.4-1.olpc2 from > 0.81.3-2.gitfcc468a323.olpc2 --- > + Add an installation time property to the activity bundle (Tomeu) > + Reveal palettes on right-click (Eben) > + Refactor bundlebuilder and add dist_source command (Marco) > + Enable journal to do open-with for activity bundles (Chema) > + Add timezone, hot_corners, warm_edges to the profile (Simon) > > --- Changes for Journal 91 from 90 --- > + Arabic translations update (Khaled) > + Italian translations update (Carlo) > + Misc small fixes (Simon and Tomeu) > > -- > This mail was automatically generated > See http://dev.laptop.org/~rwh/announcer/faster-pkgs.html for aggregate logs > See http://dev.laptop.org/~rwh/announcer/joyride_vs_update1.html for a > comparison > ___ > Devel mailing list > Devel@lists.laptop.org > http://lists.laptop.org/listinfo/devel > ___ Devel mailing list Devel@lists.laptop.org http://lists.laptop.org/listinfo/devel
speed reading activity?
one of the things that got me started reading well was that at an early age I went to a school that had a speed reading activity. it had light cardstock sheets that you ran through a machine that moved them at the appropriate speed through a ~4-5 line window and the student would take a quiz on what they just read. I've been digging a little bit, but not finding anything like this available for the XO. has anyone seen anything like this? if so could you point me at it? David Lang ___ Devel mailing list Devel@lists.laptop.org http://lists.laptop.org/listinfo/devel
Re: New, more realistic multi-hop network testbed
On Jun 7, 2008, at 2:31 AM, Polychronis Ypodimatopoulos wrote: > C. Scott Ananian wrote: >> Last I checked, Poly wasn't an employee of OLPC. > I don't think this is a valid argument either: > > Not being an employee of OLPC does not mean I 'm willing to waste > my time on something OLPC has no interest in. Like most other > volunteers, work at OLPC is interesting because it's technically > challenging and globally significant. If the work is not in OLPC's > radar of interest, then something's wrong and it should be discussed. And I didn't mean that OLPC isn't interested in making the mesh work. The opposite is the truth.But we HAVE to prioritize the testing being done to the scenarios we are deploying into. > Being an employee of OLPC does not mean your technical solution is > better than mine either (me being a volunteer). Please don't take > this personally or literally. Having such a large pool of > volunteers means you may have to assess your software stack more > often against what volunteers can offer you. Companies that aren't resource starved frequently fund different approaches. Volunteers can make that possible even in resource starved companies. >> I don't think we can or should make him fix our dense network >> problems, or run our mesh >> testbed. > > Heh, I think I actually offered a solution on the first and > volunteered for the second, but was put off until OLPC figures out > what how to proceed with the mesh testbed. What I am saying is that I don't believe a mesh testbed addresses OLPC's customer's immediate needs.A collaboration testbed does. >> We should, however, give him all the support he needs (and >> he's only asking for ~10 laptops) to create the sparse network >> testbed >> he's interested in, since we will need that after 8.2, and if it's to >> be ready then someone needs to start working on it now. I read more than ten. Ten laptops aren't worth the time already spent on this thread. I would like to point out that both Marvell and Nortel have mesh testbeds (100 and 50 nodes, respectedly).Our problem has been that no-one has a collaboration testbed. >>> The 8.2 release is the one that Peru will be using next year (2009). >>> It is very important that any MPP functionality that is added back >>> to the build be very well tested in the dense school wifi scenario >>> by 8.2 freeze to ensure happy customers. >> >> Yes, continued wireless testing is important. We also need to be >> willing to act on the results of that testing. > > I must admit that it is rather hard for OLPC to act on such > results. It may be for lack of resources, but I'm speaking for > myself when I say that OLPC has a hard time trusting developers > unless they're on its payroll, especially for core parts of its > software (with the exception of Marco? ;-). I think commitment, > communication and roadmaps is the answer to this problem. Lack of resources and QA testing. As Martin put it, we can't take Linus' approach of putting stuff into our build and letting the customer test it.If we put it in our build, it should have been tested, tested, tested. I'm sorry, but I've spent too much time in the last week being told what doesn't work. If the laptops can't communicate well in a school, OLPC fails. wad ___ Devel mailing list Devel@lists.laptop.org http://lists.laptop.org/listinfo/devel
Re: Peru Upgrade process.
On Jun 7, 2008, at 1:16 AM, C. Scott Ananian wrote: > On Fri, Jun 6, 2008 at 11:32 PM, Martin Langhoff > <[EMAIL PROTECTED]> wrote: >> As Wad discussed today, the new upgrade process is a step backwards >> from what we had before. Specifically, it will wipe activation keys >> and homedirs. >> >> I am not sure how important people @ 1CC find this to be, but it's a >> pretty awkward thing when contemplating on-the-field upgrades. And I >> have no idea how feasible it to add that back. >> >> What Wad had prepared was a usb stick with an rpm, an image file >> and a >> shellscript that - when executed - would install the olpc-upgrade >> (update?) rpm and execute it pointing to the image file. We did >> notget >> a chance to test it, as plans changed and we ended up going to >> Arahuay, where XOs were mostly up-to-date. > I'm not sure where this "new upgrade process" stuff is coming from. > If by "new upgrade process" we're talking about olpc-update, then it > certainly does preserve activation and home dirs. If "new upgrade > process" means secure reflash: it is specifically meant for clean > "factory fresh" installs only. If you're trying to preserve user > homedirs, then that's not what you want to be using. (And how "new" > is this, anyway?) This ties back to why we ship machines to G1G1 without developer keys. It isn't new, but I hadn't been paying attention as I always have developer keys in order to run the newest builds. And, for the sake of repeatable testing of hardware or networking, I usually reflash instead of upgrading. > Talking to wad over IRC, what he seemed to really be saying was that > there wasn't a "no keystrokes required" way to use olpc-update on a > classroom full of machines *without involving a school server*. And I > will admit that that wasn't a use case I ever had in mind, for a > variety of reasons. Look, the reality on the ground is that Peru has at least 15K laptops in the field running 651/653/656 that need upgrading.They will not have school servers deployed for another three months.If upgrade (not reflash) requires more than inserting a key, or it wipes the activation lease/the kids work, this won't happen. This wasn't in my plans either. But reality has a way of intervening itself. > As you mention, there are a number of "minimal keystroke" methods of > upgrading a classroom full of machines, with the most direct being to > put a small script on a USB key that can be invoked from console or > terminal to run through the steps. The initial "upgrade olpc-update > from an RPM" step in that script won't be necessary going from 703. > The intent was to do field upgrades primarily over the network from a > school server. Is that no longer the plan of record? That is still the recommended method (although I would believe this more if someone had packaged the update service for the school server), but that plan needs to also include a simple (no typing) method to upgrade (not reflash) a laptop from a USB key. I don't know when that requirement got lost from the "plan of record". wad ___ Devel mailing list Devel@lists.laptop.org http://lists.laptop.org/listinfo/devel
Re: speed reading activity?
There seems to be two problems for a speed reading activity in the XO. The first is that some of those technologies are patent encumbered, but it seems that the main technology or concept behind speed reading, called rapid serial visual presentation, it's either patent free or free of royalties. So writing an activity based on RSVP could be feasible. The second problem could be that this can be a battery drainer, the screen is constantly swapping words. I've written a flashcard activity*, and I've implemented a way to see the answer using RSVP; don't have a real XO (I'm developing using sugar-jhbuild under Ubuntu) but I could modify what I've coded to do a test activity to see how much battery reading a test that way consumes. If speed reading activity is to be written, you could also take advantage of the screen size, because RSVP seems to be suited for small screens, like mobile phones and PDAs and the rest of the XO's screen could be used someway or another. Cheers, Urko *http://wiki.laptop.org/go/Assimilate On Sat, 2008-06-07 at 06:32 -0700, [EMAIL PROTECTED] wrote: > one of the things that got me started reading well was that at an early > age I went to a school that had a speed reading activity. it had light > cardstock sheets that you ran through a machine that moved them at the > appropriate speed through a ~4-5 line window and the student would take a > quiz on what they just read. > > I've been digging a little bit, but not finding anything like this > available for the XO. > > has anyone seen anything like this? if so could you point me at it? > > David Lang > ___ > Devel mailing list > Devel@lists.laptop.org > http://lists.laptop.org/listinfo/devel ___ Devel mailing list Devel@lists.laptop.org http://lists.laptop.org/listinfo/devel
Re: speed reading activity?
On Sat, 7 Jun 2008, Urko Fernandez wrote: > There seems to be two problems for a speed reading activity in the XO. > The first is that some of those technologies are patent encumbered, but > it seems that the main technology or concept behind speed reading, > called rapid serial visual presentation, it's either patent free or free > of royalties. So writing an activity based on RSVP could be feasible. the approach that I used was over 30 years ago, so if there is a patent on it it's either expired or invalid due to prior art. > The second problem could be that this can be a battery drainer, the > screen is constantly swapping words. I've written a flashcard activity*, > and I've implemented a way to see the answer using RSVP; don't have a > real XO (I'm developing using sugar-jhbuild under Ubuntu) but I could > modify what I've coded to do a test activity to see how much battery > reading a test that way consumes. yes, it will prevent the system from going to sleet, but the current versions of the software can't put the system to sleep while keeping the screen running anyway, so it's not a short-term problem it will eat up a little cpu to scroll the screen, but it should't be that bad (and in any case can be deemed an accdeptable trade-off for the capability. > If speed reading activity is to be written, you could also take > advantage of the screen size, because RSVP seems to be suited for small > screens, like mobile phones and PDAs and the rest of the XO's screen > could be used someway or another. what I'm envisioning is the ability to define a window size (which would be much smaller then the XO screen size in most cases), the scroll rate, and the font size. it would then smoothly scroll the text through the window and then quiz the student for comprehention and calculate a wpm score (raw speed - penalties for missing comprehention questions) this seems such a trivial (but useful) that I'm having trouble beliving that nobody has one already written. David Lang > Cheers, > > Urko > > *http://wiki.laptop.org/go/Assimilate > > On Sat, 2008-06-07 at 06:32 -0700, [EMAIL PROTECTED] wrote: >> one of the things that got me started reading well was that at an early >> age I went to a school that had a speed reading activity. it had light >> cardstock sheets that you ran through a machine that moved them at the >> appropriate speed through a ~4-5 line window and the student would take a >> quiz on what they just read. >> >> I've been digging a little bit, but not finding anything like this >> available for the XO. >> >> has anyone seen anything like this? if so could you point me at it? >> >> David Lang >> ___ >> Devel mailing list >> Devel@lists.laptop.org >> http://lists.laptop.org/listinfo/devel > > ___ Devel mailing list Devel@lists.laptop.org http://lists.laptop.org/listinfo/devel
Re: Sucrose 0.81.2 Development Release
The Glucose modules[1] from Sucrose 0.81.2 went into the olpc image joyride-2024. Here are instructions[2] how to update and how to get the Fructose modules[3]. [1] Glucose modules http://wiki.sugarlabs.org/go/Taxonomy#Glucose:_The_base_Sugar_environment [2] Update instructions http://wiki.sugarlabs.org/go/ReleaseTeam/Releases/Sucrose/0.81.2#Instructions_to_test_in_olpc_joyride [3] Fructose modules http://wiki.sugarlabs.org/go/Taxonomy#Fructose:_A_set_of_demonstration_activities Best, Simon Simon Schampijer wrote: > Watch out your teeth! > > The new Sucrose[1] 0.81.2 Development Release is out! > > This release has many great improvements. Pippy and the Log activity fixed > the > platform specific issues and could be added to the release. Refinements has > been > made to the activity list view like adding installation dates of the > activities, > sorting by dates and searching in the list of activities. > > The control panel has been refactored and has now a graphical interface as > well as > the command line one. Refactoring work has been done as well in the > bundlebuilder > and a speaker device has been added to the frame so you can control the > volume of > your speakers from there. In Etoys new phrases have been marked for > translation to > improve internationalization even more. > > Make sure to check out the new palette features for links in the web-activity > and > try to quit the terminal activity by quitting the shell. As another little > smoke > test you could use the control panel to change your buddy to use a light fill > color > and check that the chat activity uses black text for your messages then. > > Finally, if the frame pops up unintentionally during these actions you can > find now > a slider to set different activation delays for the frame in the control > panel. > > More detailed news are at [2] and as well at the end of this email. > > If your feature missed that train, don't be sad the next cycle is already on > in two > weeks[3]. > > Thanks to everyone who made this release possible! > > In behalf of the sugar community, > Your release team > > > [1] Sucrose > http://wiki.sugarlabs.org/go/Taxonomy#Sucrose:_The_interface.2C_plus_a_set_of_demonstration_activities > > [2] Release Notes: > http://wiki.sugarlabs.org/go/ReleaseTeam/CurrentRelease/Sucrose > > [3] Sucrose Release Schedule: > http://wiki.sugarlabs.org/go/ReleaseTeam/Roadmap#Schedule > > ___ > > sugar-base > * Fix logging (Tomeu) > > sugar-toolkit > * Add an installation time property to the activity bundle (Tomeu) > * Reveal palettes on right-click (Eben) > * Refactor bundlebuilder and add dist_source command (Marco) > * Enable journal to do open-with for activity bundles (Chema) > * Add timezone, hot_corners, warm_edges to the profile (Simon) > > sugar > * Search in the activity list (Tomeu) > * Add installation date in the activity list (Tomeu) > * Improve performance of the activity list (Tomeu) > * Sort activities in the list and ring by installation date (Tomeu) > * Speaker device (Martin Dengler) > * Graphical frontend for the control panel (Simon) > * Rotate the dpad keys when the screen rotate button is pressed (Erik > Garrison) > > sugar-artwork > * Skipped this release > > sugar-datastore > * Skipped this release > > sugar-presence-service > * Skipped this release > > etoys > * more translatable phrases > * minor tile fixes > > journal-activity > * Arabic translations update (Khaled) > * Italian translations update (Carlo) > * Misc small fixes (Simon and Tomeu) > > Fructose modules > * read-activity 46 > * chat-activity 40 > * terminal-activity 12 > * web-activity 89 > * etoys-activity 81 > * write-activity 55 > * calculate-activity 19 > * log-activity 9 > * pippy-activity 22 > > Fructose news > > read-activity > * Skipped this release > > chat-activity > * #5767: Use black text on light fill colors (matthias) > > terminal-activity > * #5520: Make the activity exit when the user exits the shell. > (sayamindu) > > web-activity > 89 > * Make the object chooser transient on the activity window. (tomeu) > 88 > * Add Edit toolbar (tomeu) > * Add Follow link item to link palette (tomeu) > * Add palette for images (tomeu) > * Add a simple palette for links with an option to copy to the clipboard > (tomeu) > > calculate-activity > * Skipped this release > > write-activity > * Skipped this release > > log-activity > * make users non-olpc be able to read the sugar logs - this is important > for > the activity running on non xo platforms > > pippy activity > * Add check to not fail on new gtksourceview2 API - this is needed for > the > activity to run on non xo platforms > > >
Re: speed reading activity?
Le samedi 07 juin 2008 à 06:32 -0700, [EMAIL PROTECTED] a écrit : > one of the things that got me started reading well was that at an early > age I went to a school that had a speed reading activity. it had light > cardstock sheets that you ran through a machine that moved them at the > appropriate speed through a ~4-5 line window and the student would take a > quiz on what they just read. > > I've been digging a little bit, but not finding anything like this > available for the XO. > > has anyone seen anything like this? if so could you point me at it? > We have something close in GCompris: http://gcompris.net/en-readingh http://gcompris.net/incoming/xo/readingh.activity.xo We have a vertical reading variant: http://gcompris.net/incoming/xo/readingv.activity.xo Bruno. ___ Devel mailing list Devel@lists.laptop.org http://lists.laptop.org/listinfo/devel
Re: speed reading activity?
On Sat, 2008-06-07 at 08:16 -0700, [EMAIL PROTECTED] wrote: > the approach that I used was over 30 years ago, so if there is a patent on > it it's either expired or invalid due to prior art. > They say in this blog that the oldest patent describing this technique expired in 2006: http://blog.willbenton.com/2004/03/rapid-serial-visual-presentation-software-patents/ The developer of a software called FastReader points out the technology is public domain and that his software is still available. > yes, it will prevent the system from going to sleet, but the current > versions of the software can't put the system to sleep while keeping the > screen running anyway, so it's not a short-term problem > > it will eat up a little cpu to scroll the screen, but it should't be that > bad (and in any case can be deemed an accdeptable trade-off for the > capability. > I was going to test my own activity on a real XO next week, so I can test how much battery time is available when displaying text using speed reading techniques. > > what I'm envisioning is the ability to define a window size (which would > be much smaller then the XO screen size in most cases), the scroll rate, > and the font size. it would then smoothly scroll the text through the > window and then quiz the student for comprehention and calculate a wpm > score (raw speed - penalties for missing comprehention questions) > There is an similar application for PDAs: http://www.pocketnow.com/index.php?a=portal_detail&t=reviews&id=333 They do also display a portion of the current read text and they use a color bar that shows where in the sentence you are. I bet all those additions are patented, if we design something different (albeit similar), would it be safe? Should we discuss this ideas publicly before publishing any working code? What's the modus operandi in this situation? > this seems such a trivial (but useful) that I'm having trouble beliving > that nobody has one already written. That doesn't mean there's nobody willing to do it ;) There is a software called flash written in python, we could port it or use it to do an activity: http://toykeeper.net/programs/flash/files/ It's GPLv2, and it seems designed for PDAs. Urko ___ Devel mailing list Devel@lists.laptop.org http://lists.laptop.org/listinfo/devel
Re: New, more realistic multi-hop network testbed
Wad, John Watlington wrote: > I would like to point out that both Marvell and Nortel have mesh testbeds > (100 and 50 nodes, respectedly).Our problem has been that no-one has > a collaboration testbed. A collaboration test is all I did in the past (http://wiki.laptop.org/go/Simple_mesh_test_(Cerebro) ) and all I proposed for the future. If you want to do a collaboration test the right way you _must_ measure your stack's overhead against the number of participating nodes, improve your design and implementation and start over. And this should be done not with 2 or 3, but with 10s of laptops. To the best of my knowledge, this has never been done; OLPC is only passively testing (with 10s of laptops but does not contribute to the implementation of telepathy) what Collabora is "guessing" that will work (no real world tests done by Collabora). >> I must admit that it is rather hard for OLPC to act on such results. >> It may be for lack of resources, but I'm speaking for myself when I >> say that OLPC has a hard time trusting developers unless they're on >> its payroll, especially for core parts of its software (with the >> exception of Marco? ;-). I think commitment, communication and >> roadmaps is the answer to this problem. > > Lack of resources and QA testing. > As Martin put it, we can't take Linus' approach of putting stuff > into our build and letting the customer test it.If we put it in > our build, it should have been tested, tested, tested. Wad, no matter how much you test the current collaboration stack, it will just never work like you'd like it to. Why is this so hard to understand? And you've already taken Linus' approach - we've seen reports from Uruguay from teachers failing to initiate collaboration, even in 6 groups of 2 laptops (http://lists.laptop.org/pipermail/devel/2008-May/013921.html). p. ___ Devel mailing list Devel@lists.laptop.org http://lists.laptop.org/listinfo/devel
Re: Peru Upgrade process.
> I don't know when that requirement got lost from the "plan of record". It was lost from the plan when Peru decided to deploy without servers. I believe we convinced them otherwise, but it seems that "reality" hasn't caught up with the plan. -walter ___ Devel mailing list Devel@lists.laptop.org http://lists.laptop.org/listinfo/devel
Re: New, more realistic multi-hop network testbed
Honestly, I'm getting very burned out over the politicking here. Ricardo, Polychronis, and the Nortel guys seem to be the ones doing the real heavy lifting here on the mesh network. When they ask for something, I think we should give it to them. Ricardo and Polychronis agree that a sparse network testbed may be useful -- in addition to, not instead of, a dense collaboration testbed -- why can't we just say, yes, do that then. Wad is right, we still need a collaboration testbed, but as Poly points out this is currently Collabora's area of responsibility. --scott -- ( http://cscott.net/ ) ___ Devel mailing list Devel@lists.laptop.org http://lists.laptop.org/listinfo/devel
Re: Peru Upgrade process.
On Sat, Jun 7, 2008 at 10:44 AM, John Watlington <[EMAIL PROTECTED]> wrote: > Look, the reality on the ground is that Peru has at least 15K laptops in > the field running 651/653/656 that need upgrading.They will not have > school servers deployed for another three months. I understand this. > If upgrade > (not reflash) requires more than inserting a key, I don't believe this. or it wipes the > activation lease/the kids work I believe this. > this won't happen. OK, even granting this, why is this necessarily a bad thing? This work has to be prioritized. If the laptops in the field don't get updated until (say) 1Q 2009, is that necessarily a bad thing? Should I be working on this rather than, say, making Uruguay's upgrades and security work? It seems reasonable to expect that machines in the field will not be updated until the teachers come in from the field for training. The teachers will be taught about the new release (UI changes, new activities, etc), and given instructions and a USB key for updating the machines in the school. They can schedule the update for a holiday when they've got time to follow the instructions to update the machines. "Open up a terminal and type this" isn't nearly as impossible as you are making it sound. Peru actually has a process in place for this training. Yes, we can imagine better, but I'm not convinced the current process isn't Good Enough. --scott -- ( http://cscott.net/ ) ___ Devel mailing list Devel@lists.laptop.org http://lists.laptop.org/listinfo/devel
Re: Peru Upgrade process.
On Jun 7, 2008, at 12:13 PM, C. Scott Ananian wrote: > On Sat, Jun 7, 2008 at 10:44 AM, John Watlington <[EMAIL PROTECTED]> > wrote: >> Look, the reality on the ground is that Peru has at least 15K >> laptops in >> the field running 651/653/656 that need upgrading.They will >> not have >> school servers deployed for another three months. > > I understand this. > >> If upgrade >> (not reflash) requires more than inserting a key, > > I don't believe this. Yes, this is the debatable part. In speaking with Carla today, she said that they've had many problems getting teachers to follow simple directions like these.And the upgrade we are discussing (from 65x to 703) requires multiple keys as well as typing. > or it wipes the >> activation lease/the kids work > > I believe this. > >> this won't happen. > > OK, even granting this, why is this necessarily a bad thing? This > work has to be prioritized. If the laptops in the field don't get > updated until (say) 1Q 2009, is that necessarily a bad thing? Should > I be working on this rather than, say, making Uruguay's upgrades and > security work? I understand that prioritization must happen. But if I don't even get it on the list of "desired features", as you seem to be arguing against, it will never happen. > It seems reasonable to expect that machines in the field will not be > updated until the teachers come in from the field for training. The > teachers will be taught about the new release (UI changes, new > activities, etc), and given instructions and a USB key for updating > the machines in the school. They can schedule the update for a > holiday when they've got time to follow the instructions to update the > machines. "Open up a terminal and type this" isn't nearly as > impossible as you are making it sound. Peru actually has a process in > place for this training. I'm aware of their training process. That is part of my concern. > Yes, we can imagine better, but I'm not > convinced the current process isn't Good Enough. Go Celtics, wad ___ Devel mailing list Devel@lists.laptop.org http://lists.laptop.org/listinfo/devel
Re: Peru Upgrade process.
-BEGIN PGP SIGNED MESSAGE- Hash: SHA1 I don't really know enough to comment correctly on this debate, but it sure seems like the much-maligned USB autoreinstallation system meets all the requirements. It is non-interactive, beyond requiring a reboot, and it preserves the user's data by copying off the contents of /home/olpc, performing the upgrade, and then copying back the contents of /home/olpc. - --Ben -BEGIN PGP SIGNATURE- Version: GnuPG v2.0.9 (GNU/Linux) Comment: Using GnuPG with Mozilla - http://enigmail.mozdev.org iEYEARECAAYFAkhKvfYACgkQUJT6e6HFtqTRBACeKC/o0dFpHdftssCGOCtuFqkv tysAn2co4L7JSuB4wab9qjN6v2dH3F+K =eEjk -END PGP SIGNATURE- ___ Devel mailing list Devel@lists.laptop.org http://lists.laptop.org/listinfo/devel
Re: New, more realistic multi-hop network testbed
Some thoughts from a QA perspective: I consider the 100 laptops that I budgeted, ordered and help install in Peabody to be the QA "collaboration testbed", which is expected to be used to recreate problems from the field and test out next release solutions. Since we had to dismantle Peabody, most of these laptops (about 70 of them) have been loaned to Poly in 1CC. Now that we have both a QA Lead and an intern, I expect we will need to refocus 20-30 laptops back to the QA testbed full time and we have signed a lease on the new test facility, which will be ready for the full 100 laptop test bed (or perhaps 200 laptops) by mid-July. Secondly, we also need to be working on the longer term solutions, such as those being investigated by Poly, Nortel, Michail, and Ricardo. If this also requires a 100 laptop test bed then we need to build one. We need to order these laptops and start making permanent homes for them. If the first step is to order 10 laptops, I will order them. Poly - What I can't tell from your progress reports is exactly what is needed for us to get to the next level. On the surface it sounds like you had to rebuild chat to make it work with cerebro. If so, does that mean all activities would have to be modified to a new API? What else is needed? How does the cerebro solution fit into the rest of the stack and the other technologies we are working on for 8.2.0 (August) and future releases? If the cerebro solution is still in research and there are a lot of issues that still need to be worked out before we can release it, then we need someone to help track all the issues and help resolve them through the stack in order to get something to release stage. Let's work with Michail on this as he probably needs to take the lead. As a first step, I will order 10 laptops for Poly to find permanent homes for throughout the MIT campus. Kim On Sat, Jun 7, 2008 at 12:02 PM, C. Scott Ananian <[EMAIL PROTECTED]> wrote: > Honestly, I'm getting very burned out over the politicking here. > Ricardo, Polychronis, and the Nortel guys seem to be the ones doing > the real heavy lifting here on the mesh network. When they ask for > something, I think we should give it to them. Ricardo and Polychronis > agree that a sparse network testbed may be useful -- in addition to, > not instead of, a dense collaboration testbed -- why can't we just > say, yes, do that then. > > Wad is right, we still need a collaboration testbed, but as Poly > points out this is currently Collabora's area of responsibility. > --scott > > -- > ( http://cscott.net/ ) > ___ > Devel mailing list > Devel@lists.laptop.org > http://lists.laptop.org/listinfo/devel > ___ Devel mailing list Devel@lists.laptop.org http://lists.laptop.org/listinfo/devel
Re: New, more realistic multi-hop network testbed
would it make sense to at least enter that request into the projectdb since that is what it was made for? (apart from the feature requests which will be taken care of at some time, it does hold the data and hence it can help in tracking the XOs) On a different note: in larger mesh networks (athens wireless comes to mind) you do encounter strange effects when you go to a couple of hundred of nodes. So I would not underestimate the need for a massive test. Massive means maybe 1000 ;-) After all you can reach that number of 1000 kids quite easily. a. On Jun 8, 2008, at 5:55 AM, Kim Quirk wrote: > Some thoughts from a QA perspective: > > I consider the 100 laptops that I budgeted, ordered and help > install in Peabody to be the QA "collaboration testbed", which is > expected to be used to recreate problems from the field and test > out next release solutions. Since we had to dismantle Peabody, most > of these laptops (about 70 of them) have been loaned to Poly in > 1CC. Now that we have both a QA Lead and an intern, I expect we > will need to refocus 20-30 laptops back to the QA testbed full time > and we have signed a lease on the new test facility, which will be > ready for the full 100 laptop test bed (or perhaps 200 laptops) by > mid-July. > > Secondly, we also need to be working on the longer term solutions, > such as those being investigated by Poly, Nortel, Michail, and > Ricardo. If this also requires a 100 laptop test bed then we need > to build one. We need to order these laptops and start making > permanent homes for them. If the first step is to order 10 laptops, > I will order them. > > Poly - What I can't tell from your progress reports is exactly what > is needed for us to get to the next level. On the surface it sounds > like you had to rebuild chat to make it work with cerebro. If so, > does that mean all activities would have to be modified to a new > API? What else is needed? How does the cerebro solution fit into > the rest of the stack and the other technologies we are working on > for 8.2.0 (August) and future releases? > > If the cerebro solution is still in research and there are a lot of > issues that still need to be worked out before we can release it, > then we need someone to help track all the issues and help resolve > them through the stack in order to get something to release stage. > Let's work with Michail on this as he probably needs to take the lead. > > As a first step, I will order 10 laptops for Poly to find permanent > homes for throughout the MIT campus. > > Kim > > > On Sat, Jun 7, 2008 at 12:02 PM, C. Scott Ananian > <[EMAIL PROTECTED]> wrote: > Honestly, I'm getting very burned out over the politicking here. > Ricardo, Polychronis, and the Nortel guys seem to be the ones doing > the real heavy lifting here on the mesh network. When they ask for > something, I think we should give it to them. Ricardo and Polychronis > agree that a sparse network testbed may be useful -- in addition to, > not instead of, a dense collaboration testbed -- why can't we just > say, yes, do that then. > > Wad is right, we still need a collaboration testbed, but as Poly > points out this is currently Collabora's area of responsibility. > --scott > > -- > ( http://cscott.net/ ) > ___ > Devel mailing list > Devel@lists.laptop.org > http://lists.laptop.org/listinfo/devel > > ___ > Devel mailing list > Devel@lists.laptop.org > http://lists.laptop.org/listinfo/devel --- there's no place like 127.0.0.1 ___ Devel mailing list Devel@lists.laptop.org http://lists.laptop.org/listinfo/devel
