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
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: 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
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
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 qu...@laptop.org 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
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 purpleairpl...@gmail.com Date: Nov 24, 2013 12:00 PM Subject: XO Problems (4 Problems) To: csc...@cscott.net 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
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
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
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 cjlhomeaddr...@gmail.com wrote: On Wed, Sep 5, 2012 at 6:58 PM, Mikus Grinbergs mi...@bga.com 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 jvo...@shaw.ca 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 martin.langh...@gmail.com wrote: On Sat, Aug 25, 2012 at 2:26 PM, C. Scott Ananian csc...@laptop.org 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 greenf...@laptop.org 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
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
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
Re: XO-1.75 OpenFirmware serial terminal
On Wed, Mar 28, 2012 at 10:44 PM, John Watlington w...@laptop.org 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
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: 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 b...@freudenbergs.de 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 sve...@sfsu.edu 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 martin.langh...@gmail.comwrote: On Wed, Jun 13, 2012 at 11:37 AM, Lester Leong lester.ble...@gmail.com 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 lester.ble...@gmail.comwrote: 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
On Tue, Jun 12, 2012 at 4:16 AM, Chris Ball c...@laptop.org 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
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 gonz...@laptop.org 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
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 martin.langh...@gmail.com 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, fors...@ozonline.com.au 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
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 g...@toad.com 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 alan.n...@yahoo.com 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, moku...@earthtreasury.org 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 echer...@gmail.com Date: Sat, May 21, 2011 at 22:10 Subject: Re: [Sur] linux system por $25 To: Eben Upton eben.up...@gmail.com On Sat, May 21, 2011 at 12:22, Eben Upton eben.up...@gmail.com 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 echer...@gmail.com 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 sdaly...@gmail.com Date: Fri, May 6, 2011 at 11:28 Subject: Re: [Sur] linux system por $25 To: OLPC para usuarios, docentes, voluntarios y administradores olpc-...@lists.laptop.org Cc: Gleducar gledu...@gleducar.org.ar http://lists.sugarlabs.org/archive/marketing/2011-May/003273.html On Fri, May 6, 2011 at 5:23 PM, Daniel Ajoy da.a...@gmail.com wrote: linux system por $25 http://www.raspberrypi.org/ -- Edward Mokurai (#40664;#38647;/#2343;#2352;#2381;#2350;#2350;#2375;#2328;#2358;#2348;#2381;#2342;#2327;#2352;#2381;#2332;/#1583;#1726;#1585;#1605;#1605;#1740;#1711;#1726;#1588;#1576;#1583;#1711;#1585; #1580;) 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
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: Turtles All The Way Down
2011/5/20 NoiseEHC noise...@freemail.hu: 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
Re: [IAEP] Turtles All The Way Down
On Fri, May 20, 2011 at 11:09 AM, Alan Kay alan.n...@yahoo.com 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: [IAEP] Turtles All The Way Out
On Fri, May 20, 2011 at 2:28 PM, John Gilmore g...@toad.com 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: The next four weeks
On Tue, Apr 12, 2011 at 1:56 PM, C. Scott Ananian csc...@laptop.org wrote: On Mon, Apr 4, 2011 at 6:09 PM, C. Scott Ananian csc...@laptop.org 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 qu...@laptop.org 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 elia...@mindspring.com 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 Mon, Apr 4, 2011 at 6:09 PM, C. Scott Ananian csc...@laptop.org 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
2011/4/12 NoiseEHC noise...@freemail.hu: 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 Tue, Apr 12, 2011 at 5:45 PM, Peter Robinson pbrobin...@gmail.com 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
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
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
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
Re: Possible XO Graphics Optimization Technique
On Apr 1, 2011 11:03 AM, Samuel Greenfeld greenf...@laptop.org 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 christoph.derndor...@gmail.com 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 pbrobin...@gmail.com wrote: On Wed, Mar 23, 2011 at 11:38 PM, John Gilmore g...@toad.com 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
On Mon, Mar 21, 2011 at 1:52 AM, C. Scott Ananian csc...@laptop.org wrote: On Mon, Mar 21, 2011 at 1:01 AM, Daniel Drake d...@laptop.org wrote: On 19 March 2011 17:16, Daniel Drake d...@laptop.org 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
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 d...@laptop.org wrote: On 13 March 2011 03:21, Samuel Greenfeld greenf...@laptop.org 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: Memory replacement
On Sun, Mar 13, 2011 at 8:57 AM, Andrei Warkentin andr...@motorola.com 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: Memory replacement
On Sun, Mar 13, 2011 at 1:00 PM, C. Scott Ananian csc...@laptop.org wrote: On Sun, Mar 13, 2011 at 8:57 AM, Andrei Warkentin andr...@motorola.com 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: Discovering the XOs local timezone in a bash script
On Sun, Mar 13, 2011 at 1:04 PM, Sascha Silbe si...@activitycentral.com 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
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: Memory replacement
On Sat, Mar 12, 2011 at 5:51 PM, Arnd Bergmann a...@arndb.de 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: 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: 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 srid...@laptop.org.au 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: [OLPC-AU] XO-1 developer key does not work
On Sat, Mar 12, 2011 at 2:16 AM, Mikus Grinbergs mi...@bga.com 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: 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
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 isolated my CCNx network is just
Re: Proposal for new frozen repositories server
On Sun, Feb 6, 2011 at 7:29 AM, Daniel Drake d...@laptop.org 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 object...@gmail.com 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 qu...@laptop.org 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 d...@laptop.org wrote: On 24 November 2010 22:40, Kevin Gordon kgordon...@gmail.com 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 sascha-ml-reply-to-201...@silbe.org 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?
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: 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 d...@laptop.org wrote: On 22 November 2010 16:41, Martin Langhoff martin.langh...@gmail.com 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?
On Mon, Nov 22, 2010 at 6:43 PM, Mikus Grinbergs mi...@bga.com 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: Notes on conventional desktop tools
On Thu, Nov 18, 2010 at 2:48 PM, Martin Langhoff martin.langh...@gmail.com 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: Notes on conventional desktop tools
On Thu, Nov 18, 2010 at 3:41 PM, Martin Langhoff martin.langh...@gmail.com wrote: On Thu, Nov 18, 2010 at 3:08 PM, C. Scott Ananian csc...@laptop.org 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
Fwd: Upgrading a _very_ old OLPC
-- Forwarded message -- From: Krishnan R.S. rskrish...@hotmail.com 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: 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
Re: XO-1.5 audio input DC mode
On Wed, Nov 17, 2010 at 2:46 PM, C. Scott Ananian csc...@laptop.org 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: Re: XO-1.75 microphone socket
On Tue, Nov 16, 2010 at 11:38 AM, Walter Bender walter.ben...@gmail.com wrote: On Tue, Nov 16, 2010 at 11:19 AM, C. Scott Ananian csc...@laptop.org wrote: On Mon, Nov 15, 2010 at 4:19 PM, fors...@ozonline.com.au 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: 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 d...@laptop.org wrote: On 28 October 2010 15:54, Martin Langhoff martin.langh...@gmail.com 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 martin.langh...@gmail.com 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* strzi...@edhouse.cz 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* strzi...@edhouse.cz 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 w...@laptop.org 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 reu...@laptop.org 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 martin.langh...@gmail.com 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 c...@laptop.org 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: NetworkManager time sync
On Wed, Jul 7, 2010 at 12:20 PM, Martin Langhoff martin.langh...@gmail.com wrote: On Mon, Jul 5, 2010 at 11:52 PM, Daniel Drake d...@laptop.org 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
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 csc...@laptop.org Date: Fri, Oct 17, 2008 at 3:11 PM Subject: 9.1 Proposal: Improving antitheft To: Devel List de...@laptop.org, sugar su...@lists.laptop.org 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 csc...@laptop.org Date: Tue, Jul 15, 2008 at 1:40 PM Subject: Re: EC EEPROM security mod. To: John Watlington w...@laptop.org, Richard Smith rich...@laptop.org, 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 exactly when to update the EC based on a random seed passed in from OFW from the Geode's HWRNG
Re: [Sugar-devel] Clocks on XOs
On Sat, Jul 3, 2010 at 9:54 AM, Bernie Innocenti ber...@codewiz.org 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
Re: Removing RTC from Theft-Deterrence
On Wed, Jul 7, 2010 at 4:48 PM, John Watlington w...@laptop.org 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] Activity packaging
On Wed, Jul 7, 2010 at 2:16 AM, Aleksey Lim alsr...@member.fsf.org 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:01 PM, C. Scott Ananian csc...@laptop.org 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: USB2VGA adapters on XO-1.5 (and XO-1 with F11 images)
On Fri, Jul 2, 2010 at 4:53 PM, Martin Langhoff martin.langh...@gmail.com 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 6:54 PM, John Watlington w...@laptop.org 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: NetworkManager time sync
On Mon, Jul 5, 2010 at 9:03 AM, Bernie Innocenti ber...@codewiz.org wrote: On Mon, 2010-07-05 at 10:33 +0200, Tomeu Vizoso wrote: You mean a script placed in /etc/NetworkManager/dispatcher.d/ ? Yes, and then invoke hwclock --systohc. I was just hoping to find something already written, tested and packaged nicely so we could use it both on the XO and SoaS. I wrote that script when I was at OLPC. It should still be packaged somewhere. --scott -- ( http://cscott.net/ ) ___ Devel mailing list Devel@lists.laptop.org http://lists.laptop.org/listinfo/devel
Re: NetworkManager time sync
On Mon, Jul 5, 2010 at 8:33 PM, Bernie Innocenti ber...@codewiz.org wrote: On Mon, 2010-07-05 at 20:30 -0400, C. Scott Ananian wrote: I wrote that script when I was at OLPC. It should still be packaged somewhere. I see olpc-update-ifup in my builds, but nothing related to ntpdate. Do you remember if it was part of olpc-utils or olpc-update? Maybe someone's got a copy of build 653 lying around and they can run rpm -q for us. --scott -- ( http://cscott.net/ ) ___ Devel mailing list Devel@lists.laptop.org http://lists.laptop.org/listinfo/devel
Re: NetworkManager time sync
On Mon, Jul 5, 2010 at 11:52 PM, Daniel Drake d...@laptop.org wrote: On 5 July 2010 21:44, C. Scott Ananian csc...@laptop.org wrote: Maybe someone's got a copy of build 653 lying around and they can run rpm -q for us. 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? A sane security system would let the user control their local time, without jeopardizing security based on server (or firmware) time. --scott -- ( http://cscott.net/ ) ___ Devel mailing list Devel@lists.laptop.org http://lists.laptop.org/listinfo/devel
Re: New keyboard layouts
On Wed, Apr 28, 2010 at 5:19 PM, James Cameron qu...@laptop.org wrote: Australian teachers that I've met have pointed out that their kids are primarily taught lowercase letters, and would prefer a keyboard to be marked with lowercase letters rather than uppercase letters. Not having looked at the key legends for about 28 years, I was surprised. ;-) What a fascinating idea. +1. The litl webbook's keyboard, FWIW, is labelled with lowercase letters. I always thought that was something that OLPC didn't quite get right. Young kids are surprised when the letter they press doesn't match what shows up on the screen. Lowercase looks nice and friendly, too. OTOH, this keyboard is meant for older students, so maybe it's not as big a deal. --scott -- ( http://cscott.net/ ) ___ Devel mailing list Devel@lists.laptop.org http://lists.laptop.org/listinfo/devel
Re: multi-touch
On Tue, Jun 8, 2010 at 4:20 AM, Carlos Nazareno object...@gmail.com wrote: If possible, go for a minimum of 5 touch points capability, which is what Apple has I think. Apple actually supports 11 on the iPad. Palm and the iPhone support 5. http://daringfireball.net/linked/2010/05/10/gemmell-multitouch --scott -- ( http://cscott.net/ ) ___ Devel mailing list Devel@lists.laptop.org http://lists.laptop.org/listinfo/devel
Re: Touchscreen requirements
On Tue, Jun 8, 2010 at 9:23 AM, John Watlington w...@laptop.org wrote: An interesting effect I've noticed is that with some touchscreen, you get smooth lines when moving your finger at a normal speed, say 8 cm/s, but when you slow down (1 cm/s) the line wiggles around. See http://labs.moto.com/robot_touchscreen_analysis/ Strength of touch also matters a great deal, and there's quite a bit of fudging being done in the hardware tracking algorithms. --scott -- ( http://cscott.net/ ) ___ Devel mailing list Devel@lists.laptop.org http://lists.laptop.org/listinfo/devel
Re: Touchscreen requirements
On Tue, Jun 8, 2010 at 11:14 PM, John Watlington w...@laptop.org wrote: The mini cocktail wieners I'm familiar with are still around 8-10mm. I guess I could carve one down and wrap it in plastic... Gummy fingers are more fun: http://cryptome.info/0001/gummy/gummy.htm --scott -- ( http://cscott.net/ ) ___ Devel mailing list Devel@lists.laptop.org http://lists.laptop.org/listinfo/devel