8 ms·

I own one of these. I bought it through the "Give One, Get One" program that OLPC ran (https://en.wikipedia.org/wiki/One_Laptop_per_Child#Give_1_Get_1_program h

I own one of these. I bought it through the "Give One, Get One" program that OLPC ran (https://en.wikipedia.org/wiki/One_Laptop_per_Child#Give_1_Get_1_program https://en.wikipedia.org/wiki/One_Laptop_per_Child#Give_1_Ge...). If you've never used one it's hard to describe just how awful this machine was. The keyboard, the screen, the processor and worst of all the software. And I say that as someone who really wanted it to work and really wanted to use it with children to help them understand computing.

lukego 7y ago
I loved my XO. I used it for writing Forth code to relive the BASIC hacking of my youth. Great in that niche :-) I don't think I ever had fun with it after booting Linux though...
- DonHopkins 7y ago
  That's Mitch Bradley's Open Firmware Forth, which was also on Suns, post-NuBus PowerPC Macs, Pegasos, and IBM Power Systems! I used to call it "L1-A Forth", because that's the Forth you got when you pressed "L1-A" on a Sun keyboard to get into the boot monitor. He also made a great version of that Forth system with a metacompiler that ran under Unix (Forthmacs), which I used a lot. https://github.com/MitchBradley https://github.com/MitchBradley https://github.com/MitchBradley/openfirmware https://github.com/MitchBradley/openfirmware https://en.wikipedia.org/wiki/Open_Firmware https://en.wikipedia.org/wiki/Open_Firmware https://elinux.org/Flameman/openfirmware-apple https://elinux.org/Flameman/openfirmware-apple http://macos9lives.com/smforum/index.php?topic=1965.0 http://macos9lives.com/smforum/index.php?topic=1965.0 https://github.com/ForthHub/ForthFreak/blob/master/Forthmacs https://github.com/ForthHub/ForthFreak/blob/master/Forthmacs
- avhon1 7y ago
  The Fedora-based distro is definitely a pain. Sugar has some neat ideas, it it's way too slow. I've enjoyed using mine with Debian and a tiling WM. Much snappier. http://wiki.laptop.org/go/Installing_Debian_as_an_upgrade#Step_1:_Create_debian_bootstrap http://wiki.laptop.org/go/Installing_Debian_as_an_upgrade#St...
- claystu 7y ago
  I wanted one for the Forth environment too! OLPC's Forth Tutorial: http://wiki.laptop.org/go/Forth_Lessons http://wiki.laptop.org/go/Forth_Lessons
amelius 7y ago
A $100 smartphone is probably far superior, nowadays.
- Retric 7y ago
  A $100 smartphone beats 400$ netbooks from 2008 in terms of hardware. 1920 x 1080p full HD display, an 8-core processor with 2GB of RAM, 32GB of storage.
  - imtringued 7y ago
    And completely loses out in terms of software and productivity.
    - forgotmypwd123 7y ago
      >productivity You've obviously never tried to use a 2008 netbook for anything productive...
      - dkersten 7y ago
        I used a 2008 eee PC exclusively for all personal computing needs for about two or three years (web browser, videos, music, chat and programming in python, C++ and clojure), running Arch Linux. The only thing I didn't do on it was play games and I had a desktop in the office for professional work at the time. It worked perfectly fine. Hell, I miss it sometimes.
      - rini17 7y ago
        I really did ton of work on MSI Wind. All kinds of work, even maintaining old Delphi codebases. Granted, it had probably the best keyboard of all netbooks of that time and most time I worked with external monitor.
      - jacquesm 7y ago
        I know plenty of people that taught themselves how to program on ZX-81's.
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
tpmx 7y ago
It was almost comically bad wen I tried it back then. https://www.economist.com/science-and-technology/2008/01/04/one-clunky-laptop-per-child https://www.economist.com/science-and-technology/2008/01/04/... > Great idea. Shame about the mediocre computer > Major PC vendors spend millions in research and development to enhance a computer's usability; OLPC tried to reinvent the wheel and came up with an oval.
mcv 7y ago
I also got one through an employer that supported "Give One, Get One". Fantastic idea, but I never really figured out what to do with it. The UI looked like it was headed somewhere really interesting, but it wasn't clear how to get there. My son did use it to play some games at some point, but to learn programming, Minecraft's redstone system turned out to be far more attractive.
em-bee 7y ago
i got one too, and for years if was my primary portable work device as a programmer only to be later replaced by a the 1.5 model which i used until 2 years ago! sure, the webbrowser on the first model couldn't open more than a handful tabs before getting bogged down due to lack of ram (the 1.5 model could open a few dozen tabs or so), but other than that it was a capable and usable device. the keyboard was made for kids, not for touch-typists. i am not a touch typist myself, and so for me the keyboard worked perfectly fine. the screen was actually awesome. the dual mode where you can turn of the color and get a high resolution black-and-white screen made working outside a blast. the famous dream of working by the beach, i did that with an OLPC because on any other laptop i would not have been able to see anything because the sunlight was to strong.
jimktrains2 7y ago
The outside, retroreflecticive screen mode whose name I forget was really nice and I'm sad it's not available on _any_ device currently. It was much closer to feeling like reading an eink display but none of the refresh delay.
octref 7y ago
> worst of all the software Steve Jobs had the same conclusion[0]. [0]: https://www.forbes.com/sites/velocity/2011/10/05/nicholas-negroponte-steve-jobs-influence-not-influenced/#54b38f43b07b https://www.forbes.com/sites/velocity/2011/10/05/nicholas-ne...
13415 7y ago
That was the main problem. The project was always based on a colonial and patronizing attitude. Don't give kids the real thing, so they can learn how to use Excel spreadsheet (some real CV item), but rather give them custom hardware and custom software that nobody would want to buy somewhere else. God forbid some kid could accidentally learn how to use some proprietary software. Instead, they could have just put their PixelQ displays on some ruggedized X86 laptops produced in China or Taiwan and put some good Linux and tons of books on it. The ironic thing is that it's still near impossible to get a laptop with a fully sun-readable screen anywhere, neither in developing nor in industrialized countries.
- duskwuff 7y ago
  If they had skipped all of the custom interface design and simply shipped a standard Linux desktop, maybe with a custom launcher and a few custom educational apps, they could have saved years of development time and put the devices in front of students much sooner.

lukego 7y ago

I loved my XO. I used it for writing Forth code to relive the BASIC hacking of my youth. Great in that niche :-) I don't think I ever had fun with it after booting Linux though...

DonHopkins 7y ago
That's Mitch Bradley's Open Firmware Forth, which was also on Suns, post-NuBus PowerPC Macs, Pegasos, and IBM Power Systems! I used to call it "L1-A Forth", because that's the Forth you got when you pressed "L1-A" on a Sun keyboard to get into the boot monitor. He also made a great version of that Forth system with a metacompiler that ran under Unix (Forthmacs), which I used a lot. https://github.com/MitchBradley https://github.com/MitchBradley https://github.com/MitchBradley/openfirmware https://github.com/MitchBradley/openfirmware https://en.wikipedia.org/wiki/Open_Firmware https://en.wikipedia.org/wiki/Open_Firmware https://elinux.org/Flameman/openfirmware-apple https://elinux.org/Flameman/openfirmware-apple http://macos9lives.com/smforum/index.php?topic=1965.0 http://macos9lives.com/smforum/index.php?topic=1965.0 https://github.com/ForthHub/ForthFreak/blob/master/Forthmacs https://github.com/ForthHub/ForthFreak/blob/master/Forthmacs
avhon1 7y ago
The Fedora-based distro is definitely a pain. Sugar has some neat ideas, it it's way too slow. I've enjoyed using mine with Debian and a tiling WM. Much snappier. http://wiki.laptop.org/go/Installing_Debian_as_an_upgrade#Step_1:_Create_debian_bootstrap http://wiki.laptop.org/go/Installing_Debian_as_an_upgrade#St...
claystu 7y ago
I wanted one for the Forth environment too! OLPC's Forth Tutorial: http://wiki.laptop.org/go/Forth_Lessons http://wiki.laptop.org/go/Forth_Lessons

amelius 7y ago

A $100 smartphone is probably far superior, nowadays.

Retric 7y ago
A $100 smartphone beats 400$ netbooks from 2008 in terms of hardware. 1920 x 1080p full HD display, an 8-core processor with 2GB of RAM, 32GB of storage.
- imtringued 7y ago
  And completely loses out in terms of software and productivity.
  - forgotmypwd123 7y ago
    >productivity You've obviously never tried to use a 2008 netbook for anything productive...
    - dkersten 7y ago
      I used a 2008 eee PC exclusively for all personal computing needs for about two or three years (web browser, videos, music, chat and programming in python, C++ and clojure), running Arch Linux. The only thing I didn't do on it was play games and I had a desktop in the office for professional work at the time. It worked perfectly fine. Hell, I miss it sometimes.
    - rini17 7y ago
      I really did ton of work on MSI Wind. All kinds of work, even maintaining old Delphi codebases. Granted, it had probably the best keyboard of all netbooks of that time and most time I worked with external monitor.
    - jacquesm 7y ago
      I know plenty of people that taught themselves how to program on ZX-81's.

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

tpmx 7y ago

It was almost comically bad wen I tried it back then. https://www.economist.com/science-and-technology/2008/01/04/one-clunky-laptop-per-child https://www.economist.com/science-and-technology/2008/01/04/... > Great idea. Shame about the mediocre computer > Major PC vendors spend millions in research and development to enhance a computer's usability; OLPC tried to reinvent the wheel and came up with an oval.

mcv 7y ago

I also got one through an employer that supported "Give One, Get One". Fantastic idea, but I never really figured out what to do with it. The UI looked like it was headed somewhere really interesting, but it wasn't clear how to get there. My son did use it to play some games at some point, but to learn programming, Minecraft's redstone system turned out to be far more attractive.

em-bee 7y ago

i got one too, and for years if was my primary portable work device as a programmer only to be later replaced by a the 1.5 model which i used until 2 years ago! sure, the webbrowser on the first model couldn't open more than a handful tabs before getting bogged down due to lack of ram (the 1.5 model could open a few dozen tabs or so), but other than that it was a capable and usable device. the keyboard was made for kids, not for touch-typists. i am not a touch typist myself, and so for me the keyboard worked perfectly fine. the screen was actually awesome. the dual mode where you can turn of the color and get a high resolution black-and-white screen made working outside a blast. the famous dream of working by the beach, i did that with an OLPC because on any other laptop i would not have been able to see anything because the sunlight was to strong.

jimktrains2 7y ago

The outside, retroreflecticive screen mode whose name I forget was really nice and I'm sad it's not available on _any_ device currently. It was much closer to feeling like reading an eink display but none of the refresh delay.

octref 7y ago

> worst of all the software Steve Jobs had the same conclusion[0]. [0]: https://www.forbes.com/sites/velocity/2011/10/05/nicholas-negroponte-steve-jobs-influence-not-influenced/#54b38f43b07b https://www.forbes.com/sites/velocity/2011/10/05/nicholas-ne...

13415 7y ago

That was the main problem. The project was always based on a colonial and patronizing attitude. Don't give kids the real thing, so they can learn how to use Excel spreadsheet (some real CV item), but rather give them custom hardware and custom software that nobody would want to buy somewhere else. God forbid some kid could accidentally learn how to use some proprietary software. Instead, they could have just put their PixelQ displays on some ruggedized X86 laptops produced in China or Taiwan and put some good Linux and tons of books on it. The ironic thing is that it's still near impossible to get a laptop with a fully sun-readable screen anywhere, neither in developing nor in industrialized countries.

duskwuff 7y ago
If they had skipped all of the custom interface design and simply shipped a standard Linux desktop, maybe with a custom launcher and a few custom educational apps, they could have saved years of development time and put the devices in front of students much sooner.