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.
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.
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.
I don't think I ever had fun with it after booting Linux though...
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/openfirmware
https://en.wikipedia.org/wiki/Open_Firmware
https://elinux.org/Flameman/openfirmware-apple
http://macos9lives.com/smforum/index.php?topic=1965.0
https://github.com/ForthHub/ForthFreak/blob/master/Forthmacs
I've enjoyed using mine with Debian and a tiling WM. Much snappier.
http://wiki.laptop.org/go/Installing_Debian_as_an_upgrade#St...
OLPC's Forth Tutorial: http://wiki.laptop.org/go/Forth_Lessons
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.
You've obviously never tried to use a 2008 netbook for anything productive...
I also used a chromebook for a few years... tbh, I only went back to a rmbp because I needed better VPN support where I was working... Of course, I generally avoid taking it with me anywhere, I use my work laptop at work (docked) and my desktop at home.. or my phone for the most part.
I've also done productive work on my OLPC XO-1s (and an external keyboard, usually my IBM Model M). For example: http://bloominglabs.org/index.php/Logo#Animated_Logo
I started on windows, tried various Linux and ended up with Jolicloud on it, which was about the best I could hope for - but soon got a real laptop, and regretted wasting my cash on the netbook.
I was able to play old games, chat on IRC and read the occasional web page (though only one page at a time) and even watch videos. That latter part was a bit annoying though since i had to transcode most videos to a lower resolution and simpler codec, otherwise the CPU wouldn't be able to keep up (i do not think there was any video decoding acceleration). This usually meant that if i wanted to watch a 30m video i'd had to wait around 2 hours :-P. But i allocated time for that, doing transcoding while sleeping or going out.
Sadly one morning i destroyed the screen by stepping on it - i often used it at bed and left it at the side and one morning i stepped on it when i woke up. I later bought an Acer Aspire One as a replacement - that one was much faster (though some video still needed transcoding) and it had a much better keyboard. Sadly i lost it by forgetting it at a bus station.
Recently i bought a used EeePC 701 from eBay for a few dollars. It is in almost mint condition and instead of Linux it comes with Windows XP. I find it funny that at startup the OS always complains about the resolution (800x480) being too low despite being the native one :-P.
That's the nice thing about those netbooks still - they're available used for a few bucks (a lot less than $100!) often in very good condition, and a mainstream Linux distribution will run fine on them, even booting from SD card storage (which a lot of modern hardware will fail at)! Sure, you do need 1GB RAM and quite a few gigs of storage space, so the original eeePC 700 series is a no go, but everything else in that class works reasonably well.
We do see projects like pmOS that aim to do pretty much the same thing for modern mobile devices (tablets and smartphones), but the difficulties there are huge due to all the bespoke hardware - there's just no comparison.
Example: a 701 paired with an external good quality audio card plus Jaaa [1] might become a small useful standalone instrument for audio alignment (generator + spectrum analyzer).
[1] http://kokkinizita.linuxaudio.org/linuxaudio/
Jaaa is at about 75% of the page among lots of other interesting software.
It has a nasty hardware problem though, as it completely freezes down to requiring a cold reboot if I grab it with my left hand in the empty space left of the trackpad, but it appears other Thinkpads share the same problem as well. However after some years I had absolutely no problems in normal use.
...that's 5 inches. pixel count isn't everything. I'd rather take a 14" 1366 * 768 laptop than a than a 1920 * 1080 5" phone.
By comparison you get a 6” 1920 x 1080p screen on a 100$ ZTE ZMax PRO.
It was a 433Mhz x86 Via Geode LX released in 2006.
Additionally, it's worth watching how fast the younger generation that was raised on smartphone keyboards can type - some type impressive, though I've never measured wpm. Then again, I'm at the equivalent of index finger pecking on a regular keyboard on my smartphone's keyboard.
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.
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-schem...
Why MIT Switched from Scheme to Python (2009) (wisdomandwonder.com)
https://news.ycombinator.com/item?id=14167453
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/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/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/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...
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://github.com/SimHacker/micropolis/tree/master/turbogea...
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
...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.
[2] https://en.wikipedia.org/wiki/Scratch_(programming_language)...
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.
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.
Steve Jobs had the same conclusion[0].
[0]: https://www.forbes.com/sites/velocity/2011/10/05/nicholas-ne...