Re: anyone want XOrduino or XO Stick bare boards
I have a bunch of these as well, and even a few sets of components. Like Paul, I put together another one every so often when I need a microcontroller for a project, but I'm happy to share my stash with other good homes. --scott On Mar 10, 2017 7:13 PM, "Paul Fox" wrote: > paul wrote: > > doing some cleanup today, i found that i have 10 XO Stick and 14 > > XOrduino bare boards that i'm happy to mail to anyone that can make > > use of them -- either all at once, or as few as one to a "customer". > > i should have been more clear, since someone has already asked -- i'm > not charging anything for the boards. these circuit boards are all > surplus that was saved from the goodwill industries and the dumpster > while we were closing down the OLPC offices in somerville several > years ago. > > i'll accumulate requests (if any) for a week or so, then send them out. > > paul > > > > > i've used a couple of the XO Stick boards for my own projects, and i'm > > setting aside a couple more for future use. i also built up an > > XOrduino, to prove it could be done (it wasn't easy -- hand-soldering > > SMT parts is harder than it looks), but i'm not sure i ever even > > booted it. i'm happy to give that board to someone too. > > > > i'm not on any of the deployment lists, or the unleashkids -- feel > > free to forward this message if you think someone not on devel would > > be interested. > > > > for a reminder of what i'm talking about see: > > http://cananian.livejournal.com/66129.html > > http://cananian.livejournal.com/66654.html > > http://cananian.livejournal.com/66895.html > > > > i have notes i made while assembling the XOrduino which i can share. > > not sure i have anything similar for the XO Stick -- i recall it was > > a piece of cake by comparison. > > > > paul > > =- > > paul fox, p...@laptop.org > > > > ___ > > Devel mailing list > > Devel@lists.laptop.org > > http://lists.laptop.org/listinfo/devel > > =- > paul fox, p...@laptop.org > > ___ > 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: Duolingo and literacy
SJ and I did get a chance to follow up with him afterward and suggest that they might considering teaching English literacy directly to non-native speakers (as we did in our Ethiopia pilot, rather than only teaching students in their native language; of course DuoLingo doesn't support a large number of languages, so allowing folks to skip directly to English would greatly increase their reach). They are big on A/B tests and quantification over there, I think we convinced him it was an interesting hypothesis to test. SJ asked how one could help with the literacy effort and he gave us some contract information. If any of the OLPC crew is interested, drop me (or SJ) a line and we'll try to hook you up. I think they might actually be able to make a significant dent in the literacy problem. scott ___ Devel mailing list Devel@lists.laptop.org http://lists.laptop.org/listinfo/devel
Duolingo and literacy
I'm in a presentation by Luis von Ahn, founder of DuoLingo, and I asked him if he had any plans to expand to literacy. He replied that they will be releasing a "reading and typing" (not writing, which he thought had poor ROI) app next year. This makes me extremely excited. --scott PS. I should have followed up re: teaching English literacy directly rather than teaching a native language first. ___ Devel mailing list Devel@lists.laptop.org http://lists.laptop.org/listinfo/devel
Re: Fwd: XO Problems (4 Problems)
Thanks! I forwarded everyone's responses on to Douglas, with pithy descriptions of who you all are and the exciting things you do and countries you live in, to give him a taste of the broader OLPC community. I'll probably install the latest image on his machine in the next few weeks, and I'll let you know if we find any issues (or maybe I'll teach him to report them himself!). Walter, let me know if you ever do any Boston-area SugarLabs activities, he's reached the age where he'd be an enthusiastic participant. (Although not a Python coder yet, he's mastering Scratch first.) --scott On Mon, Nov 25, 2013 at 4:53 PM, James Cameron wrote: > G'day Scott, > > There have been no significant changes to the hardware support since > the 13.2.0 release, although Daniel Drake has contributed some fixes > I've seen in the various git repositories. > > Firmware fixes yet to be included in a release are: > > - a fix for erroneous low-battery power downs that may occur between > the time the runin tests are used and when power cable and battery > are removed for shipping, (released as XO-4 EC 0.4.11), > > - a minor fix for ntp-set-clock, relevant only for deployments who > plan to use NTP in their firmware boot script or USB drives, (not > released, but is in repository), > > - a fix for four game key reflash over HTTP, relevant only for > deployments who plan to use a reinstall image available over > wireless; e.g. short range 802.11n dongles attached to a server, > (not released, but is in repository), > > I've been working on a fix for the #12694 hang of the XO-4 mwifiex > wireless driver that may occur when a laptop experiences heavy demand > for memory at the same time as a large download. I'm not ready for > wider testing yet. > > Gonzalo and Walter are working on a deployment image, in a different > version number namespace, for which they have used the number 13.3.0, > in which most of the change is in Sugar and activities. It is based > on 13.2.0 hardware support. > > One of the Sugar changes might be considered hardware support; > compatibility with WPA Enterprise and hidden SSID access points. > There might be others, I haven't checked. > > There are no hardware changes that I'm aware of in the manufacturing > pipeline, so no new hardware support needed yet. > > On Mon, Nov 25, 2013 at 11:59:59AM -0500, C. Scott Ananian wrote: >> A related question. I'll try to phrase this delicately -- what's the >> relationship between Walter's "Sugar 100" build and the latest OLPC >> kernel? Can I safely assume that SugarLabs is the current keeper of >> the flame and has all the latest hardware-support bits (I hope so!). >> Gonzalo pointed me to a different build. Can someone explain the >> different sources of bits and development to me? >> --scott > > -- > James Cameron > http://quozl.linux.org.au/ -- ( http://cscott.net/ ) ___ Devel mailing list Devel@lists.laptop.org http://lists.laptop.org/listinfo/devel
Re: Fwd: XO Problems (4 Problems)
A related question. I'll try to phrase this delicately -- what's the relationship between Walter's "Sugar 100" build and the latest OLPC kernel? Can I safely assume that SugarLabs is the current keeper of the flame and has all the latest hardware-support bits (I hope so!). Gonzalo pointed me to a different build. Can someone explain the different sources of bits and development to me? --scott ___ Devel mailing list Devel@lists.laptop.org http://lists.laptop.org/listinfo/devel
Fwd: XO Problems (4 Problems)
Anyone have any suggestions for my six year old friend? IIRC startup volume is persistent, but I can't remember how it is adjusted. The rest might be helped by upgrading to the latest XO4 build? --scott -- Forwarded message -- From: "Douglas Rogers" Date: Nov 24, 2013 12:00 PM Subject: XO Problems (4 Problems) To: Cc: hi scott it's Douglas. Can you help me make my xo work? 1) When I turn on the computer,the ''on music'' is too loud.(so loud I have to cover the speakers) 2) In scratch when I switch projects all the sprites from the old project stay there. 3) My XO freezes up a lot 4) If I use the touch screen I can't start using the mouse again ___ Devel mailing list Devel@lists.laptop.org http://lists.laptop.org/listinfo/devel
Popular Science article on OLPC project.
The following mostly-critical article was mentioned on IRC: http://www.popsci.com/gadgets/article/2013-07/one-laptop-childs-de-evolution It's worth keeping the criticisms in mind while working to invalidate them. --scott -- ( http://cscott.net ) ___ Devel mailing list Devel@lists.laptop.org http://lists.laptop.org/listinfo/devel
Sugar Collaboration with a Tow Truck
I mentioned this project a while ago on IRC, and cjb has spread it around, but manuq reminded me that I never actually posted it to a mailing list. The mozilla Tow Truck project: https://towtruck.mozillalabs.com/ is a very nice framework for real-time collaboration in the context of web apps. It has a plugin architecture, so you can add your own editor components for (say) building a turtleart program together. It also does a lot of the hard plumbing, like friend-discovery, and necessities, like real-time chat on top of the collaboration. This would be a great foundation for "web app Sugar" collaboration. With the native plugin approach I've previously advocated, you could build native Sugar plugins so that TowTruck collaboration could interoperate with native Sugar collaboration as well (ie, share friends lists, say). It's a project worth exploring, and potentially a set of wheels worth not reinventing. --scott -- ( http://cscott.net ) ___ Devel mailing list Devel@lists.laptop.org http://lists.laptop.org/listinfo/devel
Issues from my 6-yr-old beta tester.
The build I installed on my beta-tester's XO4 is about a month old. I'm hoping the following are known issues, and all I have to do is update the build. (Can I use olpc-update to do that?) * The sound in Scratch and Memorize is scrambled; sound appears to be piped from /dev/random and "hurts my ears". * Tam Tam Edit had different sound issues -- the playback cursor wandered all over the screen when play was pressed, sometimes moving backwards. The sound wasn't scrambled, but I'm not convinced that the sequencing was correct (I forget exactly what the demo is supposed to sound like, but it didn't sound "right" to me.) * When you capture a new costume in Scratch using the camera, everything appears to have a strong yellow cast. He's also missing the top-right keycap from his crunchy keyboard. He was very vague about how exactly that happened... --scott -- ( http://cscott.net ) ___ Devel mailing list Devel@lists.laptop.org http://lists.laptop.org/listinfo/devel
Re: Shipping bigger fonts by default for greater glyph coverage
IIRC its only the CJK fonts which really bloat the build. There's an old bug in trac which discussed fonts at length; it might be worth digging that up to ensure we're still covering all the languages we were covering then. --scott On Sep 5, 2012 6:58 PM, "Chris Leonard" wrote: > On Wed, Sep 5, 2012 at 6:58 PM, Mikus Grinbergs wrote: > > Something to watch out for is the content of /usr/lib/locale. > > > > Having been caught several time in the past with "C" as the only language > > recognized, I now pay attention to the content of that directory. [For > > instance, allowing a Fedora "upgrade" of the package 'glibc-common' could > > add an extra 80 MB into that directory. > > > > mikus > > That is an interesting and important point. I wonder if the langpack > install could be adjusted to bring it's locale with it, if needed? > > cjl > ___ > 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: Impossible to set date in 11.3.0?
It seems like all that is necessary is to add a test for a secured laptop to allow this patch to go upstream, right? (This approach looks very similar to what I did in OLPC build 603 or so.) --scott On Aug 25, 2012 7:08 PM, "Jerry Vonau" wrote: > On Sat, 2012-08-25 at 18:25 -0400, Walter Bender wrote: > > File a ticket and someone may jump in to tackle it. > > > > -walter > > > > see http://dev.laptop.org/ticket/11004 > > > > On Sat, Aug 25, 2012 at 3:24 PM, Martin Langhoff > > wrote: > > > On Sat, Aug 25, 2012 at 2:26 PM, C. Scott Ananian > wrote: > > >> Surely we can distinguish secured from unsecured laptops and allow > > >> unsecured laptops to set the date? > > > > > > Sure. Nobody's done the UI work for that, Sugar-side. > > > > > > - In all builds, hwclock is available from cli > > > - On 11.3.x and earler builds you can install the appropriate gnome > > > control panel. > > > - On 12.x.y builds, gnome control panels aren't so easy to make work, > > > 'cause they need clutter. > > > > > > Also, we should run ntp by default, or at least ntpdate on an NM hook. > > We do that in Australia builds, need nptdate to be added to the image, > setup /etc/sysconfig/ntpdate and the NM hook. > > # toggle setting the rtc > sed -i -e "s/SYNC_HWCLOCK=no/SYNC_HWCLOCK=yes/" /etc/sysconfig/ntpdate > > # call ntpdate when connected > cat << EOF > /etc/NetworkManager/dispatcher.d/10-ntpdate > #!/bin/sh > > if [ "\$2" = "up" ]; then > if [ ! -e /tmp/ntpdate ]; then > touch /tmp/ntpdate > /sbin/service ntpdate restart || : > fi > fi > EOF > chmod 755 /etc/NetworkManager/dispatcher.d/10-ntpdate > > Jerry > > > ___ > 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: Setting the time
On Mon, Aug 27, 2012 at 10:05 AM, Samuel Greenfeld wrote: > In any case if OLPC or Sugarlabs wants to formally integrate NTP services > into our products, we should be polite and ask ntp.pool.org if we need our > own vendor subdomain. These allow the NTP pool to shut off misbehaving > clients without affecting other users, and Fedora and CentOS already have > their own. We already did this (the first time I fixed this bug, years ago). I believe we have olpc.ntp.pool.org, although I'll have to dig up the email from my archive to double-check. We also got permission to use fedora's pool at the same time, because it was more suitable for the upstreamed version of the patch. --scott -- ( http://cscott.net ) ___ Devel mailing list Devel@lists.laptop.org http://lists.laptop.org/listinfo/devel
Re: Impossible to set date in 11.3.0?
Surely we can distinguish secured from unsecured laptops and allow unsecured laptops to set the date? I know I implemented this once... --scott -- ( http://cscott.net ) ___ Devel mailing list Devel@lists.laptop.org http://lists.laptop.org/listinfo/devel
Impossible to set date in 11.3.0?
A friend has 11.3.0 installed on his son's XO 1.5. The kid complained that the date was wrong on his XO, and he couldn't figure out how to set it. Indeed, the "Time and Date" control panel only has time zone selection, and no sort of network time program seems to be included in the build. Was this an intentional omission? How is the date supposed to be set in 11.3? --scott -- ( http://cscott.net ) ___ Devel mailing list Devel@lists.laptop.org http://lists.laptop.org/listinfo/devel
XO Sticks and XOrduino
I have about 20 XO Sticks and XOrduinos to give away to developers. Details at: http://cananian.livejournal.com/66654.html --scott -- ( http://cscott.net ) ___ Devel mailing list Devel@lists.laptop.org http://lists.laptop.org/listinfo/devel
Re: XO-1.75 OpenFirmware serial terminal
On Wed, Mar 28, 2012 at 10:44 PM, John Watlington wrote: > I'd love to see serial terminal preloaded, but also acknowledge that I'm the > one pushing against a 2MB SPI Flash ROM. How about specifying > a location in the main build, where another 20KB of example OFW code > isn't as important ? Say: > > devalias lib int:2 # build a pointer to the library into OFW > > dir lib:\ofwlib\ # See what is available (anyway to avoid the > dir name ?) > fload lib:\ofwlib\serial.fth > serial > > We could also move some of the existing non-essential OFW utilities there as > SPI Flash ROM space gets tighter, such as emacs. Incidentally, we could also add VFAT long filename support to such an auxilliary location, so that it's not part of distributed OFW and keeps Mitch far from culpability. --scott -- ( http://cscott.net ) ___ Devel mailing list Devel@lists.laptop.org http://lists.laptop.org/listinfo/devel
Re: Engadget post on XO Touch
Presumably with the standard multi-touch X support, which is landing in Linux all over. That's how the XO-3 worked, at least, although that was traditional capacitive touch; I don't think there's an actual Neonode driver in existence anywhere yet. --scott On Tue, Jul 31, 2012 at 8:54 PM, Bert Freudenberg wrote: > > On 26.07.2012, at 20:21, Mike Lee wrote: > >> Here's a cool demo of the Neonode multitouch frame: >> >> http://www.slashgear.com/neonode-3d-touch-headed-to-tablets-and-phones-hands-on-28215933/ >> >> Not only multi-touch, but also entry direction and tilt. For a dollar! > > Well, for tilt you would need to stack multiple frames on top of each other > as they did in that prototype. For a touch-screen you would want it to be as > thin as possible, that would mean single-layer. The Kindle Touch and Nook use > Neonode zForce touch sensors, too. Here's a nice animation showing the > principle: > > http://www.neonode.com/solutions/zforce > > Does anyone know how the multi-touch stuff is going to be exposed in Linux? > > - Bert - > > >> >> Seems like this would be great as a retrofit kit. >> >> Mike >> >> On Thu, Jul 26, 2012 at 11:09 PM, Sameer Verma wrote: >> www.engadget.com/2012/07/26/olpc-xo-touch-1-75-to-use-neonode-tech/ >> >> The post says "as yet unreleased XO 1.75". What's the official status >> on the 1.75? Still as yet unreleased? >> >> cheers, >> Sameer > > > ___ > Devel mailing list > Devel@lists.laptop.org > http://lists.laptop.org/listinfo/devel -- ( http://cscott.net ) ___ Devel mailing list Devel@lists.laptop.org http://lists.laptop.org/listinfo/devel
Re: Developer XO laptop loan or buy - Speakeasy project
On Wed, Jun 13, 2012 at 6:17 PM, Martin Langhoff wrote: > On Wed, Jun 13, 2012 at 11:37 AM, Lester Leong > wrote: > > Scott - could you point me in the right direction as far as a good > > JS/HTML5 framework? > > Keep in mind that _today_ XOs don't ship with a workable JS runtime > environment other than the webbrowser. > ...which is a perfectly fine runtime environment. And writing a python wrapper that functions like PhoneGap is perfectly straightforward; the wikipedia and other apps on the XO already do it. As for JS/HTML5 frameworks, there are a bazillion of them. Some popular bits: http://twitter.github.com/bootstrap/ http://enyojs.com/ http://knockoutjs.com/ http://brian.io/lawnchair/ http://sproutcore.com/ (although this is geared for client/server) Lots more random stuff linked from: http://wiki.laptop.org/go/Nell/InterestingJavascriptLibraries http://dailyjs.com --scott -- ( http://cscott.net ) ___ Devel mailing list Devel@lists.laptop.org http://lists.laptop.org/listinfo/devel
Re: Developer XO laptop loan or buy - Speakeasy project
On Tue, Jun 12, 2012 at 9:15 PM, Lester Leong wrote: > As for Javascript, how? Javascript can't handle backends without some > significant running around - everything's gotta be database driven. > I think you need to look again at modern Javascript/HTML5 toolkits. There are databases. There are routers. You don't need anything else. --scott -- ( http://cscott.net ) ___ Devel mailing list Devel@lists.laptop.org http://lists.laptop.org/listinfo/devel
Re: Developer XO laptop loan or buy - Speakeasy project
..and if you can replace the php with javascript, your life will be even easier. ;) --scott On 6/12/12, Gonzalo Odiard wrote: >> >> >> Another thing is, with regards to webapp implementation - I have >> thought of using PHP/HTML5/Javascript. >> > > > If you can replace PHP by python, your live will be a lot easier including > your work as a activity in sugar. > > Gonzalo > -- ( http://cscott.net ) ___ Devel mailing list Devel@lists.laptop.org http://lists.laptop.org/listinfo/devel
Re: Developer XO laptop loan or buy - Speakeasy project
On Tue, Jun 12, 2012 at 4:16 AM, Chris Ball wrote: > Hi Lester, > > On Mon, Jun 11 2012, Lester Leong wrote: > > I think it could just be as easy as having a collection of multimedia > > and gamifying it. I thought of having a set of flashcards with audio - > > then many things could be done with that. Audio to picture matching. > > Finish the sentence. Multiplayer races. Pictures in a series to denote > > context, etc. It could just be that simple. Would be really trivial to > > implement as well. I even thought of implementing it as web served > > pages so that the whole thing could exist in website form - in remote > > locations without Internet, maybe the pages can be locally > > stored/hosted. > > I like this idea, and I'm happy to see that you aren't trying to do too > much. I think develping this as a set of webapps sounds like a fine > start -- it allows you to work on it more easily with other developers, > who don't share your platform, too. > > > Anyway, the reason I would like an XO is because I'd like to get a > > feel for user interface, as well as the limitations of it, from the > > very beginning. It would help guide design immensely. > > Did you know that it's easy to run OLPC's user interface, Sugar, on > non-OLPC laptops? Here's a recent guide written by Simon Schampijer: > > http://wiki.sugarlabs.org/go/Activity_Team/Activity_Development_Fedora17 > > There isn't much (if anything) of the user interface that's dependent on > the hardware; you can see it all by running Sugar locally too. > Also, for what it's worth: our current literacy deployments in Ethiopia are using the Motorola Xoom Android tablets. I've found that writing apps using HTML5 toolkits is a great way to make them portable across XOs and Android tablets and educators sitting at their desktops who are in a position to offer advice. As two examples, you might look at: http://cscott.github.com/nell-balloons/ which is the core of a simple matching game for assessment. At some point you have to be able to determine if the kids are actually learning anything, and their speed/accuracy in matching words with sounds/pictures is a reasonable way to measure this, with good support in the educational literature. At a different point in the continuum: http://cscott.github.com/nell-colors/ is a simple drawing program that helps kids learn handwriting by recognizing when they draw letters (lowercase only for now, this is a work-in-progress). My experience is that it takes a long time to actually polish an app to the point where kids will enjoy using it *and* you've tuned all the 'gamification' aspects such that the kid is motivated to do what you want to do (instead of, say, deliberately choosing wrong answers because the fart sound it makes it more fun). --scott -- ( http://cscott.net ) ___ Devel mailing list Devel@lists.laptop.org http://lists.laptop.org/listinfo/devel
Short paper on Nell (XO-3)
Chris Ball, Michael Stone, and I submitted a short paper about Nell's design for the 2012 Interaction Design and Children conference. It contains a much more coherent description of our ideas and goals than the random fragments at http://wiki.laptop.org/go/Nell. The paper is posted at http://cscott.net/Publications/OLPC/idc2012.pdf Comments and feedback welcome! Assuming the paper is accepted, we will still have to revise for publication, so also let us know if you found any of our arguments confusing, wrong, or simply disagree, so we can do a better job for the final paper. --scott -- ( http://cscott.net ) ___ Devel mailing list Devel@lists.laptop.org http://lists.laptop.org/listinfo/devel
Re: [Sugar-devel] automatic backlight control
Just to reinforce a few points which maybe might not be clear to people who haven't played with the new hardware: 1) the switch point is set that *you cannot tell when we turn the backlight off*. Ie, the threshold is so high that by the time we turn it off, you couldn't never have told whether the backlight was on or not. This is very different from the "auto dim" feature in Macs, for example. (And it's the primary reason why the switch to monochrome was so visible -- you couldn't tell that we were turning the backlight on and off, you could only tell that the images on the display were shifting greyscale values intermittently for no obvious reason.) 2) this is a very important power-saving feature for young kids, who generally aren't savvy enough to manually do all these measures which prolong battery life. So, even if "power tweakers" might want a little more control, it's important to make the default behavior as power-friendly as possible (especially as we move further into deployments where access to power is a big big deal). We should keep in mind the trade-offs here. --scott -- ( http://cscott.net ) ___ Devel mailing list Devel@lists.laptop.org http://lists.laptop.org/listinfo/devel
Re: 11.3.1 build 10 released for XO-1.75
On Wed, Nov 9, 2011 at 3:43 PM, Martin Langhoff wrote: > The "suspense resume" build, featuring suspend resume that may or may > not resume. IIRC, some of the resume crashes are in fact suspend crashes. So it may not even suspend. More suspense! --scott -- ( http://cscott.net ) ___ Devel mailing list Devel@lists.laptop.org http://lists.laptop.org/listinfo/devel
Re: XO-1.75 relative performance
And note that Jon's original advice was based on the absence of *EGL* support in clutter at the present time. The fact that you can run/not run gnome-shell on desktops with full *GL* support is not relevant. This thread has diverged. GTK3 is not gnome3 is not gnome-shell; EGL is not GL; Sugar is not Gnome. --scott -- ( http://cscott.net ) ___ Devel mailing list Devel@lists.laptop.org http://lists.laptop.org/listinfo/devel
Re: XO-1.75 relative performance
On Wed, Nov 2, 2011 at 12:49 AM, wrote: > For what its worth, the XO-1.75 is currently about half the speed of the XO1.5 > > Measured with Turtle Art > > repeat 5000 > fwd 100 > back 100 > print time > > but as said, its early days for the 1.75 with optimization to come Yeah, this is almost certainly due to the terrible graphics driver performance which jon nettleton is working to fix. A pure-CPU benchmark (maybe something in Pippy?) would be a little more reliable. But anything involving floating point will suck, because we're not using the hardware floating point support yet. So much software to tune... --scott -- ( http://cscott.net ) ___ Devel mailing list Devel@lists.laptop.org http://lists.laptop.org/listinfo/devel
Re: [OLPC-AU] XO-1.75 relative performance
Graphics drivers aren't fully optimized yet for XO-1.75, and we're not using hardware floating point at all in our builds yet, so measurements using present builds may greatly undersell the XO-1.75's capabilities.We're working on it! The ARM chipset is very similar to that used in http://www.vizio.com/vtab1008.html ; if you can find online benchmarks for that, it might give you a rough idea of XO-1.75 performance. (But the online benchmarks will probably be Android-based, and won't tell you anything about battery life and power consumption, where OLPC has put its focus and made great improvements.) --scott -- ( http://cscott.net ) ___ Devel mailing list Devel@lists.laptop.org http://lists.laptop.org/listinfo/devel
"Narrative Interfaces" at OLPC
I just posted an announcement for some invited talks we're having at OLPC's new offices this Friday: http://cananian.livejournal.com/64747.html It will all be live-streamed at: http://www.ustream.tv/channel/cscottnet --scott -- ( http://cscott.net ) ___ Devel mailing list Devel@lists.laptop.org http://lists.laptop.org/listinfo/devel
Re: [IAEP] Turtles All The Way Out
On Mon, Jun 6, 2011 at 8:11 PM, John Gilmore wrote: > Don Hopkins worked on a PostScript-based window system (HyperLook) > that would let you "flip over" an object on the screen to see "behind > it" a control panel with the guts of its implementation visible. You > could modify those, then "flip it back" and it would resume running. > See: http://www.art.net/~hopkins/Don/hyperlook/index.html and > http://www.art.net/~hopkins/Don/simcity/hyperlook-demo.html . "Self: The Movie" is also worth watching. The self guys thought that continuous execution of the code was important for liveness, along with some other views (like direct correspondence between objects and representation) which I don't think I actually agree with. But still, worth thinking about: http://www.smalltalk.org.br/movies/ --scott -- ( http://cscott.net ) ___ Devel mailing list Devel@lists.laptop.org http://lists.laptop.org/listinfo/devel
Re: [IAEP] Turtles All The Way Down
On Fri, May 20, 2011 at 11:09 AM, Alan Kay wrote:
> Smalltalk actually got started by thinking about a way to make a child's
> Logo-like language with objects and pattern matching that could express its
> own operating system and environment.
>
> It is very tricky to retain/maintain readability (so the first Smalltalk was
> also an extensible language not just semantically but syntactically).
>
> With a tile language, this is really worth thinking about, since using tiles
> suggests ways to extend both the form and the meaning of the tiles.
I've written a follow-up post, musing on the "readability" aspect Alan
mentioned above:
http://cananian.livejournal.com/64330.html
Is it worth trading a very simple and direct syntax like:
var Point = {};
Point.x = 0;
Point.y = 0;
var Point3D = Object.create(Point);
Point3D.z = 0;
for the more readable:
Class("Point", {
has: {
x: {is: "ro"},
y: {is: "rw"},
},
})
Class("Point.ThreeD", {
isa: Point,
has: {
z: {}
},
})
at the cost of introducing additional complexity into the object
creation process. The complexity is in a library, so the base
language is kept small -- but it's still more turtles thrown onto the
stack that you have to understand.
Returning to Alan's point about tiles -- the nice thing is that you
could define a custom tile for the Class() syntax above, with
pretty selectors to help you select parent class, slot attributes,
etc. But perhaps it's better just to keep the conceptual model small
-- then you don't need fancy GUI widgets to help you out.
For a more concrete example, you might want to read through:
https://github.com/cscott/TurtleScript/blob/beeba5c138d88af40297f93689ecbe7721724819/crender.js#L333
starting at line 333 or so. That's a widget library written in
Simplified JavaScript/TurtleScript which uses prototype inheritance
extensively. You can do clever things like swipe the implementation
of a function from a totally different class; see how we do "multiple
inheritance" around line 661. Is the Joose syntax an improvement?
--scott
--
( http://cscott.net )
___
Devel mailing list
Devel@lists.laptop.org
http://lists.laptop.org/listinfo/devel
Re: Raspberry Pi $25 computer
To sweeten the pot, I'm offering a delicious stone soup for anyone who those who pitch in on the port. You need only supply a few extra ingredients. --scott On May 21, 2011 10:35 PM, wrote: > FYI. Anybody who would like to port Sugar to a $25 computer (requiring > only monitor, mouse, and keyboard) should contact Eben, and let us > know too. > > -- Forwarded message -- > From: Edward Cherlin > Date: Sat, May 21, 2011 at 22:10 > Subject: Re: [Sur] linux system por $25 > To: Eben Upton > > On Sat, May 21, 2011 at 12:22, Eben Upton wrote: >> Hi Edward >> Thanks for your mail, and apologies for the delay in replying. The >> devices should be available to the general public later in the year; >> I'll add you to our mailing list, and will keep you posted as we get >> closer to launch. > > Thank you. > >> We've heard of Sugar, but need to find out more about it. Do you think >> it's suitable for a machine with limited processing power and only >> 256MB of RAM? > > That's what it was designed for. > > http://wiki.laptop.org/go/Hardware_specifications > AMD Geode 433 Mhz processor > 256M RAM > Fedora Linux > > http://wiki.sugarlabs.org/go/Getting_Started > http://wiki.sugarlabs.org/go/Activities > >> Cheers >> Eben Upton >> Director, Raspberry Pi Foundation >> >> Follow us @Raspberry_Pi on Twitter >> >> >> On Fri, May 6, 2011 at 5:07 PM, Edward Cherlin wrote: >>> Your Web site asks >>> Do you have open-source educational software we can use? >>> >>> The answer is Yes. Sugar education software runs on a variety of Linux >>> distributions, including Ubuntu. It is currently in the hands of more >>> than 2 million children. >>> We plan to develop, manufacture and distribute an ultra-low-cost > computer, for use in teaching computer programming to children. >>> >>> Sugar includes Python and Smalltalk (Etoys). One Laptop Per Child XO >>> computers also run Open Firmware, written in FORTH, and including the >>> complete FORTH development library, the editor, and an assembler. OFW >>> is available for systems based on ARM processors. >>> >>> The Sugar Labs Replacing Textbooks project, which I started recently, >>> will include a variety of materials for teaching programming and >>> Computer Science, and for applying those languages to every school >>> subject. We have compiled a list of successful projects for teaching >>> programming in the elementary grades, including projects using Python, >>> Smalltalk, Logo, LISP, BASIC, and APL. >>> >>> The real question is one that Seymour Papert asked in 1970: Can we >>> design an environment in which children learn math and programming >>> languages as readily as they learn human languages, largely from each >>> other? Some of us think so, and we are working on it. >>> >>> I will be happy to answer further questions, or to direct you to those >>> who know more about some aspects of Sugar than I. >>> >>> -- Forwarded message -- >>> From: Sean DALY >>> Date: Fri, May 6, 2011 at 11:28 >>> Subject: Re: [Sur] linux system por $25 >>> To: "OLPC para usuarios, docentes, voluntarios y administradores" >>> >>> Cc: Gleducar >>> >>> >>> http://lists.sugarlabs.org/archive/marketing/2011-May/003273.html >>> >>> >>> On Fri, May 6, 2011 at 5:23 PM, Daniel Ajoy wrote: linux system por $25 http://www.raspberrypi.org/ > > -- > Edward Mokurai > (默雷/धर्ममेघशब्दगर्ज/دھرممیگھشبدگر > ج) Cherlin > Silent Thunder is my name, and Children are my nation. > The Cosmos is my dwelling place, the Truth my destination. > http://wiki.sugarlabs.org/go/Replacing_Textbooks > > ___ > 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: [IAEP] Turtles All The Way Down
I'm familiar with the processors designed for specific high-level languages. There was another generation of them built for Java (microblaze, picoblaze, etc) and some of those are even still commercially significant (they run Java subsets on smart cards). I'm not terribly interested in those processors. More in tune with the "turles all the way down" agenda is the work done on compiling high level languages to hardware. It's not that the hardware chipset runs turtlescript (that's not really giving you any additional insight into the operation of the hardware), but that the hardware is *described* in turtlescript. I've made some modest contributions to this in the distant past (http://flex.cscott.net/SiliconC/paper.pdf). That said, there is *zero* chance that this work will result in hardware suitable for the kids we care about. So let's stop talking about it. > I once used a tile-based UI in a commercial database program. It was > horrible once we got past the toy examples. [...] > Of course. I would say that perhaps 40 or 50 blocks is a reasonable limit. > After that, you should be writing subroutines to go in Python blocks, and > not very long after transition to pure Python. Let's find out. I've written almost 4,000 lines of code in my "tile based language" so far. So far I've been typing it. I hope to leave the keyboard behind soon. And then we'll see whether I agree with you or not. --scott -- ( http://cscott.net ) ___ Devel mailing list Devel@lists.laptop.org http://lists.laptop.org/listinfo/devel
Re: [IAEP] Turtles All The Way Out
On Fri, May 20, 2011 at 2:28 PM, John Gilmore wrote: > separation. This is why they never learn to modify the real programs > that hide behind the fluffy interfaces on their real XO computers. I hope to show you a system where the real program *is* the fluffy interface (and vice versa). I'm not at that point yet, but you've correctly extracted the point of this particular research program. --scott -- ( http://cscott.net ) ___ Devel mailing list Devel@lists.laptop.org http://lists.laptop.org/listinfo/devel
Re: [IAEP] Turtles All The Way Down
On Fri, May 20, 2011 at 11:09 AM, Alan Kay wrote:
> This is nice!
>
> Smalltalk actually got started by thinking about a way to make a child's
> Logo-like language with objects and pattern matching that could express its
> own operating system and environment.
>
> It is very tricky to retain/maintain readability (so the first Smalltalk was
> also an extensible language not just semantically but syntactically).
>
> With a tile language, this is really worth thinking about, since using tiles
> suggests ways to extend both the form and the meaning of the tiles.
My current thinking is that macros are *graphical*, not *source*
transformations. You can create
your own tiles for the language which render into hygenic macros.
They are represented in source as simple message dispatch. For
example, choosing a particularly ugly bit of JavaScript syntax:
var ForBlockMacro = imports.macros.ForBlockMacro;
var foo = function() {
var i;
ForBlockMacro(function() { i=0; },
function() { return i < 5; },
function() { i+=1; },
function() { /* body */ });
}
This is the "underlying" syntax for the macro. But the ForBlockMacro
function (which is a first class object in JavaScript) can have an
asTile() method which returns a more attractive visual representation
in the tile editor; in fact, the representation could elide all the
'function' and 'return' nastiness of the raw syntax and display
(traditionally) as:
for ( i=0 ; i < 5 ; i+=1 ) {
/* body */
}
My current plan is to finess the "multiple views" issue (discussed in
3.4 of http://labs.oracle.com/self/papers/programming-as-experience.html)
by representing objects as 3d polyhedra. The "front" view might be
the nice cleaned up tile macro, but you should be able to "rotate" the
tile to see the low level source, and then rotate it again to see the
object corresponding to the actual widget displaying the source, etc.
So, "one object, many views".
I've built the current system on a very flexible operator precedence
grammar, so there's no reason I *couldn't* allow the user to flexibly
extend the base grammar. But that increases the conceptual effort
necessary to understand the system -- I have to understand the
expanded language before I can understand the code I'm looking at.
The macro system I describe above has the nice property that you don't
*have* to understand the macro or the grammar of the new if statement.
It's enough to look at the desugared version:
ForBlockMacro(function() { i=0; },
function() { return i < 5; },
function() { i+=1; },
function() { /* body */ });
and the implementation of ForBlockMacro:
ForBlockMacro = function(initBlock, condBlock, incrBlock, bodyBlock) {
initBlock();
while (condBlock()) {
bodyBlock();
incrBlock();
}
};
ForBlockMacro.asTile() = ;
This seems (to me) a preferable way of understanding what the new tile
does. But I'm open to other ideas on this front. (And yes,
JavaScript's syntax isn't lovely. But I'm interested in what I can do
with what I've got.)
--scott
--
( http://cscott.net )
___
Devel mailing list
Devel@lists.laptop.org
http://lists.laptop.org/listinfo/devel
Re: Turtles All The Way Down
2011/5/20 NoiseEHC : > 1. Why do the bytecode stuff? JS seems to be a perfectly good code > representation to me and it can be run much faster compared to a naive > bytecode interpreter or compiler written without the resources of the > Chrome/V8 team. It's true. As described in my blog post, the VM work was an experiment to see "how far down the turtles could go". As the Klein VM and other examples have shown -- pretty far down! Even if you end up running the language in the fast V8 VM, you might want to have a version with somewhat lower performance which is 99.9% "view source"-able. But I really should be concentrating on the higher-level stuff at the moment. > 2. Why do you want to serialize the stuff? Is not it enough to serialize > just the JS code + screenshot and on load run it? It relates to the desire to be able to do prototype-style development, where you modify existing objects to create new functionality. (Think etoys.) Once you've got a bunch of user-modified objects floating around, you have to start thinking about how to save/load them. > 3. Why is the pervasive undo necessary? Only for debugging? That relates to the goals of Sugar, leaking through into TurtleScript. It's actually pretty easy to screw up your VM pretty badly if you can actually access it down all the way to the bottommost turtle. Once you've done this, it would be nice to be able to recover gracefully -- or at least, more gracefully than "toss the saved image and restart". Supporting cheap snapshots of the system image is one way to do this. > BTW cool project, that is exactly what I wanted to do, now I do not have > to... :) Oh no! That's the opposite of my intended goal in talking about this stuff -- at some point I badly need other people to adopt the ideas and carry on with the implementation, as I'm unfortunately still a single-core human. --scott -- ( http://cscott.net ) ___ Devel mailing list Devel@lists.laptop.org http://lists.laptop.org/listinfo/devel
Turtles All The Way Down
I've done a little more work on "Turtles All The Way Down", which I (very briefly) discussed at EduJam. I actually wrote a garbage collector in TurtleScript for TurtleScript on Sunday. Brief writeup here: http://cananian.livejournal.com/64140.html and exhaustive mind-numbing detail here: http://cscott.net/Projects/TurtleScript/ No actual turtles yet! I'm going to have to fix that soon. --scott -- ( http://cscott.net ) ___ Devel mailing list Devel@lists.laptop.org http://lists.laptop.org/listinfo/devel
Re: The next four weeks
On Tue, Apr 12, 2011 at 1:56 PM, C. Scott Ananian wrote: > On Mon, Apr 4, 2011 at 6:09 PM, C. Scott Ananian wrote: >> I've posted a four week plan for XO-3 software exploration at >> http://cananian.livejournal.com/62667.html >> >> Briefly: >> April 4-8: Android >> April 11-15: Chrome/ChromeOS/NativeClient > > The report on the first week of work is now up at: > http://cananian.livejournal.com/62756.html The report on "week two" is now up, in three parts: * Sugar on Native Client (general observations) http://cananian.livejournal.com/63325.html * Comparing NaCl and Android, and some demos http://cananian.livejournal.com/63595.html * Next steps for the next month http://cananian.livejournal.com/63783.html Bottom line: no major technical roadblocks. NaCl has the edge on web integration, Android holds its market lead. --scott -- ( http://cscott.net ) ___ Devel mailing list Devel@lists.laptop.org http://lists.laptop.org/listinfo/devel
Re: XO-1.5 users: need your SD card data
Note that Quozl's version also works better on images created with image-builder tools which delete files during the image creation process (ie, on just about anything which involves mounting the filesystem image during the image creation process; as opposed to (say) squashfs, which is a read-only filesystem created all at once from a filesystem tree at the very end). Deleted files will leave 'dirty' blocks which are not zero but can still be safely skipped. --scott -- ( http://cscott.net ) ___ Devel mailing list Devel@lists.laptop.org http://lists.laptop.org/listinfo/devel
Re: XO-1.5 users: need your SD card data
On Thu, Apr 14, 2011 at 10:10 PM, James Cameron wrote: > As an alternative, consider identifying the unused blocks in the > filesystem, and avoid including them in the .zd file. This would make > it unnecessary to know whether the bits will be set or cleared by the > card. ext2, ext3, and ext4 care nothing for the bits in unused blocks. This would also nicely finesse the problem that different cards may erase to different values (0xFF vs 0x00). --scott -- ( http://cscott.net ) ___ Devel mailing list Devel@lists.laptop.org http://lists.laptop.org/listinfo/devel
Re: XO-1.75 -> Flash, Java?
On Wed, Apr 13, 2011 at 9:16 PM, Alan Eliasen wrote: > I considered it also a serious problem that the then-shipping > configurations of the OLPC completely lacked fonts with glyphs for many > languages (e.g. there were no fonts with Chinese or Japanese characters) > so these languages could not be rendered in any application on the OLPC, > including in the browser. This should probably be considered to be a bug > in a supposedly-internationalized platform, and affects language > learning, or even seeing what another language looks like. The Chinese and Japanese fonts are *very* large. I believe OLPC only ships them to countries which need them, in order to make more space for kids' stuff. --scott ___ Devel mailing list Devel@lists.laptop.org http://lists.laptop.org/listinfo/devel
Re: The next four weeks
On Tue, Apr 12, 2011 at 5:45 PM, Peter Robinson wrote: >> And, again, I have to remind folks that this is only *one* possible >> forward path for Sugar-on-Tablets. This week I am examining a >> ChromeOS-based option. http://cananian.livejournal.com/62667.html >> describes the current plan of work, and there will be further >> exploration of promising options after that. > > Out of interest is the meego tablet / touch interface on the to look > at list as well? Meego development has been quite turbulent. The goal is to build on a stable and reliable foundation, so that OLPC won't have to do as much basic platform work. It's not clear that meego will provide that, or that meego will ever be a first-class citizen on ARM (http://wiki.meego.com/ARM). But meego's definitely on the list. Just not as high priority at the moment. --scott ___ Devel mailing list Devel@lists.laptop.org http://lists.laptop.org/listinfo/devel
Re: The next four weeks
2011/4/12 NoiseEHC : > What I do not get is this: what is the goal? An excellent educational experience on tablet devices, within the resources of the current Sugar community. > Having an environment running on Android which can run the same XO bundles > which are run by XO-1.x? Ideally, yes. In practice, some porting will almost certainly be required; the goal would be to minimize that work. In addition, in the Android scenario, Sugar would gain the ability to run educational activities written natively for the Android environment which would provide capabilities currently missing from Sugar -- for example, the Android "Movie Studio" activity. > If the Sugar API has to be changed (adapted for some technical reason) would > you fork all activities? It may be possible to write activities such that they can run on either platform. TurtleArt has a number of ports, for example, but I do not believe it has forked. It's a little too early to make definitive statements, but obviously there are many benefits to avoiding unnecessary forks. And, again, I have to remind folks that this is only *one* possible forward path for Sugar-on-Tablets. This week I am examining a ChromeOS-based option. http://cananian.livejournal.com/62667.html describes the current plan of work, and there will be further exploration of promising options after that. --scott ___ Devel mailing list Devel@lists.laptop.org http://lists.laptop.org/listinfo/devel
Re: The next four weeks
On Mon, Apr 4, 2011 at 6:09 PM, C. Scott Ananian wrote: > I've posted a four week plan for XO-3 software exploration at > http://cananian.livejournal.com/62667.html > > Briefly: > April 4-8: Android The report on the first week of work is now up at: http://cananian.livejournal.com/62756.html Basically -- yes, I can see how Sugar-on-Android can be done. No major blockers, but the build chain and packaging issues will be an initial annoyance. --scott ___ Devel mailing list Devel@lists.laptop.org http://lists.laptop.org/listinfo/devel
Re: The next four weeks
Thanks for your links to the mailing list threads. That's handy to have at my fingertips. I agree that the activities are key. "Transparent" compatibility is probably impossible, but I hope that porting the activities will not be too hard. Minimizing unnecessary API changes and writing a good porting guide should go far. The Journal and Portfolio are really important part of Walter's vision of Sugar. They will be "system services", with strong enough modularization to allow multiple competing implementations. I know how that will work in web/nativeclient model. I'm not certain how that works on Android yet; hopefully by the end of this week I'll have some better ideas. --scott ___ Devel mailing list Devel@lists.laptop.org http://lists.laptop.org/listinfo/devel
People to talk to
This is a corollary with my recent post on "things to do" -- here are the people I've like to get OLPC talking/working more closely with. Google teams: - ChromeOS (Ed has contact info already for the ChromeOS on ARM project manager) - Android - NativeClient Networking teams: - OLSRd (we've got good contacts, just need to reawake/nuture them) - 802.11s (cozybit and that community) - Universities interested in research and deployment of mesh networks Miscellaneous: - JG is very excited about content-centric networking. There's a large NSF project around this; contact program leads. - Haptic technologies (wad and I have been chasing down some leads here) Anyone have specific contacts for any of these areas, and/or want to suggest other external teams we should be working with? --scott ___ Devel mailing list Devel@lists.laptop.org http://lists.laptop.org/listinfo/devel
The next four weeks
I've posted a four week plan for XO-3 software exploration at http://cananian.livejournal.com/62667.html Briefly: April 4-8: Android April 11-15: Chrome/ChromeOS/NativeClient April 18-22: Get down & dirty with mesh April 25-29: Yanking legacy Sugar codebase into the future May 2-6: in Uruguay to present results and discuss all this w/ Sugar folks in person I'll be posting more about each project as I dig into them; there are also threads on IAEP where I've discussed all these topics before, so they shouldn't come as too much of a surprise. There are other ideas out there, and I'm not going to *finish* any of these investigations in a single week. Feel free to ask questions and suggest other projects -- although please read the existing discussions first if you can. In order to actually get work done w/o endless distraction, I'll probably try to avoid getting into lots of details for projects other than the one I'm currently focusing on. --scott ___ Devel mailing list Devel@lists.laptop.org http://lists.laptop.org/listinfo/devel
Re: Possible XO Graphics Optimization Technique
On Apr 1, 2011 11:03 AM, "Samuel Greenfeld" wrote: > > Hello all: > > As many of you are aware, work is being done to improve the graphics performance of various XO laptop platforms. > > So in an attempt to improve things further, I looked into optimizing the data Sugar sends to the video subsystem itself. > > I think I have made some improvements, and put up some samples of my Sugar interface work at http://www.greenfeld.org/1April2011/ . Feedback is welcome. > > But while I have drastically reduced the amount of bandwidth required to display the Sugar interface, I fear I have significantly increased the amount of power required for optimal rendering. Very nice work. It looks like the sugarlabs website could use some better markup. (Sidebar at the end would make it more readable.) --scott ___ Devel mailing list Devel@lists.laptop.org http://lists.laptop.org/listinfo/devel
Re: Any restrictions or recommendations regarding SD cards?
On Thu, Mar 24, 2011 at 3:26 PM, Christoph Derndorfer wrote: > Hi all, > the folks from the Austrian pilot project want to equip the XO-1s there with > SD cards. Are there any restrictions wrt size, speed, etc. that they should > be aware of when purchasing the SD cards? I'm particularly asking after > reading James' mention of seeing more issues with newer cards and the XO-1 > power off bug. > Or asked the other way 'round: Are there any particular cards or > manufacturers which people can recommend? My recommendation would be to get some samples and test them. The manufacturer's name doesn't really tell you much when it comes to SD cards. There are some numbers at http://wiki.laptop.org/go/NAND_Testing but again, your results will vary. More speed is always better, but "class 4" isn't *necessarily* slower than "class 6", it all depends on what parts they had on the shelf that day. But it's probably worth looking for the fastest cards you can afford. --scott -- ( http://cscott.net/ ) ___ Devel mailing list Devel@lists.laptop.org http://lists.laptop.org/listinfo/devel
Re: Mesh Potatos and OLPCs?
On Wed, Mar 23, 2011 at 9:30 PM, Peter Robinson wrote: > On Wed, Mar 23, 2011 at 11:38 PM, John Gilmore wrote: > Meraki are also doing mesh related things with the APs etc. > > Its my understanding (not that I've had much time to play) that mesh > has improved greatly over the last couple of years with developments > like BATMAN which is now in the 2.6.38 mainline kernel. I suspect pure > IPv6 might also assist with some of the problems seen with broadcast > on mesh networks as they get larger simply due to its lack of it. IPv6 isn't a magic bullet for mesh. If anything, IPv6's reliance on multicast for basic ARP-type stuff adds additional difficulties. That's not to say that IPv6+mesh is impossible. I'm just saying it doesn't make things significantly *easier*. I agree with Ed's contention in so far as I also haven't seen anyone doing exactly what OLPC originally wanted to do. I also agree with Peter and Charles that Mesh has matured greatly in the past few years (although the mature deployements are not exactly OLPC's use case). I think the opportunity is there for either (a) someone to take the mature meshes and push them the extra distance to work in OLPC's case (mobile nodes, ideally IPv6, dynamic mesh configuration), or (b) OLPC to rethink its deployments such that the mature mesh technologies are more immediately applicable. As one strawman proposal for (b), you might consider making the school servers the mesh nodes, not the XOs. As another strawman proposal for (b), you could "flip a switch" to make an XO into a dedicated stationary mesh node -- and put it on a pole in the middle of the neighborhood with a solar panel, say. Either of these would be significantly different from the original "every child's machine also a mobile mesh node" vision -- but might be much closer to the mature deployed mesh technologies. --scott -- ( http://cscott.net/ ) ___ Devel mailing list Devel@lists.laptop.org http://lists.laptop.org/listinfo/devel
Re: 11.2.0 development build 14 released
You might also try just using python's implementation of tar (the 'tarfile' module), which can probably be hacked to support rsync's --fake-super as well. Might kill two birds that way. Although I'm sure that fixing fakeroot will benefit more people. --scott -- ( http://cscott.net/ ) ___ Devel mailing list Devel@lists.laptop.org http://lists.laptop.org/listinfo/devel
Re: 11.2.0 development build 14 released
On Mon, Mar 21, 2011 at 1:01 AM, Daniel Drake wrote: > On 19 March 2011 17:16, Daniel Drake wrote: >> updates.laptop.org now offers this stream. Instructions are on the >> 11.2.0 page above. > > Unfortunately this doesn't work. > > Files such as /etc/shadow and /etc/gshadow are now installed from > Fedora with permissions 000. > > rsyncd on updates.laptop.org runs as non-root, hence cannot read these files: > rsync: send_files failed to open "root/etc/gshadow" (in > build-11.2.0_xo1.5-14): Permission denied (13) > > We could fix this by making these files have permissions 400 in the > image, or by making rsyncd run as root on updates.laptop.org. > > Scott, any thoughts? I used to run rsyncd inside fakeroot, which solved these problems neatly. There's also a --fake-super option to rsync which can work. Or you can just run rsync as root. --scott -- ( http://cscott.net/ ) ___ Devel mailing list Devel@lists.laptop.org http://lists.laptop.org/listinfo/devel
Re: 11.2.0 development build 14 released
On Mon, Mar 21, 2011 at 1:56 AM, C. Scott Ananian wrote: >> I used to run rsyncd inside fakeroot, which solved these problems >> neatly. There's also a --fake-super option to rsync which can work. >> Or you can just run rsync as root. > > http://dev.laptop.org/git/users/cscott/upgrade-server/tree/upserv.py > used fakeroot. > The --fake-super option was added after upserv was written; it's > probably a better solution now. cananian@skiffserv:~$ fakeroot root@skiffserv:~# cd /tmp root@skiffserv:/tmp# mkdir XYZ root@skiffserv:/tmp# cd XYZ/ root@skiffserv:/tmp/XYZ# touch foo root@skiffserv:/tmp/XYZ# echo A > foo root@skiffserv:/tmp/XYZ# chmod 000 foo root@skiffserv:/tmp/XYZ# cat foo A root@skiffserv:/tmp/XYZ# exit so fakeroot (at least debian/unstable's version of fakeroot) should be able to handle this just fine. --scott -- ( http://cscott.net/ ) ___ Devel mailing list Devel@lists.laptop.org http://lists.laptop.org/listinfo/devel
Re: 11.2.0 development build 14 released
On Mon, Mar 21, 2011 at 1:52 AM, C. Scott Ananian wrote: > On Mon, Mar 21, 2011 at 1:01 AM, Daniel Drake wrote: >> On 19 March 2011 17:16, Daniel Drake wrote: >>> updates.laptop.org now offers this stream. Instructions are on the >>> 11.2.0 page above. >> >> Unfortunately this doesn't work. >> >> Files such as /etc/shadow and /etc/gshadow are now installed from >> Fedora with permissions 000. >> >> rsyncd on updates.laptop.org runs as non-root, hence cannot read these files: >> rsync: send_files failed to open "root/etc/gshadow" (in >> build-11.2.0_xo1.5-14): Permission denied (13) >> >> We could fix this by making these files have permissions 400 in the >> image, or by making rsyncd run as root on updates.laptop.org. >> >> Scott, any thoughts? > > I used to run rsyncd inside fakeroot, which solved these problems > neatly. There's also a --fake-super option to rsync which can work. > Or you can just run rsync as root. http://dev.laptop.org/git/users/cscott/upgrade-server/tree/upserv.py used fakeroot. The --fake-super option was added after upserv was written; it's probably a better solution now. I don't know what's actually running on updates.laptop.org these days. --scott -- ( http://cscott.net/ ) ___ Devel mailing list Devel@lists.laptop.org http://lists.laptop.org/listinfo/devel
Re: Updating olpc-boot-anim for a 10.1.3 build with minimum fuss
Originally you could override by putting frames in ~/.bootanim. http://wiki.laptop.org/go/Tweaking_the_boot_animation Don't know if that's still the case. --scott -- ( http://cscott.net/ ) ___ Devel mailing list Devel@lists.laptop.org http://lists.laptop.org/listinfo/devel
Re: Discovering the XOs local timezone in a bash script
On Sun, Mar 13, 2011 at 1:04 PM, Sascha Silbe wrote: > Excerpts from C. Scott Ananian's message of Sun Mar 13 16:41:36 +0100 2011: > >> I apologize; I think the code that sets timezone "correctly" might >> have been code I wrote for litl, not OLPC. > > No problem. Do you remember how it worked at Litl? Did you manipulate > /etc/timezone directly or using a distro specific tool? We read the list of time zones from /usr/share/zoneinfo/zone.tab in the GUI code, and set the time and time zone by calling /sbin/hwclock and manipulating /etc/localtime and /etc/timezone directly in what I believe was a dbus system service running as root. The dbus service was about 70 lines of g-o-i javascript. --scott -- ( http://cscott.net/ ) ___ Devel mailing list Devel@lists.laptop.org http://lists.laptop.org/listinfo/devel
Re: Memory replacement
On Sun, Mar 13, 2011 at 1:00 PM, C. Scott Ananian wrote: > On Sun, Mar 13, 2011 at 8:57 AM, Andrei Warkentin > wrote: >> Sorry to butt in, I think I'm missing most of the context >> herenevertheless... I'm curious, ignoring outer packaging and >> product names, if you look at cards with the "same" CID (i.e. same >> manfid/oemid/date/firmware and hw rev), do you get same performance >> characteristics? > > No. To elaborate: see bunnie's blog post (cited above) on how the CID is often forged or wrong. I've also personally witnessed a manufacturer's rep come to the factory floor to reprogram a compact flash card's internal microcontroller with new firmware. This did not update any externally visible information reported by the chip. I had to convince the manufacturer to leave their proprietary hardware on the factory floor in order to be able to verify that future units would have the correct firmware. (Granted, this was not an MMC unit, but I would be surprised if MMC vendors were significantly different in this regard.) If you've spent any time working with Chinese/Taiwanese OEMs, you will notice that version control methodologies are (in general) disappointingly lax. --scott -- ( http://cscott.net/ ) ___ Devel mailing list Devel@lists.laptop.org http://lists.laptop.org/listinfo/devel
Re: Memory replacement
On Sun, Mar 13, 2011 at 8:57 AM, Andrei Warkentin wrote: > Sorry to butt in, I think I'm missing most of the context > herenevertheless... I'm curious, ignoring outer packaging and > product names, if you look at cards with the "same" CID (i.e. same > manfid/oemid/date/firmware and hw rev), do you get same performance > characteristics? No. --scott -- ( http://cscott.net/ ) ___ Devel mailing list Devel@lists.laptop.org http://lists.laptop.org/listinfo/devel
Re: Discovering the XOs local timezone in a bash script
I apologize; I think the code that sets timezone "correctly" might have been code I wrote for litl, not OLPC. --scott On Sunday, March 13, 2011, Daniel Drake wrote: > On 13 March 2011 03:21, Samuel Greenfeld wrote: >> Sugar reports only relative times in its core GUI, so I don't know how >> common it is for deployments or other users to actually change this >> setting. Setting a time zone other than UTC with 10.1.3 and prior may >> also expose a flaw where the offset is repetitively applied every >> reboot, shifting the clock. > > Just to remove any doubt.. > Setting the time zone from the control panel doesn't have any adverse > effects such as the clock shift described above. This is is because > sugar's time zone is isolated from the rest of the system as described > here. > > Setting a different timezone on the system level will cause problems > on existing builds, but there is no UI for this, and this is fixed in > 11.2.0 (with a "UI" now available via olpc-os-builder configuration > setting). > > Daniel > ___ > Devel mailing list > Devel@lists.laptop.org > http://lists.laptop.org/listinfo/devel > -- ( http://cscott.net/ ) ___ Devel mailing list Devel@lists.laptop.org http://lists.laptop.org/listinfo/devel
Re: Discovering the XOs local timezone in a bash script
Last I knew we used standard Linux conventions for timezones and sugar called the standard Linux commands (via sudo) to set the timezone. But that should make 'date' report the correct local time (unless you use '-u') so maybe someone broke that sometime in the past two years. Check /etc/timezone? --scott -- ( http://cscott.net/ ) ___ Devel mailing list Devel@lists.laptop.org http://lists.laptop.org/listinfo/devel
Re: Memory replacement
On Sat, Mar 12, 2011 at 5:51 PM, Arnd Bergmann wrote:
> I've had four cards with a Sandisk label that had unusual characteristics
> and manufacturer/OEM IDs that refer to other companies, three Samsung ("SM")
> and one unknown ("BE", possibly lexar). In all cases, the Sandisk support
> has confirmed from photos that the cards are definitely fake. They also
Please see the blog post I cited in the email immediately prior to
yours, which discusses this situation precisely. Often the cards are
not actually "fake" -- they may even be produced on the exact same
equipment as the usual cards, but "off the books" during hours when
the factory is officially closed. This sort of thing is very very
widespread, and fakes can come even via official distribution
channels. (Discussed in bunnie's post.)
> However, they have apparently managed to make them work well
> for random access by using some erase blocks as SLC (writing only
> the pages that carry the most significant bit in each cell) and
> by doing log structured writes in there, something that apparently
> others have not figured out yet. Also, as I mentioned, they
> consistenly use a relatively large number of open erase blocks.
> I've measured both effects on SD cards and USB sticks.
You've been lucky.
> I believe you can get this level of sophistication only from
> companies that make the nand flash, the controller and the card:
> Sandisk, Samsung and Toshiba.
> Other brands that just get the controllers and the flash chips
> from whoever sells them cheaply (kingston, adata, panasonic,
> transcend, ...) apparently don't get the really good stuff.
You're giving the OEMs too much credit. As John says, unless you
arrange for a special SKU, even the "first source" companies will give
you whatever they've got cheap that day.
>> How we deal with this is constant testing and getting notification from
>> the manufacturer that they are changing the internals (unfortunately,
>> we aren't willing to pay the premium to have a special SKU).
>
> Do you have test results somewhere publically available? We are currently
> discussing adding some tweaks to the linux mmc drivers to detect cards
> with certain features, and to do some optimizations in the block layer
> for common ones.
http://wiki.laptop.org/go/NAND_Testing
But the testing wad is talking about is really *on the factory floor*:
Regular sampling of chips as they come into the factory to ensure
that the chips *you are actually about to put into the XOs* are
consistent. Relying on manufacturing data reported by the chips is
not reliable.
--scott
--
( http://cscott.net/ )
___
Devel mailing list
Devel@lists.laptop.org
http://lists.laptop.org/listinfo/devel
Re: Memory replacement
Canonical related blog post: http://www.bunniestudios.com/blog/?p=918 Mandatory reading for anyone who has to deal with flash memory. --scott -- ( http://cscott.net/ ) ___ Devel mailing list Devel@lists.laptop.org http://lists.laptop.org/listinfo/devel
Re: [OLPC-AU] XO-1 developer key does not work
On Sat, Mar 12, 2011 at 2:16 AM, Mikus Grinbergs wrote: >> why am I getting different readings for each method? > > My guess is that file /home/.devkey.html was copied in from some other > system, and shows the serial number and UUID of the copied-from system. It would be interesting to investigate how /home/.devkey.html got onto the machine -- ie, what build you used, and how you installed it onto the device -- in order to prevent this problem from recurring. > I myself would trust the collection key values. yup. --scott -- ( http://cscott.net/ ) ___ Devel mailing list Devel@lists.laptop.org http://lists.laptop.org/listinfo/devel
Re: XO-1 developer key does not work
Posting your machine's serial number as well as then contents of your develop.sig might help; your developer key might be malformed or correspond to a different XO than the one you are trying to use it on. You can also try the collection key method, as one more check on the process by which you are generating the developer key. --Scott On Friday, March 11, 2011, Sridhar Dhanapalan wrote: > I am trying to put a permanent developer key on an XO-1. I have been > following the steps at > http://wiki.laptop.org/go/Activation_and_developer_keys > > First, I created the key using devkey.html. Then I copied develop.sig > to /security on the XO. After rebooting, I still see a wp tag in > /ofw/mfg-data. > > Then I copied develop.sig to /security to a USB drive. Turning the XO > on with the drive plugged in makes no difference. If I hold down the > tick key while turning on, I get the messages: > > trying disk:\security\develop.sig > Devel key No matching records > ... > Trying nand:\security\develop.sig > Devel key No matching records > > I tried several FAT32-formatted USB drives, including one that I have > used to upgrade to the latest signed firmware. > > Can anyone help out? > > Thanks, > Sridhar > ___ > Devel mailing list > Devel@lists.laptop.org > http://lists.laptop.org/listinfo/devel > -- ( http://cscott.net/ ) ___ Devel mailing list Devel@lists.laptop.org http://lists.laptop.org/listinfo/devel
Re: Require ".olpc" in rpms in ~/public_rpms/F14?
FWIW, the original intent was *only* to allow SRPMS in the dropbox; we were going to explicitly rebuild the RPMs from the SRPMS in mock and use only the built RPMs. In addition to ensuring compliance with licensing provisions, this was also intended as a developer aid: at the time, it was often easier to generate a correct patched SRPM from the source than it was to create an appropriate and up-to-date mock environment for the build, and often developer RPMs were built in subtly-incompatible environments. I don't know if those concerns are still valid at the present time. Like many things from long ago, the "build from SRPM" feature was incomplete when it lost its developers. It might be the proper time to resurrect it, although perhaps having RPMs which don't match the SRPM isn't a problem any more. --scott -- ( http://cscott.net/ ) ___ Devel mailing list Devel@lists.laptop.org http://lists.laptop.org/listinfo/devel
Re: Content-Centric Networking.
On Fri, Feb 18, 2011 at 12:28 PM, Michael Stone wrote: > 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. IP-based routing has a lot of known problems, especially wrt firewalls, and so does DNS (I think the strongest kickback on the Network Principles was the idea of giving each school its own domain name). So I think there is some latitude for trying new stuff within the school *as long as it is interoperable with the outside world*. Our existing XMPP is not interoperable, and our DNS is unimplemented. So it's not hard to do better. The real opportunity is to partner with a research group and multiply OLPC's efforts. Basically, we *must* use something which other people are working on. If we can't find "others" interested in working on CCNx, then we must use DNS, etc -- although we haven't been too successful in finding people who want to work on *those* in the ways OLPC would like to use them, either. 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? New CCNx router == school server. The router is the primary place where content is cached. There are over-IP hops to other school servers. It does depend critically on how interoperation with "legacy networks" is done. It seems that they have a reasonable story for this, falling back to direct connections when no "CCNx router" is available. I agree we could use more details, but the fact that they have working Android implementations (which must work with the vagarities of carrier networking) seems to be a proof-by-example that this is not an insurmountable problem. Remember that the Network Principles document also posits new "routers" -- but in that case, they were IPv6 routers (called 'tunnels' in the spec). Basically, disconnected and mobile operation, coupled with IPv4 firewalls and NAT, means that some network router infrastructure (aka, connecting school servers to each other, or to the globally-routable internet) is required in any case. The question is what those routers look like. (A few years ago I also looked at the idea of making those 'routers' look like bittorrent clients, which basically uses DHT techniques to route content between schools. Lots of different ideas; the trick is in interoperability, transparency, and deployment.) 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 >> years?). >> > > 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?) > Yes, but it would potentially allow content to be aggregated over several caches more easily (ie, you don't have to store the entire cache on one machine), and solves some of the DNS issues more cleanly (no one has to look up DNS and make a connection to an arbitrary IPv4 or IPv6 address, as in Network Principles). So far this is more of a replacement than an improvement. The improvement would be for stuff kids publish, which now doesn't need to be discoverable via a fixed IPv4 or IPv6 address. As long as it has a CCNx 'name' it can be reached/cached/etc in the same way as the rest of the web content. So now the school server can fulfill its role in storing kids' assignments in the same way it is storing web content. And discovery can now be done via CCNx as well. It's reducing a number of different mechanisms into one. 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." > > ? Yeah, something
Content-Centric Networking.
Recapping for the list: Jim Gettys sent me a pair of papers to read yesterday, both linked from http://www.ccnx.org/content/content-centric-networking-resources 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, 2009. 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 http://wiki.laptop.org/go/Network_principles 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. 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). 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 years?). This would let all of the laptops "talk pure CCNx" to each other, without losing web access, and make the web behave better when machines are disconnected. For bonus points, the CCNx routers would use something like rproxy ( http://rproxy.samba.org/doc/protocol/protocol.html) 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. 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 consideration. 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 field. So, secondarily to the HTTP gateway, I would suggest the ol' Journal as a research area they might like to explore: a collection of ~100 machines, each of which has a (unique?) name and a collection of documents sorted by date. The task is to efficiently enumerate your friends or classmates, and then look through their shared documents. Ideally this would work even if some of your friends (and their documents) aren't currently in class, assuming other students have cached the relevant information. (In addition, I would add an indirection layer: my best ideas for solving the document collaboration problem involve the notions of "borrowing" vs "copying". So person A can "borrow" some document, make edits (possibly with others) and then "return" the borrowed document to the original owner. So when you request document A from friend X, the response might be "friend Y is currently borrowing it". This might involve another request to friend Y, with a different document "name" -- or it might involve friend Y publishing a document in friend X's namespace. I'd be very interested in hearing the "CCNx way" to approach this problem. The goal is to simplify the multi-editor versioning problem by ensuring that there is exactly one "owner" at any given time who is responsible for serializing edits.) So, bottom line: very interesting work. Offers some benefits even in an isola
Re: Proposal for new frozen repositories server
On Sun, Feb 6, 2011 at 7:29 AM, Daniel Drake wrote: > mock.laptop.org, our server for "frozen packages" i.e. a clone of the > latest Fedora and OLPC RPMs frozen for each software release, is out > of disk space and somewhat unloved, and I'd like to use the > opportunity to make some changes to the system. > > In a sentence, the changes are: Repositories which are essentially > unmodified by OLPC are moved out of revision control, and OLPC-local > repositories are moved from being unrelated branches in a > huge/old/long-living git repository into their own individual, > short-lived git repositories. > > Full details here: > http://wiki.laptop.org/go/User:DanielDrake/NewMockProposal > > Comments welcome. I'm looking to refine the proposal and implement it > within the next few weeks Why not just add more disk space? Disk space is cheap. Or archive the older parts of the repo. The benefit to version controlling even the non-OLPC packages is that the repo contains a *complete* snapshot of all the bits that went into a particular build. This protects against upstream reorganizing their repos, or cleaning old packages, or changing their package manager, etc, etc. It makes builds 100% reproducible at any point in the future (or at least that was the point). Removing any packages from the repo would pretty much defeat the whole purpose. If disk space really is a problem, one alternative is to make release candidate builds on a branch, and only merge released builds to master. Then you can prune the branches with git to free up disk space, while still ensuring that you have all the bits related to released builds. But really -- why not more disk? [I understand there are parts of mock which are non-ideal, but the essential "saving all the bits" part isn't one of them. IMHO.] --scott -- ( http://cscott.net/ ) ___ Devel mailing list Devel@lists.laptop.org http://lists.laptop.org/listinfo/devel
Re: XO-1.75 A2 information
On Sun, Jan 9, 2011 at 6:02 PM, Carlos Nazareno wrote: > Accelerometer? > > Sweet! :) It looks like the XO-1.75 has the LIS33xx, which is roughly the same accelerometer as used in the iPhone, Android phones, etc. Our ODM suggested replacing our LIS33DH with an accelerometer from Kionix (we went with the KXTE9; it turned out when we tested with games we didn't need more than 6-bit resolution, but Kionix also has high-resolution devices) because ST microelectronics was having leadtime issues with the LISxx accelerometers. I think the Kionix solution saved a bit of BOM cost, too. I don't know if that's a good second-source alternative for OLPC or not, but it might be worth some investigation. --scott -- ( http://cscott.net/ ) ___ Devel mailing list Devel@lists.laptop.org http://lists.laptop.org/listinfo/devel
Re: Looking for startup sound recording
On Tue, Dec 7, 2010 at 12:04 AM, James Cameron wrote: > (You'll notice that on a good sound system it is quite different to > playback on an XO ... it takes a bit of equalisation to reproduce the XO > speakers.) The converse, actually. The sound file was extensively EQ'd so that it is *accurate* when played on an XO's speakers. Playback via other output devices doesn't correctly reproduce the Edge's performance. --scott -- ( http://cscott.net/ ) ___ Devel mailing list Devel@lists.laptop.org http://lists.laptop.org/listinfo/devel
Re: Firmware update
On Wed, Nov 24, 2010 at 5:49 PM, Daniel Drake wrote: > On 24 November 2010 22:40, Kevin Gordon wrote: >> Is this recommendation against yum and rpm for all software, or just the >> oplc repo packages, the kernel and the firmware? I'm certainly happy doing >> just safe builds for the core. > > To avoid all corner cases it the recommendation really needs to be > "everything" > In reality, you'll probably get away with it, especially because > you're only really working with added packages in your deployment (not > upgrading ones that are already installed). > > Some of the resultant problems will also not affect small deployments > like yours. For example, one side effect is that olpc-update pristine > (efficient) updates stop working as soon as you make any filesystem > modifications like this. Another side effect is that your > custom-installed packages will magically disappear after an > olpc-update upgrade (which in a real deployment would happen without > you even knowing). > > But in a small deployment like yours, touching each laptop for updates > is probably more sensible than the knowledge and infrastructure > investment needed for hands-off olpc-update, so you aren't affected. > >> However, as part of our 'refresh' stick when we wipe and install a new >> signed build, we generally also include the necessary rpm's for cheese and a >> couple of other utilities that are locally installed from the USB stick >> using a bash script; or, for the Vernier software dependencies, the >> dependent rpm's are installed by means of a python script. However, they >> are rpm's and they are downloaded onto the stick (the first time) using yum, >> and they are then installed from the stick using --localinstall from the >> stick. > > You probably won't see any problem with this collection of changes. > Nevertheless, at the SF summit I started showing Adam the "correct" > way to do this: building a custom OS image with those customizations > already included. We didn't have time to completely finish it, but he > picked it up quickly and could probably finish it with a little effort > (and perhaps a couple of mails to this list). At one point Michael and I also had a side-loading mechanism implemented -- if you put your target RPMs in some directory in /home/olpc -- I think it was ~/.rpms -- then they'd automatically get re-installed after olpc-update. That was (at the time) the preferred mechanism for "adding a few packages" persistently to a build. Assuming this mechanism hasn't code-rotted, this is a nice intermediate step: less work than rolling an entire new build, and relatively easy to accomodate new "upstream" builds without disruption. --scott -- ( http://cscott.net/ ) ___ Devel mailing list Devel@lists.laptop.org http://lists.laptop.org/listinfo/devel
Re: XO-1.5 audio input DC mode
On Wed, Nov 24, 2010 at 6:52 AM, Sascha Silbe wrote: > 2. The voltage I see with bias off is probably generated internally by > the codec chip. [...] > Unless someone finds a magic way to disable this from the digital > side of the chip (which I doubt), we'll have to cope with it. This > means that we need an external buffer circuit in order to prevent the > XO-1.5 from feeding voltage back into the measured circuit. What is the impedance of your input? What's the capacitance? I can see getting some leakage current into a high-impedance high-capacitance circuit, but for most purposes this shouldn't really be a problem. --scott -- ( http://cscott.net/ ) ___ Devel mailing list Devel@lists.laptop.org http://lists.laptop.org/listinfo/devel
Re: SD card unpartitioned space -- used for swap?
On Mon, Nov 22, 2010 at 6:43 PM, Mikus Grinbergs wrote: > If "indistinguishable" is true, then there is as much wear to the SD > card from one file-block written as there is from one swap-block > written. Yes. > I have no measurements whatsoever - but my gut feel is that > the majority of my SD card writes are for file-blocks. If that happens > to be the case, then writes to swap space are a minor wear contributor. Measurements are always helpful. > Also, I'm not familiar with "evil keepout time". But note that on the > new XO-1 F14 build, the "shutdown" time-lapse is only a few seconds. > If actually 30s are needed to keep the SD circuitry happy, perhaps a > delay (and a Release Notes explanation) should be added to the OLPC. This is an issue with particular brands of SD cards. It's not an XO issue, per se. >> To advance the discussion, collecting a quantitative measure >> of "average swap writes per day" given some usage profile would let >> you more-or-less rigorously determine whether swap was 'safe' over the >> 5 year expected lifetime of the device. > > Note: I'm using an external SD card. So if it fails before the OLPC > itself fails, I can at reasonable expense replace this swap device -- I > don't have to plan for a definite wear lifetime. Are you making regular backups? >> If you started >> collecting/recording total data written to your swap partition, I'd be >> very interested to hear (in a month or so) what your numbers were. > > I'm NOT into instrumentation. Please help me in locating software that > will collect the number of swap (and file) writes to a physical device > -- but it must be software that is simple_for_me_to_install_on_OLPC. > [For persistence, the output of that software needs to go to the SD.] The contents of /proc/diskstats seem to contain the interesting info. http://www.linuxquestions.org/questions/suse-novell-60/interpreting-proc-diskstats-360350/ describes their interpretation. A user-friendly script would probably live in /etc/init.d and record the relevant information from /proc/diskstats at shutdown time. --scott -- ( http://cscott.net/ ) ___ Devel mailing list Devel@lists.laptop.org http://lists.laptop.org/listinfo/devel
Re: SD card unpartitioned space -- used for swap?
On Mon, Nov 22, 2010 at 2:21 PM, Mikus Grinbergs wrote: >> Downsides >> - Increased SD card wear > > For about two years now, I've been defining a swap partition on the > (external) "permanent" SD card I use with my XO-1 systems. So far, I > have never experienced any problems with that setup. A couple of points: a) wear lifetime is statistical, so one report does not equal a guarantee b) wear lifetime is roughly proportional to SD card size, so if you're using a largish card your report is not applicable to smallish card users (you didn't say how large your card was) c) life expectancy of the XO-1 is 5 years (you provided a report after 2) It's not too hard to actually write enough to an SD card to wear it out. For one 4GB card I tested, about 5TB of writes is enough; wad's got equivalent numbers for all of the flash technologies OLPC has tested. To advance the discussion, collecting a quantitative measure of "average swap writes per day" given some usage profile would let you more-or-less rigorously determine whether swap was 'safe' over the 5 year expected lifetime of the device. If you started collecting/recording total data written to your swap partition, I'd be very interested to hear (in a month or so) what your numbers were. --scott -- ( http://cscott.net/ ) ___ Devel mailing list Devel@lists.laptop.org http://lists.laptop.org/listinfo/devel
Re: SD card unpartitioned space -- used for swap?
As my own clarification: I wasn't dismissing possible performance improvements (of any kind). I was just commenting on the old "lockup" bugs, saying this might not actually be related to no-swap-space, although it's possible memory pressure exacerbates the problem. For performance issues, you have to balance against the risks. If it enables you to run ooo, maybe it's worth it. It seems you might also be introducing a configuration management issue, though, where only some units with a given SKU can run (say) OOo. --scott On Monday, November 22, 2010, Daniel Drake wrote: > On 22 November 2010 16:41, Martin Langhoff wrote: >> Just to clarify -- side-to-side comparison in the past have shown a >> significant improvement. We did get a specially bad-behaving kernel in >> our F7 builds in that regard, but even F9 builds have shown it to be >> better. > > That was an XO-1 comparison though. > I haven't heard of similar problems existing for XO-1.5, but my field > experience there is much less. Are there known situations where adding > swap actually helps? > > Another thing to consider would be the current series of patches going > into Linux that improve interactivity under high CPU/memory pressure. > Certainly candidates for inclusion if we can briefly show their value. > > Daniel > -- ( http://cscott.net/ ) ___ Devel mailing list Devel@lists.laptop.org http://lists.laptop.org/listinfo/devel
Re: SD card unpartitioned space -- used for swap?
Assuming OLPC isn't using TRIM support on the SD cards, writes to the swap space are indistinguishable from writes to any other space on the card. That means that writes to the swap "partition" could potentially corrupt other data on the card, especially if it occurs less than 30s before removal of power (or whatever that evil keepout time is). >From my recent experience, I wouldn't be too worried about swap space "wearing out" the SD card, as we used to -- but that's not to say it's 100% safe, all reads and writes are risky to some degree. We've seen up to 60s delays on reads from flash as well, you might consider how that might affect perceived performance. FWIW, litl also uses a no-swap-space linux setup. We haven't actually had any problems with it; bugs I thought I could pin on low-memory/no-swap issues turned out to actually be bugs in the Atom page table hardware (!) which were exacerbated when lots of page table operations were done -- in our case, GPU-heavy tasks triggered the bug just as well. Our superstitions about OLPC's no-swap configuration may well prove to be similarly unfounded. --scott -- ( http://cscott.net/ ) ___ Devel mailing list Devel@lists.laptop.org http://lists.laptop.org/listinfo/devel
Re: Notes on conventional desktop tools
On Thu, Nov 18, 2010 at 3:41 PM, Martin Langhoff wrote: > On Thu, Nov 18, 2010 at 3:08 PM, C. Scott Ananian wrote: >> I think you'll have more success with the latest skype using pulseaudio. > > No need for speculation. I can tell you: in general terms, F11 > pulseaudio ain't a good one. And for whatever reason, this pulseaudio > does not play ball with our alsa drivers. > > PA proponents should hop on the F14 builds and push, tweak, > bastardize, abuse, patch and report :-) Perhaps you are mistaking me for a PA proponent. ;-) I just know which way the wind is blowing. --scott -- ( http://cscott.net/ ) ___ Devel mailing list Devel@lists.laptop.org http://lists.laptop.org/listinfo/devel
Re: Notes on conventional desktop tools
On Thu, Nov 18, 2010 at 2:48 PM, Martin Langhoff wrote: > - Flash pays a hefty price for its refusal to use Xv. Don't install > pulseaudio. > - Skype 2.0.0.72 works reasonably well once you set the right > microphone input. Latest Skype (2.1.0.81) doesn't play well with our > ALSA implementation. We aren't alone in this, various chipsets/drivers > are affected similarly -- your voice is distorted into a growling > mess, see https://jira.skype.com/browse/SCL-638 -- someone with > serious alsa trickery and magic may be able to massage .asoundrc to > work around the issue, I could not. This is recent - previous release > 2.1.0.47 has good audio but video is corrupt. I think you'll have more success with the latest skype using pulseaudio. Yes, pulseaudio is awful. But it's what's being adopted upstream. Pain now == less pain later. (But you probably want to use the pulseaudio plugin called idle something or other (IIRC) to close the audio device when it's not being used, otherwise your indicator light will be stuck on. --scott -- ( http://cscott.net/ ) ___ Devel mailing list Devel@lists.laptop.org http://lists.laptop.org/listinfo/devel
Re: XO-1.5 audio input DC mode
On Wed, Nov 17, 2010 at 2:46 PM, C. Scott Ananian wrote: > As a wild stab at a first guess, it sounds like a software problem to > me -- seems like xoscope is not successfully turning off either the > bias voltage or the decoupling capacitor (high pass filter). Perhaps > a silent failure of some sort? If you've got access to a signal generator (or another machine with a sound card), feeding in a 1kHz square wave with an offset (say 0 off, 1V on) is probably a better diagnostic than using your potentiometer. If my wild guess is correct, then you should see a characteristically rounded square wave with no offset. Then you could poke at the software until (a) the rounding goes away, and (b) you see the offset you expect, which would indicate that the decoupling capacitor has successfully been switched out of the circuit. --scott -- ( http://cscott.net/ ) ___ Devel mailing list Devel@lists.laptop.org http://lists.laptop.org/listinfo/devel
Re: XO-1.5 audio input DC mode
As a wild stab at a first guess, it sounds like a software problem to me -- seems like xoscope is not successfully turning off either the bias voltage or the decoupling capacitor (high pass filter). Perhaps a silent failure of some sort? --scott -- ( http://cscott.net/ ) ___ Devel mailing list Devel@lists.laptop.org http://lists.laptop.org/listinfo/devel
Fwd: Upgrading a _very_ old OLPC
-- Forwarded message -- From: Krishnan R.S. Date: Wed, Nov 17, 2010 at 2:48 AM Subject: Upgrading a _very_ old OLPC To: csc...@laptop.org Hello, I managed to get my hands on a very old OLPC XO laptop for my daughter. I've been trying, unsuccessfully, to upgrade the OS to something current. The main issues are: My image has no olpc-update I tried to follow the wiki instruction to update olpc-update - alas that leads to more issues about missing python2.5 I tried to install python using apt/deb/dpkg but all of these fail since the apt/deb/dpkg tools are missing :( Looking at /etc/issue - I see build 417 - and some messages that look like errors "kernel \r \m " :) so maybe I have a pre-alpha build :) So ... I'm somewhat at a loss as to what my next steps are. My daughter seems pretty excited with the device and enjoys the "paint" application. I'd like to get a more recent build so she can use the newer apps/toos. Can you point me in the right direction ? Or am I wasting my time trying to do the impossible? Thanks, Krishnan +1-415-606-3069 -- Krishnan Subramaniam rskrish...@hotmail.com -- ( http://cscott.net/ ) ___ Devel mailing list Devel@lists.laptop.org http://lists.laptop.org/listinfo/devel
Re: Re: XO-1.75 microphone socket
On Tue, Nov 16, 2010 at 11:38 AM, Walter Bender wrote: > On Tue, Nov 16, 2010 at 11:19 AM, C. Scott Ananian wrote: >> On Mon, Nov 15, 2010 at 4:19 PM, wrote: >>>> Just make sure you keep in mind the difference between the specification >>>> and what is likely to be acceptable. One value is better suited to >>>> personal tinkering, the other to widespread propagation. >>> >>> Good point. As background to my questions Turtle Art 103 now supports >>> sensor input. >>> http://wiki.sugarlabs.org/go/Activities/TurtleArt/Using_Turtle_Art_Sensors >>> >>> As the specification stands, no teacher is going to conduct science >>> experiments with external voltages. If the specification is changed to +-9v >>> then they will have the confidence to conduct experiments with caution. >> >> Why not use 1.5V alkaline cells? Or measure voltage from a lemon >> battery? I can think of any number of safe experiments. > > Why not indeed. See > http://wiki.sugarlabs.org/go/Activities/TurtleArt/Using_Turtle_Art_Sensors#Lemon_battery Right. You can also do quite a lot of useful experiments using the built-in 2V bias. I'm not sure exactly what the problem is -- maybe Tony can offer a more precise objection? Perhaps he feels there needs to be more guidance given on how teachers can construct "fool proof" sensor experiments that are minimally dangerous to hardware, even if the teacher isn't watching every kid every minute? --scott ps. my rule of thumb would be "don't involve an external battery more powerful than a lemon" -- as I understand the protection circuits, there's no way you can connect the internal bias voltage coming from the microphone jack in a way that would damage the input. You can construct a lot of experiments (ie, most on the Turtle Art Sensors page) which are thus "guaranteed safe, even if kids make mistakes" on an XO-1.5/XO-1.75. But the "measuring AC amps" example should be moved to a separate "only with supervision and adequate care" page. (Maybe also the "Generating electricity" example also, although it would take a lot of turns of wire, a pretty strong magnet, and very vigorous motion to exceed 9V.) And the "Lemon battery" and "generating electricity" examples should additionally be warned against on the XO-1 --- maybe also the "burglar alarm", depending on whether the XO-1 is always safe if its inputs are shorted. -- ( http://cscott.net/ ) ___ Devel mailing list Devel@lists.laptop.org http://lists.laptop.org/listinfo/devel
Re: Re: XO-1.75 microphone socket
On Mon, Nov 15, 2010 at 4:19 PM, wrote: >> Just make sure you keep in mind the difference between the specification and >> what is likely to be acceptable. One value is better suited to personal >> tinkering, the other to widespread propagation. > > Good point. As background to my questions Turtle Art 103 now supports sensor > input. > http://wiki.sugarlabs.org/go/Activities/TurtleArt/Using_Turtle_Art_Sensors > > As the specification stands, no teacher is going to conduct science > experiments with external voltages. If the specification is changed to +-9v > then they will have the confidence to conduct experiments with caution. Why not use 1.5V alkaline cells? Or measure voltage from a lemon battery? I can think of any number of safe experiments. --scott -- ( http://cscott.net/ ) ___ Devel mailing list Devel@lists.laptop.org http://lists.laptop.org/listinfo/devel
Re: XO-1.75 progress
Hey, that looks a lot like the conference rooms *I've* been spending weeks in! ;-) --scott -- ( http://cscott.net/ ) ___ Devel mailing list Devel@lists.laptop.org http://lists.laptop.org/listinfo/devel
Re: Synaptics driver on XO-1.5 hw?
On Thu, Oct 28, 2010 at 11:01 PM, Daniel Drake wrote: > On 28 October 2010 15:54, Martin Langhoff wrote: >> On XO-1, we have a long painful history with synaptics and the EC, >> that's led to it being disabled. Instead we use the PS2 protocol. >> >> I just realised that we still do that on XO-1.5 on F11 and F14 builds, >> and can't find commentary from anyone trying anything different. >> >> Are there reasons to think Synaptics may now work? > > As far as I know there is still no explanation nor diagnosis for the > super-strange EC behaviour in this mode. I don't know if anyone has IIRC (and it's been a long time, so don't trust me on this) the Synaptics PS/2 protocol involves more 'context' than the standard mouse packet format, making it more likely that dropped PS/2 bytes could lead to desynchronization (and Bad Mousing). If the underlying PS/2 bus code is more reliable on XO-1.5, I'd expect that Synaptics might be fine again. FWIW, careful about the distinction between the "Synaptics PS/2 protocol" (since there are USB versions), the "Synaptics driver in the kernel", which converts that protocol to evdev, and the "Synaptics X driver" which is actually hardware agnostic and just translate generic evdev messages into X events, handling edge scrolling and other nice touchpad features. (Although on non-evdev platforms I understand that the "Synaptics X driver" does contain code to parse the "Synaptics PS/2 protocol".) I highly recommend using the Synaptics X driver. I don't know enough about the XO-1.5 hardware to say whether you should be using the Synaptics PS/2 protocol. --scott -- ( http://cscott.net/ ) ___ Devel mailing list Devel@lists.laptop.org http://lists.laptop.org/listinfo/devel
Re: Aggressive suspend vs NM/DHCP
On Wed, Oct 20, 2010 at 5:55 PM, Martin Langhoff wrote: > The "right fix" is just what we wanna do for the upstream dev branch, > for the next cycle. Sigh. --scott -- ( http://cscott.net/ ) ___ Devel mailing list Devel@lists.laptop.org http://lists.laptop.org/listinfo/devel
Forwarded developer key request (was Fwd: Internal Server Error)
Forwarded conversation Subject: Internal Server Error From: *Pavel Stržínek* Date: 2010/9/11 To: csc...@laptop.org Hello Scott I'm trying to apply for a developer key for OLPC v1 from Browser activity right on XO device but I'm getting Internal Server Error message. Is it still possible to get the developer key? Is the error just a temporary situation on server or some problem on my device? Thank you for your answers, Regards Pavel Strzinek -- From: *Pavel Stržínek* Date: 2010/9/11 To: csc...@laptop.org Additional XO info: serial number: CSN74701271 Build: 802 Sugar: 0.82.1 Firmware: Q2E41 Pavel Strzinek -- ( http://cscott.net/ ) ___ Devel mailing list Devel@lists.laptop.org http://lists.laptop.org/listinfo/devel
Re: [IAEP] "Mesh" Dreams = OLSR
I'm not 100% certain we've pulled in members of the OLSR mailing lists on this thread yet. But they've actually got a number of very impressive *real world* demonstrations of OLSRd in the wild. You'll have to search the devel@ archives for 'olsr' to find the emails I sent years ago with all the details. Granted, I don't know that they've demonstrated the software scaling out to distributed notes *and* in to 100 laptops in a single room w/o any manual tweaking. They can best tell you about that themselves. But OLSR is a much more appropriate and much less "pixie dust" solution than 802.11s ever was/is/will be. I think the primary challenge is social -- isn't it always? The OLSRd guys have to get passionate about making their stuff work on XOs, and enough deployments have to be adventuresome (and desperate) enough to give them a testbed to iron out all the kinks. But I think it's a worthwhile "management" challenge for someone to attempt. Because what's needed is leadership, managing the resources, linking person A to person B, driving it to release/ship, and a little bit of inspiring the troops. The technical challenges are much less hard. (And it's probably an "outside OLPC" project, at least initially, because OLPC can't afford to devote any resources to it.) --scott ps. technical challenges: making it bulletproof and brainless, seamless scalability from lots of laptops in a tight space to a few laptops spread out, and (eventually) processor-independent operation on the marvel microcontroller to allow sustaining the mesh at very low power levels. ___ Devel mailing list Devel@lists.laptop.org http://lists.laptop.org/listinfo/devel
Re: SD/MMC cards, a year later
On Thu, Aug 19, 2010 at 11:24 AM, John Watlington wrote: > Our experiment with SD/MMC cards as main storage continues. FWIW, I'm about two weeks into failure testing of 4G MLC compact flash from a couple of vendors. I'll update the list when one or both of them kick the bucket. Is OLPC looking at SD rather than CF for price, speed, form factor, or other reasons? --scott -- ( http://cscott.net/ ) ___ Devel mailing list Devel@lists.laptop.org http://lists.laptop.org/listinfo/devel
Re: [IAEP] Redesigning: Library, Read, Get-Books, and Content bundles
On Tue, Jul 20, 2010 at 2:33 PM, Reuben K. Caron wrote: > deployments that would like to install content bundles. They package > these files into .xol packages and these packages get installed into > the "Library," which is contained on the left hand side of the Browse > activity. Yes, you read that correctly..."the BROWSE activity," an > activity intended for online exploration is used to view offline > content. Every deployment that I have shown this to has found it very > unintuitive. Consider another example: You want to use Get-Books to The original goal was to blur the boundary between offline and online as much as possible. You would have a large-ish cache of "online" material available "offline" -- including not only your textbooks, but also many other web sites or educational resources. Updating a textbook would be as easy as updating the "online" source of that textbook, and the "offline" copy would get updated from that. Surfing while "offline" to a page which was not available in the offline cache would create a request for that content, which would be fetched when you are next "online", or added to a queue for your teacher to fetch next time they travelled to a place with internet access. This is a pretty straightforward extension of the wwwoffle program, but the necessary tuits to integrate all the pieces never appeared. Anyway, that's just to say that there was justification once for putting library content in Browse. Don't know if that justification still applies. --scott -- ( http://cscott.net/ ) ___ Devel mailing list Devel@lists.laptop.org http://lists.laptop.org/listinfo/devel
Re: 10.1.1 and os300 -- DPI vs fontsizes on FF vs Browse.xo
On Tue, Jul 13, 2010 at 1:47 PM, Martin Langhoff wrote: > I was aware that maybe we had different in scaling/dpi on our > browsers, but Aliosh (from the Perú team) pointed out how large the > difference is between Firefox and Browse.xo: > > Here shown between an XO-1.5 on 10.1.1 and an XO-1 on os300, both > showing wiki.laptop.org: > http://dev.laptop.org/~martin/IMG_20100713_133515.jpg > > Browse shows smaller type than on 802 builds (where we were patching > xulrunner to hardcode 133 dpi...). FF shows things _huge_. > > - Are we doing anything explicit with DPI on the Sugar side? (AFAIK, > we dropped the xulrunner patch... grepping Browse.xo itself shows > nothing of interest... ) > > - Are we doing anything with DPI on the Gnome side? Why is FF > super-sizing my internets? You should probably include the preferences from: http://dev.laptop.org/git/activities/firefox-activity/tree/vendor.js --scott -- ( http://cscott.net/ ) ___ Devel mailing list Devel@lists.laptop.org http://lists.laptop.org/listinfo/devel
Re: [IAEP] Announce: OLPC software strategy.
It may be worth looking at http://trac.edgewall.org/roadmap for how the trac team itself uses it. In particular, if you check the "Show completed milestones" box, and then on some old milestone (like, say, http://trac.edgewall.org/milestone/0.11.3 ) you can drill down into any component and see what bug fixes it contained. FWIW, at litl we use two fixed milestones for "Future" (stuff we're likely to do in the next release or two) and "Far Future" (stuff we'd really like to do, but admit isn't going to happen any time soon). At the beginning of each release cycle, we mine the Future and Far Future milestones for stuff we expect to include in our next release, and then close/move those bugs as the release approaches. (We don't use trac, but the methodology is similar.) --scott -- ( http://cscott.net/ ) ___ Devel mailing list Devel@lists.laptop.org http://lists.laptop.org/listinfo/devel
Re: [Sugar-devel] Announce: OLPC software strategy.
On Thu, Jul 8, 2010 at 3:49 PM, Chris Ball wrote: > > What about the compiler? IIUC currently a commercial compiler is > > required. If that continues to be the case (as I expect it to), > > would it be possible for OLPC to provide the (probably very few) > > users interested in hacking on the EC code access to a machine > > having this compiler installed? I.e. does the license OLPC has > > for this compiler allow more than one user (on the same machine) > > to use it (if necessary sequentially, ensured by using a lock > > file) and would OLPC be willing to give users access to such a > > machine? > > Good news here too: we've moved to the free SDCC compiler, so there > should be no problem here. I don't know full details, but there have > been some incompatibilities seen between SDCC and the EC code in the > past, so staying with SDCC is going to be conditional on being able > to find a way around those. SDCC is the plan, though. > > For more questions, I think we should move to the OLPC devel list, > and I'll let Richard Smith answer because this is his project. :) If I understand correctly, the biggest problem is that SDCC lets you reserve a variable at a specific address, but that *doesn't* prevent it from using that address for its own automatically-allocated variables. This is probably just a linker issue, to detect the overlapping address assignments -- although if you wanted the compiler to allocate "with holes", that's a compiler issue. The SDCC source code is very hackable. This might be something a volunteer could address at the compiler level. The alternative is to very very very carefully read through the legacy EC code to try to ferret out (and somehow correct) any such conflicts. --scott -- ( http://cscott.net/ ) ___ Devel mailing list Devel@lists.laptop.org http://lists.laptop.org/listinfo/devel
Re: Removing RTC from Theft-Deterrence
On Wed, Jul 7, 2010 at 6:54 PM, John Watlington wrote: > > On Jul 7, 2010, at 5:07 PM, James Cameron wrote: > >> On Wed, Jul 07, 2010 at 04:57:19PM -0400, C. Scott Ananian wrote: >>> Unfortunately, the software changes required are to EC code, which is >>> difficult for outside contributors to work on. >> >> Yeah, that would be good to change. > > Have you forgotten that Richard and I have been working > to get that changed for XO-1.75 ? Or did we forget to report it ? I hope that XO-1.75 will also have space for a small serial flash on the motherboard then. =) --scott -- ( http://cscott.net/ ) ___ Devel mailing list Devel@lists.laptop.org http://lists.laptop.org/listinfo/devel
Re: USB2VGA adapters on XO-1.5 (and XO-1 with F11 images)
On Fri, Jul 2, 2010 at 4:53 PM, Martin Langhoff wrote: > - It is slow and laggy. A VNC protocol expert may be able to help us > optimise... Might try some of the VNC encoding options, like those at: http://www.realvnc.com/products/free/4.1/winvncviewer.html#ColorEncoding Assuming you're using a Unix domain or localhost socket, the "raw" encoding might be best, with # colors matched to the source/dest. > - If you look carefully, the mirror session has a small square cursor > in the middle of the screen. We need a variant on > http://wiki.x.org/wiki/AdvancedTopicsFAQ#Iwanttomakethemousecursorinvisible > but I could not make it work. Given how the technique works, I think > vncviewer is overriding the root window cursor. This is a feature of vnc -- since the "remote system" cursor may lag your local cursor, VNC represents your local cursor with a small box, so that any mismatch between local and remote cursors is obvious and visible. The "UseLocalCursor" option to VNC should affect this. (You also might want to look into AutoReconnect.) I'm using the names of the options in the "official" vnc viewer, but I think the open source ones have the same options, maybe spelled somewhat differently. --scott -- ( http://cscott.net/ ) ___ Devel mailing list Devel@lists.laptop.org http://lists.laptop.org/listinfo/devel
Re: Removing RTC from Theft-Deterrence
On Wed, Jul 7, 2010 at 4:01 PM, C. Scott Ananian wrote: > * Updating exactly every hour is vulnerable to an attacker who > arranges to remove the battery from the machine exactly 55 minutes > after power on, every time. This is still quite awkward, but to avoid > even this attack, the EC can pseudo-randomly decide exactly when to > update the EC based on a random seed passed in from OFW from the > Geode's HWRNG, with an *average* interval of an hour. We probably > don't have to perform this extra trickery if we just shorten the > interval to 6 minutes or so, but the means that the EC's EEPROM will > wear out at the end of the 5 year service life of the machine. We can > probably detect this condition (EEPROM no longer writes reliably) and > just disable passive kill security at this point, though, which might > be nice for freedom-loving reasons. 2010 thoughts: I like the idea of pseudo-random updates. Having a uniform 1/60 probability of update every minute makes powering off as a circumvention mechanism pointless, while reducing EEPROM writes. A very simple linear feedback shift register for generating pseudo-random bits would be sufficient, since the inputs and outputs of the system are hidden. --scott -- ( http://cscott.net/ ) ___ Devel mailing list Devel@lists.laptop.org http://lists.laptop.org/listinfo/devel
Re: [Sugar-devel] Activity packaging
On Wed, Jul 7, 2010 at 2:16 AM, Aleksey Lim 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 >> still >> received no independent testing despite repeated calls for same. >> >> Rainbow, on the other hand, has seen a major new release, feature development >> that spurred new work in general Linux sandboxing, and is now available in >> more >> distributions than ever before thanks to dedicated support by folks like >> Luke, >> Sascha, and Jonas. >> >> Finally, if rainbow itself now receives little day-to-day attention, this is >> because it mostly does what its authors require and it does it well enough >> not >> to require their continued hand-holding. > > 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 - compile on demand is a regular workflow within > 0install (existed sugar doesn't not let such possibility:), rainbow should > be more then essential requirement. I took some time to read up on 0install -- very impressive technology, good work. I agree with Michael that this (userland installs) is the direction Sugar should be pursuing. With rainbow (or other sandbox) integration, this would accomplish all of the original goals with a much more robust packaging and dependency system than the .xo bundle. --scott -- ( http://cscott.net/ ) ___ Devel mailing list Devel@lists.laptop.org http://lists.laptop.org/listinfo/devel
Re: Removing RTC from Theft-Deterrence
On Wed, Jul 7, 2010 at 4:48 PM, John Watlington wrote: > On Jul 7, 2010, at 4:01 PM, C. Scott Ananian wrote: > >> Since "RTC security" is being discussed again, I'm going to repost two >> relevant proposals from "the good old days". First: on making >> theft-deterrence a "feature"; then technical details of a $0.16 change >> to remove RTC dependence from the theft-deterrence feature. >> Unfortunately, the specific circuit changes required are XO-1 >> specific; presumably some slightly different version is needed for XO >> 1.5, XO 1.75, etc. I vaguely remember wad saying he managed to make >> this change in hardware at some point; I don't know if corresponding >> software was ever written. > > The EEPROM needed for this was included in early XO-1.5 prototypes, > but was dropped from production due to the lack of software making use > of it. It could be added back to any XO-1.5 SKU for a slight cost increase. Unfortunately, the software changes required are to EC code, which is difficult for outside contributors to work on. (Also some OFW work, but that's available and easily hackable.) --scott -- ( http://cscott.net/ ) ___ Devel mailing list Devel@lists.laptop.org http://lists.laptop.org/listinfo/devel
Re: [Sugar-devel] Clocks on XOs
On Sat, Jul 3, 2010 at 9:54 AM, Bernie Innocenti wrote: >> NetworkManager used to call ntpdate when it setup a connection. Was that an >> OLPC addition? Yes, although it's now present in litl's software builds as well. > We figured out that the ntp package has never been present on the XO > images. It was ntpdate, which was smaller than the whole ntp package. > There's no way to practical way to implement effective anti-theft > without taking away root from the user. And once we take away root > access, we've also taken away olpc's principle #1: child ownership. See my recent message on this topic. Apart from the hardware fix (which avoids RTC dependency altogether), it is also possible to separate most of root's authority from the RTC priviledge. Installing software, for example, requires root access to the filesystem, but not access to the RTC. >> What are the school servers doing to keep their clocks reasonable? > > They're using ntp, with the Fedora pool of ntp servers. You should probably apply for your own pool: http://www.pool.ntp.org/en/vendors.html#open-source It's pretty painless, and makes you a better netizen. >> > Why aren't we using ntp? >> >> ntp is probably overkill for XOs. Besides, who would want to give up that >> much ram? On top of that, ntpd doesn't get along with power saving mode. That's why you use ntpdate. --scott -- ( http://cscott.net/ ) ___ Devel mailing list Devel@lists.laptop.org http://lists.laptop.org/listinfo/devel
Removing RTC from Theft-Deterrence
Since "RTC security" is being discussed again, I'm going to repost two relevant proposals from "the good old days". First: on making theft-deterrence a "feature"; then technical details of a $0.16 change to remove RTC dependence from the theft-deterrence feature. Unfortunately, the specific circuit changes required are XO-1 specific; presumably some slightly different version is needed for XO 1.5, XO 1.75, etc. I vaguely remember wad saying he managed to make this change in hardware at some point; I don't know if corresponding software was ever written. Note that the principle here is that OFW and the EC are the only "protected code" in the system, and the only pieces which must be protected from unauthorized update/modification. The EC is a separate processor running its program independent of OS interference, and so is the perfect place "on which to stand" to implement a security system. Computation capabilities in the EC are limited, so any lease validation, cryptography, etc, is done in OFW on the main processor in the protected run time before the OS boots. Once the OS boots we don't expect any additional trusted computation to be done on the main processor. --scott -- Forwarded message -- From: C. Scott Ananian Date: Fri, Oct 17, 2008 at 3:11 PM Subject: 9.1 Proposal: Improving antitheft To: Devel List , sugar I'd like our antitheft support to be more of a "feature" which G1G1 users could elect to enable, if they like. This involved making it much more visible and configurable, most likely putting it in the control panel. The idea is if you are taking a trip or leaving home for a few days, you could "turn on theft-deterrence" before you go, get some added tracking/remote-kill features, and then turn it off later when you get home. Other topics: * ECO fix and EC improvements * Security control panel, with "am I stolen" and lease renewal buttons: ticket #1502, ticket #6428 * olpcrd work: ticket #7397 * Revoke root capabilities when booted with security enabled: ticket #7562 --scott -- Forwarded message -- From: C. Scott Ananian Date: Tue, Jul 15, 2008 at 1:40 PM Subject: Re: EC EEPROM security mod. To: John Watlington , Richard Smith , techteam Context for tech team: working on a minimal hardware fix that would provide enough "protected real-time clock" functionality that we could enable root and still believe in passive kill for theft-deterrence. Proposed hardware ECO: a) depopulate D31 b) add Microchip 24LC00T/OT (SOT-23 package), wiring: pin 1 (SCL) to SPIWP# (EC GPIOEC) pin 2 (Vss) to ground pin 3 (SDA) to EC_WP# (EC GPIOE0) pin 4 is n/c pin 5 (Vcc) to 3VPCU The 24LC00 part is less than $0.16 in quantity (maybe less from a Chinese source, there are lots of equivalent parts), some tiny fraction of which would be recouped by eliminating D31. This gives us 128 bits of nonvolatile storage accessible only via the EC. We use this to backstop the RTC to prevent clock replay attacks as follows: * At boot time, OFW asks the EC to read the EEPROM and takes max(RTC time, EC time) as its notion of "current time" when evaluating the validity of leases. [2010 edit: may want to completely ignore RTC instead, so that lease isn't shortened by accidentally setting RTC ahead too far in the future.] * At the point where OFW disables writes to the SPI flash, it also asks the EC to write the calculated "current time" back to its own EEPROM. Writes to the EEPROM after this point are disabled. * About once an hour (although it can be as frequently as every six minutes and still stay within the rated erase cycles of the EEPROM) the EC increments the EEPROM's value of time with its own notion of how much time has passed. We will probably deliberately calibrate this to be just shy of "real time" so the EC clock never runs faster than real time. (Details below.) The EEPROM is not accessible except via the EC, and no kernel commands can cause the EC to either avoid updating or misupdate its internal EEPROM. This allows us to give root priviledges to code running on the main processor without affecting the security of the passive kill system, addressing the major weakness in the current system. Lease times are more properly thought of in terms of "powered up time", not "real time", but they still perform their intended purpose. In my copious free time, I'll try to perform this ECO on a spare machine and hack up some EC code to drive it to prove the concept. --scott Details for the strong-hearted: * Updating exactly every hour is vulnerable to an attacker who arranges to remove the battery from the machine exactly 55 minutes after power on, every time. This is still quite awkward, but to avoid even this attack, the EC can pseudo-randomly decide
Re: NetworkManager time sync
On Wed, Jul 7, 2010 at 12:20 PM, Martin Langhoff
wrote:
> On Mon, Jul 5, 2010 at 11:52 PM, Daniel Drake wrote:
>> While we have your attention on this topic...
>> Do you not think that this is a security issue? In that a thief could
>> put a laptop on a network with rigged DNS and have control over the
>> time/date on the laptop?
>
> We *really* have to get OFW clock checks working -- then this
> disappears as an issue. I really want to be able to use ntp (at least
> ntpdate on NM successful connect). The OATS clock sync is very rough
> -- on purpose.
I believe my proposal was to use OFW protected execution to replace
"trust the RTC clock" -- which is pretty daft, even if theoretically
vserver would let you isolate that priviledge domain -- with having
OFW keep a monotonically increasing counter of CPU time (not "real
time"). Theft-deterrence leases would be then good for a certain
amount of CPU time, and you can screw with your RTC all you like.
("CPU time" is also guaranteed to increase by some amount on every
boot, so the lease also roughly limits "number of boots".)
I think wad said he managed to squeeze the hardware to enable this
into the latest generation, but I don't know if the support was ever
fully integrated. It's mostly a OFW/EC hack, since all the privileged
code is removed from the OS in this case.
--scott
--
( http://cscott.net/ )
___
Devel mailing list
Devel@lists.laptop.org
http://lists.laptop.org/listinfo/devel
