3 ms·

It was what could be built for the money. I was ok with the cheap keyboard. The processor could have been sufficient if there hadn't have been such a focus on

by Lerc 7y ago

It was what could be built for the money. I was ok with the cheap keyboard. The processor could have been sufficient if there hadn't have been such a focus on python. I got one through the G1G1 program and managed to get some decent work out of it.

jgrahamc 7y ago
What did you do with it? I did stuff like this: https://blog.jgc.org/2008/03/building-temperature-probe-for-olpc-xo.html https://blog.jgc.org/2008/03/building-temperature-probe-for-... and https://blog.jgc.org/2010/01/simplifying-my-olpc-xo-1-temperature.html https://blog.jgc.org/2010/01/simplifying-my-olpc-xo-1-temper...
- Lerc 7y ago
  I had a go at making a more performant desktop environment. https://www.youtube.com/watch?v=58UmxHryq8E https://www.youtube.com/watch?v=58UmxHryq8E This used a collection of existing Linux programs and a few I made myself. I built the Desktop widget engine, The physics doodle program, and made a NPAPI browser plugin that ran sandboxed x86 code (since it was evident that the CPU wasn't up to flash, I explored other ways to get active things running in-browser). Note at 2:17 I run free to show the resources used for the desktop with Firefox running. I also made a graphics library to use a video overlay to display scaled graphics so that you could render lower resolutions and scale to fullscreen. The Geode could drive a rgb565 video overlay with free scaling which meant you didn't have to push around the super high resolution of the XO-1 display when you wanted things to move swiftly.
DonHopkins 7y ago
Sugar missed the boat on JavaScript. Python seemed like a good idea at the time, in the days before Python 3, with its rich ecosystem of extension modules and extensible applications and framework integrations and web application servers, especially because it was so widely used educationally (and on the way to replacing Scheme at MIT and other schools); while JavaScript hadn't quite made its ascendency yet. MIT replaces Scheme with Python https://www.johndcook.com/blog/2009/03/26/mit-replaces-scheme-with-python/ https://www.johndcook.com/blog/2009/03/26/mit-replaces-schem... Why MIT Switched from Scheme to Python (2009) (wisdomandwonder.com) https://news.ycombinator.com/item?id=14167453 https://news.ycombinator.com/item?id=14167453 https://www.wisdomandwonder.com/link/2110/why-mit-switched-from-scheme-to-python https://www.wisdomandwonder.com/link/2110/why-mit-switched-f... Sugar's plan was for Python programs to access web functionality and integrate dynamic html and JavaScript via the xulrunner Python extension. But in the end, the xulrunner Python extension was not well supported, was extremely complex, and had lots of overhead. https://developer.mozilla.org/en-US/docs/Archive/Mozilla/XULRunner/Building_XULRunner_with_Python https://developer.mozilla.org/en-US/docs/Archive/Mozilla/XUL... And xulrunner itself turned out to be poorly supported by Mozilla, and never became popular, feature-rich, and well maintained like Electron. https://developer.mozilla.org/en-US/docs/Archive/Mozilla/XULRunner/Hall_of_Fame https://developer.mozilla.org/en-US/docs/Archive/Mozilla/XUL... Sugar was build on top of the Cairo graphics library, like xulrunner (Mozilla/Gecko/Firefox) and GTK were, so at least they shared the same 2D rendering library. Cairo (the moral equivalent of html canvas 2d context) was a great choice of 2D graphics library at the time, both for the browser and for Python, because the OLPC XO-1 hardware didn't have a 3D graphics accelerator (so WebGL was out). But Sugar then went on to use GTK via Python (using a complex GObject/Python adaptor bridge), and built a thick sweet syrupy layer of object oriented graphics and user interface gobbledygook on top of that. It was a mish-mash of way too many competing object systems (GTK objects + Python objects + Cairo objects + xulrunner objects + Sugar objects). At first, I simply ported and polished the old TCL/Tk/X11 version of SimCity to Sugar, by making a tiny Python wrapper around it to launch and kill the TCL/Tk app under control of the Sugar desktop user interface (with some metadata to give it a name and an icon on the Sugar desktop). My next more ambitious goal was to rewrite SimCity's TCL/Tk user interface in Python using Sugar, but Sugar was just not ready yet. But the PyGTK/Cairo stuff was solid and efficient. So I simply refactored SimCity into C++ classes, plugged them into Python with SWIG, and made a pure PyGTK/Cairo user interface that ran on Mac, Windows and Linux, instead of a Sugar-specific interface. So I could at least make some progress while waiting for Sugar's GUI API to gel and mature, which never really happened before I had to stop working for free and do something else to pay the rent. https://github.com/SimHacker/micropolis/tree/master/MicropolisCore/src/pyMicropolis/micropolisEngine https://github.com/SimHacker/micropolis/tree/master/Micropol... The original TCL/Tk version of SimCity supported multiplayer, but I had to disable it for the OLPC, because it used hard-to-set-up insecure X11 networking, not suitable for kids. And the sugar mesh network invitation rendezvous stuff wan't ready yet (or worth reimplementing in TCL/Tk just for SimCity). http://www.art.net/~hopkins/Don/simcity/simcity-announcement.html http://www.art.net/~hopkins/Don/simcity/simcity-announcement... To implement a modern multiplayer version of SimCity (now referred to as Micropolis), instead of using X11, it made much more sense to run the simulation as a web service and the user interface in the web browser. So I develop a Python/TurboGears/SQLAlchemy based back-end web application server, plugged the C++ MicropolisCore simulation engine into the web server with SWIG, and made an OpenLaszlo/Flash/AMF based front-end user interface, because Dynamic HTML, WebSockets and WebRTC were't quite ready yet. https://www.youtube.com/watch?v=8snnqQSI0GE https://www.youtube.com/watch?v=8snnqQSI0GE https://github.com/SimHacker/micropolis/tree/master/turbogears https://github.com/SimHacker/micropolis/tree/master/turbogea... https://github.com/SimHacker/micropolis/tree/master/laszlo/micropolis/classes https://github.com/SimHacker/micropolis/tree/master/laszlo/m... Now days the JavaScript ecosystem is mature enough to implement the user interface and networking without proprietary crap like Flash and AMF (in fact Graeme McCutcheon has rewritten the entire simulator and user interface in JavaScript). https://github.com/graememcc/micropolisJS https://github.com/graememcc/micropolisJS ...Eventually JavaScript started running a hell of a lot faster than anyone expected, then Flash died, xulrunner withered on the vine, while dynamic HTML, canvas, WebGL, and WebAssembly finally matured, and node.js and Electron happened, JavaScript evolved, the tooling and library ecosystem expanded like a supernova, and JavaScript took over the world. But that wasn't what most people expected to happen 14 years ago in 2005, when Python was on its way to ascendency as both a general purpose language to replace Perl, PHP and Java, and an educational language to replace Scheme. In retrospect, if we could restart from scratch today, Sugar could have been written entirely in JavaScript, on top of something like xulrunner or Electron to access the operating system, and the entire system and many applications could have been programmed and scripted in JavaScript instead of Python. But then Sugar would have to compete with the myriad of other JavaScript pointy clicky user interface frameworks out there, on its merits. And while it had some great ideas and nice designs, it also made a lot of huge design and architectural mistakes and bad trade-offs. Redesigning a friendly graphical internationalized localizable user interface for children from the ground up is a gigantic fractally complex long term problem, and Sugar bit off of a lot more than it could chew and optimistically overpromised, even if it were built on top of today's software and hardware. But there are still some great long term evolutionary projects that were adapted for the OLPC and have migrated or been reborn to run in the web browser. By now, Squeak and Scratch and Snap! all run in the web browser: both in an emulated Smalltalk VM written in JavaScript (squeakjs [1]), and also Scratch 3.0 [2] has been rewritten entirely in JavaScript. Snap! [3] was originally written in JavaScript from the ground up, and has all the power and generality of Scheme, that Scratch left out. [1] https://squeak.js.org/ https://squeak.js.org/ [2] https://en.wikipedia.org/wiki/Scratch_(programming_language)#Code_base https://en.wikipedia.org/wiki/Scratch_(programming_language)... [3] https://snap.berkeley.edu https://snap.berkeley.edu
- Lerc 7y ago
  If the plan was to have something nice performing on the XO-1 then I would have gone with something like FreePascal, It existed, The compiler was fast, friendly to newcomers, and the final code is much faster than anything Interpreted. JIT gets you speed but at the cost of memory. Remember it only had 256Meg. Similarly, Having used Cairo on the XO, I saw no evidence of hardware acceleration, and was significantly slower than other software renderer I tried. I used Imlib2 which was massively faster. I would have preferred a much simpler graphics library that was specifically designed to support the 2d Acceleration that the geode provided. Fewer features but everything fast. I played the original StarCraft on a machine significantly less powerful than the XO-1. It managed a smoother GUI with Sci-fi looking transparent panels sliding in. The power was there but abstraction threw it all away.

by Lerc 7y ago

jgrahamc 7y ago

What did you do with it? I did stuff like this: https://blog.jgc.org/2008/03/building-temperature-probe-for-olpc-xo.html https://blog.jgc.org/2008/03/building-temperature-probe-for-... and https://blog.jgc.org/2010/01/simplifying-my-olpc-xo-1-temperature.html https://blog.jgc.org/2010/01/simplifying-my-olpc-xo-1-temper...

Lerc 7y ago
I had a go at making a more performant desktop environment. https://www.youtube.com/watch?v=58UmxHryq8E https://www.youtube.com/watch?v=58UmxHryq8E This used a collection of existing Linux programs and a few I made myself. I built the Desktop widget engine, The physics doodle program, and made a NPAPI browser plugin that ran sandboxed x86 code (since it was evident that the CPU wasn't up to flash, I explored other ways to get active things running in-browser). Note at 2:17 I run free to show the resources used for the desktop with Firefox running. I also made a graphics library to use a video overlay to display scaled graphics so that you could render lower resolutions and scale to fullscreen. The Geode could drive a rgb565 video overlay with free scaling which meant you didn't have to push around the super high resolution of the XO-1 display when you wanted things to move swiftly.

DonHopkins 7y ago

Sugar missed the boat on JavaScript. Python seemed like a good idea at the time, in the days before Python 3, with its rich ecosystem of extension modules and extensible applications and framework integrations and web application servers, especially because it was so widely used educationally (and on the way to replacing Scheme at MIT and other schools); while JavaScript hadn't quite made its ascendency yet. MIT replaces Scheme with Python https://www.johndcook.com/blog/2009/03/26/mit-replaces-scheme-with-python/ https://www.johndcook.com/blog/2009/03/26/mit-replaces-schem... Why MIT Switched from Scheme to Python (2009) (wisdomandwonder.com) https://news.ycombinator.com/item?id=14167453 https://news.ycombinator.com/item?id=14167453 https://www.wisdomandwonder.com/link/2110/why-mit-switched-from-scheme-to-python https://www.wisdomandwonder.com/link/2110/why-mit-switched-f... Sugar's plan was for Python programs to access web functionality and integrate dynamic html and JavaScript via the xulrunner Python extension. But in the end, the xulrunner Python extension was not well supported, was extremely complex, and had lots of overhead. https://developer.mozilla.org/en-US/docs/Archive/Mozilla/XULRunner/Building_XULRunner_with_Python https://developer.mozilla.org/en-US/docs/Archive/Mozilla/XUL... And xulrunner itself turned out to be poorly supported by Mozilla, and never became popular, feature-rich, and well maintained like Electron. https://developer.mozilla.org/en-US/docs/Archive/Mozilla/XULRunner/Hall_of_Fame https://developer.mozilla.org/en-US/docs/Archive/Mozilla/XUL... Sugar was build on top of the Cairo graphics library, like xulrunner (Mozilla/Gecko/Firefox) and GTK were, so at least they shared the same 2D rendering library. Cairo (the moral equivalent of html canvas 2d context) was a great choice of 2D graphics library at the time, both for the browser and for Python, because the OLPC XO-1 hardware didn't have a 3D graphics accelerator (so WebGL was out). But Sugar then went on to use GTK via Python (using a complex GObject/Python adaptor bridge), and built a thick sweet syrupy layer of object oriented graphics and user interface gobbledygook on top of that. It was a mish-mash of way too many competing object systems (GTK objects + Python objects + Cairo objects + xulrunner objects + Sugar objects). At first, I simply ported and polished the old TCL/Tk/X11 version of SimCity to Sugar, by making a tiny Python wrapper around it to launch and kill the TCL/Tk app under control of the Sugar desktop user interface (with some metadata to give it a name and an icon on the Sugar desktop). My next more ambitious goal was to rewrite SimCity's TCL/Tk user interface in Python using Sugar, but Sugar was just not ready yet. But the PyGTK/Cairo stuff was solid and efficient. So I simply refactored SimCity into C++ classes, plugged them into Python with SWIG, and made a pure PyGTK/Cairo user interface that ran on Mac, Windows and Linux, instead of a Sugar-specific interface. So I could at least make some progress while waiting for Sugar's GUI API to gel and mature, which never really happened before I had to stop working for free and do something else to pay the rent. https://github.com/SimHacker/micropolis/tree/master/MicropolisCore/src/pyMicropolis/micropolisEngine https://github.com/SimHacker/micropolis/tree/master/Micropol... The original TCL/Tk version of SimCity supported multiplayer, but I had to disable it for the OLPC, because it used hard-to-set-up insecure X11 networking, not suitable for kids. And the sugar mesh network invitation rendezvous stuff wan't ready yet (or worth reimplementing in TCL/Tk just for SimCity). http://www.art.net/~hopkins/Don/simcity/simcity-announcement.html http://www.art.net/~hopkins/Don/simcity/simcity-announcement... To implement a modern multiplayer version of SimCity (now referred to as Micropolis), instead of using X11, it made much more sense to run the simulation as a web service and the user interface in the web browser. So I develop a Python/TurboGears/SQLAlchemy based back-end web application server, plugged the C++ MicropolisCore simulation engine into the web server with SWIG, and made an OpenLaszlo/Flash/AMF based front-end user interface, because Dynamic HTML, WebSockets and WebRTC were't quite ready yet. https://www.youtube.com/watch?v=8snnqQSI0GE https://www.youtube.com/watch?v=8snnqQSI0GE https://github.com/SimHacker/micropolis/tree/master/turbogears https://github.com/SimHacker/micropolis/tree/master/turbogea... https://github.com/SimHacker/micropolis/tree/master/laszlo/micropolis/classes https://github.com/SimHacker/micropolis/tree/master/laszlo/m... Now days the JavaScript ecosystem is mature enough to implement the user interface and networking without proprietary crap like Flash and AMF (in fact Graeme McCutcheon has rewritten the entire simulator and user interface in JavaScript). https://github.com/graememcc/micropolisJS https://github.com/graememcc/micropolisJS ...Eventually JavaScript started running a hell of a lot faster than anyone expected, then Flash died, xulrunner withered on the vine, while dynamic HTML, canvas, WebGL, and WebAssembly finally matured, and node.js and Electron happened, JavaScript evolved, the tooling and library ecosystem expanded like a supernova, and JavaScript took over the world. But that wasn't what most people expected to happen 14 years ago in 2005, when Python was on its way to ascendency as both a general purpose language to replace Perl, PHP and Java, and an educational language to replace Scheme. In retrospect, if we could restart from scratch today, Sugar could have been written entirely in JavaScript, on top of something like xulrunner or Electron to access the operating system, and the entire system and many applications could have been programmed and scripted in JavaScript instead of Python. But then Sugar would have to compete with the myriad of other JavaScript pointy clicky user interface frameworks out there, on its merits. And while it had some great ideas and nice designs, it also made a lot of huge design and architectural mistakes and bad trade-offs. Redesigning a friendly graphical internationalized localizable user interface for children from the ground up is a gigantic fractally complex long term problem, and Sugar bit off of a lot more than it could chew and optimistically overpromised, even if it were built on top of today's software and hardware. But there are still some great long term evolutionary projects that were adapted for the OLPC and have migrated or been reborn to run in the web browser. By now, Squeak and Scratch and Snap! all run in the web browser: both in an emulated Smalltalk VM written in JavaScript (squeakjs [1]), and also Scratch 3.0 [2] has been rewritten entirely in JavaScript. Snap! [3] was originally written in JavaScript from the ground up, and has all the power and generality of Scheme, that Scratch left out. [1] https://squeak.js.org/ https://squeak.js.org/ [2] https://en.wikipedia.org/wiki/Scratch_(programming_language)#Code_base https://en.wikipedia.org/wiki/Scratch_(programming_language)... [3] https://snap.berkeley.edu https://snap.berkeley.edu

Lerc 7y ago
If the plan was to have something nice performing on the XO-1 then I would have gone with something like FreePascal, It existed, The compiler was fast, friendly to newcomers, and the final code is much faster than anything Interpreted. JIT gets you speed but at the cost of memory. Remember it only had 256Meg. Similarly, Having used Cairo on the XO, I saw no evidence of hardware acceleration, and was significantly slower than other software renderer I tried. I used Imlib2 which was massively faster. I would have preferred a much simpler graphics library that was specifically designed to support the 2d Acceleration that the geode provided. Fewer features but everything fast. I played the original StarCraft on a machine significantly less powerful than the XO-1. It managed a smoother GUI with Sci-fi looking transparent panels sliding in. The power was there but abstraction threw it all away.