On Mon, Jul 14, 2008 at 10:24 AM, Eben Eliason <[EMAIL PROTECTED]> wrote: > 2008/7/14 Kim Quirk <[EMAIL PROTECTED]>: >> I've been thinking about this problem for the last year -- when it first >> became obvious (to me) that: >> >> 1 - we were definitely NOT going to be able to lock down APIs for at least a >> year or two >> 2 - we have no control over the activity developers and the maintainability >> of any given activity (unless we decide to 'own' it) >> 3 - all standard 'best practices' for ensure that 'customers' can keep >> working seamlessly through upgrades have to be dropped for the OLPC project > > Agreed on all of the above. > >> And the only 'real' solutions I have come up with are: >> >> 1 - completely separate the activities from the OS in order to help people >> understand that most activities are NOT supported or maintained by OLPC; >> they need to be able to upgrade activities as needed and not wait for new >> releases from OLPC > > This is one of those steps that makes sense politically, but doesn't > really pan out so well in practice. We really *do* need to have > maintainability of a subset of activities. It's unfortunately that > defining the set we want to 'own' gets people so flustered, but I > still think we may find we need to make some form of commitment in > this regard. > >> 2 - push for 'school year' releases (fall and spring); where a school will >> pick a release and use it for the entire school year so we don't have to >> worry about upgrades in between that time > > Yup. > >> and, most recently you will hear me pushing for: >> >> 3 - Encourage schools to completely reflash (cleaninstall) their laptops >> each year. At the end of the school year, you save away kids data (hopefully >> that is done automatically) and you do a cleaninstall of the next year's >> image; retest all the latest versions of Activities that you want to use; >> and provide 'clean' laptops to the kids at the start of the next school >> year. > > I think this would be a real shame, honestly. It completely tosses out > the benefits of the Journal as a structure for ones interactions and > created objects. It means I can't incorporate photos that I took over > the summer, or last year, into a story I wrote (for instance, even a > "what I did this summer" essay that we've all written at least once). > It means I can't go back and look at some math homework I did to > refresh myself on how a particular algorithm works. It means I can't > create a new etoys project from an experiment I made last year but > didn't have time to continue. It means that I lose references to all > the friends/groups I've made. It means that my computer is reset to > factory state and I have to change my personal preferences all over > again. > > I think we need to find a way to make solid, secure updates without > wiping the machines clean each year; otherwise we're contradicting our > goals for learning, as I see it.
At the very least, end of year sounds like a good time to backup and organize all student data from the year somewhere (XS?). > > - Eben > _______________________________________________ > 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