Sorry

This feed does not validate.

In addition, interoperability with the widest range of feed readers could be improved by implementing the following recommendations.

Source: http://cananian.livejournal.com/data/rss?tag=olpc

  1. <?xml version='1.0' encoding='utf-8' ?>
  2. <!--  If you are running a bot please visit this policy page outlining rules you must respect. https://www.livejournal.com/bots/  -->
  3. <rss version='2.0'  xmlns:lj='http://www.livejournal.org/rss/lj/1.0/' xmlns:media='http://search.yahoo.com/mrss/' xmlns:atom10='http://www.w3.org/2005/Atom'>
  4. <channel>
  5.  <title>Dr. C. Scott Ananian</title>
  6.  <link>https://cananian.livejournal.com/</link>
  7.  <description>Dr. C. Scott Ananian - LiveJournal.com</description>
  8.  <lastBuildDate>Sun, 21 Oct 2012 22:51:05 GMT</lastBuildDate>
  9.  <generator>LiveJournal / LiveJournal.com</generator>
  10.  <lj:journal>cananian</lj:journal>
  11.  <lj:journalid>123187</lj:journalid>
  12.  <lj:journaltype>personal</lj:journaltype>
  13.  <image>
  14.    <url>https://l-userpic.livejournal.com/11312513/123187</url>
  15.    <title>Dr. C. Scott Ananian</title>
  16.    <link>https://cananian.livejournal.com/</link>
  17.    <width>100</width>
  18.    <height>100</height>
  19.  </image>
  20.  
  21.  <item>
  22.  <guid isPermaLink='true'>https://cananian.livejournal.com/67703.html</guid>
  23.  <pubDate>Sun, 21 Oct 2012 22:51:05 GMT</pubDate>
  24.  <title>Reading Project Talk (and slides)</title>
  25.  <author>cananian</author>
  26.  <link>https://cananian.livejournal.com/67703.html</link>
  27.  <description>&lt;p&gt;An unruly tag team of OLPC folks gave a long talk on &lt;a href=&quot;http://wiki.laptop.org/go/Literacy_Project&quot; target=&quot;_blank&quot;&gt;the Literacy Project&lt;/a&gt; today for attendees at this year&apos;s &lt;a href=&quot;http://www.olpcsf.org/CommunitySummit2012&quot; target=&quot;_blank&quot;&gt;OLPC-SF Community Summit&lt;/a&gt;.  It was streamed live on Ustream: &lt;a href=&quot;http://www.ustream.tv/recorded/26344794&quot; target=&quot;_blank&quot;&gt;Part 1&lt;/a&gt; (Matt Keller, Richard Smith), &lt;a href=&quot;http://www.ustream.tv/recorded/26345580&quot; target=&quot;_blank&quot;&gt;Part 2&lt;/a&gt; (Richard Smith, Ed McNierney, C. Scott Ananian, Chris Ball, questions from the audience).  We&apos;ve posted the slides: &lt;a href=&quot;http://dev.laptop.org/~cscott/literacy-public/Keller-Reading.ppt&quot; target=&quot;_blank&quot;&gt;Matt Keller&lt;/a&gt;, &lt;a href=&quot;https://docs.google.com/presentation/d/18S9eSMMZeCxiCRxXZl4VgVAxQFTLIWQCOkO2GVGjk8g/edit&quot; target=&quot;_blank&quot;&gt;Richard Smith&lt;/a&gt;, &lt;a href=&quot;https://docs.google.com/presentation/d/1CSJBu_11YKc_3H20Zi5maDPym9tcYo7gdmK9Hj1Wc30/edit&quot; target=&quot;_blank&quot;&gt;C. Scott Ananian&lt;/a&gt;.&lt;/p&gt;
  28.  
  29. &lt;p&gt;You can try out some of the apps mentioned in the talk.  &lt;a href=&quot;http://nell-balloons.github.cscott.net&quot; target=&quot;_blank&quot;&gt;Nell&apos;s Balloons&lt;/a&gt; and &lt;a href=&quot;http://nell-colors.github.cscott.net&quot; target=&quot;_blank&quot;&gt;Nell&apos;s Colors&lt;/a&gt; will run in any reasonably-recent Google Chrome or Mozilla Firefox browser.  They will also run as a &lt;a href=&quot;https://marketplace.mozilla.org/developers/&quot; target=&quot;_blank&quot;&gt;Firefox webapp&lt;/a&gt; on Android devices, using the &lt;a href=&quot;http://nightly.mozilla.org/&quot; target=&quot;_blank&quot;&gt;latest Firefox nightly for Android&lt;/a&gt;.  For deployment we use a slightly-tweaked build of Firefox (adding expanded webapp storage quotas and the ability to use plugins from inside webapps), and a &lt;a href=&quot;https://github.com/cscott/intent-addon&quot; target=&quot;_blank&quot;&gt;custom plugin&lt;/a&gt; to hook up the &lt;a href=&quot;http://funf.org/&quot; target=&quot;_blank&quot;&gt;Funf logging framework&lt;/a&gt;.  Source code is available on github: &lt;a href=&quot;http://github.com/cscott/nell-balloons&quot; target=&quot;_blank&quot;&gt;nell-balloons&lt;/a&gt;; &lt;a href=&quot;http://github.com/cscott/nell-colors&quot; target=&quot;_blank&quot;&gt;nell-colors&lt;/a&gt;.  In addition, Chris Ball&apos;s &quot;Matching&quot; app for Android is available: &lt;a href=&quot;http://dev.laptop.org/~cscott/literacy-public/Matching-1.4.0.apk&quot; target=&quot;_blank&quot;&gt;apk&lt;/a&gt;; &lt;a href=&quot;http://dev.laptop.org/git/users/cjb/android-matching/&quot; target=&quot;_blank&quot;&gt;source&lt;/a&gt;.&lt;/p&gt;</description>
  30.  <comments>https://cananian.livejournal.com/67703.html?view=comments#comments</comments>
  31.  <category>javascript</category>
  32.  <category>sugar</category>
  33.  <category>olpc</category>
  34.  <category>nell</category>
  35.  <category>android</category>
  36.  <lj:security>public</lj:security>
  37.  <lj:reply-count>3</lj:reply-count>
  38.  </item>
  39.  <item>
  40.  <guid isPermaLink='true'>https://cananian.livejournal.com/67390.html</guid>
  41.  <pubDate>Wed, 22 Aug 2012 16:29:11 GMT</pubDate>
  42.  <title>The Importance of Sensing Distance</title>
  43.  <author>cananian</author>
  44.  <link>https://cananian.livejournal.com/67390.html</link>
  45.  <description>&lt;p&gt;At &lt;a href=&quot;http://www.dimeb.de/idc2012&quot; target=&quot;_blank&quot;&gt;IDC 2012&lt;/a&gt; in June, Arnan Sipitakiat and Nusarin Nusen discussed how they are using &lt;a href=&quot;http://dx.doi.org/10.1145/2307096.2307108&quot; target=&quot;_blank&quot;&gt;Robo-Blocks&lt;/a&gt;&amp;mdash;a turtle robot and &amp;ldquo;tangible &lt;a href=&quot;http://wiki.sugarlabs.org/go/Activities/Turtle_Art&quot; target=&quot;_blank&quot;&gt;Turtle Blocks&lt;/a&gt;&amp;rdquo;&amp;mdash;to teach problem solving and debugging skills to 5- through 12-year-olds.&lt;/p&gt;
  46.  
  47. &lt;p&gt;One of the things I learned from their presentation was that children had difficulty reasoning about relative angles.  The Robo-Blocks robot does not have any distance feedback on its motors, so &amp;ldquo;the result of a program will change depending on the roughness of the surface and the battery level of the robot.&amp;rdquo;  They worked around this issue by developing a protractor tool to guide the children&apos;s reasoning about the relationship between the (arbitrary) numbers entered and the amount the robot turned, but some kids still had difficulty.  The researchers &amp;ldquo;often had to insist on trying the protractor&amp;rdquo; and &amp;ldquo;some children preferred to keep increasing the turn amount even if a small decrease would have fixed the problem&amp;rdquo; resulting in programs that had the robot making multiple complete rotations before setting off in the correct direction.  The kids were also dissatisfied with polygon-drawing tasks (&amp;ldquo;&lt;a href=&quot;http://en.wikipedia.org/wiki/Turtle_Geometry&quot; target=&quot;_blank&quot;&gt;turtle geometry&lt;/a&gt;&amp;rdquo;) because the inaccuracies of open-loop control of the robot means that the polygons often didn&apos;t close completely, and &amp;ldquo;[t]his small error turned out to be unacceptable to children.&amp;rdquo;&lt;/p&gt;
  48.  
  49. &lt;p&gt;So I designed the XOrduino turtle robot from the start to have distance sensors so that it can do accurate turns with closed-loop control.  Here&apos;s a little video showing how they work in the current (A1.5 / B1) revision of the board:&lt;/p&gt;
  50.  
  51. &lt;lj-embed id=&quot;18&quot; /&gt;
  52.  
  53. &lt;p&gt;Some bonus pictures of the speed sensor on the workbench:&lt;/p&gt;
  54. &lt;ul&gt;
  55. &lt;li&gt;The robot on the workbench with probes.&lt;br /&gt;
  56. &lt;a href=&quot;http://ic.pics.livejournal.com/cananian/123187/2055/original.jpg&quot; target=&quot;_blank&quot;&gt;&lt;img alt=&quot;Speed sensor test setup&quot; border=&quot;0&quot; title=&quot;Speed sensor test setup&quot; src=&quot;https://ic.pics.livejournal.com/cananian/123187/2055/300.jpg&quot; width=&quot;300&quot; fetchpriority=&quot;high&quot; /&gt;&lt;/a&gt;
  57. &lt;/li&gt;
  58. &lt;li&gt;Signal from the motor speed sensor. 5ms/div .5v/div. Motor is running at full speed, unloaded. Two dips are seen: the larger is from a piece of white paper glued to the rim of the gear; the smaller is from a spot made with a white paint marker (the paint didn&apos;t stick very well).  White-out worked much better (as shown in the video above).&lt;br /&gt;
  59. &lt;a href=&quot;http://ic.pics.livejournal.com/cananian/123187/1814/original.jpg&quot; target=&quot;_blank&quot;&gt;&lt;img alt=&quot;Oscilloscope trace&quot; border=&quot;0&quot; title=&quot;Oscilloscope trace&quot; src=&quot;https://ic.pics.livejournal.com/cananian/123187/1814/300.jpg&quot; width=&quot;300&quot; loading=&quot;lazy&quot; /&gt;&lt;/a&gt;
  60. &lt;/li&gt;
  61. &lt;li&gt;Oscilloscope settings&lt;br /&gt;
  62. &lt;a href=&quot;http://ic.pics.livejournal.com/cananian/123187/1575/original.jpg&quot; target=&quot;_blank&quot;&gt;&lt;img alt=&quot;Oscilloscope settings&quot; border=&quot;0&quot; title=&quot;Oscilloscope settings&quot; src=&quot;https://ic.pics.livejournal.com/cananian/123187/1575/300.jpg&quot; width=&quot;300&quot; loading=&quot;lazy&quot; /&gt;&lt;/a&gt;
  63. &lt;/li&gt;
  64. &lt;/ul&gt;</description>
  65.  <comments>https://cananian.livejournal.com/67390.html?view=comments#comments</comments>
  66.  <category>sugar</category>
  67.  <category>olpc</category>
  68.  <category>xorduino</category>
  69.  <category>arduino</category>
  70.  <lj:security>public</lj:security>
  71.  <lj:reply-count>2</lj:reply-count>
  72.  </item>
  73.  <item>
  74.  <guid isPermaLink='true'>https://cananian.livejournal.com/67093.html</guid>
  75.  <pubDate>Sat, 18 Aug 2012 05:13:16 GMT</pubDate>
  76.  <title>XO Turtle Bot drives around</title>
  77.  <author>cananian</author>
  78.  <link>https://cananian.livejournal.com/67093.html</link>
  79.  <description>&lt;p&gt;Here&apos;s a first look at an XOrduino Turtle bot driving around:&lt;/p&gt;
  80. &lt;lj-embed id=&quot;13&quot; /&gt;
  81. &lt;p&gt;I&apos;ve checked out all of the functionality on the A1.5 board except the step-up voltage regulator now.   I&apos;m optimistic the B1 boards (being made now in Taipei) will be clean.&lt;/p&gt;
  82. &lt;p&gt;It will be great when we&apos;ve got lesson plans written up so kids can learn how to control the bot with Turtle Blocks, and play with the different possible behaviors.  Instead of just bumping around (&quot;like a Roomba, except it doesn&apos;t vaccuum&quot; a friendly 6-year-old beta-tester told me), you can trace patterns you design, or use the Scratch Sensor Board sensors to make the robot &quot;afraid of sound&quot;, &quot;attracted to light&quot;, or add your own sensors and behaviors.&lt;/p&gt;</description>
  83.  <comments>https://cananian.livejournal.com/67093.html?view=comments#comments</comments>
  84.  <category>olpc</category>
  85.  <category>xorduino</category>
  86.  <lj:security>public</lj:security>
  87.  <lj:reply-count>0</lj:reply-count>
  88.  </item>
  89.  <item>
  90.  <guid isPermaLink='true'>https://cananian.livejournal.com/66895.html</guid>
  91.  <pubDate>Wed, 15 Aug 2012 20:34:02 GMT</pubDate>
  92.  <title>&quot;Hello, World&quot; from XOrduino/XO Stick</title>
  93.  <author>cananian</author>
  94.  <link>https://cananian.livejournal.com/66895.html</link>
  95.  <description>&lt;p&gt;Here&apos;s a quick look at the next versions of the XOrduino and XO Stick boards.  These were assembled from a small quantity of &quot;pre-B1&quot; boards I had made at &lt;a href=&quot;http://batchpcb.com&quot; target=&quot;_blank&quot;&gt;BatchPCB&lt;/a&gt;.&lt;/p&gt;
  96.  
  97. &lt;lj-embed id=&quot;11&quot; /&gt;
  98.  
  99. &lt;p&gt;I&apos;ve uploaded some more pictures to &lt;a href=&quot;https://plus.google.com/photos/109541946294746531763/albums/5772322118805954321&quot; target=&quot;_blank&quot;&gt;the XOrduino album&lt;/a&gt; as well.&lt;/p&gt;
  100.  
  101. &lt;p&gt;Here&apos;s a little table relating the board versions pictured with those I&apos;ve previously discussed.&lt;/p&gt;
  102. &lt;table&gt;
  103. &lt;tr&gt;&lt;td&gt;Build&lt;/td&gt;&lt;td&gt;XOrduino&lt;/td&gt;&lt;td&gt;XO Stick&lt;/td&gt;&lt;/tr&gt;
  104. &lt;tr&gt;&lt;td&gt;A1&lt;/td&gt;&lt;td&gt;v4&lt;/td&gt;&lt;td&gt;v5&lt;/td&gt;&lt;/tr&gt;
  105. &lt;tr&gt;&lt;td&gt;This video&lt;/td&gt;&lt;td&gt;v6&lt;/td&gt;&lt;td&gt;v7&lt;/td&gt;&lt;/tr&gt;
  106. &lt;tr&gt;&lt;td&gt;B1&lt;/td&gt;&lt;td&gt;v8&lt;/td&gt;&lt;td&gt;v14&lt;/td&gt;&lt;/tr&gt;
  107. &lt;/table&gt;
  108. &lt;p&gt;B1 is &quot;the next run&quot; of boards, already released to the fab house but not yet in hand.&lt;/p&gt;
  109.  
  110. &lt;p&gt;The big feature added to XOrduino after A1 was a motor driver, to allow using the XOrduino as a Turtle robot.  The big feature added to XO Stick after A1 was the shield form factor, allowing it to ride piggy back on the XOrduino.  This makes it easier to share a single turtle robot with a classroom: there may be only one XOrduino robot base, but each student can have their own low-cost XO Stick &quot;brains&quot;.  They can take turns snapping their brains on top of the base to drive it.&lt;/p&gt;
  111.  
  112. &lt;p&gt;I haven&apos;t finished testing all the functionality of these new boards yet, but it looks like I haven&apos;t made any major mistakes!  Help still wanted with software, documentation, etc; send email to xorduino@gmail.com if you&apos;re interested.&lt;/p&gt;</description>
  113.  <comments>https://cananian.livejournal.com/66895.html?view=comments#comments</comments>
  114.  <category>sugar</category>
  115.  <category>olpc</category>
  116.  <category>xorduino</category>
  117.  <category>arduino</category>
  118.  <lj:security>public</lj:security>
  119.  <lj:reply-count>0</lj:reply-count>
  120.  </item>
  121.  <item>
  122.  <guid isPermaLink='true'>https://cananian.livejournal.com/66654.html</guid>
  123.  <pubDate>Thu, 02 Aug 2012 06:39:39 GMT</pubDate>
  124.  <title>XO Bot joins the XOrduino and XO Stick</title>
  125.  <author>cananian</author>
  126.  <link>https://cananian.livejournal.com/66654.html</link>
  127.  <description>&lt;p&gt;Free things first: I&apos;ve got parts for 20 copies of the &quot;Mk I&quot;
  128. &lt;a href=&quot;http://cananian.livejournal.com/66129.html&quot; target=&quot;_blank&quot;&gt;XOrduino and XO Stick&lt;/a&gt;.  &lt;b&gt;I&apos;m mailing them out for free&lt;/b&gt; (!) in exchange
  129. for your development help.  Send me an email at
  130. xorduino@gmail.com describing what you&apos;d like to do with the
  131. XOrduino/XO Stick, and your full mailing address.  Best 20 or so get kits.&lt;/p&gt;
  132.  
  133. &lt;p align=&quot;center&quot;&gt;&lt;img alt=&quot;XOrduino A1&quot; border=&quot;0&quot; title=&quot;XOrduino A1&quot; src=&quot;https://ic.pics.livejournal.com/cananian/123187/847/original.jpg&quot; fetchpriority=&quot;high&quot; /&gt;&lt;/p&gt;
  134.  
  135. &lt;p&gt;Here are some of the projects which you might be able to help with:&lt;/p&gt;
  136. &lt;ul&gt;
  137. &lt;li&gt;&lt;b&gt;Assemble an XOrduino / XO stick with an 8-12 year old&lt;/b&gt; and document
  138.  the process.  What parts were tricky to solder?  Where did polarity
  139.  matter?  How much of the function of the different devices did you
  140.  find worth explaining?  Photos or video of children assembling the device would be great for future publicity, with their permission. (We&apos;re not crazy: kids can &lt;a href=&quot;http://www.youtube.com/watch?v=Pus_fA1Tv9w&quot; target=&quot;_blank&quot;&gt;repair XOs&lt;/a&gt; and &lt;a href=&quot;http://www.sparkfun.com/news/555&quot; target=&quot;_blank&quot;&gt;solder&lt;/a&gt;.)&lt;/li&gt;
  141. &lt;li&gt;&lt;b&gt;Test different configurations&lt;/b&gt; of the boards.  What are the
  142.  fewest components necessary for a functional XO Stick?
  143.  What capacitors are really needed?  What&apos;s the smallest number of
  144.  components needed to get the arduino IDE to talk to the XOrduino?
  145.  Then add the components for the &lt;a href=&quot;http://info.scratch.mit.edu/Sensor_Boards&quot; target=&quot;_blank&quot;&gt;Scratch Sensor Board&lt;/a&gt; functionality,
  146.  and test that with this &lt;a href=&quot;https://github.com/osbock/ScratchSensors&quot; target=&quot;_blank&quot;&gt;Arduino sketch&lt;/a&gt; (some minor porting required).  Try out whatever
  147.  Arduino shields/old Arduino code you have lying around, and see if there
  148.  are any gotchas there.  Document it all, take photos and video, let me know about bugs and pitfalls.&lt;/li&gt;
  149. &lt;li&gt;&lt;b&gt;Write some killer &lt;i&gt;education&lt;/i&gt; apps&lt;/b&gt;!  These
  150.  boards are meant specifically for teaching kids&amp;mdash;take the &lt;a href=&quot;http://wiki.sugarlabs.org/go/Activities/Turtle_Art/Using_Turtle_Art_Sensors&quot; target=&quot;_blank&quot;&gt;Turtle Art with Sensors&lt;/a&gt; ideas as examples, and write up some
  151.  lessons to teach science.  Or take inspiration from the old school
  152.  &quot;fun with electronics&quot; kits from Radio Shack and recreate some of the
  153.  popular standbys: a burglar alarm for kids&apos; tree fort,
  154.  a light-sensitive alarm they can hide in their sibling&apos;s drawer,
  155.  etc.  Or a document how to program a robot (more on the robot below) with simple emergent behaviors&amp;mdash;avoiding walls, turning toward light, fleeing loud sounds, etc.  The &lt;a href=&quot;https://www.sparkfun.com/products/11074&quot; target=&quot;_blank&quot;&gt;Cubelets&lt;/a&gt; examples may give you ideas.  Take photos and video.&lt;/li&gt;
  156. &lt;li&gt;&lt;b&gt;Arduino support for the XO Stick&lt;/b&gt;.  There are a number of projects
  157.  which add support for the ATtiny85 and friends to the Arduino IDE (for example, &lt;a href=&quot;http://provideyourown.com/2011/arduino-program-attiny/&quot; target=&quot;_blank&quot;&gt;this one&lt;/a&gt;).
  158.  Ideally we&apos;d like to make the XO Stick as Arduino-compatible as
  159.  possible, so we can reuse the excellent Arduino IDE, etc.
  160.  This involves (a) porting an arduino-compatible bootloader (like
  161.  &lt;a href=&quot;http://embedded-creations.com/projects/attiny85-usb-bootloader-overview/avr-jtag-programmer/&quot; target=&quot;_blank&quot;&gt;usbAspLoader-tiny&lt;/a&gt;), as well as (b) porting the Arduino libraries to match the
  162.  pinout/peripherals of the ATtiny85 and ATtiny861 (&lt;a href=&quot;http://hlt.media.mit.edu/?p=1695&quot; target=&quot;_blank&quot;&gt;this page&lt;/a&gt; is a good start).&lt;/li&gt;
  163. &lt;li&gt;&lt;b&gt;Program an XO Stick from an XOrduino&lt;/b&gt; and vice versa.  Ideally we&apos;d
  164.  like to bootstrap the initial chip programming, so that one
  165.  programmed XOrduino (or XO Stick) can be used to put the initial
  166.  bootloaders on the others.  For technical reasons the XO Stick
  167.  is probably best as a &quot;clone tool&quot;: without interacting with the
  168.  USB bus it would just copy its internal memory to another
  169.  XO Stick.  The XOrduino is a little easier, just a matter of
  170.  adapting the existing &lt;a href=&quot;http://arduino.cc/en/Tutorial/ArduinoISP&quot; target=&quot;_blank&quot;&gt;Arduino sketches and documentation&lt;/a&gt;.&lt;/li&gt;
  171. &lt;li&gt;&lt;b&gt;Debrick an XO&lt;/b&gt; from the XO Stick.  The XO Stick can talk to the
  172.  EC programming bus to recover a bricked XO; it can probably also
  173.  &lt;a href=&quot;http://wiki.laptop.org/go/SPI_FLASH_Recovery&quot; target=&quot;_blank&quot;&gt;reprogram OpenFirmware&lt;/a&gt;.  We need to write a bit of code to make it
  174.  pain-free and document the process.  This would make the XO Stick a useful repair accessory for XO deployments.&lt;/li&gt;
  175. &lt;li&gt;&lt;b&gt;&lt;a href=&quot;http://catroid.org&quot; target=&quot;_blank&quot;&gt;Scratch&lt;/a&gt;/&lt;a href=&quot;http://wiki.sugarlabs.org/go/Activities/TurtleArt&quot; target=&quot;_blank&quot;&gt;Turtle Blocks&lt;/a&gt; support&lt;/b&gt; for the &lt;a href=&quot;http://wiki.sugarlabs.org/go/Activities/Turtle_Art/Plugins#Arduino&quot; target=&quot;_blank&quot;&gt;XOrduino&lt;/a&gt; and/or &lt;a href=&quot;http://youtu.be/qfU_f8HF-78&quot; target=&quot;_blank&quot;&gt;XO turtle bot&lt;/a&gt; (see below).&lt;/li&gt;
  176. &lt;/ul&gt;
  177.  
  178. &lt;p&gt;Here&apos;s the exciting part two: I&apos;m already working on the XOrduino and XO Stick &quot;Mk II&quot;.  The latest schematics/boards
  179. are in github (&lt;a href=&quot;https://github.com/cscott/xostick&quot; target=&quot;_blank&quot;&gt;xostick&lt;/a&gt;, &lt;a href=&quot;https://github.com/cscott/xorduino&quot; target=&quot;_blank&quot;&gt;xorduino&lt;/a&gt;).  The kits I&apos;ll be sending out this week correspond to the &quot;A1&quot; tag in those repositories; the &quot;Mk II&quot; revision is on the master
  180. branch.&lt;/p&gt;
  181.  
  182. &lt;p&gt;The XO Stick gets a minor change with big implications: instead of
  183. using a 20-pin header matching the ATtiny861 pinout, I&apos;ve widened the
  184. board to &lt;b&gt;give the XO Stick a standard Arduino shield connector&lt;/b&gt; (and some
  185. prototyping area).  This opens the way for a port of the Arduino IDE
  186. (mentioned above), but it also means that the XO Stick can be mounted on top of
  187. an XOrduino.  In a cost-conscious classroom environment, this allows a teacher to buy/make one copy of the XOrduino with all of its
  188. fancy peripherals (scratch sensors, robot support) and then give each student a copy of the
  189. cheaper XO Stick.  The students share the XOrduino and swap out their XO Stick &quot;brains&quot; on top to control it or use its peripherals.  Mating the two
  190. boards also makes it straightforward to program an XO Stick from
  191. an XOrduino, or to use the XO Stick&apos;s prototyping area to hack together
  192. a shield for the XOrduino.&lt;/p&gt;
  193.  
  194. &lt;p&gt;The XOrduino gets a more exciting feature (hinted at above) -- enough peripherals to become the &lt;b&gt;XO Turtle Bot&lt;/b&gt;!  This is a very
  195. low-cost &lt;a href=&quot;http://en.wikipedia.org/wiki/Turtle_%28robot%29&quot; target=&quot;_blank&quot;&gt;turtle robot&lt;/a&gt; based on a &lt;a href=&quot;http://www.tamiyausa.com/product/item.php?product-id=70097&quot; target=&quot;_blank&quot;&gt;Tamiya motor assembly&lt;/a&gt;.  All of the
  196. extra robot components are optional&amp;mdash;you can populate just the parts you want&amp;mdash;but a classroom can now make
  197. their XOrduinos (or XO Stick + XOrduino base) into standalone turtle
  198. robots, controlled by Scratch, Turtle Art, or Arduino code.  The XO Turtle Bot revision adds a motor driver, two bump switches, a simple 3-cell
  199. power supply, and rotation sensors for the motors to the XOrduino.  (Arnan Sipitakiat and Nussarin Nusen in their Robo-Blocks presentation for &lt;a href=&quot;http://dimeb.informatik.uni-bremen.de/idc2012/program.htm&quot; target=&quot;_blank&quot;&gt;IDC 2012&lt;/a&gt; explained that children find &quot;turn for two seconds&quot; hard to understand; we include motor sensors so that we can &quot;turn 90 degrees&quot; instead.)  And of course because the robot is based on XOrduino, you can add
  200. whatever other sensors you like and write arduino/Scratch/Turtle Blocks code for it.&lt;/p&gt;
  201.  
  202. &lt;p align=&quot;center&quot;&gt;&lt;img alt=&quot;XOrduino A1 board on top of Tamiya Twin Motor Gearbox.&quot; border=&quot;0&quot; title=&quot;XOrduino A1 board on top of Tamiya Twin Motor Gearbox.&quot; src=&quot;https://ic.pics.livejournal.com/cananian/123187/1350/300.jpg&quot; width=&quot;300&quot; loading=&quot;lazy&quot; /&gt;&amp;nbsp;&amp;nbsp;&amp;nbsp;&lt;img alt=&quot;XOrduino A1 plugged into USB port; prototype XO Turtle Bot in the background.&quot; border=&quot;0&quot; title=&quot;XOrduino A1 plugged into USB port; prototype XO Turtle Bot in the background.&quot; src=&quot;https://ic.pics.livejournal.com/cananian/123187/1278/300.jpg&quot; width=&quot;300&quot; loading=&quot;lazy&quot; /&gt;&lt;/p&gt;
  203.  
  204. &lt;p&gt;I&apos;m excited about the potential of low-cost robotics and the Arduino platform for
  205. education.  If you are, too, let me send you a kit so you can help
  206. out!&lt;/p&gt;</description>
  207.  <comments>https://cananian.livejournal.com/66654.html?view=comments#comments</comments>
  208.  <category>sugar</category>
  209.  <category>olpc</category>
  210.  <category>xorduino</category>
  211.  <category>android</category>
  212.  <category>arduino</category>
  213.  <lj:security>public</lj:security>
  214.  <lj:reply-count>1</lj:reply-count>
  215.  </item>
  216.  <item>
  217.  <guid isPermaLink='true'>https://cananian.livejournal.com/66444.html</guid>
  218.  <pubDate>Tue, 12 Jun 2012 06:39:52 GMT</pubDate>
  219.  <title>Nell&apos;s Tinkrbook in Omo</title>
  220.  <author>cananian</author>
  221.  <link>https://cananian.livejournal.com/66444.html</link>
  222.  <description>&lt;p&gt;
  223. This week I will be at the 2012 &lt;a href=&quot;http://dimeb.informatik.uni-bremen.de/idc2012/&quot; target=&quot;_blank&quot;&gt;Interaction Design and Children
  224. conference&lt;/a&gt; in Bremen, Germany.  I will be presenting the
  225. &lt;a href=&quot;http://cananian.livejournal.com/66008.html&quot; target=&quot;_blank&quot;&gt;Growing Up With Nell&lt;/a&gt;
  226. paper as well as discussing the OLPC Foundation&apos;s literacy pilots in
  227. Ethiopia.
  228. &lt;/p&gt;
  229.  
  230. &lt;p&gt;
  231. The &lt;a href=&quot;http://wiki.laptop.org/go/Literacy_Project&quot; target=&quot;_blank&quot;&gt;Literacy
  232. Project&lt;/a&gt; is a collaboration between four different groups (as
  233. alluded to by the title of this post): the One Laptop per Child
  234. Foundation (&amp;ldquo;Nell&amp;rdquo;), the MIT Media Lab
  235. (&amp;ldquo;Tinkrbook&amp;rdquo;), the School of Education, Communication and
  236. Language Sciences at Newcastle University, and the Center for Reading
  237. and Language Research at Tufts University (&amp;ldquo;Omo&amp;rdquo;).
  238. The goal is to reach children even further from educational
  239. infrastructure than OLPC has ventured to date.  In particular, the
  240. Ethiopia pilots are complete child-led bootstraps, attempting to teach
  241. kids to read English (an official language of Ethiopia) who neither
  242. speak English nor read in any language yet.  There are no teachers in the village,
  243. and no literate adults either.
  244. &lt;/p&gt;
  245.  
  246. &lt;p&gt;Adapting Nell to this environment has some challenges: how do we
  247. guide students through pedagogic material with stories if they don&apos;t
  248. yet understand the language of the stories we want to tell?  But the
  249. essential challenge is the same: we have hundreds of apps and videos
  250. on the tablets and need to provide scaffolding and guidance to the
  251. bits most appropriate for each child at any given time, just as Nell seeks to
  252. guide children through the many activities included in Sugar.  In the
  253. literacy project there is also a need for automated assessment tools: how can we tell that the project is
  254. working?  How can we determine what parts of our content are effective
  255. in their role?&lt;/p&gt;
  256.  
  257. &lt;p&gt;I&apos;ll write more about the Literacy Project in the coming weeks.
  258. As we&apos;ve started to get data back, some of the lessons learned are
  259. familiar: kids do the strangest things!  They learn how to do things
  260. we never knew they could do (or meant for them to) and often are
  261. motivated by pleasures which surprise us.  For example, one app we
  262. deployed had a sphere which deflated with a sort of farting noise when
  263. the child picked the wrong answer.  It turns out that the kids liked making the farting noise
  264. much more than they liked the response to the correct answer!  Obvious
  265. in retrospect, but the lesson reminds us why we are pursuing an incremental development and data collection approach.  Happily, the hardware itself
  266. has been a success: low hardware failure rates, solar powered charging
  267. is successful (although they prefer to charge the devices during the
  268. middle of the day; we&apos;d expected them to do so overnight from storage batteries charged during the day), and they&apos;ve
  269. mastered the touch interface very quickly on their own.  The pilots
  270. have been running since February, and the kids are still very engaged
  271. with the content.  So far, so good!&lt;/p&gt;
  272.  
  273. &lt;p align=&quot;center&quot;&gt;
  274. &lt;img alt=&quot;Smiling boy in Ethiopia Literacy Pilot&quot; border=&quot;0&quot; title=&quot;Smiling boy in Ethiopia Literacy Pilot&quot; src=&quot;https://ic.pics.livejournal.com/cananian/123187/387/300.jpg&quot; height=&quot;225&quot; fetchpriority=&quot;high&quot; /&gt;&amp;nbsp;&lt;img alt=&quot;Two girls in Ethiopia Literacy Pilot&quot; border=&quot;0&quot; title=&quot;Two girls in Ethiopia Literacy Pilot&quot; src=&quot;https://ic.pics.livejournal.com/cananian/123187/749/300.jpg&quot; width=&quot;300&quot; loading=&quot;lazy&quot; /&gt;&lt;/p&gt;</description>
  275.  <comments>https://cananian.livejournal.com/66444.html?view=comments#comments</comments>
  276.  <category>sugar</category>
  277.  <category>olpc</category>
  278.  <category>nell</category>
  279.  <lj:security>public</lj:security>
  280.  <lj:reply-count>0</lj:reply-count>
  281.  </item>
  282.  <item>
  283.  <guid isPermaLink='true'>https://cananian.livejournal.com/66129.html</guid>
  284.  <pubDate>Sat, 09 Jun 2012 16:06:32 GMT</pubDate>
  285.  <title>Introducting the XOrduino! (and XO Stick)</title>
  286.  <author>cananian</author>
  287.  <link>https://cananian.livejournal.com/66129.html</link>
  288.  <description>&lt;p&gt;I banged out two &lt;a href=&quot;http://freedomdefined.org/OSHW&quot; target=&quot;_blank&quot;&gt;open hardware&lt;/a&gt; designs this week, designed for use with the &lt;a href=&quot;http://en.wikipedia.org/wiki/OLPC_XO-1&quot; target=&quot;_blank&quot;&gt;OLPC XO&lt;/a&gt; laptops.&lt;/p&gt;
  289.  
  290. &lt;p&gt;The first is the &lt;b&gt;XOrduino&lt;/b&gt;, a stripped down low-cost
  291. &lt;a href=&quot;http://arduino.cc/&quot; target=&quot;_blank&quot;&gt;Arduino&lt;/a&gt;-compatible board that plugs right into the XO&apos;s USB ports.
  292. But wait, there&apos;s more: it&apos;s also compatible with the &lt;a href=&quot;http://info.scratch.mit.edu/Sensor_Boards&quot; target=&quot;_blank&quot;&gt;Scratch Sensor
  293. Board&lt;/a&gt;, so you can use this device to control &lt;a href=&quot;http://scratch.mit.edu/&quot; target=&quot;_blank&quot;&gt;Scratch&lt;/a&gt; (and &lt;a href=&quot;http://wiki.sugarlabs.org/go/Activities/TurtleArt#Arduino&quot; target=&quot;_blank&quot;&gt;Turtle Art&lt;/a&gt;, once &lt;a href=&quot;http://firmata.org/&quot; target=&quot;_blank&quot;&gt;Firmata&lt;/a&gt; is ported).
  294. It should be compatible with the &lt;a href=&quot;http://en.wikipedia.org/wiki/Arduino#Software&quot; target=&quot;_blank&quot;&gt;Arduino IDE&lt;/a&gt; and all &lt;a href=&quot;http://arduino.cc/en/Main/ArduinoBoardLeonardo&quot; target=&quot;_blank&quot;&gt;Arduino
  295. Leonardo&lt;/a&gt;-compatible shields.&lt;/p&gt;
  296.  
  297. &lt;p&gt;The board uses mostly through-hole parts, with one exception, and
  298. there are only 20 required components for the basic Arduino
  299. functionality, costing about $5 (from digikey, quantity 100).  It is
  300. reasonable for local labor or even older kids to assemble by hand.&lt;/p&gt;
  301.  
  302. &lt;p&gt;It&apos;s open hardware: &lt;a href=&quot;http://en.wikipedia.org/wiki/Eagle_(program)&quot; target=&quot;_blank&quot;&gt;Eagle&lt;/a&gt; design files are &lt;a href=&quot;https://github.com/cscott/xorduino&quot; target=&quot;_blank&quot;&gt;on github&lt;/a&gt; (&lt;a href=&quot;https://github.com/cscott/xorduino/blob/A1/XOrduino-sch.pdf?raw=true&quot; target=&quot;_blank&quot;&gt;schematic PDF&lt;/a&gt;,
  303. &lt;a href=&quot;https://github.com/cscott/xorduino/blob/A1/XOrduino-brd.pdf?raw=true&quot; target=&quot;_blank&quot;&gt;pcb PDF&lt;/a&gt;).  I expect to have a small number of boards in a few weeks; let
  304. me know if you&apos;d like one in exchange for help with hardware and
  305. software bring-up.  Schematic and layout review also appreciated (I did the PCB routing late at night under time pressure leaning heavily on autoroute, it&apos;s certainly not the prettiest).  And feedback from Arduino and Arduino shield hackers would also be welcome.&lt;/p&gt;
  306.  
  307. &lt;p&gt;If $5 per student is too much money, there&apos;s also the &lt;b&gt;XO Stick&lt;/b&gt;, my
  308. second board.  It&apos;s based on the &lt;a href=&quot;http://www.sparkfun.com/products/9147&quot; target=&quot;_blank&quot;&gt;AVR Stick&lt;/a&gt; using the &lt;a href=&quot;http://www.atmel.com/devices/attiny85.aspx&quot; target=&quot;_blank&quot;&gt;ATtiny85&lt;/a&gt; processor and costs only
  309. $1/student.  It&apos;s not quite as user-friendly as the Arduino-compatible
  310. board, but it can also be used to teach simple lessons in embedded
  311. electronics.  For $0.12 more you can populate an &lt;a href=&quot;http://www.atmel.com/devices/ATTINY261A.aspx&quot; target=&quot;_blank&quot;&gt;ATtiny261A&lt;/a&gt; (though a &apos;461 or &apos;861 would be better) and get 13 I/O ports; this variant should be powerful enough to program other XO Sticks and perform XO maintenance tasks (accessing the serial
  312. console, debricking a laptop via SPI flash).  The XO Stick is even easier for a
  313. kid to assemble themself: only 8 required components, all through-hole.
  314. (Sadly, my desire to shave every penny off the cost of this design meant that I couldn&apos;t use some of the symmetry tricks I invented for &lt;a href=&quot;http://www.mit.edu/~puzzle/12/ben_bitdiddle/investigators_report/solution/&quot; target=&quot;_blank&quot;&gt;a 2012 Mystery Hunt puzzle&lt;/a&gt; to make the circuit &lt;i&gt;impossible&lt;/i&gt; to assemble incorrectly.)
  315. &lt;/p&gt;
  316.  
  317. &lt;p&gt;Same deal as the XOrduino: design files &lt;a href=&quot;https://github.com/cscott/xostick&quot; target=&quot;_blank&quot;&gt;on github&lt;/a&gt; (&lt;a href=&quot;https://github.com/cscott/xostick/blob/master/XO-Stick-sch.pdf?raw=true&quot; target=&quot;_blank&quot;&gt;schematic PDF&lt;/a&gt;,
  318. &lt;a href=&quot;https://github.com/cscott/xostick/blob/master/XO-Stick-brd.pdf?raw=true&quot; target=&quot;_blank&quot;&gt;pcb PDF&lt;/a&gt;); I expect to have a few boards available to people who want to
  319. help make some software for them.  Schematic and layout review is also appreciated!&lt;/p&gt;</description>
  320.  <comments>https://cananian.livejournal.com/66129.html?view=comments#comments</comments>
  321.  <category>sugar</category>
  322.  <category>olpc</category>
  323.  <category>xorduino</category>
  324.  <category>arduino</category>
  325.  <lj:security>public</lj:security>
  326.  <lj:reply-count>0</lj:reply-count>
  327.  </item>
  328.  <item>
  329.  <guid isPermaLink='true'>https://cananian.livejournal.com/66008.html</guid>
  330.  <pubDate>Mon, 12 Mar 2012 20:55:35 GMT</pubDate>
  331.  <title>Growing Up With Nell</title>
  332.  <author>cananian</author>
  333.  <link>https://cananian.livejournal.com/66008.html</link>
  334.  <description>&lt;p&gt;Chris, Michael, and I just submitted a short paper describing our work on the XO-3 Nell project to this year&apos;s &lt;a href=&quot;http://dimeb.informatik.uni-bremen.de/idc2012/&quot; target=&quot;_blank&quot;&gt;Interaction Design and Children&lt;/a&gt; conference.  Give the preprint a read: &lt;a href=&quot;http://cscott.net/Publications/OLPC/idc2012.pdf&quot; target=&quot;_blank&quot;&gt;&lt;i&gt;Growing Up With Nell: A Narrative Interface for Literacy&lt;/i&gt; [pdf]&lt;/a&gt;.&lt;/p&gt;
  335.  
  336. &lt;p&gt;We&apos;re hard at work implementing Nell.  We could use help in a number of areas: art, animation, story, user interface, javascript hacking, and probably others.  For example, at the moment Chris and I are: drawing the characters, drawing user interface concepts, writing silly alphabet stories, animating the silly alphabet stories, doing the CSS/HTML layout to mock up designs, making some of the mock ups into functional demos, implementing HMM-based handwriting recognition in JavaScript, porting pyaiml to JavaScript, implementing an Apple Guide-style contextual help system on top of HTML widgets, and writing a integrated story editor (and stories about the story editor).  I&apos;d welcome volunteers for any of these tasks!&lt;/p&gt;</description>
  337.  <comments>https://cananian.livejournal.com/66008.html?view=comments#comments</comments>
  338.  <category>sugar</category>
  339.  <category>olpc</category>
  340.  <category>nell</category>
  341.  <lj:security>public</lj:security>
  342.  <lj:reply-count>1</lj:reply-count>
  343.  </item>
  344.  <item>
  345.  <guid isPermaLink='true'>https://cananian.livejournal.com/65380.html</guid>
  346.  <pubDate>Tue, 01 Nov 2011 22:28:14 GMT</pubDate>
  347.  <title>A collection of Nell demos</title>
  348.  <author>cananian</author>
  349.  <link>https://cananian.livejournal.com/65380.html</link>
  350.  <description>&lt;p&gt;Here are some banged-together demos of various pieces of
  351. &lt;a href=&quot;http://laptop.org&quot; target=&quot;_blank&quot;&gt;One Laptop per Child&lt;/a&gt;&apos;s
  352. &lt;a href=&quot;http://cananian.livejournal.com/65077.html&quot; target=&quot;_blank&quot;&gt;Project Nell&lt;/a&gt;.
  353. The ultimate goal is a Nell &lt;a href=&quot;http://wiki.laptop.org/go/Nell&quot; target=&quot;_blank&quot;&gt;demo&lt;/a&gt;
  354. for &lt;a href=&quot;http://en.wikipedia.org/wiki/Consumer_Electronics_Show&quot; target=&quot;_blank&quot;&gt;CES&lt;/a&gt;
  355. in January 2012, but these bits should be considered as tech demos,
  356. benchmarks, and proofs of concept, not actual pieces of that demo (yet).
  357. &lt;/p&gt;
  358.  
  359. &lt;p&gt;Most of these demos require WebGL support.  Visit &lt;a href=&quot;http://get.webgl.org/&quot; target=&quot;_blank&quot;&gt;get.webgl.org&lt;/a&gt; for information about
  360. enabling WebGL in your browser; there is WebGL support in Chrome,
  361. Firefox, Safari, and Opera&amp;mdash;although it often requires enabling
  362. experimental features in the browser preferences.&lt;/p&gt;
  363.  
  364. &lt;ul&gt;
  365.  &lt;li&gt;&lt;a href=&quot;http://dev.laptop.org/~cscott/nelldemo.20111101/tile_test.html&quot; target=&quot;_blank&quot;&gt;Tiles&lt;/a&gt;.  Performance benchmark
  366.  for a tile-based home screen.  &quot;Apps&quot; are &quot;locations&quot; on your world map,
  367.  which you can customize as you like.  (Here&apos;s an interesting
  368.  &lt;a href=&quot;http://vocamus.net/dave/?p=1168&quot; target=&quot;_blank&quot;&gt;blog entry&lt;/a&gt; discussing
  369.  world-creation for kids.)  Day/night would ultimately reflect current
  370.  time, although they&apos;ve been greatly sped up in this demo.  Lots of
  371.  rough edges and missing UI, but all the textured triangles are
  372.  present, so it should be an accurate benchmark.&lt;br /&gt;
  373.  (Drag with left mouse button to rotate, middle mouse button to zoom,
  374.  right mouse button to pan.)
  375.  &lt;/li&gt;
  376.  
  377.  &lt;li&gt;&lt;a href=&quot;http://dev.laptop.org/~cscott/nelldemo.20111101/nell_home_test.html&quot; target=&quot;_blank&quot;&gt;Nell at home&lt;/a&gt;.  Basic idea
  378.  (including transition) for activities which include dialog with
  379.  Nell or story-telling.&lt;br /&gt;
  380.  Standalone model viewers:
  381.  &lt;a href=&quot;http://dev.laptop.org/~cscott/nelldemo.20111101/watchtower_test.html&quot; target=&quot;_blank&quot;&gt;Castle&lt;/a&gt; (from &lt;a href=&quot;http://www.blendswap.com/3D-models/architecture/watchtower/&quot; target=&quot;_blank&quot;&gt;blendswap&lt;/a&gt;),
  382.  &lt;a href=&quot;http://dev.laptop.org/~cscott/nelldemo.20111101/sintel_test.html&quot; target=&quot;_blank&quot;&gt;&quot;Nell&quot;&lt;/a&gt; (Sintel, from &lt;a href=&quot;http://www.blendswap.com/3D-models/characters/sintel-lite-2-57b/&quot; target=&quot;_blank&quot;&gt;blendswap&lt;/a&gt;),
  383.  &lt;a href=&quot;http://dev.laptop.org/~cscott/nelldemo.20111101/sintel_lite_test.html&quot; target=&quot;_blank&quot;&gt;Alternate (lightweight) Nell model&lt;/a&gt;,
  384.  &lt;a href=&quot;http://dev.laptop.org/~cscott/nelldemo.20111101/maison_test.html&quot; target=&quot;_blank&quot;&gt;Alternate (heavyweight) house model&lt;/a&gt;
  385.  (from &lt;a href=&quot;http://www.blendswap.com/3D-models/architecture/little-house/&quot; target=&quot;_blank&quot;&gt;blendswap&lt;/a&gt;).&lt;br /&gt;
  386.  In model viewers: drag with left mouse button to rotate, middle
  387.  mouse button to zoom, right mouse button to pan.
  388.  &lt;/li&gt;
  389.  
  390.  &lt;li&gt;&lt;a href=&quot;http://dev.laptop.org/~cscott/nelldemo.20111101/music.html&quot; target=&quot;_blank&quot;&gt;Music maker&lt;/a&gt;. Uses WebGL and the Web
  391.  Audio APIs to let you draw and perform music.&lt;br /&gt;
  392.  Inspired by Andr&amp;eacute; Michelle&apos;s
  393.  &lt;a href=&quot;http://lab.andre-michelle.com/tonematrix&quot; target=&quot;_blank&quot;&gt;ToneMatrix&lt;/a&gt; and
  394.  &lt;a href=&quot;http://lab.andre-michelle.com/karplus-strong-guitar&quot; target=&quot;_blank&quot;&gt;Karplus-Strong
  395.  Guitar&lt;/a&gt; (see also
  396.  &lt;a href=&quot;http://en.wikipedia.org/wiki/Karplus-Strong_string_synthesis&quot; target=&quot;_blank&quot;&gt;wiki&lt;/a&gt;
  397.  and this 2008 &lt;a href=&quot;http://lac.linuxaudio.org/&quot; target=&quot;_blank&quot;&gt;Linux Audio Conference&lt;/a&gt;
  398.  &lt;a href=&quot;https://ccrma.stanford.edu/realsimple/faust_strings/faust_strings.pdf&quot; target=&quot;_blank&quot;&gt;paper&lt;/a&gt;),
  399.  as well as &lt;a href=&quot;http://labs.dinahmoe.com/&quot; target=&quot;_blank&quot;&gt;DinahMoe&lt;/a&gt;&apos;s
  400.  &lt;a href=&quot;http://labs.dinahmoe.com/ToneCraft/&quot; target=&quot;_blank&quot;&gt;ToneCraft&lt;/a&gt; and
  401.  the &lt;a href=&quot;http://www.global.yamaha.com/tenori-on/&quot; target=&quot;_blank&quot;&gt;Tenori-on&lt;/a&gt;.
  402.  &lt;/li&gt;
  403.  
  404.  &lt;li&gt;&lt;a href=&quot;http://www.youtube.com/watch?v=4Mr27yY8-A8&quot; target=&quot;_blank&quot;&gt;Quake on XO-1.75&lt;/a&gt;
  405.  (video).
  406.  Of course we need to actually run WebGL with good performance on XO
  407.  hardware.  Jon Nettleton has been working hard on our GL drivers,
  408.  enabling the GPU on the XO-1.75 hardware for the first time.
  409.  This Quake demo shows his progress&amp;mdash;don&apos;t worry, Quake is not
  410.  actually part of the Nell demo! (We have a GPU in the XO-1.5 as
  411.  well, which hasn&apos;t yet been utilized.)
  412.  &lt;/li&gt;
  413.  
  414.  &lt;li&gt;&lt;a href=&quot;http://twolivesleft.com/Codify/&quot; target=&quot;_blank&quot;&gt;Codify&lt;/a&gt;&amp;mdash;not
  415.  one of our demos (it&apos;s a commercial iPad app) but it demonstrates
  416.  the direction we&apos;d like to push &lt;a href=&quot;http://wiki.laptop.org/go/Pippy&quot; target=&quot;_blank&quot;&gt;Pippy&lt;/a&gt;.&lt;/li&gt;
  417. &lt;/ul&gt;
  418.  
  419. &lt;p&gt;Coming soon: TurtleArt and Implode for the web.  We&apos;ve started
  420.  converting them to GTK3 in preparation for hoisting them bodily onto
  421.  the interwebs.  Here&apos;s the &lt;a href=&quot;http://git.sugarlabs.org/~cscott/turtleart/cscott-gtk3/commits/gtk3&quot; target=&quot;_blank&quot;&gt;source
  422.  code repository for the TurtleArt port&lt;/a&gt; if you&apos;d like to watch or
  423.  participate in this hackage.  (See &lt;a href=&quot;http://repl.it&quot; target=&quot;_blank&quot;&gt;repl.it&lt;/a&gt;
  424.  for one of the more unusual ways to get Python running in the web
  425.  context.)  The rest of the demo source code is on &lt;a href=&quot;https://github.com/cscott/nelldemo&quot; target=&quot;_blank&quot;&gt;github&lt;/a&gt; (or just &quot;View Source&quot; in your browser).&lt;/p&gt;</description>
  426.  <comments>https://cananian.livejournal.com/65380.html?view=comments#comments</comments>
  427.  <category>olpc</category>
  428.  <category>nell</category>
  429.  <lj:security>public</lj:security>
  430.  <lj:reply-count>1</lj:reply-count>
  431.  </item>
  432.  <item>
  433.  <guid isPermaLink='true'>https://cananian.livejournal.com/65077.html</guid>
  434.  <pubDate>Sat, 01 Oct 2011 05:18:05 GMT</pubDate>
  435.  <title>Introducing Nell</title>
  436.  <author>cananian</author>
  437.  <link>https://cananian.livejournal.com/65077.html</link>
  438.  <description>&lt;p&gt;Between now and January &lt;a href=&quot;http://en.wikipedia.org/wiki/Consumer_Electronics_Show&quot; target=&quot;_blank&quot;&gt;CES&lt;/a&gt;, Chris Ball and I will be building &lt;i&gt;Nell&lt;/i&gt; for the &lt;a href=&quot;http://en.wikipedia.org/wiki/OLPC&quot; target=&quot;_blank&quot;&gt;OLPC&lt;/a&gt; &lt;a href=&quot;http://blog.laptop.org/2011/07/22/olpc-xo-3-design-update/&quot; target=&quot;_blank&quot;&gt;XO-3&lt;/a&gt; tablet.
  439. Nell is a name, not an acronym, but if you want to pronounce it as
  440. &quot;Narrative Environment for &lt;a href=&quot;http://wiki.laptop.org/go/Learning_Learning&quot; target=&quot;_blank&quot;&gt;Learning Learning&lt;/a&gt;,&quot; I won&apos;t stop you.&lt;/p&gt;
  441.  
  442. &lt;p&gt;Nell&apos;s development will be demo-oriented&amp;mdash;we&apos;re going to try to write the most
  443. interesting bits first and learn as we go&amp;mdash;so don&apos;t be upset if you
  444. don&apos;t see support right away for legacy Sugar activities (&quot;Sweet
  445. Nell&quot;), robust sharing support, mesh networking, or whatever
  446. your favorite existing feature is.  They&apos;ll come, but the new
  447. crazy stuff is what we need to evaluate first.&lt;/p&gt;
  448.  
  449. &lt;p&gt;Here are four of the big ideas behind Nell, along with pointers to some of our sources of inspiration.&lt;/p&gt;
  450.  
  451. &lt;p&gt;&lt;b&gt;Narrative.&lt;/b&gt; I probably don&apos;t need to restate that Neil
  452. Stephenson&apos;s &quot;The Diamond Age&quot; has been hugely influential, and we also owe
  453. a large debt to interactive fiction and the &lt;a href=&quot;http://pr-if.org/&quot; target=&quot;_blank&quot;&gt;Boston IF group&lt;/a&gt; in particular.  (Check out
  454. the talks from our
  455. &quot;&lt;a href=&quot;http://blog.printf.net/articles/2011/06/18/narrative-interfaces&quot; target=&quot;_blank&quot;&gt;Narrative
  456. Interfaces day&lt;/a&gt;&quot; at OLPC.)
  457. &lt;a href=&quot;http://users.soe.ucsc.edu/~jskorups/wiki/wide_ruled/wide_ruled_v2&quot; target=&quot;_blank&quot;&gt;Wide
  458. Ruled&lt;/a&gt; (&lt;a href=&quot;http://eis.ucsc.edu/sites/default/files/Skorupski_DAC09_WideRuledLessonsLearned.pdf&quot; target=&quot;_blank&quot;&gt;conference
  459. paper&lt;/a&gt;) and &lt;a href=&quot;https://research.cc.gatech.edu/inc/mark-riedl&quot; target=&quot;_blank&quot;&gt;Mark Riedl&lt;/a&gt;
  460. at Georgia Tech have demonstrated interesting approaches to story representation.
  461. I&apos;m also looking forward to the results of the Experimental Game Play
  462. group&apos;s September &lt;a href=&quot;http://experimentalgameplay.com/blog/2011/09/story-game-in-september-2011/&quot; target=&quot;_blank&quot;&gt;Story
  463. Game&lt;/a&gt; competition.&lt;/p&gt;
  464.  
  465. &lt;p&gt;&lt;b&gt;Emotion.&lt;/b&gt; The Radiolab podcast &quot;&lt;a href=&quot;http://www.radiolab.org/2011/may/31/&quot; target=&quot;_blank&quot;&gt;Talking To Machines&lt;/a&gt;&quot; crystallized my thinking about emotionally-attractive environments.  The discussion with Caleb
  466. Chung, the creator of Furby, is particularly apropos.  Caleb&apos;s goal is
  467. to make things which kids want to &quot;play with for a long time,&quot; and he
  468. contributes his three rules for creating things which &quot;feel alive&quot;:
  469. it must (1) feel and show emotions, (2) be aware of itself and its
  470. environment, and (3) have behaviors which change over time.  Furby&apos;s
  471. pursuit of these goals include expressive eyes and ears, crying when
  472. held upside down, reacting to loud noises, and gradually switching from &lt;a href=&quot;http://en.wikipedia.org/wiki/Furby#Furbish-English_phrases&quot; target=&quot;_blank&quot;&gt;Furbish&lt;/a&gt;
  473. to English for its utterances.  A living thing emits a
  474. constant stream of little surprises.  Expect to see Nell put the
  475. XO-3&apos;s microphone and accelerometer to good use.&lt;/p&gt;
  476.  
  477. &lt;p&gt;&lt;b&gt;Talking and Listening.&lt;/b&gt; The &quot;Talking To Machines&quot; podcast also discusses &lt;a href=&quot;http://en.wikipedia.org/wiki/ELIZA&quot; target=&quot;_blank&quot;&gt;ELIZA&lt;/a&gt; and &lt;a href=&quot;http://en.wikipedia.org/wiki/Cleverbot&quot; target=&quot;_blank&quot;&gt;Cleverbot&lt;/a&gt;, which
  478. dovetails with my interest in the popular &lt;a href=&quot;http://wiki.sugarlabs.org/go/Activities/Speak&quot; target=&quot;_blank&quot;&gt;Speak
  479. activity&lt;/a&gt; for Sugar and related toys like &lt;a href=&quot;http://outfit7.com/apps/talking-tom-cat/&quot; target=&quot;_blank&quot;&gt;Talking Tomcat&lt;/a&gt; for
  480. mobile phones.  The key insight here is that a little bit of &quot;cheap
  481. trick&quot; AI can go a long way toward making a personable and engaging
  482. system.  We want Nell to feel like a friend.  Recent work by
  483. the &lt;a href=&quot;http://csc.media.mit.edu/&quot; target=&quot;_blank&quot;&gt;Common Sense Computing
  484. Initiative&lt;/a&gt; at MIT&apos;s Media Lab shows how we can reset this on a sounder
  485. basis and use mostly-unstructured input to allow the system to grow
  486. and learn (creating &quot;behaviors changing over time&quot;).  In particular, I&apos;ll cite &lt;a href=&quot;http://csc.media.mit.edu/conceptnet&quot; target=&quot;_blank&quot;&gt;ConceptNet&lt;/a&gt; for its
  487. database and practical NLP tools, and inspiration from
  488. &quot;Empathy Buddy,&quot; &quot;StoryFighter,&quot; and the other projects described in their
  489. &lt;a href=&quot;http://web.media.mit.edu/~push/Beating-Common-Sense.pdf&quot; target=&quot;_blank&quot;&gt;Beating
  490. Common Sense&lt;/a&gt; paper.  It&apos;s also worth noting that open source
  491. speech tools are good and getting better (the &lt;a href=&quot;http://voxforge.org/&quot; target=&quot;_blank&quot;&gt;VoxForge&lt;/a&gt; site points to most of them);
  492. also interesting is &lt;a href=&quot;http://festvox.org/transform/transform.html&quot; target=&quot;_blank&quot;&gt;this technique&lt;/a&gt;
  493. for matching a synthesized voice to that of the user.&lt;/p&gt;
  494.  
  495. &lt;p&gt;&lt;b&gt;Collecting, nurturing, and rewarding.&lt;/b&gt; Collector games such as &lt;a href=&quot;http://en.wikipedia.org/wiki/Pocket_Frogs&quot; target=&quot;_blank&quot;&gt;Pocket Frogs&lt;/a&gt; and
  496. &lt;a href=&quot;http://www.facebook.com/iphoneflowergarden&quot; target=&quot;_blank&quot;&gt;Flower Garden&lt;/a&gt;
  497. are sticky activities which
  498. encourage kids to come back to the device and continue working toward a goal over a long period of time.
  499. &lt;a href=&quot;http://www.technologyreview.com/printer_friendly_article.aspx?id=37874&quot; target=&quot;_blank&quot;&gt;Memrise&lt;/a&gt;
  500. is educational software illustrating this technique: its users tend a garden of flowers by
  501. mastering a set of flash cards.  Nell will incorporate the sticky aspects of such games, possibly also integrating the Mozilla &lt;a href=&quot;http://openbadges.org/&quot; target=&quot;_blank&quot;&gt;Open Badges infrastructure&lt;/a&gt; into an achievement/reward system.&lt;/p&gt;
  502.  
  503. &lt;p&gt;I hope this has given you a general sense of the direction of our Nell project.  In future
  504. blog posts I&apos;ll drill down into implementation details, demonstration storyboards, and other more concrete facets of Nell.&lt;/p&gt;</description>
  505.  <comments>https://cananian.livejournal.com/65077.html?view=comments#comments</comments>
  506.  <category>sugar</category>
  507.  <category>olpc</category>
  508.  <category>nell</category>
  509.  <category>if</category>
  510.  <lj:security>public</lj:security>
  511.  <lj:reply-count>4</lj:reply-count>
  512.  </item>
  513.  <item>
  514.  <guid isPermaLink='true'>https://cananian.livejournal.com/64747.html</guid>
  515.  <pubDate>Wed, 15 Jun 2011 21:27:50 GMT</pubDate>
  516.  <title>Narrative Interfaces</title>
  517.  <author>cananian</author>
  518.  <link>https://cananian.livejournal.com/64747.html</link>
  519.  <description>&lt;p&gt;One Laptop per Child creates student-centric learning experiences.  Our current software stack, however, is somewhat &quot;shallow&quot;.  When you turn on the XO, all the content is immediately available but there is no path or guidance provided.  Nothing suggests what you should try first, or indicates an order to progress through the activities provided.  Everything is available, but there&apos;s no built-in journey.  No plot.  How can we improve this?&lt;/p&gt;
  520.  
  521. &lt;p&gt;&lt;a href=&quot;http://www.timeanddate.com/worldclock/fixedtime.html?msg=Narrative+Interfaces+Talks+at+OLPC&amp;amp;iso=20110617T14&amp;amp;p1=43&amp;amp;ah=2&amp;amp;am=30&quot; target=&quot;_blank&quot;&gt;This Friday (June 17) at 2pm Eastern&lt;/a&gt; we&apos;re inviting some folks over to OLPC&apos;s new offices at the &lt;a href=&quot;http://www.americantwine.com/&quot; target=&quot;_blank&quot;&gt;American Twine&lt;/a&gt; building to discuss &lt;i&gt;Narrative Interfaces&lt;/i&gt;, as part of the proposed XO-3 software stack.  &lt;a href=&quot;http://nickm.com/&quot; target=&quot;_blank&quot;&gt;Nick Montfort&lt;/a&gt; will give a short talk on &lt;a href=&quot;http://curveship.com/&quot; target=&quot;_blank&quot;&gt;&lt;i&gt;Curveship&lt;/i&gt;&lt;/a&gt;, his model-based interactive fiction system, and &lt;a href=&quot;http://printf.net/&quot; target=&quot;_blank&quot;&gt;Chris Ball&lt;/a&gt; will present some related recent hacking.  &lt;a href=&quot;http://web.media.mit.edu/~anjchang/&quot; target=&quot;_blank&quot;&gt;Angela Chang&lt;/a&gt; will present her &lt;i&gt;Tinkerbooks&lt;/i&gt; early-literacy platform, which allows kids to interactively change the written story on the page.  And I&apos;ll discuss Neal Stephenson&apos;s novel &lt;a href=&quot;http://en.wikipedia.org/wiki/The_Diamond_Age&quot; target=&quot;_blank&quot;&gt;&lt;i&gt;The Diamond Age&lt;/i&gt;&lt;/a&gt; (a recap of &lt;a href=&quot;http://www.dailymotion.com/video/xip6ep_en-the-diamond-age_tech&quot; target=&quot;_blank&quot;&gt;a short talk I gave at EduJAM in Uruguay&lt;/a&gt;), and give concrete suggestions for how Diamond Age&apos;s &lt;i&gt;Primer&lt;/i&gt; might influence the software architecture for the XO-3.  (I might even reveal how to make software testing semantically indistinguishable from writing a game!)  Chris Ball and I have also been collecting best-of-breed &quot;comic books that teach you something&quot; as examples of educational narrative; we&apos;ll pass those around and post a reading list after the event.&lt;/p&gt;
  522.  
  523. &lt;p&gt;The real point of this meeting isn&apos;t the talks, per se, but the discussions to follow.  We&apos;re trying to gather folks who know a lot more about this stuff than we do, in order to learn from them and be inspired.  We don&apos;t have a lot of space, unfortunately, so I&apos;m going to have to ask for RSVPs from those who wish to attend.  If you&apos;re in the Boston area and feel like you have something to contribute (and especially if you have created/could create &lt;a href=&quot;http://creativecommons.org/&quot; target=&quot;_blank&quot;&gt;Creative Commons&lt;/a&gt;-licensed content for education), drop me a line at cscott at laptop dot org.  Describing what you can contribute to the discussion will help break ties if space is inadequate.&lt;/p&gt;
  524.  
  525. &lt;p&gt;We will also live-stream the meeting at &lt;a href=&quot;http://www.ustream.tv/channel/cscottnet&quot; target=&quot;_blank&quot;&gt;ustream.tv/channel/cscottnet&lt;/a&gt;.  Afterwards we&apos;ll post higher-quality video and a list of cited works. Thanks in advance to everyone who will participate, online and off!&lt;/p&gt;
  526.  
  527. &lt;p&gt;&lt;b&gt;UPDATE:&lt;/b&gt; video now up; see &lt;a href=&quot;http://blog.printf.net/articles/2011/06/18/narrative-interfaces&quot; target=&quot;_blank&quot;&gt;this writeup on Chris Ball&apos;s blog&lt;/a&gt;.&lt;/p&gt;</description>
  528.  <comments>https://cananian.livejournal.com/64747.html?view=comments#comments</comments>
  529.  <category>sugar</category>
  530.  <category>olpc</category>
  531.  <category>nell</category>
  532.  <category>if</category>
  533.  <category>games</category>
  534.  <category>curveship</category>
  535.  <lj:security>public</lj:security>
  536.  <lj:reply-count>0</lj:reply-count>
  537.  </item>
  538.  <item>
  539.  <guid isPermaLink='true'>https://cananian.livejournal.com/64330.html</guid>
  540.  <pubDate>Tue, 24 May 2011 16:22:51 GMT</pubDate>
  541.  <title>Small systems... and distributed ones</title>
  542.  <author>cananian</author>
  543.  <link>https://cananian.livejournal.com/64330.html</link>
  544.  <description>&lt;p&gt;Today I stumbled across some very interesting projects by &lt;a href=&quot;https://github.com/SamuraiJack&quot; target=&quot;_blank&quot;&gt;Nickolay Platonov&lt;/a&gt; which I&apos;d like to discuss in an OLPC context.&lt;/p&gt;
  545.  
  546. &lt;p&gt;I&apos;ve been hacking away at &lt;a href=&quot;http://cscott.net/Projects/TurtleScript&quot; target=&quot;_blank&quot;&gt;TurtleScript&lt;/a&gt; fueled partly by a drive for minimalism: a small system is a learnable system.  To that end, the language is based on &lt;a href=&quot;http://www.crockford.com/&quot; target=&quot;_blank&quot;&gt;Douglas Crockford&lt;/a&gt;&apos;s &quot;Simplified JavaScript&quot; (as recognized by &lt;a href=&quot;http://javascript.crockford.com/tdop/tdop.html&quot; target=&quot;_blank&quot;&gt;this top-down operator precedence parser&lt;/a&gt;) which tries hard to include only JavaScript&apos;s &quot;&lt;a href=&quot;http://www.livestream.com/etsy/video?clipId=pla_1463e546-47ed-4a93-b59a-bd52b236e8b8&quot; target=&quot;_blank&quot;&gt;Good Parts&lt;/a&gt;&quot;.  For example, the &lt;a href=&quot;https://github.com/cscott/TurtleScript/blob/beeba5c138d88af40297f93689ecbe7721724819/crender.js#L333&quot; target=&quot;_blank&quot;&gt;initial code&lt;/a&gt; for the TurtleScript system uses &lt;a href=&quot;http://javascript.crockford.com/prototypal.html&quot; target=&quot;_blank&quot;&gt;prototype inheritance&lt;/a&gt; (via &lt;code&gt;Object.create&lt;/code&gt;) rather than classical class-style inheritance.  In fact, the &lt;code&gt;new&lt;/code&gt; operator isn&apos;t even included in the Simplified JavaScript/TurtleScript language.&lt;/p&gt;
  547.  
  548. &lt;p&gt;In a discussion of TurtleScript Alan Kay mentioned, &quot;It is very tricky to retain/maintain readability (so the first Smalltalk was also an extensible language not just semantically but syntactically).&quot;  And today I stumbled across the &lt;a href=&quot;http://joose.it/&quot; target=&quot;_blank&quot;&gt;Joose&lt;/a&gt; library, which gives a very &lt;a href=&quot;http://joose.github.com/Joose/doc/html/Joose.html&quot; target=&quot;_blank&quot;&gt;readable syntax&lt;/a&gt; for traditional class-based inheritance.  It backs this up with a robust meta-object protocol, introspection, and lots of nice features borrowed from Perl 6, CLOS, and Smalltalk.  The syntax ought to work fine with the limited tile set of TurtleScript, although I might have to add a tile for the &lt;code&gt;new&lt;/code&gt; operator.&lt;/p&gt;
  549.  
  550. &lt;p&gt;However, adding Joose raises some questions. Is the increase in readability worth the addition of such a large library to the system?  What impact will this have on understanding problems and debugging? Is a return to class-based inheritance a positive change?  (There have been arguments that the make-a-clone-and-change-it practice of prototype inheritance is easier to understand for new learners.)  Can a larger overall system actually be easier to understand?&lt;/p&gt;
  551.  
  552. &lt;p&gt;And once we&apos;re looking at libraries... Nickolay Platonov is now working on &lt;a href=&quot;http://joose.it/blog/2011/04/08/syncler-distributed-applications-for-human-beings/&quot; target=&quot;_blank&quot;&gt;Syncler&lt;/a&gt;, based on the &lt;a href=&quot;http://joose.it/blog/wp-content/uploads/2011/03/Bayou-updates-propagation.pdf&quot; target=&quot;_blank&quot;&gt;Bayou&lt;/a&gt; system.  Unobstructive replication mechanisms would certainly make it easier to construct the sorts of collaborative applications we&apos;ve wanted for &lt;a href=&quot;http://en.wikipedia.org/wiki/Sugar_(desktop_environment)&quot; target=&quot;_blank&quot;&gt;Sugar&lt;/a&gt;.  I have two concerns with Syncler&apos;s current state.  First, the use of &lt;a href=&quot;http://joose.it/blog/2011/02/14/joosex-cps-tutorial-part-i/&quot; target=&quot;_blank&quot;&gt;explicit continuation-passing style&lt;/a&gt; greatly impairs readability.  The JavaScript &lt;code&gt;yield&lt;/code&gt; keyword &lt;a href=&quot;http://blog.ometer.com/2010/11/28/a-sequential-actor-like-api-for-server-side-javascript/&quot; target=&quot;_blank&quot;&gt;helps a lot&lt;/a&gt; when writing asynchronous code.  (It&apos;s not supported by all JavaScript engines, but &lt;code&gt;yield&lt;/code&gt; wouldn&apos;t be hard to add to TurtleScript.)  Second, Syncler&apos;s event model uses explicit callbacks.  I&apos;ve been greatly impressed with the &lt;a href=&quot;http://www.flapjax-lang.org/&quot; target=&quot;_blank&quot;&gt;Flapjax&lt;/a&gt; event model (and its &lt;a href=&quot;http://lamp.epfl.ch/~imaier/pub/DeprecatingObserversTR2010.pdf&quot; target=&quot;_blank&quot;&gt;strongly-typed functional cousin&lt;/a&gt;).  Both of these changes ought to make asynchronous code much more readable&amp;mdash;and isn&apos;t that an important part of &lt;a href=&quot;http://en.wikipedia.org/wiki/Grok&quot; target=&quot;_blank&quot;&gt;grokking&lt;/a&gt; a system?&lt;/p&gt;</description>
  553.  <comments>https://cananian.livejournal.com/64330.html?view=comments#comments</comments>
  554.  <category>javascript</category>
  555.  <category>sugar</category>
  556.  <category>olpc</category>
  557.  <category>turtlescript</category>
  558.  <category>programming</category>
  559.  <lj:security>public</lj:security>
  560.  <lj:reply-count>3</lj:reply-count>
  561.  </item>
  562.  <item>
  563.  <guid isPermaLink='true'>https://cananian.livejournal.com/64140.html</guid>
  564.  <pubDate>Fri, 20 May 2011 06:06:15 GMT</pubDate>
  565.  <title>Turtles All The Way Down</title>
  566.  <author>cananian</author>
  567.  <link>https://cananian.livejournal.com/64140.html</link>
  568.  <description>&lt;p&gt;&lt;img src=&quot;https://imgprx.livejournal.net/9b91b2dab6eaf256d69dd8c4e15906b767c1ec52/p1mSi3tXVUwXGuSe_IHwDid88SdoMSrgGOlcGq7_FH48ARU5d8KRTT0onv8NOmo-98QhFjA5kFoOldhsu7HWYWHktqXe5BmXkvOy1pJ44rDR9ECcAdzXuoKgYBmbcc55&quot; fetchpriority=&quot;high&quot; /&gt;&lt;/p&gt;
  569. &lt;p&gt;Inspired by &lt;a href=&quot;http://croquetweak.blogspot.com/&quot; target=&quot;_blank&quot;&gt;Bert Freudenberg&lt;/a&gt;, &lt;a href=&quot;http://piumarta.com/software/&quot; target=&quot;_blank&quot;&gt;Ian Piumarta&lt;/a&gt;, and &lt;a href=&quot;http://wiki.sugarlabs.org/go/User:Walter&quot; target=&quot;_blank&quot;&gt;Walter Bender&lt;/a&gt;, I started hacking on &quot;Turtles All The Way Down&quot; (aka &lt;a href=&quot;http://cscott.net/Projects/TurtleScript/&quot; target=&quot;_blank&quot;&gt;TurtleScript&lt;/a&gt;) on the plane back from Uruguay.
  570. Now there&apos;s a nice &lt;a href=&quot;http://cscott.net/Projects/TurtleScript/ctiles.html&quot; target=&quot;_blank&quot;&gt;rendering demo&lt;/a&gt; to show what a tile-based editor for JavaScript might look like, as well as a &lt;a href=&quot;http://cscott.net/Projects/TurtleScript/tdop.html&quot; target=&quot;_blank&quot;&gt;bytecode compiler and interpreter&lt;/a&gt; for the language.  The &lt;a href=&quot;https://github.com/cscott/TurtleScript/blob/f977f782bb2bda06d26e5eeb1259db95dd48f2ca/bytecode_table.js&quot; target=&quot;_blank&quot;&gt;bytecode instruction set&lt;/a&gt; is still too large; encouraged by Craig Chambers&apos; work on &lt;a href=&quot;http://selflanguage.org/documentation/published/implementation.html&quot; target=&quot;_blank&quot;&gt;SELF&lt;/a&gt; I think I ought to be able to replace all the unary and binary operators, conditional jumps, and slot selectors by a single &lt;code&gt;mapof&lt;/code&gt; operator.  I can put a better &lt;a href=&quot;http://piumarta.com/software/cola/objmodel2.pdf&quot; target=&quot;_blank&quot;&gt;object model&lt;/a&gt; on the interpreter, too;
  571. I&apos;ve written some &lt;a href=&quot;http://cscott.net/Projects/TurtleScript/#simplifying-the-environment&quot; target=&quot;_blank&quot;&gt;notes on the matter&lt;/a&gt;.&lt;/p&gt;
  572. &lt;p&gt;The question is: does this really have educational value?  &quot;Turtles all the way down&quot; is a great slogan, and a fine way to teach a graduate-level class on compiler technology, but I feel that the higher-level UI for tile-based program editing is the really useful thing for tablet computing.  I&apos;m a compiler geek and love the grungy underbelly of this stuff, but I keep reminding myself I should really be spending more time building a beautiful fluffy surface.&lt;/p&gt;</description>
  573.  <comments>https://cananian.livejournal.com/64140.html?view=comments#comments</comments>
  574.  <category>javascript</category>
  575.  <category>sugar</category>
  576.  <category>olpc</category>
  577.  <category>turtlescript</category>
  578.  <category>turtles</category>
  579.  <lj:security>public</lj:security>
  580.  <lj:reply-count>1</lj:reply-count>
  581.  </item>
  582.  <item>
  583.  <guid isPermaLink='true'>https://cananian.livejournal.com/63783.html</guid>
  584.  <pubDate>Fri, 29 Apr 2011 15:47:57 GMT</pubDate>
  585.  <title>Next Steps for New Technologies</title>
  586.  <author>cananian</author>
  587.  <link>https://cananian.livejournal.com/63783.html</link>
  588.  <description>&lt;p&gt;I&apos;ve reached the end of the month.  I&apos;ve accomplished my
  589. Android and NativeClient-related &lt;a href=&quot;http://cananian.livejournal.com/62667.html&quot; target=&quot;_blank&quot;&gt;goals&lt;/a&gt;, but didn&apos;t get the time to do
  590. as much mesh and python investigation as I&apos;d wanted.  Here are some
  591. ideas for next month&apos;s work.  (Next week I&apos;ll be in Uruguay for &lt;a href=&quot;http://wiki.sugarlabs.org/go/Uruguay_Summit_2011&quot; target=&quot;_blank&quot;&gt;EduJAM&lt;/a&gt;.)&lt;/p&gt;
  592.  
  593. &lt;h3&gt;GObject Introspection (Android or NaCl)&lt;/h3&gt;
  594. &lt;ol&gt;
  595. &lt;li&gt;Start by porting &lt;a href=&quot;http://en.wikipedia.org/wiki/Libffi&quot; target=&quot;_blank&quot;&gt;libffi&lt;/a&gt;.  An android port would be
  596.  straightforward, but since libffi involves code generation
  597.  (&lt;a href=&quot;https://github.com/atgreen/libffi/blob/master/src/arm/ffi.c#L557&quot; target=&quot;_blank&quot;&gt;ARM&lt;/a&gt;, &lt;a href=&quot;https://github.com/atgreen/libffi/blob/master/src/x86/ffi.c#L475&quot; target=&quot;_blank&quot;&gt;x86&lt;/a&gt;), this is going to require a bit of assembly
  598.  magic and the new &quot;JIT&quot;/&quot;shared library&quot; support in the NaCl plugin.&lt;/li&gt;
  599.  
  600. &lt;li&gt;Then port &lt;a href=&quot;http://blogs.gnome.org/johan/2008/06/01/introduction-to-gobject-introspection/&quot; target=&quot;_blank&quot;&gt;gobject-introspection&lt;/a&gt;.  GObject-Introspection relies on
  601.  libffi for its guts, but the &lt;strong&gt;hard&lt;/strong&gt; part of this port will be refactoring
  602.  g-i&apos;s build process, which is &lt;a href=&quot;http://mail.gnome.org/archives/gtk-devel-list/2009-March/msg00062.html&quot; target=&quot;_blank&quot;&gt;not cross-compilation
  603.  friendly&lt;/a&gt;.  Might need to rewrite some tools.  If targeting NaCl, you might consider finishing the &lt;a href=&quot;https://groups.google.com/group/native-client-discuss/msg/1e61ab5f7bd71797&quot; target=&quot;_blank&quot;&gt;code allowing execution of unsandboxed NaCl binaries&lt;/a&gt;.&lt;/li&gt;
  604.  
  605. &lt;li&gt;Turn gobject-introspection on its head: generate GIR and a
  606.  C binding for the platform &quot;native&quot; interface.  For NaCl,
  607.  this would be a &lt;a href=&quot;http://www.w3.org/DOM/Bindings&quot; target=&quot;_blank&quot;&gt;GObject-using C-level binding
  608.  of the browser-native DOM&lt;/a&gt;; for
  609.  Android, this would be a GIR binding of the native Android APIs.  These bindings should be mostly
  610.  automatically generated, since they will need to continue tracking
  611.  successive native platform releases/HTML5 features.&lt;/li&gt;
  612.  
  613. &lt;li&gt;Demos!  Change browser DOM from Python, write native Android apps
  614.  in Python.  Add a gobject-introspection binding to &lt;a href=&quot;http://dev.laptop.org/git/users/wmb/cforth&quot; target=&quot;_blank&quot;&gt;cforth&lt;/a&gt;,
  615.  then do the same from forth.  (Forth might be a simpler place to
  616.  start than Python.  Or not.)&lt;/li&gt;
  617. &lt;/ol&gt;
  618.  
  619. &lt;h3&gt;GTK (Android or NaCl)&lt;/h3&gt;
  620. &lt;ol&gt;
  621. &lt;li&gt; Build on the cairo/pango port to proceed to a full GTK backend for
  622.  Android/NaCl.  These backends ought to be upstreamable.  The NaCl
  623.  port should be based on the &lt;a href=&quot;http://blogs.gnome.org/alexl/2011/03/15/gtk-html-backend-update/&quot; target=&quot;_blank&quot;&gt;broadway&lt;/a&gt; work: the cairo canvas
  624.  would be drawn to more directly, but a lot of the mechanism which
  625.  captures JavaScript events and translates them into the GTK event loop
  626.  could probably be reused.&lt;/li&gt;
  627.  
  628. &lt;li&gt; Demo: &quot;Hello GTK world&quot; in Android/NaCl.&lt;/li&gt;
  629. &lt;/ol&gt;
  630.  
  631. &lt;h3&gt;Sugar partitioning.&lt;/h3&gt;
  632. &lt;p&gt;Bring Sugar closer to being a true
  633. multi-language multi-library platform.&lt;/p&gt;
  634. &lt;ol&gt;
  635. &lt;li&gt; Refactor sugar modules (for example, sugar toolbar widget) as
  636.  standalone C libraries.  Basic idea is to embed Python and export
  637.  a C API, while preserving as much of the code as possible.  Python
  638.  libraries now invoke this library via g-i-r instead of directly.
  639.  The python embedding tool is probably a useful standalone product.&lt;/li&gt;
  640.  
  641. &lt;li&gt; Rewrite &quot;Hello, Sugar&quot; activity in C (or &lt;a href=&quot;http://en.wikipedia.org/wiki/Vala_(programming_language)&quot; target=&quot;_blank&quot;&gt;vala&lt;/a&gt;), using &lt;code&gt;#include&lt;/code&gt; for &lt;code&gt;import&lt;/code&gt;
  642.  and &lt;a href=&quot;http://en.wikipedia.org/wiki/GObject&quot; target=&quot;_blank&quot;&gt;GObject&lt;/a&gt; inheritance instead of python inheritance.  Use this as
  643.  a guide to pull apart sugar into modules (as above) to make this
  644.  code actually work as written.&lt;/li&gt;
  645. &lt;/ol&gt;
  646.  
  647. &lt;h3&gt;Miscellanous topics&lt;/h3&gt;
  648. &lt;ol&gt;
  649. &lt;li&gt; &lt;a href=&quot;http://en.wikipedia.org/wiki/Google_Chrome_OS&quot; target=&quot;_blank&quot;&gt;ChromeOS&lt;/a&gt; w/ touch support.
  650.     &lt;p&gt;Find an appropriate machine, do an installation, what are the
  651.     roadblocks/rough spots?  Can we install on &lt;a href=&quot;http://www.engadget.com/2011/01/09/marvell-powered-olpc-xo-1-75-only-draws-2-watts-of-power-finall/&quot; target=&quot;_blank&quot;&gt;XO-1.75&lt;/a&gt; as a testbed?&lt;/p&gt;
  652. &lt;/li&gt;
  653.  
  654. &lt;li&gt;TurtleArt as JavaScript viewer/editor.
  655.     &lt;p&gt;Revisit &lt;a href=&quot;https://github.com/cscott/TurtleScript#readme&quot; target=&quot;_blank&quot;&gt;TurtleScript&lt;/a&gt; work, but skip over the
  656.     time-consuming &quot;construct an editor&quot; step by reusing the
  657.     (excellent) &lt;a href=&quot;http://wiki.laptop.org/go/Turtle_Art&quot; target=&quot;_blank&quot;&gt;TurtleArt&lt;/a&gt; code.&lt;/p&gt;
  658. &lt;/li&gt;
  659. &lt;li&gt; Mesh: android &lt;a href=&quot;http://lists.olsr.org/pipermail/olsr-dev/2011-April/004439.html&quot; target=&quot;_blank&quot;&gt;olsrd&lt;/a&gt; frontend, build testbed, research 802.11 DCF issues.&lt;/li&gt;
  660. &lt;/ol&gt;
  661.  
  662. &lt;h3&gt;Summary&lt;/h3&gt;
  663. &lt;p&gt;There are four rough topics here; I might try to continue the
  664. breadth-first search by spending a week on each.  It might be more
  665. satisfying to downselect two of these issues and spend two weeks on
  666. each.&lt;/p&gt;</description>
  667.  <comments>https://cananian.livejournal.com/63783.html?view=comments#comments</comments>
  668.  <category>nativeclient</category>
  669.  <category>javascript</category>
  670.  <category>sugar</category>
  671.  <category>olpc</category>
  672.  <category>android</category>
  673.  <category>programming</category>
  674.  <category>mesh</category>
  675.  <lj:security>public</lj:security>
  676.  <lj:reply-count>0</lj:reply-count>
  677.  </item>
  678.  <item>
  679.  <guid isPermaLink='true'>https://cananian.livejournal.com/63595.html</guid>
  680.  <pubDate>Fri, 29 Apr 2011 15:08:56 GMT</pubDate>
  681.  <title>Pango/Android -vs- Pango/NaCl</title>
  682.  <author>cananian</author>
  683.  <link>https://cananian.livejournal.com/63595.html</link>
  684.  <description>&lt;p&gt;At the end of &lt;a href=&quot;http://cananian.livejournal.com/62756.html&quot; target=&quot;_blank&quot;&gt;my Sugar/Android&lt;/a&gt; week, I had a simple
  685. &lt;a href=&quot;http://en.wikipedia.org/wiki/Pango&quot; target=&quot;_blank&quot;&gt;Pango&lt;/a&gt;-on-&lt;a href=&quot;http://en.wikipedia.org/wiki/Cairo_(graphics)&quot; target=&quot;_blank&quot;&gt;Cairo&lt;/a&gt; demo running.  This was built on a stack
  686. of ported libraries, including &lt;a href=&quot;http://en.wikipedia.org/wiki/Gettext&quot; target=&quot;_blank&quot;&gt;gettext&lt;/a&gt;, &lt;a href=&quot;http://cgit.freedesktop.org/pixman/tree/README&quot; target=&quot;_blank&quot;&gt;pixman&lt;/a&gt;,
  687. &lt;a href=&quot;http://en.wikipedia.org/wiki/FreeType&quot; target=&quot;_blank&quot;&gt;freetype&lt;/a&gt;, &lt;a href=&quot;http://en.wikipedia.org/wiki/Libxml2&quot; target=&quot;_blank&quot;&gt;libxml2&lt;/a&gt;, &lt;a href=&quot;http://en.wikipedia.org/wiki/Fontconfig&quot; target=&quot;_blank&quot;&gt;fontconfig&lt;/a&gt;, and &lt;a href=&quot;http://en.wikipedia.org/wiki/Glib&quot; target=&quot;_blank&quot;&gt;glib&lt;/a&gt;,
  688. as well as &lt;a href=&quot;http://en.wikipedia.org/wiki/Cairo_(graphics)&quot; target=&quot;_blank&quot;&gt;cairo&lt;/a&gt; and &lt;a href=&quot;http://en.wikipedia.org/wiki/Pango&quot; target=&quot;_blank&quot;&gt;pango&lt;/a&gt;.  You can run the demo
  689. yourself by &lt;a href=&quot;http://en.wikipedia.org/wiki/Sideloading&quot; target=&quot;_blank&quot;&gt;sideloading&lt;/a&gt; &lt;a href=&quot;http://dev.laptop.org/~cscott/Android/Pango/pango-demo.apk&quot; target=&quot;_blank&quot;&gt;pango-demo.apk&lt;/a&gt; onto your Android
  690. device (tested on a Motorola &lt;a href=&quot;http://en.wikipedia.org/wiki/Motorola_Xoom&quot; target=&quot;_blank&quot;&gt;Xoom&lt;/a&gt;), and you can &lt;a href=&quot;http://dev.laptop.org/git/users/cscott/android-libs/tree/&quot; target=&quot;_blank&quot;&gt;browse the
  691. source code&lt;/a&gt; to see what it entailed (here&apos;s the &lt;a href=&quot;http://dev.laptop.org/git/users/cscott/android-libs/tree/jni/Makefile.devel&quot; target=&quot;_blank&quot;&gt;scariest
  692. part&lt;/a&gt;).  (I was inspired by Akita Noek&apos;s &lt;a href=&quot;https://github.com/anoek/android-cairo&quot; target=&quot;_blank&quot;&gt;android-cairo project&lt;/a&gt;,
  693. but I ended up reworking the build scheme and redoing most of the
  694. ports.)&lt;/p&gt;
  695.  
  696. &lt;a href=&quot;http://dev.laptop.org/~cscott/Android/Pango/screenshot.png&quot; target=&quot;_blank&quot;&gt;&lt;img src=&quot;https://imgprx.livejournal.net/28d8ab2bb527e3657f7f2e86a91818591f07ad4c/p1mSi3tXVUwXGuSe_IHwDvdhl9c3MOPZ6unsGmM4ErFzxk3TlY2IMoGaeIdaiC6PYkdhxFLHFYthKYnuPlkGe0kencJQ6ykAe_lJZ5iAuEg&quot; width=&quot;300&quot; alt=&quot;Screenshot of Pango demo on Android&quot; title=&quot;Pango demo on Android&quot; fetchpriority=&quot;high&quot; /&gt;&lt;/a&gt;
  697.  
  698. &lt;p&gt;It made sense to start my Sugar/&lt;a href=&quot;http://en.wikipedia.org/wiki/Google_Native_Client&quot; target=&quot;_blank&quot;&gt;NaCl&lt;/a&gt; investigation by porting
  699. the same demo application to Native Client.  The same stack of ported
  700. libraries was involved, although it was easy to include more
  701. functionality in the Native Client ports, including threading and
  702. PNG/PS/PDF support in cairo.  The &lt;a href=&quot;http://dev.laptop.org/git/users/cscott/naclports&quot; target=&quot;_blank&quot;&gt;source code&lt;/a&gt; is a fork from
  703. the upstream &lt;a href=&quot;http://code.google.com/p/naclports/&quot; target=&quot;_blank&quot;&gt;naclports&lt;/a&gt; project, and the process was generally much cleaner.
  704. (But see my previous post for some &lt;a href=&quot;http://cananian.livejournal.com/63325.html&quot; target=&quot;_blank&quot;&gt;caveats regarding naclports&lt;/a&gt;.)
  705. If you&apos;re using Chrome 10 or 11, you can &lt;a href=&quot;http://dev.laptop.org/~cscott/NaCl/Pango/cairo.html&quot; target=&quot;_blank&quot;&gt;run the demo in your
  706. browser&lt;/a&gt; (follow the instructions on that page).  The
  707. Wesnoth team has a parallel project which &lt;a href=&quot;https://groups.google.com/group/native-client-discuss/msg/8bfa6401e4951551?pli=1&quot; target=&quot;_blank&quot;&gt;ported some of these libraries as well&lt;/a&gt;, but
  708. not in an upstreamable manner.&lt;/p&gt;
  709.  
  710. &lt;a href=&quot;http://dev.laptop.org/~cscott/NaCl/Pango/screenshot.png&quot; target=&quot;_blank&quot;&gt;&lt;img src=&quot;https://imgprx.livejournal.net/78f325f7523b8dc6fe87f38eafed29f56ae80467/p1mSi3tXVUwXGuSe_IHwDvdhl9c3MOPZ6unsGmM4ErE2UeGWLdo5S1WP86H0YJ4HVx5RpW7REm3nrrnLMIyaXVhL5inVoDn5EYWGS-sdFZ0&quot; width=&quot;300&quot; alt=&quot;Screenshot of Pango demo on Native Client&quot; title=&quot;Pango demo on NaCl&quot; loading=&quot;lazy&quot; /&gt;&lt;/a&gt;
  711.  
  712. &lt;p&gt;The demo app uses cairo to draw the background, an animated X, and
  713. some basic text in the center; it uses Pango&apos;s advanced international
  714. text support to draw properly-shaped Persian text in a circle
  715. around it.  The center text is the &quot;proper&quot; bilingual Greek/Japanese
  716. written form of &quot;pango&quot;; the text around the edges is the Persian name of
  717. the internationalization library, &quot;harfbuzz&quot;.  Note that the Persian
  718. text is written right-to-left&amp;mdash;and that I didn&apos;t put a full CJK
  719. font in the NaCl app, so the Japanese &quot;go&quot; character is missing.
  720. The Android port rebuilds the font cache at each startup, so it loads
  721. rather slowly; the NaCl port contains a prebuilt font cache so it starts
  722. more quickly.&lt;/p&gt;
  723.  
  724. &lt;p&gt;&lt;b&gt;Both ports took about two weeks.&lt;/b&gt;  I blew my &lt;a href=&quot;http://cananian.livejournal.com/62667.html&quot; target=&quot;_blank&quot;&gt;original schedule&lt;/a&gt;,
  725. partly due to the Patriot&apos;s day holiday, and partly because I&apos;d given
  726. Android about a week&apos;s head start by tinkering on it before my
  727. original schedule post.  The framerate of the demo is much better on
  728. NaCl (so fast that the edges of the animated X look choppy in the
  729. screenshot), but the hardware isn&apos;t easily comparable, so the
  730. comparison doesn&apos;t really tell us much.  The porting effort was
  731. certainly more pleasant on NaCl, since newlib is a much more complete
  732. libc than Android&apos;s &quot;Bionic&quot;&amp;mdash;but having gdb available made
  733. debugging on Android easier.  (There is an unintegrated NaCl branch that
  734. &lt;a href=&quot;https://groups.google.com/group/native-client-discuss/browse_thread/thread/e11fdea235fa3702&quot; target=&quot;_blank&quot;&gt;integrates NaCl gdb in the browser&lt;/a&gt;, though!)&lt;/p&gt;
  735.  
  736. &lt;p&gt;Much of the GNOME/POSIX library stack assumes access to a filesystem
  737. tree and does file-based configuration.  In our demo application,
  738. fontconfig was the most culpable party: it wanted to load a
  739. configuration file describing font locations and naming, then to load
  740. the fonts themselves from the file system, and finally to write a
  741. cache file describing what it found back to the file system.  Most
  742. ported software is going to want similar access&amp;mdash;even if you store
  743. the user&apos;s own documents in a &lt;a href=&quot;http://wiki.laptop.org/go/Journal_Activity&quot; target=&quot;_blank&quot;&gt;Journal&lt;/a&gt;, software still expects
  744. to find configuration, caches, and other data in a filesystem.&lt;/p&gt;
  745.  
  746. &lt;p&gt;Android provides the &lt;b&gt;POSIX filesystem APIs&lt;/b&gt;, but the filesystem an app can
  747. touch is segmented and sandboxed.  As discussed previously, Android&apos;s
  748. &lt;a href=&quot;http://developer.android.com/reference/android/os/storage/StorageManager.html&quot; target=&quot;_blank&quot;&gt;Opaque Binary Blob&lt;/a&gt; feature may allow you to create a app-specific
  749. filesystem, but this doesn&apos;t let you share (for example) fonts and
  750. font configuration between activities.  NaCl might eventually provide
  751. a similar unshared mechanism based on the HTML5 &lt;a href=&quot;http://www.html5rocks.com/tutorials/appcache/beginner/&quot; target=&quot;_blank&quot;&gt;AppCache&lt;/a&gt;.&lt;/p&gt;
  752.  
  753. &lt;p&gt;The preferred solution is more limited, but more flexible: no built-in
  754. filesystem APIs are used (or in NaCl&apos;s case, provided!) at all.
  755. Instead, you provide your own implementation of the POSIX file APIs
  756. (either via the &lt;a href=&quot;https://groups.google.com/group/native-client-discuss/msg/4b84cd47910430e2&quot; target=&quot;_blank&quot;&gt;--wrap linker indirection&lt;/a&gt; or through an appropriate
  757. backend to newlib/glibc/glib).  For the NaCl demo app, I wrote a
  758. rather-elaborate &lt;a href=&quot;http://dev.laptop.org/git/users/cscott/naclports/tree/src/examples/graphics/cairo/cairo_files.c&quot; target=&quot;_blank&quot;&gt;in-memory filesystem&lt;/a&gt; --- only to find that an
  759. even-more-elaborate one &lt;a href=&quot;http://dev.laptop.org/git/users/cscott/naclports/tree/src/packages/scripts/memory_filesys&quot; target=&quot;_blank&quot;&gt;already existed in naclports&lt;/a&gt;.  But the
  760. longer-term solution uses message-passing (&lt;a href=&quot;https://sites.google.com/a/chromium.org/dev/nativeclient/how-tos/simple-rpc&quot; target=&quot;_blank&quot;&gt;SRPC&lt;/a&gt; in NaCl, &lt;a href=&quot;http://developer.android.com/guide/topics/intents/intents-filters.html&quot; target=&quot;_blank&quot;&gt;intents&lt;/a&gt; in
  761. Android) to implement these POSIX APIs.  In Native Client, the
  762. implementation would be in browser-side JavaScript, which would then
  763. allow you to share parts of the filesystem tree between activities
  764. and/or map it into (cached) web-addressed resources.  In either case,
  765. your application still sees the bog-standard POSIX API it expects.&lt;/p&gt;
  766.  
  767. &lt;p&gt;More problematic are the &lt;b&gt;networking APIs&lt;/b&gt;.  Here Android provides
  768. a pretty standard socket library, while Native Client provides
  769. nothing at all.  Using a browser-based implementation, as for
  770. the file APIs, will work fine for HTTP, &lt;a href=&quot;http://en.wikipedia.org/wiki/WebSockets&quot; target=&quot;_blank&quot;&gt;WebSockets&lt;/a&gt; and even P2P via the
  771. &lt;a href=&quot;http://rtc-web.alvestrand.com/home/papers/juberti-p2ptransport-api.pdf&quot; target=&quot;_blank&quot;&gt;HTML5 P2P APIs&lt;/a&gt;.  But it&apos;s not clear that (for example) glib&apos;s
  772. elaborate &lt;a href=&quot;http://git.gnome.org/browse/glib/tree/gio/libasyncns/asyncns.c&quot; target=&quot;_blank&quot;&gt;asynchronous DNS name resolver implementation&lt;/a&gt; can (or
  773. should!) be implemented in a NaCl port.&lt;/p&gt;
  774.  
  775. &lt;p&gt;In the end, the porting effort and abstraction shifts needed for
  776. Native Client and Android are &lt;b&gt;roughly comparable&lt;/b&gt;.  I expect
  777. Native Client will hold a strong edge in allowing close
  778. integration with web standards and web technologies.  Android will
  779. probably continue to hold an edge in third-party application support and
  780. platform maturity.&lt;/p&gt;</description>
  781.  <comments>https://cananian.livejournal.com/63595.html?view=comments#comments</comments>
  782.  <category>nativeclient</category>
  783.  <category>sugar</category>
  784.  <category>olpc</category>
  785.  <category>android</category>
  786.  <category>programming</category>
  787.  <category>gnome</category>
  788.  <lj:security>public</lj:security>
  789.  <lj:reply-count>1</lj:reply-count>
  790.  </item>
  791.  <item>
  792.  <guid isPermaLink='true'>https://cananian.livejournal.com/63325.html</guid>
  793.  <pubDate>Fri, 29 Apr 2011 14:24:36 GMT</pubDate>
  794.  <title>Sugar-on-Native Client investigation</title>
  795.  <author>cananian</author>
  796.  <link>https://cananian.livejournal.com/63325.html</link>
  797.  <description>&lt;p&gt;This post will describe the state of Native Client in general, based on
  798. week 2 of my &lt;a href=&quot;http://cananian.livejournal.com/62667.html&quot; target=&quot;_blank&quot;&gt;original four week plan&lt;/a&gt;.  In the next post, I&apos;ll
  799. link to my work so far, and compare the Native Client and the Android
  800. efforts. Recapping, the end goal of these explorations is a platform for the next generation of the
  801. &lt;a href=&quot;http://en.wikipedia.org/wiki/Sugar_(desktop_environment)&quot; target=&quot;_blank&quot;&gt;Sugar learning environment&lt;/a&gt;.&lt;/p&gt;
  802.  
  803. &lt;p&gt;To begin, the Native Client (NaCl) plugin is fairly mature in a number of
  804. areas.  Version &lt;a href=&quot;http://code.google.com/chrome/nativeclient/docs/releasenotes.html&quot; target=&quot;_blank&quot;&gt;0.2 of the NaCl SDK&lt;/a&gt; was recently released (a
  805. version number which substantiates the &quot;fairly&quot; in my previous
  806. sentence), and the NativeClient plugin is currently shipping in Chrome
  807. (versions 10 and 11), although you have to manually turn on a
  808. preference in the &lt;code&gt;about:flags&lt;/code&gt; dialog to enable it.  The
  809. NaCl toolchain is much more standard than the Android NDK toolchain &lt;a href=&quot;http://cananian.livejournal.com/62756.html&quot; target=&quot;_blank&quot;&gt;I
  810. discussed previously&lt;/a&gt;, and the robust &lt;a href=&quot;http://code.google.com/p/naclports/&quot; target=&quot;_blank&quot;&gt;naclports&lt;/a&gt; tree shows
  811. that the patches required for NaCl ports of common packages &lt;a href=&quot;http://code.google.com/p/naclports/source/browse/trunk/src/packages/scripts/pixman-0.16.2/nacl-pixman-0.16.2.patch&quot; target=&quot;_blank&quot;&gt;tend not
  812. to be too evil&lt;/a&gt;.  The &lt;a href=&quot;http://wiki.tcl.tk/28211&quot; target=&quot;_blank&quot;&gt;Tcl
  813. interpreter&lt;/a&gt; and &lt;a href=&quot;http://dev.laptop.org/~cscott/NaCl/Qt/&quot; target=&quot;_blank&quot;&gt;Qt tookit port&lt;/a&gt; demos show that fairly complex pieces of code can be deployed today on NaCl.&lt;/p&gt;
  814.  
  815. &lt;p&gt;On the other hand, there are three main difficulties:&lt;/p&gt;
  816. &lt;ol&gt;
  817. &lt;li&gt; The default NaCl toolchain uses &lt;a href=&quot;http://en.wikipedia.org/wiki/Newlib&quot; target=&quot;_blank&quot;&gt;newlib&lt;/a&gt; as its standard C library.
  818. This is consistent with Google&apos;s preference for BSD-licensed code in
  819. SDKs they provide to the public (see the &lt;a href=&quot;http://codingrelic.geekhold.com/2008/11/six-million-dollar-libc.html&quot; target=&quot;_blank&quot;&gt;discussion of Bionic in the
  820. Android SDK&lt;/a&gt;).  However, there also exists &lt;a href=&quot;https://groups.google.com/group/native-client-discuss/msg/16bcc685269fa09e&quot; target=&quot;_blank&quot;&gt;a branch of the SDK which
  821. uses glibc&lt;/a&gt;.  The glibc branch supports several additional
  822. features, like &lt;a href=&quot;http://code.google.com/p/nativeclient/issues/detail?id=565&quot; target=&quot;_blank&quot;&gt;shared library support&lt;/a&gt;.  However, it is unclear
  823. whether this will ever be a &quot;supported&quot; part of the SDK.  If glibc does
  824. become supported, it is unlikely ever to be the &lt;i&gt;only&lt;/i&gt; supported libc;
  825. the BSD-licensed newlib will need to remain available as an option.
  826. (Yes, the LGPL license of glibc shouldn&apos;t inspire such paranoia, but
  827. Google has elected not to undertake the education of all prospective
  828. third-party developers.)&lt;/li&gt;
  829.  
  830. &lt;li&gt; The naclports project, although fairly robust, is driven between the
  831. &lt;a href=&quot;http://en.wikipedia.org/wiki/Between_Scylla_and_Charybdis&quot; target=&quot;_blank&quot;&gt;Scylla and Charybdis&lt;/a&gt; of compatibility.  The goal is that all
  832. the code in naclports be buildable at all times on all three major
  833. platforms: Windows, Mac, and Linux.  Further, it should support both
  834. x86_32 and x86_64 backends, and ideally ARM and &lt;a href=&quot;http://nativeclient.googlecode.com/svn/data/site/pnacl.pdf&quot; target=&quot;_blank&quot;&gt;pNaCl&lt;/a&gt; as well.
  835. It&apos;s &lt;a href=&quot;http://build.chromium.org/p/client.nacl.ports/console&quot; target=&quot;_blank&quot;&gt;auto-built&lt;/a&gt; against the latest SDK sources, but should also work
  836. on the latest &lt;i&gt;released&lt;/i&gt; SDK.  And with the addition of the
  837. glibc/newlib split discussed above, the possible build targets are
  838. multiplied further.  Needless to say, keeping the tree building
  839. against such a large number of variants is not an easy task, and
  840. naclports is usually broken in some way.  In practice, most developers
  841. seem to pay attention to some subset (say, x86_32/newlib/Linux host),
  842. but it&apos;s hard to push patches upstream without worrying about breaking
  843. some obscure target.  It might be best to base future work on a
  844. proper package technology, like (say) dpkg-cross.&lt;/li&gt;
  845.  
  846. &lt;li&gt; In general, a lot of interesting NaCl development has occurred on
  847. branches that are not easily integrated.  I&apos;ve already mentioned glibc
  848. support, which is a toolchain branch; shared library support is on
  849. another branch that requires a new chromium plugin as well.  At
  850. various times different means have been implemented to run NaCl
  851. binaries &quot;natively&quot; outside the sandbox (for example, in order to test
  852. some feature at build time, or auto-generate some piece of code via
  853. introspection).  These efforts live on abandoned branches, while the
  854. &quot;official&quot; means to do this is incomplete.  Similarly, a lot of
  855. interesting NaCl work used the now-abandoned legacy &quot;&lt;a href=&quot;http://en.wikipedia.org/wiki/NPAPI&quot; target=&quot;_blank&quot;&gt;NPAPI&lt;/a&gt;&quot; plugin
  856. interface to interact with the browser.  It was followed by the
  857. &quot;Pepper&quot; plugin interface, which was &lt;a href=&quot;https://wiki.mozilla.org/NPAPI:Pepper&quot; target=&quot;_blank&quot;&gt;itself abandoned&lt;/a&gt;.  Current
  858. work uses the &lt;a href=&quot;http://code.google.com/p/ppapi/&quot; target=&quot;_blank&quot;&gt;Pepper2&lt;/a&gt; browser plugin APIs, which
  859. (unfortunately) have not yet been implemented in non-Chrome browsers
  860. and continue to flux about.  Many interesting browser interactions
  861. exist only in deprecated Pepper APIs, not having yet been built into
  862. Pepper2.  ARM and pNaCl work also appears to be on unintegrated
  863. branches.  There are a number of different &lt;a href=&quot;https://sites.google.com/a/chromium.org/dev/nativeclient/how-tos/debuggingtips&quot; target=&quot;_blank&quot;&gt;gdb support
  864. strategies&lt;/a&gt;.&lt;/li&gt;
  865. &lt;/ol&gt;
  866.  
  867. &lt;p&gt;None of these difficulties is insurmountable&amp;mdash;and in fact, some
  868. are side-effects of the desirable active development and
  869. productization of Native Client.  To date I&apos;ve done my work on the
  870. (more compatible) SDK v0.1 and the (more upstreamable) newlib library.
  871. So far newlib has not been a huge obstacle, and this basis allows my
  872. patches and ports to be more broadly useful.  This might change in the
  873. future&amp;mdash;certainly at some point we need to move to ARM and/or
  874. pNaCl for XO-3, which will probably require building chrome and the NaCl
  875. toolchain from scratch.  At that point, it may be worth further
  876. exploring the non-mainstream branches.&lt;/p&gt;</description>
  877.  <comments>https://cananian.livejournal.com/63325.html?view=comments#comments</comments>
  878.  <category>nativeclient</category>
  879.  <category>sugar</category>
  880.  <category>olpc</category>
  881.  <category>programming</category>
  882.  <lj:security>public</lj:security>
  883.  <lj:reply-count>1</lj:reply-count>
  884.  </item>
  885.  <item>
  886.  <guid isPermaLink='true'>https://cananian.livejournal.com/62756.html</guid>
  887.  <pubDate>Tue, 12 Apr 2011 17:40:48 GMT</pubDate>
  888.  <title>Sugar-on-Android, week one</title>
  889.  <author>cananian</author>
  890.  <link>https://cananian.livejournal.com/62756.html</link>
  891.  <description>&lt;p&gt;Last week I described a four-week plan to survey key technologies for
  892. One Laptop Per Child&apos;s forthcoming XO-3 tablet computer.  Here I&apos;ll
  893. describe the results of the first week of work, which dove into
  894. Google&apos;s Android operating system.  &lt;i&gt;Warning: technical content ahead...&lt;/i&gt;&lt;/p&gt;
  895.  
  896. &lt;h3&gt;Basic design of Sugar-on-Android&lt;/h3&gt;
  897. &lt;ol&gt;
  898. &lt;li&gt;Cross-compile gobject/GTK/gobject-introspection/cairo/dbus for Android;
  899. distribute these key libraries as &lt;a href=&quot;http://developer.android.com/sdk/ndk/&quot; target=&quot;_blank&quot;&gt;NDK&lt;/a&gt; libraries.  This is what I spent
  900. most of my time on this week: I&apos;ve managed so far to port libiconv, gettext,
  901. glib, pixman, freetype, fontconfig, cairo, libxml2, and pango. (&lt;a href=&quot;http://dev.laptop.org/git/users/cscott/android-libs&quot; target=&quot;_blank&quot;&gt;Source code&lt;/a&gt;)&lt;/li&gt;
  902. &lt;li&gt;Use cairo or OpenGL backends of GTK3 to render legacy Sugar activities directly to Android
  903. canvas.&lt;/li&gt;
  904. &lt;li&gt;Modularize sugar; use &lt;a href=&quot;http://www.freedesktop.org/wiki/Software/dbus&quot; target=&quot;_blank&quot;&gt;D-Bus&lt;/a&gt; for inter-module communication.
  905. Interprocess communication mechanism is Android &lt;a href=&quot;http://developer.android.com/guide/topics/intents/intents-filters.html&quot; target=&quot;_blank&quot;&gt;&apos;intents&apos;&lt;/a&gt;; these can
  906. &lt;a href=&quot;http://developer.android.com/resources/articles/can-i-use-this-intent.html&quot; target=&quot;_blank&quot;&gt;redirect to the web or the Android Market for missing dependencies&lt;/a&gt;.  (&lt;a href=&quot;http://blogs.gnome.org/uraeus/2011/04/12/gstreamer-and-android/&quot; target=&quot;_blank&quot;&gt;Collabora reportedly already has a D-Bus implementation for Android&lt;/a&gt;.)  Sugar components can also become Android &lt;a href=&quot;http://developer.android.com/guide/topics/fundamentals/services.html&quot; target=&quot;_blank&quot;&gt;Services&lt;/a&gt;.&lt;/li&gt;
  907. &lt;li&gt;Implement Sugar &lt;a href=&quot;http://wiki.sugarlabs.org/go/Human_Interface_Guidelines/The_Laptop_Experience/Zoom_Metaphor&quot; target=&quot;_blank&quot;&gt;Home/Groups/Neighborhood&lt;/a&gt; views and &lt;a href=&quot;http://wiki.sugarlabs.org/go/Human_Interface_Guidelines/The_Laptop_Experience/The_Journal&quot; target=&quot;_blank&quot;&gt;Journal&lt;/a&gt; as four separate Android
  908. &lt;a href=&quot;http://developer.android.com/guide/topics/appwidgets/index.html&quot; target=&quot;_blank&quot;&gt;App Widgets&lt;/a&gt;.  These could also be implemented by &lt;a href=&quot;http://developer.android.com/resources/samples/Home/index.html&quot; target=&quot;_blank&quot;&gt;providing a new Android home application&lt;/a&gt;, but I think the finer-grained modularity afforded by splitting these functions would yield a better design and make it easier to incorporate upstream improvements to the Android launcher.(Android &lt;a href=&quot;http://developer.android.com/resources/samples/CubeLiveWallpaper/index.html&quot; target=&quot;_blank&quot;&gt;Live Wallpaper&lt;/a&gt; is also similar in function, but not as good a fit.)&lt;/li&gt;
  909. &lt;li&gt;The Sugar &lt;a href=&quot;http://wiki.sugarlabs.org/go/Human_Interface_Guidelines/The_Laptop_Experience/The_Journal&quot; target=&quot;_blank&quot;&gt;Journal&lt;/a&gt; becomes an Android &lt;a href=&quot;http://developer.android.com/guide/topics/providers/content-providers.html&quot; target=&quot;_blank&quot;&gt;&quot;Content Provider&quot;&lt;/a&gt;, which
  910. stores/retrieves content for other Sugar activities. (There is special Android support for &lt;a href=&quot;http://developer.android.com/resources/samples/WeatherListWidget/index.html&quot; target=&quot;_blank&quot;&gt;&quot;collection-based Widgets&quot;&lt;/a&gt; and &lt;a href=&quot;http://developer.android.com/resources/articles/live-folders.html&quot; target=&quot;_blank&quot;&gt;Live Folders&lt;/a&gt; which may be helpful.)&lt;/li&gt;
  911. &lt;li&gt;Use &lt;a href=&quot;https://live.gnome.org/GObjectIntrospection&quot; target=&quot;_blank&quot;&gt;gobject-introspection&lt;/a&gt; to build a multi-language environment.
  912. Use &lt;a href=&quot;http://live.gnome.org/JGIR&quot; target=&quot;_blank&quot;&gt;JGIR&lt;/a&gt; to expose Sugar APIs to &quot;native&quot;
  913. Dalvik apps; use something like the &lt;a href=&quot;http://code.google.com/p/android-scripting/&quot; target=&quot;_blank&quot;&gt;Android Scripting Environment&lt;/a&gt; to expose Android native
  914. APIs to GIR languages (Python, JavaScript, C, etc).&lt;/li&gt;
  915. &lt;li&gt;[opportunity] Use the &lt;a href=&quot;http://www.olsr.org/?q=node/30&quot; target=&quot;_blank&quot;&gt;Android port of OLSRd&lt;/a&gt; to implement a &lt;a href=&quot;http://wiki.sugarlabs.org/go/Human_Interface_Guidelines/The_Laptop_Experience/Zoom_Metaphor#Neighborhood&quot; target=&quot;_blank&quot;&gt;Neighborhood view&lt;/a&gt;.
  916. Alternatively, investigate &lt;a href=&quot;http://code.google.com/p/adhoc-on-android/&quot; target=&quot;_blank&quot;&gt;AODV routing on Android&lt;/a&gt; and/or &lt;a href=&quot;https://www.alljoyn.org&quot; target=&quot;_blank&quot;&gt;AllJoyn&lt;/a&gt; (which also requires root access, see &lt;a href=&quot;https://www.alljoyn.org/sites/default/files/80-BA001-1_C_AllJoyn-Android-NDK-Developer-Guide.pdf&quot; target=&quot;_blank&quot;&gt;pg 24-25 of the manual&lt;/a&gt;).&lt;/li&gt;
  917. &lt;/ol&gt;
  918.  
  919. &lt;h3&gt;Key Benefits&lt;/h3&gt;
  920. &lt;ul&gt;
  921. &lt;li&gt;Sugar is integrated into Android environment; use native Android
  922. education apps, or apps like &lt;a href=&quot;http://www.gottabemobile.com/2011/02/18/android-3-0-honeycomb-movie-studio-enables-movie-editing-on-the-go/&quot; target=&quot;_blank&quot;&gt;Movie Studio&lt;/a&gt; which have no Sugar
  923. equivalents yet.&lt;/li&gt;
  924. &lt;li&gt;Android APIs and customization hooks are good, and provide a
  925. more-extensible framework for development.&lt;/li&gt;
  926. &lt;/ul&gt;
  927.  
  928. &lt;h3&gt;Open challenges (general)&lt;/h3&gt;
  929. &lt;ol&gt;
  930. &lt;li&gt;The web integration story is cloudy.  &lt;a href=&quot;http://code.google.com/p/apps-for-android/source/browse/trunk/Samples/WebViewDemo/src/com/google/android/webviewdemo/WebViewDemo.java&quot; target=&quot;_blank&quot;&gt;Java and JavaScript can call each other inside a bundled WebView widget&lt;/a&gt;,
  931. but this isn&apos;t supported in standard Browser app.  Browser plugin interface would help.&lt;/li&gt;
  932. &lt;li&gt;No good story for building &apos;native&apos; &lt;a href=&quot;http://en.wikipedia.org/wiki/Dalvik_(software)&quot; target=&quot;_blank&quot;&gt;Java/Dalvik&lt;/a&gt; or C apps on the device.
  933. Writing a simple Dalvik compiler would help.  &lt;a href=&quot;http://en.wikipedia.org/wiki/Dalvik_(software)#External_links&quot; target=&quot;_blank&quot;&gt;Dalvik specs are available&lt;/a&gt;, and people have
  934. written &lt;a href=&quot;http://benlynn.blogspot.com/2009/02/compiler-compilers_11.html&quot; target=&quot;_blank&quot;&gt;Dalvik compilers for toy languages&lt;/a&gt;.&lt;/li&gt;
  935. &lt;li&gt;&quot;View source&quot; requests can be implemented as an Android &apos;intent&apos; message,
  936. but no good story for implementing this functionality other than on a case-by-case basis in each activity.&lt;/li&gt;
  937. &lt;li&gt;Although the Amazon Marketplace for Android indicates that it can be done, it appears that there is no &quot;blessed&quot; mechanism for creating .apk files on the device and installing them. (&lt;a href=&quot;http://code.google.com/p/android/issues/detail?id=545&quot; target=&quot;_blank&quot;&gt;Android bug&lt;/a&gt;, &lt;a href=&quot;http://groups.google.com/group/android-developers/browse_thread/thread/fe0978b471d4bef4/72507bfb7586aded?lnk=gst&quot; target=&quot;_blank&quot;&gt;discussion&lt;/a&gt;)&lt;/li&gt;
  938. &lt;/ol&gt;
  939.  
  940. &lt;h3&gt;Current technical issues/bugs&lt;/h3&gt;
  941. &lt;ol&gt;
  942. &lt;li&gt;Cross-compiling for Android is currently a miserable
  943. experience.  The Android NDK appears to have been put together by a
  944. team which had never seen a proper cross-compiler before.  Since I
  945. only had a week for this exploration, I mostly &lt;a href=&quot;http://dev.laptop.org/git/users/cscott/android-libs/tree/jni/Makefile.devel&quot; target=&quot;_blank&quot;&gt;kludged things together&lt;/a&gt;
  946. to get past this, but any serious work with Android should start by
  947. defining and upstreaming proper autoconf &quot;target triplets&quot; for
  948. Android-on-{ARMv5, ARMv7, x86} and building a proper cross-compiler.
  949. Then patches to various tools and libraries could start being
  950. upstreamed.  Using the bespoke &lt;code&gt;Android.mk&lt;/code&gt; build system of the NDK is
  951. a non-starter.  No serious obstacles here, just work to
  952. do.&lt;/li&gt;
  953. &lt;li&gt;Xoom hardware is ARMv7, but &lt;a href=&quot;http://groups.google.com/group/android-ndk/browse_thread/thread/a19fc6df3d661d79&quot; target=&quot;_blank&quot;&gt;Android emulator is ARMv5 only&lt;/a&gt;.
  954. Unfortunately, gdb is broken on the Xoom.  So we&apos;re
  955. building for ARMv5 at the moment, so we can debug in the (slow) emulator.&lt;/li&gt;
  956. &lt;li&gt;No good support for shared libraries may cause activity bloat.
  957. May be able to be worked around using the &lt;a href=&quot;http://developer.android.com/reference/android/os/storage/StorageManager.html&quot; target=&quot;_blank&quot;&gt;new Opaque Binary Blob (OBB) feature&lt;/a&gt;.&lt;/li&gt;
  958. &lt;li&gt;Much existing code (fontconfig, gettext, gtk, etc) expects to read
  959. configuration files from the filesystem.  Currently we are using the
  960. default fall-back configurations.  OBB support may help here as well.
  961. There are a number of different &lt;a href=&quot;http://developer.android.com/guide/topics/data/data-storage.html&quot; target=&quot;_blank&quot;&gt;storage APIs in Android&lt;/a&gt;, but none seems quite right.
  962. &lt;/li&gt;
  963. &lt;li&gt;It would be nice to implement a ring-style XO home screen without
  964. completing replacing the android Launcher.  No clear way to constrain
  965. app layout on home screen w/o completely replacing the Launcher.
  966. Is it worth hacking the &lt;a href=&quot;http://android.git.kernel.org/?p=platform/packages/apps/Launcher2.git;a=summary&quot; target=&quot;_blank&quot;&gt;Launcher source&lt;/a&gt;?&lt;/li&gt;
  967. &lt;li&gt;Mesh on Android using OLSRd current requires root access.  In order
  968. to run on unrooted Android devices, we need (a) proper power
  969. management for Ad Hoc mode wifi, (b) APIs to enable Ad Hoc mode, and
  970. (c) APIs to manipulate kernel routes.&lt;/li&gt;
  971. &lt;li&gt;We&apos;re building libraries without thread support because Android&apos;s
  972. &quot;Bionic&quot; libc has an eccentric thread library.  Linking with
  973. &lt;code&gt;-lpthread&lt;/code&gt; fails because the thread functionality is bundled into &lt;code&gt;-lc&lt;/code&gt;.
  974. Probably just providing an empty &lt;code&gt;libpthread.so&lt;/code&gt; would help a lot.&lt;/li&gt;
  975. &lt;li&gt;Some work has been done to build GNU libc for Android.  This bloats
  976. activities even further, but might help ease library porting.&lt;/li&gt;
  977.  
  978. &lt;li&gt;Porting gobject-introspection will be painful because &lt;a href=&quot;http://mail.gnome.org/archives/gtk-devel-list/2009-March/msg00062.html&quot; target=&quot;_blank&quot;&gt;its makefiles
  979.  are not set up for cross-compiling&lt;/a&gt;.  Some steps want to run on the
  980.  target hardware, which is difficult in the Android environment.&lt;/li&gt;
  981. &lt;/ol&gt;
  982.  
  983. &lt;h3&gt;Bottom line&lt;/h3&gt;
  984.  
  985. &lt;p&gt;I can see how the whole Sugar stack can be put together on the Android
  986. platform.  The hardest part is probably just setting up packaging
  987. and a good and repeatable build environment for the different
  988. components, and getting enough adoption of this that patches to
  989. support Android can be pushed upstream.  Many of the important pieces
  990. can be developed in parallel (Theme, Journal, Mesh, Friends, Home,
  991. library porting, etc).  A little early to tell how hard it will be
  992. to port existing Sugar activities to the new Python/pygobject/GTK3
  993. framework.&lt;/p&gt;</description>
  994.  <comments>https://cananian.livejournal.com/62756.html?view=comments#comments</comments>
  995.  <category>sugar</category>
  996.  <category>olpc</category>
  997.  <category>android</category>
  998.  <lj:security>public</lj:security>
  999.  <lj:reply-count>5</lj:reply-count>
  1000.  </item>
  1001.  <item>
  1002.  <guid isPermaLink='true'>https://cananian.livejournal.com/62667.html</guid>
  1003.  <pubDate>Mon, 04 Apr 2011 21:48:52 GMT</pubDate>
  1004.  <title>Exploring New Technologies</title>
  1005.  <author>cananian</author>
  1006.  <link>https://cananian.livejournal.com/62667.html</link>
  1007.  <description>&lt;p&gt;Last Monday I rejoined &lt;a href=&quot;http://laptop.org&quot; target=&quot;_blank&quot;&gt;One Laptop Per Child&lt;/a&gt; as Director, New
  1008. Technologies.  My mandate is hardware and software for the XO-3,
  1009. OLPC&apos;s upcoming ARM-based tablet computer for education in the
  1010. developing world.  The new machine should be lower cost, lower power,
  1011. more indestructible, more powerful, and potentially more expandable
  1012. than ever.  There are &lt;a href=&quot;http://wiki.laptop.org/go/Deployments&quot; target=&quot;_blank&quot;&gt;about two million machines&lt;/a&gt; in the XO-1 family
  1013. (XO-1, XO-1.5) in the hands of kids
  1014. today. The XO-3 will build upon
  1015. this impressive foundation to reach further into the poorest and
  1016. least-connected regions of the world.&lt;/p&gt;
  1017.  
  1018. &lt;p&gt;I will kick-off my work with a series of &lt;b&gt;four week-long sprints&lt;/b&gt;
  1019. between now and &lt;a href=&quot;http://wiki.sugarlabs.org/go/Uruguay_Summit_2011&quot; target=&quot;_blank&quot;&gt;eduJAM Uruguay&lt;/a&gt;
  1020. to investigate a
  1021. number of possible directions for the educational software stack on
  1022. the XO-3 tablet.  On the XO-1&amp;mdash;series machines OLPC ships &lt;a href=&quot;http://en.wikipedia.org/wiki/Sugar_(desktop_environment)&quot; target=&quot;_blank&quot;&gt;Sugar&lt;/a&gt;, an
  1023. impressive collection of educational software developed by
  1024. &lt;a href=&quot;http://sugarlabs.org/&quot; target=&quot;_blank&quot;&gt;Sugar Labs&lt;/a&gt;.  How can we best keep
  1025. the best of Sugar while yanking the UI forward into a touch-friendly
  1026. tablet world?&lt;/p&gt;
  1027.  
  1028. &lt;ol&gt;
  1029. &lt;li&gt;This week (April 4-8) I&apos;ll begin by working on a &lt;b&gt;port of the &lt;a href=&quot;http://gtk.org&quot; target=&quot;_blank&quot;&gt;GTK3&lt;/a&gt; UI library to
  1030. &lt;a href=&quot;http://en.wikipedia.org/wiki/Android_(operating_system)&quot; target=&quot;_blank&quot;&gt;Android&lt;/a&gt;&lt;/b&gt;.  The GTK3 library contains touch support missing from the
  1031. GTK2 library on which Sugar is currently based.  The end goal here
  1032. would be a full port of the Python/GTK-based Sugar APIs, running on
  1033. something like the Honeycomb Android OS.   Our existing educational
  1034. activities could be ported to the new APIs without too much
  1035. difficulty, but we&apos;d largely use the existing Android OS facilities
  1036. instead of the parts of Sugar concerned with low-level system
  1037. management.  To clarify: this is a preliminary exploration&amp;mdash;we
  1038. haven&apos;t decided to base the tablet software on Android (or anything
  1039. else) yet.&lt;/li&gt;
  1040.  
  1041. &lt;li&gt;The next week brings a new direction.  During the week of April 11-15
  1042. I will start &lt;b&gt;porting Python/GTK3 to &lt;a href=&quot;http://en.wikipedia.org/wiki/Google_Chrome&quot; target=&quot;_blank&quot;&gt;Chrome&lt;/a&gt; or &lt;a href=&quot;http://en.wikipedia.org/wiki/ChromeOS&quot; target=&quot;_blank&quot;&gt;ChromeOS&lt;/a&gt; via the Google
  1043. &lt;a href=&quot;http://en.wikipedia.org/wiki/Google_Native_Client&quot; target=&quot;_blank&quot;&gt;NativeClient plugin&lt;/a&gt;&lt;/b&gt;.  This path would result in activities which more
  1044. fully integrate with web technologies&amp;mdash;even in disconnected regions
  1045. of the world.  On desktop machines, Sugar activities could be run
  1046. inside the Chrome browser, while ChromeOS (or another embedded OS
  1047. running chrome/webkit) would provide the system management functions
  1048. on tablet machines like the XO-3.  As with the Android port, this is
  1049. an exploration, not a definite software direction.&lt;/li&gt;
  1050.  
  1051. &lt;li&gt;The week of April 18-22 I hope to &lt;b&gt;focus on &lt;a href=&quot;http://en.wikipedia.org/wiki/Wireless_mesh_network&quot; target=&quot;_blank&quot;&gt;mesh networking&lt;/a&gt;&lt;/b&gt;.  This has
  1052. a somewhat checkered history in our deployments; I hope to identify
  1053. the remaining roadblocks and map a way forward to make this a flagship
  1054. feature of the XO-3 software.&lt;/li&gt;
  1055.  
  1056. &lt;li&gt;The week of April 25-29 is for the &lt;b&gt;existing Python-based Sugar
  1057. codebase&lt;/b&gt;.  In order to continue moving forward, it needs to migrate to
  1058. GTK3, &lt;a href=&quot;http://live.gnome.org/GObjectIntrospection&quot; target=&quot;_blank&quot;&gt;gobject-introspection&lt;/a&gt;, and some other key enabling technologies.
  1059. I believe it would also benefit from language-independent APIs and
  1060. better modularization to allow a more incremental migration path.&lt;/li&gt;
  1061. &lt;/ol&gt;
  1062.  
  1063. &lt;p&gt;The following week is &lt;b&gt;&lt;a href=&quot;http://wiki.sugarlabs.org/go/Conozco_Uruguay_Tour&quot; target=&quot;_blank&quot;&gt;Conozco Uruguay&lt;/a&gt; and the &lt;a href=&quot;http://wiki.sugarlabs.org/go/Uruguay_Summit_2011&quot; target=&quot;_blank&quot;&gt;Uruguay EduJAM&lt;/a&gt;&lt;/b&gt; where I&apos;ll present my
  1064. progress on these initial exploratory projects and discuss the path ahead
  1065. with the wider OLPC and Sugar communities.  Clearly, a week each is not
  1066. enough time to finish any of these projects!  But the focused effort should
  1067. help to better identify the promise, roadblocks, and challenges in
  1068. each of these paths, which then in turn will help us to plan the future.&lt;/p&gt;</description>
  1069.  <comments>https://cananian.livejournal.com/62667.html?view=comments#comments</comments>
  1070.  <category>sugar</category>
  1071.  <category>olpc</category>
  1072.  <category>chromeos</category>
  1073.  <category>networking</category>
  1074.  <category>android</category>
  1075.  <category>google</category>
  1076.  <category>python</category>
  1077.  <category>nativeclient</category>
  1078.  <category>sugarlabs</category>
  1079.  <category>sugarcamp</category>
  1080.  <category>jobs</category>
  1081.  <category>programming</category>
  1082.  <category>mesh</category>
  1083.  <lj:security>public</lj:security>
  1084.  <lj:reply-count>10</lj:reply-count>
  1085.  </item>
  1086.  <item>
  1087.  <guid isPermaLink='true'>https://cananian.livejournal.com/61568.html</guid>
  1088.  <pubDate>Thu, 02 Dec 2010 21:02:49 GMT</pubDate>
  1089.  <title>What&apos;s Wikileaks up to?</title>
  1090.  <author>cananian</author>
  1091.  <link>https://cananian.livejournal.com/61568.html</link>
  1092.  <description>&lt;p&gt;A recent &lt;a href=&quot;http://www.economist.com/blogs/democracyinamerica/2010/12/after_secrets&quot; target=&quot;_blank&quot;&gt;article in the Economist&lt;/a&gt; points out that Wikileaks is not unique: modern network tools have made anonymous communication ubiquitous.  You can&apos;t stop &quot;wikileaks&quot; by attacking Julian Assange alone.  The article is incorrect, however, in claiming that anonymity is &lt;i&gt;easy&lt;/i&gt; &amp;mdash; in some sense &lt;a href=&quot;http://en.wikipedia.org/wiki/Federalist_Papers&quot; target=&quot;_blank&quot;&gt;anonymous leafleteers in Colonial America&lt;/a&gt; were better off.  &lt;a href=&quot;http://en.wikipedia.org/wiki/Bradley_Manning&quot; target=&quot;_blank&quot;&gt;Bradley Manning currently sits in jail&lt;/a&gt;.  &lt;a href=&quot;http://boingboing.net/2010/09/14/haystack-is-burning.html&quot; target=&quot;_blank&quot;&gt;Haystack was fundamentally flawed&lt;/a&gt;. There continues to be a role for organizations who desire to facilitate anonymous speech to identify and provide trustworthy and user-friendly tools and procedures.&lt;/p&gt;
  1093. &lt;p&gt;Aaron Brady achieves a more fundamental insight by &lt;a href=&quot;http://zunguzungu.wordpress.com/2010/11/29/julian-assange-and-the-computer-conspiracy-%E2%80%9Cto-destroy-this-invisible-government%E2%80%9D/&quot; target=&quot;_blank&quot;&gt;examining Julian Assange&apos;s aims&lt;/a&gt;.  Assange&apos;s goal is to hobble &quot;conspiracies&quot;, that is, the small cliques of power and secrecy embedded in most organizations, and he seeks to do this by causing them to fear information sharing. By this metric, Wikileaks &lt;a href=&quot;http://swampland.blogs.time.com/2010/11/29/state-pulls-the-plug-on-siprnet/&quot; target=&quot;_blank&quot;&gt;seems to be succeeding&lt;/a&gt;. (Read Aaron Brady&apos;s essay for the details.)&lt;/p&gt;
  1094. &lt;p&gt;But it&apos;s worth pausing to consider: are open organizations truly better?  Is openness practically achievable?  This is an organizational problem which was on the front burner at &lt;a href=&quot;http://en.wikipedia.org/wiki/OLPC&quot; target=&quot;_blank&quot;&gt;OLPC&lt;/a&gt; while I worked there: OLPC pledged an open development and governance model, but was continually charged with being closed, insular, and secretive in practice.  We reorganized previously-internal mailing lists and pledged to conduct all important business on public archived lists.  Yet there was continual backsliding.  Sometimes private email was used merely to prevent embarrassment or confusion&amp;mdash;to fact-check before making a public statement.  Other times it was claimed that &lt;i&gt;some&lt;/i&gt; measure of secret/private communication was a fundamental part of business or negotiation, necessary for interacting with external entities.  In order to evaluate the latest components/plans/schedules of our partners, we had to sign NDAs.  The secrecy requirements of the third-party then contaminated related discussions.  In the end, even an organization with a goal of openness ended up embedding pockets of secrecy, which always threatened to grow and spread unless they were occasionally beaten back.  Attempting to stand for open principles was often claimed to make OLPC &quot;uncompetitive,&quot; as in: we couldn&apos;t hope to get the best deals/access to the latest components/whatever if we insisted on being open about everything.&lt;/p&gt;
  1095. &lt;p&gt;The quest for openness in business seems to parallel the role of Wikileaks in national affairs.  As with OLPC&apos;s business negotiations, we are being told that secrecy is an essential part of the diplomatic process, and that publishing internal cables hobbles America&apos;s ability to achieve its goals.  The claim is that Wikileaks threatens to make America &quot;uncompetitive.&quot;&lt;/p&gt;
  1096. &lt;p&gt;Is this true?  Openness is an ethical position, but not a black-and-white one.  Very few people argued that OLPC (or America) should have &lt;i&gt;no&lt;/i&gt; secrets &amp;mdash; the debate was always &quot;how many?&quot;  In practice if the desired answer was &quot;as few as possible&quot;, there was always a Wikileaks-like need to continually drag private content to public forums in order to combat the creep of secrecy.  Perhaps the same is true of governments.&lt;/p&gt;
  1097. &lt;p&gt;Then again, over-reaching openness threatens &lt;i&gt;individual privacy&lt;/i&gt; &amp;mdash; where to draw the line?  Must all our personal mistakes be made in public?  Must all our &lt;i&gt;national&lt;/i&gt; mistakes be made in public?&lt;/p&gt;</description>
  1098.  <comments>https://cananian.livejournal.com/61568.html?view=comments#comments</comments>
  1099.  <category>security</category>
  1100.  <category>olpc</category>
  1101.  <category>echelon</category>
  1102.  <category>legal</category>
  1103.  <category>wikileaks</category>
  1104.  <lj:security>public</lj:security>
  1105.  <lj:reply-count>0</lj:reply-count>
  1106.  </item>
  1107.  <item>
  1108.  <guid isPermaLink='true'>https://cananian.livejournal.com/60302.html</guid>
  1109.  <pubDate>Thu, 27 May 2010 17:46:33 GMT</pubDate>
  1110.  <title>Congratulations, OLPC!</title>
  1111.  <author>cananian</author>
  1112.  <link>https://cananian.livejournal.com/60302.html</link>
  1113.  <description>&lt;p&gt;Today OLPC announced a &lt;a href=&quot;http://blog.laptop.org/2010/05/27/xo3-marvell-and-olpc/&quot; target=&quot;_blank&quot;&gt;partnership with Marvell&lt;/a&gt; to develop the XO-3.  This is great news &amp;mdash; according to my little birdies this will put development efforts at OLPC on substantially more solid financial footing.  And software development for new tablet computers is non-trivial!  Here&apos;s hoping that OLPC, which led the netbook movement, can similarly spur the nacent tablet computer market.  So far tablets are seen as content &lt;em&gt;consumers&lt;/em&gt;, with all &quot;real&quot; content creation (ie not just jotting notes or makng minor edits) being done on seperate &quot;real&quot; computers.  OLPC&apos;s vision should insist on fully productive machines which allow kids to create and contribute, not just passively consume.  (In particular, the killer app for kids on XO laptops to date is making movies and telling stories.)&lt;/p&gt;
  1114.  
  1115. &lt;p&gt;In addition to funding further software development, the Marvell partnership ought to give OLPC the muscle to continue pushing forward the hardware state of the art.  A lot of the reality of modern electronics manufacturing depends on guaranteeing enough production volume to sustain the interest of suppliers and their engineers.  For low volumes you instead get &quot;least effort&quot; solutions from your partners, which result in higher costs and poorer results.  So I&apos;m cautiously optimistic that the &quot;capture&quot; of OLPC resources for Marvell&apos;s high volume &quot;first world&quot; tablet efforts will in the end be a means to accomplishing the XO-3 goals for &quot;the rest&quot;.  But care and caution are waranted.  OLPC is not large enough to do multiple things at once; its resources and attention are dissipated easily.&lt;/p&gt;</description>
  1116.  <comments>https://cananian.livejournal.com/60302.html?view=comments#comments</comments>
  1117.  <category>olpc</category>
  1118.  <lj:security>public</lj:security>
  1119.  <lj:reply-count>1</lj:reply-count>
  1120.  </item>
  1121.  <item>
  1122.  <guid isPermaLink='true'>https://cananian.livejournal.com/59091.html</guid>
  1123.  <pubDate>Thu, 19 Nov 2009 19:27:35 GMT</pubDate>
  1124.  <title>Chrome OS, litl, and OLPC</title>
  1125.  <author>cananian</author>
  1126.  <link>https://cananian.livejournal.com/59091.html</link>
  1127.  <description>Well, Google just announced Chrome OS, to be available next Christmas.  Some parts of it are very similar to what you can already put under the tree &lt;b&gt;this&lt;/b&gt; Christmas from litl (actually, you can buy one &lt;a href=&quot;http://store.litl.com/&quot; target=&quot;_blank&quot;&gt;right now&lt;/a&gt;) &amp;mdash; and other parts are familiar from my time at OLPC.  For example, the legacy-free BIOS and signed bootloader are what OLPC shipped two years ago on the XO-1.  The XO-1 was not an &quot;always connected&quot; device, though &amp;mdash; in fact the opposite: it assumed connectivity was infrequent and low-bandwidth.  At OLPC, the signed code scheme was part of an theft-deterrence system, crucial for OLPC&apos;s target third-world deployments.  It wasn&apos;t very popular among our first-world users, and I&apos;m not actually sure why Google implemented it for Chrome OS.  Phone company lock-in (due to largely misplaced concerns about maintaining the integrity of their networks) are why phone apps are locked down with signature schemes; this isn&apos;t necessary (and verges on Evil) for what&apos;s intended as a general-purpose computing device.
  1128. &lt;p&gt;
  1129. The somewhat oddly-technical (and often slightly-wrong) middle section of the Chrome OS presentation veered off at one point about filesystem partitions (!) and how having a read-only partition is a novel feature of their OS.  Read-only partitions are one of the &lt;i&gt;oldest&lt;/i&gt; security mechanisms &amp;mdash; my boot floppy had the write-protect notch taped over back when I was booting DOS &amp;mdash; and a near-universal feature of thin-client deployments (which Chrome OS certainly is).  OLPC maintained a mostly-read-only root, but primarily to extend the lifetime of the flash disk (flash lifetime was not touched on in the Chrome OS presentation).  Litl mounts a read-only root with a writable unionfs on top, which actually works much better in practice: improved maintainability because all the various Linux system daemons can still &quot;do their thing&quot; as they expect, but you can wipe the top partition whenever you like to return to a clean state (at litl we do this on every update).  (If you haven&apos;t hacked the lower levels of a Linux distribution, you&apos;d probably be surprised at how many system daemons assume they can write various places in the root partition, and you really don&apos;t want to maintain hacked versions of all of them.)  Since ChromeOS gave an Ubuntu shout-out at one point, I strongly suspect the unionfs scheme is actually what they are doing as well &amp;mdash; and, for that matter, what all the other Ubuntu Mobile downstreams are doing.  Not new.
  1130. &lt;p&gt;
  1131. The emphasis on a read-only root partition is rather misleading from a security standpoint (as much of the middle portion of the presentation was).  If you&apos;re not storing your files locally, it doesn&apos;t mean that you suddenly have no security concerns.  It just means you have &lt;i&gt;different&lt;/i&gt; security concerns.  Cross-site scripting attacks give a malicious website access to your Google account through your web browser: these sorts of things are the malware for a WebOS.  You have a different attack surface, but a vulnerability in your browser or flash plugin still gives access to private data.  Mentioning that they encrypt the data on disk seems to be pure &lt;a href=&quot;http://en.wikipedia.org/wiki/Snake_oil_(cryptography)&quot; target=&quot;_blank&quot;&gt;snake oil&lt;/a&gt;: your browser has access to the unencrypted data, and that&apos;s your most vulnerable surface anyway.
  1132. &lt;p&gt;
  1133. Overall, Chrome OS is a nice validation of some of the cloud-computing ideas we&apos;ve been working on at &lt;a href=&quot;http://litl.com&quot; target=&quot;_blank&quot;&gt;litl&lt;/a&gt;, and it&apos;s always nice to see more legacy-free hardware (like the OLPC XO-1 and the litl webbook), but the presentation was oddly underwhelming.  They&apos;re not really &quot;reimagining the PC&quot; &amp;mdash; they&apos;re just removing all the applications on the PC except for Chrome.  You still interact with &quot;the PC&quot; the same way you currently interact with Chrome.  For reimagination, watch the &lt;a href=&quot;http://litl.com/support/&quot; target=&quot;_blank&quot;&gt;videos at litl&lt;/a&gt;.</description>
  1134.  <comments>https://cananian.livejournal.com/59091.html?view=comments#comments</comments>
  1135.  <category>olpc</category>
  1136.  <category>chromeos</category>
  1137.  <category>google</category>
  1138.  <lj:security>public</lj:security>
  1139.  <lj:reply-count>1</lj:reply-count>
  1140.  </item>
  1141.  <item>
  1142.  <guid isPermaLink='true'>https://cananian.livejournal.com/58744.html</guid>
  1143.  <pubDate>Wed, 04 Nov 2009 19:27:15 GMT</pubDate>
  1144.  <title>litl&apos;s technical secrets revealed!</title>
  1145.  <author>cananian</author>
  1146.  <link>https://cananian.livejournal.com/58744.html</link>
  1147.  <description>&lt;p&gt;&lt;b&gt;Update:&lt;/b&gt; Lucas has written up some additional &lt;a href=&quot;http://blogs.gnome.org/lucasr/2009/11/04/litl-webbook-some-technical-comments/&quot; target=&quot;_blank&quot;&gt;technical details&lt;/a&gt; &amp;mdash; and he mentions our update system, which was one of the first bits I worked on when I arrived.  We heavily dog-food the updater, using &lt;a href=&quot;http://buildbot.net/&quot; target=&quot;_blank&quot;&gt;buildbot&lt;/a&gt; to push out the latest bits to developers every night.&lt;/p&gt;
  1148.  
  1149. &lt;p&gt;&lt;b&gt;Update 2:&lt;/b&gt; Welcome, slashdot!  The videos at &lt;a href=&quot;http://litl.com/support/&quot; target=&quot;_blank&quot;&gt;http://litl.com/support/&lt;/a&gt; give a good idea of what the UI is like.&lt;/p&gt;
  1150.  
  1151. &lt;p&gt;&lt;b&gt;Update 3:&lt;/b&gt; Non-technical press coverage: &lt;a href=&quot;http://www.wired.com/gadgetlab/2009/11/litl-webbook/&quot; target=&quot;_blank&quot;&gt;Wired&lt;/a&gt;, &lt;a href=&quot;http://blogs.wsj.com/digits/2009/11/04/litl-introduces-its-web-based-netbook/&quot; target=&quot;_blank&quot;&gt;WSJ&lt;/a&gt;, &lt;a href=&quot;http://www.xconomy.com/boston/2009/11/04/the-litl-computer-that-could-boston-startup-tries-a-new-take-on-the-home-internet-appliance/&quot; target=&quot;_blank&quot;&gt;Xconomy&lt;/a&gt;, &lt;a href=&quot;http://www.crunchgear.com/2009/11/04/litl-webbook-aims-to-blend-portable-computing-with-a-tv-like-experience/&quot; target=&quot;_blank&quot;&gt;CrunchGear&lt;/a&gt;&lt;/p&gt;
  1152.  
  1153. &lt;p&gt;&lt;b&gt;Update 4:&lt;/b&gt; More words: &lt;a href=&quot;http://innergeekmoments.blogspot.com/2009/11/litl-theres-server-component-too.html&quot; target=&quot;_blank&quot;&gt;dignacio on litl&apos;s server side&lt;/a&gt;, &lt;a href=&quot;http://www.j5live.com/2009/11/04/litls-little-netbook/&quot; target=&quot;_blank&quot;&gt;J5&lt;/a&gt;, &lt;a href=&quot;http://twitter.com/#search?q=%23litl&quot; target=&quot;_blank&quot;&gt;twitter&lt;/a&gt;&lt;/p&gt;
  1154.  
  1155. &lt;p&gt;&lt;a href=&quot;http://litl.com&quot; target=&quot;_blank&quot;&gt;litl&lt;/a&gt; launches today, so I can finally
  1156. talk a bit about the cool technologies behind our software stack.&lt;/p&gt;
  1157.  
  1158. &lt;p&gt;On the server side, litl is a cloud computer, built on &lt;a href=&quot;http://en.wikipedia.org/wiki/Google_App_Engine&quot; target=&quot;_blank&quot;&gt;Google App
  1159. Engine&lt;/a&gt;, &lt;a href=&quot;http://en.wikipedia.org/wiki/Amazon_S3&quot; target=&quot;_blank&quot;&gt;Amazon
  1160. S3&lt;/a&gt;, and &lt;a href=&quot;http://en.wikipedia.org/wiki/Django_(web_framework)&quot; target=&quot;_blank&quot;&gt;Django&lt;/a&gt;
  1161. &amp;mdash; all of which are fantastic technologies.
  1162. All machine data is stored in the cloud, so you can have a
  1163. gorilla stomp on your litl, pick up another one, log on and instantly
  1164. recreate your environment.  (Since we developers are always abusing
  1165. our prototype hardware, we&apos;ve tested this a lot!)&lt;/p&gt;
  1166.  
  1167. &lt;p&gt;On the client side, the litl software (naturally, code-named &quot;big&quot;)
  1168. is built on &lt;a href=&quot;http://live.gnome.org/Gjs/&quot; target=&quot;_blank&quot;&gt;gjs&lt;/a&gt;, which is the
  1169. smallest possible wrapper around &lt;a href=&quot;http://www.amazon.com/exec/obidos/ASIN/0596517742/wrrrldwideweb&quot; target=&quot;_blank&quot;&gt;JavaScript&lt;/a&gt;
  1170. necessary to make it a large-scale programming language.  I&apos;ve really
  1171. enjoyed programming in JavaScript, which might seem odd to people who
  1172. (a) have had frustrating experiences with global variables and crazy
  1173. incompatibilites trying to make JavaScript work on the web, and (b)
  1174. know that I&apos;m a &lt;a href=&quot;http://cscott.net/Publications/thesis.pdf&quot; target=&quot;_blank&quot;&gt;static types&lt;/a&gt; and
  1175. &lt;a href=&quot;http://cscott.net/Publications/p072-ananian.pdf&quot; target=&quot;_blank&quot;&gt;compiler-bondage&lt;/a&gt;
  1176. sort of guy.  So I&apos;ll spend a little time here talking about gjs.&lt;/p&gt;
  1177.  
  1178. &lt;p&gt;From a language standpoint gjs adds just one feature: a minimal
  1179. module/namespacing mechanism built on a single top-level definition: the name &quot;&lt;code&gt;imports&lt;/code&gt;&quot;.
  1180. Modules are imported using (typically constant) definitions, such as:&lt;/p&gt;
  1181. &lt;pre style=&quot;background: #eef; border: 1px solid #ccc; margin: 1em; padding: 1em; width: 40em;&quot;&gt;
  1182. const StringUtil = imports.stringUtil;
  1183.  
  1184. s = StringUtil.sprintf(&quot;%d&quot;, 3);
  1185. &lt;/pre&gt;
  1186.  
  1187. &lt;p&gt;The dynamic &lt;code&gt;stringUtil&lt;/code&gt; property of the
  1188. &lt;code&gt;imports&lt;/code&gt; object is an object whose properties are the
  1189. top-level definitions in the file &lt;code&gt;stringUtil.js&lt;/code&gt;, found on
  1190. the import path.  Subdirectories are additional dot-separated
  1191. components, as in Java package names; &lt;code&gt;imports.util&lt;/code&gt; is a
  1192. dynamic object representing modules found in a &lt;code&gt;util&lt;/code&gt;
  1193. directory on the path.  You may need to compare this to the
  1194. namespacing mechanism in the abandoned &lt;a href=&quot;http://www.ecmascript.org/es4/spec/overview.pdf&quot; target=&quot;_blank&quot;&gt;ES4&lt;/a&gt;
  1195. proposal to appreciate how small and elegant this is.&lt;/p&gt;
  1196.  
  1197. &lt;p&gt;Further, this module system integrates with the &lt;a href=&quot;http://library.gnome.org/devel/gobject/unstable/index.html&quot; target=&quot;_blank&quot;&gt;GObject system&lt;/a&gt; via
  1198. &lt;a href=&quot;http://live.gnome.org/GObjectIntrospection/&quot; target=&quot;_blank&quot;&gt;GObject
  1199. introspection&lt;/a&gt; annotations for library code.  This allows
  1200. easy integration with libraries written in C
  1201. or any other introspectable language.  For example:&lt;/p&gt;
  1202. &lt;pre style=&quot;background: #eef; border: 1px solid #ccc; margin: 1em; padding: 1em; width: 40em;&quot;&gt;
  1203. const Gtk = imports.gi.Gtk;
  1204. Gtk.init(0, null);
  1205.  
  1206. let w = new Gtk.Window({ type: Gtk.WindowType.TOPLEVEL });
  1207. w.connect(&apos;destroy&apos;, Gtk.main_quit );
  1208.  
  1209. let button = new Gtk.Button({ label: &quot;Hello, world!&quot; });
  1210. button.connect(&apos;clicked&apos;, function() { w.destroy(); } );
  1211. w.add(button);
  1212. w.show_all();
  1213.  
  1214. Gtk.main();
  1215. &lt;/pre&gt;
  1216.  
  1217. &lt;p&gt;The gjs system is built on the &lt;a href=&quot;http://www.mozilla.org/js/spidermonkey/&quot; target=&quot;_blank&quot;&gt;SpiderMonkey&lt;/a&gt;
  1218. JavaScript engine, the one used in &lt;a href=&quot;http://www.mozilla.com/en-US/firefox/upgrade.html&quot; target=&quot;_blank&quot;&gt;Firefox&lt;/a&gt;,
  1219. so JavaScript execution benefits from all the &lt;a href=&quot;http://ejohn.org/blog/tracemonkey/&quot; target=&quot;_blank&quot;&gt;JIT&lt;/a&gt; and performance work
  1220. done upstream.  Further, it means that we can code in &lt;a href=&quot;https://developer.mozilla.org/en/New_in_JavaScript_1.8&quot; target=&quot;_blank&quot;&gt;JavaScript
  1221. 1.8&lt;/a&gt;, Mozilla&apos;s dialect of JavaScript with lots of bells and
  1222. whistles (mostly borrowed from Python):&lt;/p&gt;
  1223.  
  1224. &lt;pre style=&quot;background: #eef; border: 1px solid #ccc; margin: 1em; padding: 1em; width: 40em;&quot;&gt;
  1225. gjs&amp;gt; function range(n) { for (let i=0; i&amp;lt;n; i++) yield i; }
  1226. gjs&amp;gt; [i*2 for (i in range(5))]
  1227. 0,2,4,6,8
  1228. &lt;/pre&gt;
  1229.  
  1230. &lt;p&gt;(In a later post perhaps I&apos;ll describe how you can use the
  1231. &lt;code&gt;yield&lt;/code&gt; expression to build a continuation-based system for
  1232. writing asynchronous callbacks for UI code in a natural manner.)&lt;/p&gt;
  1233.  
  1234. &lt;p&gt;Overall,
  1235. JavaScript as a system programming language feels a lot like Lisp must
  1236. have for the programming generation before mine: minimal
  1237. syntax, very powerful and orthogonal core abstractions, and (dare I
  1238. say it) not much type-checking or busy-work to get in your way.
  1239. (&lt;code&gt;gjs&lt;/code&gt; is not a homage to &lt;a href=&quot;http://en.wikipedia.org/wiki/Gjs&quot; target=&quot;_blank&quot;&gt;Sussman&lt;/a&gt;, but it should
  1240. be!)  JavaScript is a programming language for those who know what they&apos;re
  1241. doing and aren&apos;t afraid of a little functional abstraction.  (Now if
  1242. only there was a way to disable &lt;a href=&quot;http://www.mozilla.org/js/language/js20-2000-07/rationale/syntax.html&quot; target=&quot;_blank&quot;&gt;semicolon
  1243. insertion&lt;/a&gt;!)&lt;/p&gt;
  1244.  
  1245. &lt;p&gt;OK, enough about gjs.  The litl software stack is based on &lt;a href=&quot;http://www.canonical.com/&quot; target=&quot;_blank&quot;&gt;Canonical&lt;/a&gt;&apos;s distribution
  1246. of Ubuntu for &lt;a href=&quot;http://www.ubuntu.com/products/mobile&quot; target=&quot;_blank&quot;&gt;mobile/embedded
  1247. devices&lt;/a&gt;, and the Canonical folks have been great partners.
  1248. It&apos;s been a joy to get changes integrated upstream, and Canonical has done a
  1249. lot of excellent work accommodating their distribution to litl&apos;s
  1250. unique needs.  On the UI side, we use X11 and some GTK widgets, but
  1251. implement our own (very simple) window manager.  Most of the
  1252. actual look and feel is done with &lt;a href=&quot;http://en.wikipedia.org/wiki/Clutter_(toolkit)&quot; target=&quot;_blank&quot;&gt;Clutter&lt;/a&gt;
  1253. (hardware-accelerated 3d animated effects, whee!), and we have a
  1254. Flash-based API for external developers.  We also have
  1255. hardware-accelerated &lt;a href=&quot;http://en.wikipedia.org/wiki/H.264&quot; target=&quot;_blank&quot;&gt;h.264&lt;/a&gt; video.&lt;/p&gt;
  1256.  
  1257. &lt;p&gt;Regardless of the technical fun, though, I have to say that the
  1258. best thing about working at litl is its management: developing with
  1259. all the other rockstars here is made the more fun by the knowledge
  1260. that management will help ensure that our goals are realistic and that
  1261. we&apos;ll be able to hit our targets, with time left over to polish before
  1262. release.  It&apos;s just much more fun to code when you know you&apos;ll be
  1263. proud of the end result.&lt;/p&gt;</description>
  1264.  <comments>https://cananian.livejournal.com/58744.html?view=comments#comments</comments>
  1265.  <category>javascript</category>
  1266.  <category>olpc</category>
  1267.  <category>litl</category>
  1268.  <category>gjs</category>
  1269.  <category>gnome</category>
  1270.  <lj:security>public</lj:security>
  1271.  <lj:reply-count>5</lj:reply-count>
  1272.  </item>
  1273.  <item>
  1274.  <guid isPermaLink='true'>https://cananian.livejournal.com/58238.html</guid>
  1275.  <pubDate>Mon, 05 Oct 2009 18:18:18 GMT</pubDate>
  1276.  <title>Flash Filesystems</title>
  1277.  <author>cananian</author>
  1278.  <link>https://cananian.livejournal.com/58238.html</link>
  1279.  <description>&lt;p&gt;Dave Woodhouse in a recent article &lt;a href=&quot;http://www.advogato.org/person/dwmw2/diary/211.html&quot; target=&quot;_blank&quot;&gt;calls shenanigans on
  1280. hardware translation for flash devices&lt;/a&gt;.  I agree: flash memory is
  1281. a Horse Of A Different Color, and trying to gussy it up to look like
  1282. a rotating disk of magnetized rust is using a bad and leaky abstraction that
  1283. will only end in tears.  But I don&apos;t think the engineers&apos; better
  1284. judgment will prevail: the use of hardware
  1285. translation is driven by Windows/DOS compatibility concerns, since
  1286. Microsoft (to my knowledge) has shown no desire in writing a new
  1287. filesystem for flash drives.  &lt;a href=&quot;http://en.wikipedia.org/wiki/OLPC&quot; target=&quot;_blank&quot;&gt;OLPC&lt;/a&gt; used a raw flash device in the
  1288. &lt;a href=&quot;http://wiki.laptop.org/images/7/71/CL1A_Hdwe_Design_Spec.pdf&quot; target=&quot;_blank&quot;&gt;XO-1&lt;/a&gt;, but in their &lt;a href=&quot;http://wiki.laptop.org/go/XO-1.5&quot; target=&quot;_blank&quot;&gt;follow-on&lt;/a&gt; had to switch to a hardware-translation device
  1289. because market/scale economics were making those
  1290. devices cheaper and cheaper while the original raw flash device was
  1291. (a) not increasing in volume (aka, getting relatively more expensive),
  1292. (b) not increasing in size (no one wanted to make new ones), and
  1293. (c) getting discontinued (aka, impossible to buy).  The best
  1294. one can hope for is that a raw interface be offered &lt;i&gt;in addition&lt;/i&gt; to
  1295. the standard &quot;Windows-compatible&quot; one, for specialized embedded or
  1296. high-performance applications &amp;mdash; but the chicken and egg problem applies:
  1297. until there are compelling gains, these interfaces won&apos;t be purchased
  1298. in sufficient volumes to yield reasonable prices, and no one is
  1299. writing the optimized filesystems because you can&apos;t find
  1300. reasonably-priced flash devices to run them on.
  1301. The end result is likely to be that &lt;a href=&quot;http://www.jwz.org/doc/worse-is-better.html&quot; target=&quot;_blank&quot;&gt;Worse Is Better&lt;/a&gt;, and we&apos;ll be left
  1302. with another set of legacy chains.  Given enough time and transistors,
  1303. the hardware may eventually grow Heroic Measures to work
  1304. around the bad abstraction (see: the x86 instruction set).&lt;/p&gt;
  1305.  
  1306. &lt;p&gt;If your filesystem is large enough and the amount of data
  1307. being rewritten small enough, the flash problems &quot;probably&quot;
  1308. won&apos;t bite you until after the obsolescence of the device &amp;mdash; flash storage
  1309. doesn&apos;t have to be good, it just has to be &quot;not too bad&quot; until, say, 3
  1310. years after purchase.  Like non-removable rechargeable batteries that
  1311. slowly degrade over time, you&apos;ll find your filesystem slowly
  1312. degrading &amp;mdash; one more reason to eventually buy a new one, and I&apos;ve never
  1313. known manufacturers to be especially sorry about that.  Heroic Measures may never be needed/taken.&lt;/p&gt;
  1314.  
  1315. &lt;p&gt;Leaving amateur market economics (and despair), let&apos;s revisit a cryptic and probably overlooked
  1316. paragraph in my &lt;a href=&quot;http://wiki.laptop.org/go/Olpcfs#Implementations_on_flash_memory&quot; target=&quot;_blank&quot;&gt;olpcfs&lt;/a&gt; proposal:&lt;/p&gt;
  1317. &lt;blockquote&gt;
  1318. &lt;p&gt;Implementations tuned for flash memory can use &lt;a href=&quot;http://doi.acm.org/10.1145/1292609.1292616&quot; class=&quot;external text&quot; title=&quot;http://doi.acm.org/10.1145/1292609.1292616&quot; rel=&quot;nofollow&quot; target=&quot;_blank&quot;&gt;Adaptive Packed Memory Arrays&lt;/a&gt; for efficient CAS.  This is an open research topic, but there is some evidence that a high-performance scalable flash-based filesystem can more profitably be implemented using cache-oblivious B-Trees and APMAs, rather than more &quot;traditional&quot; filesystem structures.
  1319. &lt;/p&gt;
  1320. &lt;/blockquote&gt;
  1321.  
  1322. &lt;p&gt;Here I&apos;m trying to build a little bridge between filesystem designers
  1323. and functional data structure researchers, two groups who probably
  1324. rarely sit down together for a beer.  I think &lt;a href=&quot;http://doi.acm.org/10.1145/1292609.1292616&quot; target=&quot;_blank&quot;&gt;Packed Memory Arrays&lt;/a&gt; are
  1325. the &quot;B-trees of flash filesystems&quot;: a better way to build an on-disk
  1326. index given the peculiar characteristics of flash memory.  Just as
  1327. &lt;a href=&quot;http://en.wikipedia.org/wiki/Be_File_System&quot; target=&quot;_blank&quot;&gt;BeOS&lt;/a&gt; demonstrated that your filesystem could be &quot;B-trees all the way
  1328. down&quot;, I believe you could build a compelling filesystem using PMAs as
  1329. the primary data structure.  Ultimately, I suspect that the
  1330. development strategy Dave Woodhouse describes &amp;mdash; small incremental
  1331. changes to existing filesystems whose philosophies are &quot;close enough&quot;
  1332. &amp;mdash; will probably prevail over a ground-up PMA rewrite.  Incremental
  1333. improvements and shared codebases are the Right Strategy for
  1334. successful open source projects: you get more developers and testers
  1335. for those parts which aren&apos;t flash-specific, and you&apos;ve already gotten
  1336. yourself out of the &lt;a href=&quot;http://en.wikipedia.org/wiki/Cathedral_and_the_Bazaar&quot; target=&quot;_blank&quot;&gt;Cathedral&lt;/a&gt; with some working code to kick things off.&lt;/p&gt;
  1337.  
  1338. &lt;p&gt;But if anyone&apos;s interested in attempting a clean slate design, PMAs are
  1339. my advice.  Maybe you&apos;ll come up with something so wonderful it will
  1340. make a compelling &lt;a href=&quot;http://www.nobius.org/~dbg/practical-file-system-design.pdf&quot; target=&quot;_blank&quot;&gt;book&lt;/a&gt; (and inspire folks like me), even if
  1341. ultimately you don&apos;t win in the marketplace.&lt;/p&gt;
  1342.  
  1343. &lt;p&gt;(But maybe you&apos;ll win!  Flash storage and your optimized filesystem will prevail, and one day we&apos;ll think of rotating media in the same way we now think of core memory, floppy disks, tape drives, and the x86 instruction set... er, hmm.)&lt;/p&gt;</description>
  1344.  <comments>https://cananian.livejournal.com/58238.html?view=comments#comments</comments>
  1345.  <category>olpcfs</category>
  1346.  <category>olpc</category>
  1347.  <lj:security>public</lj:security>
  1348.  <lj:reply-count>2</lj:reply-count>
  1349.  </item>
  1350.  <item>
  1351.  <guid isPermaLink='true'>https://cananian.livejournal.com/57486.html</guid>
  1352.  <pubDate>Tue, 04 Aug 2009 15:54:51 GMT</pubDate>
  1353.  <title>Sugar waves: time to get started!</title>
  1354.  <author>cananian</author>
  1355.  <link>https://cananian.livejournal.com/57486.html</link>
  1356.  <description>While I was abroad, it seems that Google &lt;a href=&quot;http://googlewavedev.blogspot.com/2009/07/google-wave-federation-protocol-and.html&quot; target=&quot;_blank&quot;&gt;released their wave server/federation code&lt;/a&gt;.  So you can now get started tackling some of the projects I outlined in &lt;a href=&quot;http://cananian.livejournal.com/56585.html&quot; target=&quot;_blank&quot;&gt;my previous post on Waves and Sugar&lt;/a&gt;: getting a basic federation server running on the school server and/or writing a server running locally on the XO which exports the content of the Journal/filesystem for collaboration.  I&apos;m hoping someone other than me thinks this is an exciting idea, and runs with it!</description>
  1357.  <comments>https://cananian.livejournal.com/57486.html?view=comments#comments</comments>
  1358.  <category>journal</category>
  1359.  <category>sugar</category>
  1360.  <category>olpc</category>
  1361.  <category>google wave</category>
  1362.  <category>google</category>
  1363.  <category>journal2</category>
  1364.  <lj:security>public</lj:security>
  1365.  <lj:reply-count>0</lj:reply-count>
  1366.  </item>
  1367.  <item>
  1368.  <guid isPermaLink='true'>https://cananian.livejournal.com/57130.html</guid>
  1369.  <pubDate>Mon, 03 Aug 2009 16:03:55 GMT</pubDate>
  1370.  <title>OLPC kerfuffle</title>
  1371.  <author>cananian</author>
  1372.  <link>https://cananian.livejournal.com/57130.html</link>
  1373.  <description>&lt;p&gt;It seems I missed a nice little &lt;a href=&quot;http://linux.slashdot.org/story/09/07/20/1628228/Negroponte-Sees-Sugar-As-OLPCs-Biggest-Mistake&quot; target=&quot;_blank&quot;&gt;Slashdot&lt;/a&gt;/&lt;a href=&quot;http://www.zdnetasia.com/insight/hardware/0,39043471,62056166,00.htm&quot; target=&quot;_blank&quot;&gt;Negroponte&lt;/a&gt;/&lt;a href=&quot;http://radian.org/notebook/nonsense-omelet&quot; target=&quot;_blank&quot;&gt;Krstić&lt;/a&gt; OLPC/Sugar row while I was away in Europe savoring the efficient intercity rail.  While Tomeu and OLPCnews choose to blame particular words or phrases (&quot;&lt;a href=&quot;http://blog.tomeuvizoso.net/2009/07/on-negropontes-omelettes.html&quot; target=&quot;_blank&quot;&gt;Sugar&lt;/a&gt;&quot;, &quot;&lt;a href=&quot;http://www.olpcnews.com/people/negroponte/olpc_biggest_mistake_sugar.html&quot; target=&quot;_blank&quot;&gt;$100 laptop&lt;/a&gt;&quot;), both &lt;a href=&quot;https://www.blogger.com/comment.g?blogID=664175667937540078&amp;amp;postID=4369316166455399161&quot; target=&quot;_blank&quot;&gt;J5&lt;/a&gt; and &lt;a href=&quot;http://gregdek.livejournal.com/52052.html&quot; target=&quot;_blank&quot;&gt;gregdek&lt;/a&gt; seem to think the Real Problem was the fact that OLPC wouldn&apos;t upstream its patches.&lt;/p&gt;
  1374. &lt;p&gt;I beg to disagree.  As I &lt;a href=&quot;http://gregdek.livejournal.com/52052.html?view=385876#t385876&quot; target=&quot;_blank&quot;&gt;wordily tried to explain&lt;/a&gt; in a comment to gregdek&apos;s post, I think Ivan is mostly right here: OLPC tried to do &quot;seven new things&quot; (as Mary Lou explained to me when I was hired) -- and &quot;new things&quot; end up costing a lot of debugging and development time, in one of the Iron Laws Of Writing New Code And Making New Hardware.  But another problem was just Picking The Wrong Partners.  With the exception of the display (one of the few unalloyed successes of the XO hardware), most of our hardware and software partners were working at cross purposes.  Red Hat didn&apos;t really want to build an embedded OS product, &quot;mesh networking&quot; to Marvel meant household networks between your TV and your stereo with maybe 10 participants, the Geode was an orphaned offering from AMD, the display and flash NAND controller was a unloved one-off, etc.  Success is found by aligning your partners&apos; interests with your own.&lt;/p&gt;
  1375. &lt;p&gt;At Litl our OS partner has many other embedded-systems clients, and has developed the toolsets to handle forks and customization without all the angst I&apos;d grown used to at OLPC.  We just say, &quot;we need feature X turned on/off&quot; or &quot;set to Y&quot; or just &quot;somehow Z needs to happen&quot; and it&apos;s done.  We&apos;re not fighting, we&apos;re not destabilizing their core OS, we don&apos;t waste time with elaborate justifications why This Is The Right Thing To Do.  If the change is appropriate to upstream, they upstream it, and maybe the work benefits the other embedded-systems clients.  There&apos;s no drama, because We All Want The Same Thing.&lt;/p&gt;
  1376. &lt;p&gt;I think &quot;upstreaming&quot; is entirely the wrong hero for OLPC here.  If anything, I think OLPC&apos;s best hope is to continue to &lt;b&gt;aggressively innovate&lt;/b&gt; -- no one buys a computer because its code has been upstreamed.  Unfortunately, I don&apos;t think OLPC has enough current funding to do anything but follow the upstream, so maybe this current round of praise for Fedora-ization is just the old cliché: making a virtue of necessity.&lt;/p&gt;</description>
  1377.  <comments>https://cananian.livejournal.com/57130.html?view=comments#comments</comments>
  1378.  <category>sugar</category>
  1379.  <category>olpc</category>
  1380.  <category>litl</category>
  1381.  <category>negroponte</category>
  1382.  <lj:security>public</lj:security>
  1383.  <lj:reply-count>1</lj:reply-count>
  1384.  </item>
  1385. </channel>
  1386. </rss>
  1387.  

Home · About · News · Docs · Terms

 
Copyright © 2002-9 Sam Ruby, Mark Pilgrim, Joseph Walton, and Phil Ringnalda