I wanted to document my school’s technology situation, and how I have chosen to tackle the gargantuan task of teaching computer skills to 300 kids with 5 computers. Rather than doing this in an email, which is a waste of bandwidth and would fill the inboxes of those who don’t care/don’t understand, I have decided to do it as a blog post.
I came to Nkoranman Senior High School in late July of 2008 on site visit as a then-Peace Corps Trainee. I was presented a pile of computer equipment and told “this is what we have.” I had a pile of approximately 15 computers, split between Dell Optiplex GXpro 200s and Compaq Deskpro 5400s. In addition, I also had 3 computers that had been tasked for use in the administrative offices, mostly for word processing.
My first task was to figure out what worked. I removed the parts from pretty much all the machines, set up a couple of testing stations, and proceeded to identify the working hardware. Out of the 15 machines, 6 of them worked — 5 Dells and an AST Advantage. I also had a tidy pile of spare parts — hard drives, video cards, network cards, memory, CD-ROM drives, and a couple of spare power supplies. I took these, set them aside, made a list of parts I needed to make the 5 Dell machines usable, and stripped down the rest. I did save one of the Compaq machines, as well as some of its parts, for use in teaching hardware. As for the AST machine, I decided to save it for a later project in which I try turning it into a router using the LEAF Project‘s software.
My next task was to get the machines I did have to an operational state. They turned on, they would start to boot, but they didn’t do anything. After a trip to Kumasi to pick up more hard drives, and a few donated floppy diskettes (remember those?), I was able to put together some computers that were ready for software.
At this point, my 5 machines had roughly the following hardware specs:
– Pentium Pro with MMX 200MHz
– 32-64 MB of EDO DRAM, depending on the machine
– 3-10GB Hard disk space, again depending on the machine
– Onboard USB 1.1 (except for one machine)
– Onboard 10/100 network interface cards
– 16X CD-ROM Drive
– 1.44MB 3.5″ Floppy Drive
The far end of trailing-edge hardware. The rare memory and lack of it made doing anything fancy out of the question; these machines were not going to run Windows XP. At the same time, I was reluctant to try anything like Windows 98, due to the fact that it’s no longer supported. It looked like Linux was about my only option.
At first, I was limited to what I brought with me: Ubuntu and Xubuntu. Both of these ended in resounding failure, due to the ridiculous amount of resources required by Xorg and Gnome. Luckily, about the time I cleaned up the remnants of Xubuntu, I had internet access at site. I thus began to download and test the following distributions:
– Damn Small Linux
– Puppy Linux
– Debian Etch (netinstall)
In the end, Debian won out. The rest were either too rigid or difficult for me to work with, and Debian allowed me to install only what I needed to teach. Due to the homogenous nature of my hardware, I also had the added benefit of being able to create one “build” of Debian, which I could then copy to all of my machines almost verbatim.
The next task was figuring out what software I needed within Debian. I needed something that wouldn’t be too intimidating for a first-time computer user, but would still run smoothly on the hardware I had. I also needed a few basic apps for teaching keyboard skills and mouse usage, and a way to make everything accessible graphically. The whole setup had to be secure and contained, so that I could control the computing experience without the kids changing the wallpaper or screwing with settings as they became more familiar with the setup. Finally, I needed to make the user interface look aesthetically similar to Windows so that my students wouldn’t be incredibly confused the first time they used a Windows box.
In the end, I opted to use a combination of Xorg, IceWM, and iDesk to give me a Windows-like feel that I could keep somewhat locked-down. I also installed XDM to present a graphical logon, and customized it a bit to make it look less like XDM. The only two applications I have installed at present are TuxTyping 2 and TuxPaint. I figure that if I have nothing else installed, it’s nothing else that can turn back and shoot me in the face.
I finished tweaking the settings, gave it revision number 0.1, and moved on to the arduous process of getting the software from 1 computer to 5. Rather than configure each box by hand, and because my hardware is pretty much all the same, I opted to use disk imaging for my lab. I used the System Rescue CD 0.2.19 live CD and my trusty USB pen drive to create the image, then deployed it to my 4 other classroom machines in the same way. Once the imaging was complete, I’d reboot, change the hostname (I’m using lab01 through lab05) and reconfigure X to use the proper resolutions for that monitor.
There were a few snags in this plan. First off, I had to rob memory out of all of the machines in order to provide the machine I was imaging at the time with the 128MB required to boot the live CD. Second, not all of the machines had CD-ROM drives that were CD-RW friendly (one of the more useful tools I brought to Ghana), so I had to install a drive that was in order to boot the live CD. Finally, I have one machine that doesn’t have USB, which resulted in me using two CD-ROM drives and two CD-RWs to install the image. All things considered, the process was cumbersome, but I’d expect any first-run system to be so.
TRIAL BY FIRE
The only true way to test software is to give it to users. In an educational setting, that means sitting a kid down in front of the machine and letting them bang on it. It has been nothing short of a resounding success — the kids love to use TuxPaint, and they scramble for the opportunity to play TuxTyping games. The first night I had the lab open, I came home feeling like a king. These kids finally have the chance to learn practical computer skills, and I managed to do it without any horrible crash-and-burn failures.
THOUGHTS AND NEXT STEPS
I’ve been using this build for about three weeks now, and it’s been surprisingly issue-free. I do have some cosmetic gripes, of course — I want to find a display manager that’s more user-friendly than XDM, I need to find a way to lock the icon position on the desktop, and so on. I also would like to optimize memory usage, both by compiling a custom kernel and removing unnecessary services from boot. Finally, I’d like to set up another small linux system just for re-imaging the machines, so that I don’t have to go through the cumbersome process of frankensteining together hardware every time I deploy a software update.
I also still have the administration machines to worry about. Right now, they work, so I’m trying not to change them until I have a reason to. At some point, however, I’ll probably end up deploying some sort of system for storing documents in a central location, as well as some sort of student information system — whether that ends up being a glorified spreadsheet or something more meaty is yet to be seen.