Archive for the 'olpc' Category


Custom activity-update howto

After a discussion on #sugar, I noticed that setting up a custom update-mechanism for Activities/XO bundles on XO’s is a bit of a lost art. I had to dig through the Sugar code a bit to get a clear understanding. I’ve updated the wiki (see, but it might be useful to give other deployments a heads-up on what’s involved through this syndicated post.

So the XO has a nice gui activity-updater, accessable by opening the control-panel, and then choosing the activity updater. Figures. The updater gives you two valuable functions: Updating existing activities, and installing new ones. At the moment the updater can’t be instructed to delete certain activities though, which is to bad, because otherwise deployments could contain just about all the administration of activities within one central place.

Out of the box an XO will check a default wiki-page on the wiki. The XO expects a list of links to relevant builds of activities, together with some metadata embedded in the span/div that surrounds it. The XO will loop through all the activities in your Activities dir, it checks if it’s got a custom update url defined in its file. If so it’ll try to update from that url. Either way, it will also check the version on the page and will use the highest one. If it finds a newer build, it will include it in the list of suggested updates. If the XO finds an activity that’s not yet installed it will also be included in the list, but new activities will not be checked for updates from the url defined in its file.

As a local deployment you would want to control yourself to which version you want to update. You want to make sure the new version works for your build, and for your objectives, and not the ones of some random guy that happens to updates the according wiki-page. So what you do is point the XO to an update page under your control, which points the XO to the activities you want to put on it. To override the default update page, put a file with either /etc/olpc-update/activity-groups or /home/olpc/Activities/.groups on your system, with the relevant update urls on different lines (yes, you can have multiple).

At OLE Nepal we manage the activities on the schoolserver. So we’ve got a canonical set of activities in a folder reachable through http. In the same folder we put a dynamically generated page in the right format. A cron job checks the folder every hour, grovels the activity/info file of every one of them, and writes out a page with the correct metadata. In this way managing the right set of activities becomes a drag-and-drop affair.

As for the format of the page, take a look at a snippet from our page generator script, invoked by a little cron script:

def makeItemString(actId, actVer, actUrl, actName):
    return """
      <span class="olpc-activity-info">
          <span class="olpc-activity-id" style="display:none;">%s</span>
          <span class="olpc-activity-version" style="display:none;">%s</span>
          <span class="olpc-activity-url"><a href='%s'>%s</a></span>
    """ % (actId, actVer, actUrl, actName)

So the updater will search for nodes with have olpc-activity-info as class name. Then it also wants to know the activity-id, the activity-version, and the activity-url, all extracted from the activity info file in the XO bundle.

As written above, if an installed activity has an update-url defined in its file by the activity creator, the XO will check the url for a version greater than the one in the groups file url. The latest version will be installed. This is seen as a feature, but I disagree. The url of some random page should NOT be checked. Again, we want to have control over what gets installed, and we can’t leave the risk of broken activities to chance or evil activity-developers. So I hacked the Sugar updater code ever so slightly and put it in our pilgrim local build:

The simplest way to not check the url is to open /usr/share/sugar/shell/controlpanel/model/ and edit refresh_existing to not call _retrieve_update_version, but assign the values it would return if no update-url was found; so a tuple containing:

(0 if _DEBUG_MAKE_ALL_OLD else act.get_activity_version()), None, None, 0

And since the updater doesn’t check for new versions of new activities, we don’t need to make provisions for them.

And that’s about it. This gives us control enough over which activity is installed on our deployment XO’s. Cases not covered though by this mechanism are new bundles installed by the children themselves, and children installing versions newer than the ones we put in the schoolserver (which can be remedied easily enough by making sure the first tuple value above is always 0). But I’m not sure not addressing them should be regarded as missing features, or wanted behaviour.

[update] I sent a mail with some of my thoughts to the sugar-devel list and C. Scott Ananian layed out some excellent ideas for enhancing the updater to resolve to deficiencies mentioned above.


Customizing the XO image

Bryan asked to write something about the XO-customization build process for OLE Nepal. See this post as the second installment of the OLE Nepal deployment series.

So here we go:

First: why do we need to customize a standard XO build? What’s wrong with the one supplied by OLPC. Isn’t that one tested through and through, and shaved to perfection?

Absolutely. To perfection… Well, almost… But that’s besides the point. In a software package as big as a total XO install, it’s just about inconceivable that the local requirements overlap a hundred percent with OLPC’s. General stuff, like proper support for Unicode keyboard layouts, is… general enough for OLPC to integrate in the standard software. But between us wanting it, and them integrating it in a stable build lies a time-gap to great to wait for. And since we are progressing with local stuff over time, we will have new requirements, when the old ones are integrated. Also we have, or might have requirements that OLPC just isn’t interested in or for which it just doesn’t have the manpower. And then then we have local configurations like our own update server for Activities or System software, which are scattered around the filesystem.

It’s easiest to keep track of all these changes in one place, and we made our own version-controlled Pilgrim build to do take on that burden. For the uninitiated: Pilgrim is the XO filesystem- and image-builder that the folks at OLPC use themselves to build their images.

The biggest benefits of Pilgrim over for example cloning (which we did before) are:
– All the customizations are contained in scripts, so you don’t have to document them, so you can’t forget certain steps
– It forces you to structure the files needed for customization, and while you’re at it, you might just as well version-control them
– You get a customization factory which builds lots of different useful files, like image files, with which you can flash XO’s, the .usb files which you can use for machine-local olpc-update-s, and an fs tree which you can use for olpc-update over the network. (note btw that olpc-update preserves user-data).

A rival of Pilgrim is Puritan by the way, written in Python, mostly by Michael Stone, which tries to be more elegant about things like caching, debugging and aborting the build process, and building and customizing the image (and has a cool way to use Git for changes). The need for something like Puritan is there, because Pilgrim IS a big daisy-chain of hacks.

Pilgrim nitty-gritty

So what kind of stuff did we change at OLE Nepal? Perhaps a bit more overview first. Say one would want to get a clean 8.2 image. One checks out Pilgrim, sets it to the right build (be it 8.2 or 703 or whatever), installs some dependencies, make-installs it and enters an incantation on the command-line to let it poop out the .img file and its brothers and sisters. And voila!

But one wants and needs to hack pilgrim a bit. The relevant big ones are the ‘pilgrim’ file in the root and the one in the streams.d dir, with some auxillery config files sourced in. A few thousand lines of bash scripting, so it’s a little dynamically scoped monster.

The first step was to cache all the rpms needed for building the XO local, since downloading them from outside Nepal takes hours and out of the box Pilgrim deletes them. We put them in a local Yum repo, and edit the yum directives  in olpc-development-yum-install.conf accordingly.

Also we revived the automatic installation of activities. Which needed a little bit of love, since last it was used it still put all of them in /usr/share/sugar. Also the installer expects an html file with links to the activities you might want to install, which it wgets to a local directory, after which it takes the latest version of the ones you specified in So you might want to have a script to generate that file from the contents of your activities directory, much like what one needs for the software-updater, but a bit less sophisticated.

Related to the last paragraph, you’ll find that the fake mounted image in your build-system will fill up pretty quickly with all that activity content. A bit to quick actually, since the XO uses jffs2 which will compress your fs pretty tight, while pilgrim configures the image on your build system to only one gig. So you might want to set PILGRIM_FS_SIZE_jffs2 and/or PILGRIM_FS_SIZE_devel_jffs2 in to double that amount, which is about right I believe.

Then some customizations on what output would be created was necessary. First of all we want to use olpc-update for updating the XO’s from time to time. olpc-update expects a filesystem tree, and a contents file pooped out by pilgrim. With the standard build, pulled from the interwebs, the files aren’t put in the right order and place (or, at all really) to be consumed by the olpc-update script present on the XO’s.

Also be ware if you want to olpc-update from your own server with a 703 build. Its on-board olpc-update version doesn’t have the option to specify another server than the standard. And the development version of olpc-update doesn’t contain all the bitfrost files needed by 703, since it doesn’t have them itself yet. You can just supplant the bitfrost dir in the development version with the bitfrost dir from a recent XO build ( /usr/lib/python2.5/site-packages/bitfrost  works with the one from 8.2 in any case. Should still send a patch). AANNDDDDD, olpc-update pulls in files from the server through rsync://…, so set up a correct rsync daemon conf file in /etc, and start the rsync daemon at startup.

And also the standard pilgrim will make tars out of the fs that you’ll rarely need but will take forever to build and take up useless space. So we commented them out.

XO customizations

Then we have to deal with the customizations to the XO itself. The whole reason for this operation.

1) We had issues with xkb and the traditional Nepali keyboard layout. SCIM solves these issues, so that’s what we installed. Everything, except for Write, seems to work for us. Since we’re expecting to work that kink out of the cable, we’re switching to SCIM. Adding extra packages in Pilgrim is just a matter of adding them to the yum list in and making sure you point to a repo that holds them and their dependencies.

2) The same holds true for auxillery packages needed by certain activities. We want flash and gnuchess for example, and xpdf, which comes with its own set of dependencies.

3) Then we have config files that we want to hardwire. So the xo’s should update from our schoolservers, not from the wiki or from a location specified by the activities themselves. So we put a file in /etc/olpc-update. Of course you can do that through the gui, but you don’t want to do that for every XO that goes through your hands.

The correct way for incorporating these configurations is perhaps making rpm packages, but to me that seems like to much of a hassle for no real gain, so we’ve got our own for that. Makes it sound nice and official.

Other victims are the scim config dir, the list of default activity favorites, Nepali espeak data and the wpa2 password for the schoolserver if utilized (connecting to aps with wpa2 set is very flaky atm).

Right now we can’t just put our images on non-unlocked (so locked) XO’s, because we can’t sign them (olpc-updating locked XOs to unsigned builds should perhaps not be that hard though, if all one needs to do is tweak the olcp-update script), but apparently OLPC is working on a solution for deployments.

Of course we tested the builds, and they work as expected. So now we’ve got a nice updater and a nice custom image generator. Pretty sweet!

Oh! And happy New Year, to the ones who celebrate! And also for the ones who don’t. No need to be cheap.


Shielding against fate

As written before, at the moment we’ve got two pilot schools, fairly close to our office. We, them and the Department of Education are connected to eachother through a simple network. If something goes wrong software- or hardware-wise, or we need to upgrade XO’s, it’s fairly easy for us to come over and fix stuff on the same day.

But actually that already is a hassle. Whoever goes to the schools looses a day, and putting new activities on 135 XO’s, repeating the same mundane commands, is time consuming. In spring we’re gonna deploy a couple of thousands XO’s to 15 schools around Nepal. We need automation! And not only that; we also need compartimetalization. Actually we are trying to strike a balance between the easiest way to put content on laptops and the most robust way to put content on laptops.

The problem

That is to say, in a country like Nepal you can’t count on anything. Take power for example. Our office is located in the center of Kathmandu, the capital. For two days running now we hardly had any power (so I’m filling my time writing blogposts on my XO). For one we have scheduled power outages which total 10 hours a day (‘loadshedding’). Rumour has it this will go up to 18 hours a day. Our battery-backup system can’t handle that many hours. Also our UPS has problems. Something that’s gonna happen in the field as well, but then there’s no power-engineer present on-site to address the problem.

A related issue is the fickleness of internet connections. Often we at the office don’t have internet because of problems at our ISP or with the connection from Nepal to the outside world. And of course no power automatically means no internet. And this can happen on a number of levels. Our schools are connected to the internet through the computer-lab at the Department of Education (DoE). And DoE is equally affected by loadshedding. Last week we discovered that the capacitators there can’t handle the power-requirements of the battery-rig we set up in the lab. No power at DoE, no internet for the schools.

The solution

And it’s not just about internet access. We’re gathering more and more content for the kids to use during their classes. Way more than we can put on their XO’s. So they need a way to access that information, and we need a way to easily update this information. An ideal scenario would be putting that content on a central server and to let all kids access that content on-demand. An additional benifit is that kids from non-pilot-schools can also benefit from our efforts. But because of network and power issues we can’t rely on a central server alone. And this is where things get messy. So software-wise, what we’re sort of trying to create a little three-layered system.

1) At the top there’s a central server, capable of upgrading the schoolservers and able to serve all our content to everybody that has access to the web.

2) The schoolservers have a local copy of all the content, since we can’t count on the central server. The schoolservers should be able to upgrade the XO’s. Both the system software and the content, which both have different requirements.

3) The XO’s themselves of course.

Upgrading the system-software is the least of our problems. Right now we use olpc-update from local servers who get custom builds, made by Pilgrim, from the central server. Upgrades will be pushed only once in a while. Content is a different problem. Since we can’t count on the schoolserver being up all the time we need to have content on the XO’s themselves. But since we’ve got too much content, some should stay on the server.

Our plan is to have the content needed for specific lessons of the current week, the last week, and the next week on the XO. If the kids want or need to access more info, they should be able to get it on demand. And all of this should be transparent and automatic. We’re gonna use Moodle to specify the content for all the school-weeks on the schoolservers. We’re gonna use google gears to cache three weeks of content on the XO’s. If for a specific week the content is not to be found locally, the XO’s should go to the schoolserver and get it there.

Most of the stuff cited above is being worked on. We’ve got a lot of content. We’ve got a central server for that content. We’re putting the last touches on our customized version of the OLPC schoolserver software (0.4 atm). Thanks to XO version 8.2 we can update our own set of activities from our local server. We’ve got our own Pilgrim XO baking factory. Olpc-update:ing from a local schoolserver works fine.

What doesn’t yet works is the whole Google Gears/Moodle setup. Moodle is set up properly but Google Gears hasn’t had enough love yet. Our in-house developed content also isn’t yet integrated yet, but our individual activities made in both Squeak/Etoys and Flash, can easily be split up and accessed through the web individually.

Also we don’t yet have a mechanism in place to update individual schoolservers from a central server. And again we need a separate mechanism for system-software and content. This is the only aspect we haven’t worked on at all so far, but we still have a few months till the deadline in mid-April. Should be time enough… we hope…


Deployment preparation

So this summer we’re gonna deploy a few thousand XO-s in around 15 schools, in around 5 districts in Nepal. How are we preparing for it?

The first question might be: what do you need?

software infrastructure
a well functioning, customized XO image
– a good plan to set up networks for these schools
– money
– people to go to these schools and have the knowledge to set up the schoolservers, the network, train the teachers and pour their knowledge into a local person, who can troubleshoot and will be our contact when we upgrade or something goes wrong beyond their control

These five items might be a good starting point for a blog series, and darn it, they are. In the next weeks I’ll write a bit on all of them, except for the last one, because there’s already enough written on them over on the OLE Nepal blog. See ‘Deploying Volunteers’ and ‘The Intern Experience’. I’ll link to the items in this post when they are written.


Boring work-description

Well, you might not have suspected it from my blogposts of late, but I AM actually here in Nepal to work. Since I don’t read much on the net about the inner workings of the XO deployments, I thought it would be nice to spend some brainpower and time on our rapidly expanding deployment-NGO-startup. Consider this an introductinary post. I’m a sucker for framing, so the following will perhaps be a bit to general for the acquired taste you undoubtedly have, but subsequent posts will bite more into the flesh. Is the plan…

So what did we do again? Giving cute little laptops to cute little kids. Not all the time do we perform that tangible act of course. Until now we only distributed 135 of them to two pilot schools. When I came to Nepal in the end of Feb we didn’t even have those yet. We had about five at the office in total. And it was a hassle to get your hands on one to test stuff.

There was less to test of course. On the productive side, there were only three activity developers, one graphic designer, a Bryan, one curriculum expert and a freshly hired admin and we didn’t have to worry at all about networking and server interoperability.

After three quarters of a year we tripled in size. We’ve got 6 activity developers (and we’re looking to hire two more), two graphic designers, two curriculum experts, a network guy, two admins, still that Bryan, a power guy, four volunteers, a me, a guru (not the Indian kind though, we’re not that kind of organisation; more the “in the old days we cut our bytes out of the bones of buffalo’s” kind), and there’s no sign of saturation.

coders at work

coders at work

So yea, we’re a startup. Operating in uncharted territory. When was the last wave of laptop deployments in poor rural area’s? Before the AI winter? No there was none I tell you. So requirements change all the time; the mess we need to control grows exponentially.

And time is never on our side. In my perception the last couple of months the biggest struggle was in content creation. Perhaps because I was very involved in it. We write activities to compliment the Nepali curriculum and it was a big struggle for us to churn out enough of them to satisfy the hunger of classes 2 and 6; the ones we initially service. How should the activities look like? Where do you pin the needle between quality and quantity? What’s the workflow?

But now we’re starting to get some rhythm going. We ended up creating a framework for every activity; with introduction, notes for the teacher, a theoretical part and a practice part. The activities are now properly versioned, packing is automatic. Still we’re struggling with a number of aspects, but it almost seems like we know what we’re doing!

Now the centre of mayhem-gravity has moved towards deployment. Or perhaps it’s just that I’m mostly involved in that atm :). In spring we’re going to expand our operation manifold. Nothing is certain, but we’re going to deploy thousands of XO’s. Today I heard the number of around 7000 (it’s a fuzzy number-type), perhaps more, perhaps much less. Nothing is certain as of yet, but that number is gonna be a hell of a lot bigger than 135.

All those XO’s need to be connected to schoolservers. All those servers need to be connected to the internet. All that equipment needs power! The XO’s need to be updated in batch and reliably. Teachers need to be trained. Wireless networks need to be installed. XO’s need to be repaired. And all this needs to be done in remote area’s in perhaps the most mounteneous (is that a word, and if so, is it spelt right?) country of the world, with inherent massive logistics problems. It’s a huge task for a small organisation as ours, and we’re working hard to get up to speed.

Especially the scale scares me. Imagine you accidentally put on some wrong firmware version, and you brick 7000 XO’s all over Nepal, without experienced on-site help… you, ehh.. well I at least would disconnect from the internet and run into the nearest pub to.. ehh.. reassess.

Baby steps.. First things first. One thing we need is a reliable way to update general XO stuff. Say we hack Sugar to force activity updates from only the schoolserver (check) we should have a reliable way to update the XO’s. So I figured using olpc-update from our schoolservers. A good suggestion from the olpc-devel list was to set up pilgrim to prepare for a sane way to service the update script, with the added benefit that we automate our custom XO build-process. Which makes perfect sense of course.

That’s a nice rounded task. I can handle that. Baby steps…


Epaati: The Best Damn Educational Software for Nepal

This piece was first published at OLPC News.

Ah, I can still remember the day we got the first computers in our school. Not just any school mind, but my school. And not just any of my schools, but my primary school. The school where even the lightest of impressions would burn into your naked soul until it hit the bone.

There, in that school all of a sudden we found a computer upon a table. No-one of us younglings knew exactly how it got there or what it was for… Yes computing of course; the meaning of which overlapped pretty much with game playing, although very few of us had actually played with or owned a computer.

Nepal olpc art
Limbu script on OLPC XO

Oh how the black magic of the thing attracted us like flies. It was a PC of sorts, but not of the Intel variety. Nor was it any of the MSX-y variety which I had come across before. But it had a tape-drive, just like the MSX. And it took forever to load anything.

But it would keep you amused by making funny screachy sounds as it did so. A bit like a demented robot. And that is about all I remember, because this wonderful educational device fell flat on it’s face at the end of the eighties. I think it sort of landed there by magic, at that odd place at the end of the class.

And the teachers of my school sort of hoped it would sorcer itself away. Which it did after two months. In a puff of smoke, never to be heard of again. To great delight of said teachers who never actually tried to use it to educate us.

Burn out

Now we will fast-forward to the present day. I’m Ties Stuij, Journalist come nerd/developer working for OLE Nepal in Kathmandu. Through the greyish magic with which fate spins its web I somehow find myself working in this dynamic and stinky city. Working on educational software for these black magic boxes for OLE Nepal. Well, not really working at present. Resting would be more accurate of a description.

We are out here

The whole development team is in a state of lazy rest. Not a laziness used as a coping strategy to counter the dreariness of everyday office life… Quite the opposite.

This laziness is a coping strategy to alleviate our fused out brains that have been mutilated beyond recognition by our iron willpower to make the best damn educational software this side of the horsehead nebula.

Ehh.. Did that sound just a bit pretentious? Perhaps, but we have been working awfully hard to produce a final build of a software suite called Epaati, that will assist teaching children from both grade 2 and grade 6 (8 respectively 12 years old) maths and English.

Final build in the sense that this version of Epaati will be put on these mini (super) computers, called XO’s. These computers will on their turn be put in the greedy little hands of Nepali schoolchildren in about a week.

Oh the pressure, the pressure!

We’ve been developing Epaati for quite a while now, but up till now we unleashed it’s considerable power only upon our test audience, game jams and the teachers of our deployment schools. And our digital child has grown quite a bit since it’s conception. We developed 47 learning activities in all.

Tons of bugs can hide in and amongst their folds and crevices, and there’s nothing like the urgency of actual use to drive the hunt in uncovering and squashing them. Animal rights organizations were held at bay with long poles, while this digital mass murder was underway. It’s hard to believe that there were so many bugs to be found. But then again, this suite is the result of 6 months work by three to four developers and one graphics artist.

The Epaati team

Another thing that’s annoying is that this software is for little puppy-eyed kids who might actually be helped in their development by our efforts. You know, a regular customer is a party on equal footing.

You ship a bug, and she’ll know this is an industry hazard. But those little kids… somewhere in that jaded, cynical, hedonistic, western brain of mine those kids invoke scary feelings of social responsibility, which drive you to walk the extra mile.

So the OLE Nepal offices have of late been a battlefield on which many a shard of good will has driven itself in the bloody soil, when it had to admit defeat against fatigue and sleep-deprivation while all involved tried to MAKE STUFF WORK. And not just the development team of course.

While our immediate task for the coming deployment is done. Other sections are still in full gear working with getting the XO’s ready, beating school servers in shape, testing jabber servers, giving press conferences, instructing teachers, aligning us with other parties involved,.. etc. Let them work like mules, we don’t care. Our brains are soup, we’re of no use.

As reporter after reporter is shuffling into our office to get the news on what is to come, we are already done. Filled with a vague satisfaction that stage-builders must also feel, just before a theatre play starts that they built the decor for.

Here there be monsters

We are doing quite cool stuff here, on the brink of the unknown. I myself am in charge of optimizations, as it’s called. And that task was more satisfying than expected. The XO’s aren’t the most powerful computers in the world and as it turned out the software we use to build our activities (Etoys, on top of Squeak, for connoisseurs), wasn’t yet prepared to handle a project of our scope in such a constrained environment.

Epaati experience

For example, when I started off, a number of activities we made would take over a minute and a half to load, and some wouldn’t load at all. Also our software took up way to much memory, affecting other software as well if it was being used at the same time. This was making the user experience much less fun and much more frustrating than is acceptable.

Not to speak of the activities that didn’t even work. If I wouldn’t be able to find some solutions, or find people that would find solutions, my job would be unenviable to say the least. Once I oversaw the full scope of our problems (or was I just exaggerating everything in my head), I got scared indeed.

Also considering I had hardly coded in Smalltalk (the language of which Squeak is an implementation) before. Luckily Smalltalk/Squeak is a very comfortable environment to work in and me and others managed to trim our problems down to an acceptable level. In certain cases the loading-time speedup was tripled or even quadrupled. All our activities are now loading, while memory consumption is halved. Not that we’re there though.

While I’d like to bring down loading time even more (Most of our activities load between 20 and thirty secs now; Still quite a bit in the light of a child’s impatience.), we need to address amongst others character-encoding and sound related problems. But these seem to be solvable problems, our biggest enemy being time and manpower.

Our goal in Nepal

Live or die

The strange thing is that we’ve created a beast, but we’ve got no clue how it’s going to behave in the wild. Maybe it’ll just curl up and die, just like the computer in my boyhood school. But I must say that the enthusiastic reactions I’ve seen from actual teachers (two of which have stayed in my house for a few days, while they received training) have very much outstripped my expectations.

And I think that if I and my comrades could already be enchanted by that computer that was basically just sitting there at the back of the class, these action- and content-packed babies will certainly have an impact on those child-brains in rural Nepal.


For those that want to try our beast of burden, you can download the XO bundle by surfing to For XO illiterate Squeakers: the bundle is a simple zip file. Just unzip it and click the image in the epaati dir.


Power to the office clerk!

(originally posted on the blog)

As it is I’m working for in Kathmandu. That is to say half my time goes to and half my time goes to OLE Nepal, the local organization that is going to implement a computerized school program with the help of OLPC laptops. I’m working most of my time in the OLE Nepal office.

Let me tell you that at the moment working at the office is kind of ’special’. That’s because of the special power circumstances around here: In Kathmandu you’re without power around eight hours a day at the moment. These are no random power faillures, but state policy. Every district got a schedule in which is indicated when the power goes down; it’s called ‘loadshedding’ over here. Usually two times a day, four hours in a row.

‘But why?’, you might think. Or you might right now think: ‘Because there’s no power of course!’ If you answered the latter you are dead right, but if we’d leave it at that, we would miss out on the tragic irony that tortures the poor country of Nepal.

You see Nepal has the worlds biggest potential for hydro-electric levered power; thanks to the huge height difference in the country. If they would only plant a number of extra hydro-plants in the country, all energy problems would be solved in an eco-friendly way. But Nepal doesn’t have the money. A company is building one of them at the moment, but an electrical engineer that works here on energy problems told me: “It’ll take five years before it’s done, and by that time the need has grown so much, that we’ll need another one just to keep up with rising demand.”

So where does this leave the general office clerk? Is he just free half of the day? It depends… OLE Nepal has got batteries which load when there’s power, and which usually would hold out during power shedding. However one of the batteries is dead, and thanks to some kind of weird configuration it doesn’t take long before the rest of the grid is dead.

This event is followed by the sound of numerous fans spinning down, and CRT’s making that weird heigh pitched sound when they’re switched off. A bit later, but well within the fan down-spinning time, there’s a collective grunt from the developers, indicating loss of work.

Me being one of the few with a laptop, am feeling a secret sigh of relief knowing this wouldn’t happen to me. But then I realize I’m one of the few which hasn’t got a rock hard excuse to sit in the sun and chit chat till there’s power again.

Now there’s talk to supply the developers with laptops. Since a laptop consumes between 14 and 19 watts and a desktop around 140 watts, or so I’m told, one doesn’t have to be a maths wizard to figure out the advantage of our portable friends. Perhaps all of us could even start using XO’s, which only consume 3.4 watts, or thereabouts.

As for me, I’m finding the XO to be a very nice excuse to take my job outside. Not for everything, but my OLE related development environment is a standard requirement for these lil’ ones, and it’s sun-friendly screen and dust-resistant build just scream ‘take me into the mountains!!’.

And as I’ve seen in the wild, there’s room to take this mobile office idea a whole lot further, but that’s the subject of a future post.

May 2019
« Jul    

Flickr Photos