Algorithms in Africa
Eleven years ago I installed a computer system at a vocational training and development center in Tutume, Botswana. Tutume is a rural village on the northeastern edge of the Kgalagadi desert in southern Africa. The computer was intended to help this organization, known as Tutume Brigades, catch up on its bookkeeping for several business units crucial to the local economy. Businesses included a brick-making unit, carpentry workshop, auto repair garage, sorghum mill, school uniform production unit, tractor hire and vegetable garden. For the local village and the surrounding catchment era, the Brigades were literally the only game in the bush for commodities, trade skills, training and employment opportunities.
When I arrived in Tutume, I was a pure novice in the field of foreign assistance. I was also a mid-career financial professional, with several years of experience in nonprofit and health-care management in the United States. And like most aid workers new on the ground in Africa, I knew what was best. In my assessment of the center, I believed a computer was essential to get a handle on the Brigades' financial position, which otherwise consisted of eight separate sets of badly maintained manual ledgers, over nine months in arrears. Except for the bank statements of eight separate checking accounts (and even the bank statements proved unreliable), we had no way of knowing if the center had any money. Every time we had to make payroll or buy another truckload of cement, we were in the heart of fiscal darkness.
Over the course of the next several months, I proceeded to computerize the records and train local staff in basic operation of the system. By the end of the first year, the financial records of the center were timely and accurate. Moreover, other staff members were beginning to use the computer for tasks such as word processing and spreadsheets. Many of these employees had never even used a typewriter before.
If I were to tell no more of this story and fade here to one of the glorious Kgalagadi sunsets, this might be called a win. Although set in the predawn (and pre-Linux) history of the Internet era, today this would be described as a small success story of “bridging the digital divide” in Africa—like I was a regular Albert Schweitzer of the Information Age or something.
But the truth is not so simple, and the issues of foreign assistance are not so trivial. The fact is, I am not proud of this story. Because as my time in Tutume went on, I realized I had blundered badly, to the point of putting the Brigades in serious jeopardy. I began to ask myself such basic questions as: What would happen to the computer after I left? Was the staff fully capable of operating the system independently? Would backups be maintained and performed rigorously? Were skills sufficient to troubleshoot problems and reinstall the system if necessary? If the equipment failed or was stolen, could the center afford to replace it? And what would the center do when the staff I had trained for so long were lured away by more lucrative jobs in the big city?
These questions all led to the same answer: the Brigades would be left in even worse shape than I found them. Rather than gaining empowerment, independence and enablement, they would more than likely be left powerless, dependent and possibly ruined. And all because of my own cultural myopia, despite my good intentions.
It is axiomatic in the field of foreign assistance that the aid program will take credit for the successes, while failures are blamed on the host country. The psychology of failure can then be even more severe and long-lasting than the loss of the project. While I was working in Tutume, for example, a friend of mine was working in the village of Lobatse in southern Botswana. Seven years earlier, an aid organization from northern Europe had decided a wool sweater factory would be just the ticket for the economic development of the village. Of course, northern Europeans are fond of nice wool sweaters and very likely have great need for them, particularly in the colder climes of northern Europe. The market for wool sweaters is less extensive in the sweltering and sparsely populated Kgalagadi desert, however. After seven years of subsidizing the losses of the operation, the aid organization finally decided it was never going to be sustainable, and they pulled the plug on the effort. My friend's unenviable assignment was to put all the women out of work, sell the facility and liquidate the equipment. It was hard for many of the women not to feel that the fault was somehow their own.
Fortunately for Brigades in Tutume, such failure was averted. As the story there continues, once I realized the risks, I spent the next several months converting the accounting system back to manual ledgers, hiring and training additional staff in bookkeeping procedures and enabling them to use the computer primarily as a support system, rather than as the central financial database.
But what do these stories from Tutume and Lobatse have to do with Linux and emerging markets? The rest of this article will consider that question.
Practical Task Scheduling Deployment
July 20, 2016 12:00 pm CDT
One of the best things about the UNIX environment (aside from being stable and efficient) is the vast array of software tools available to help you do your job. Traditionally, a UNIX tool does only one thing, but does that one thing very well. For example, grep is very easy to use and can search vast amounts of data quickly. The find tool can find a particular file or files based on all kinds of criteria. It's pretty easy to string these tools together to build even more powerful tools, such as a tool that finds all of the .log files in the /home directory and searches each one for a particular entry. This erector-set mentality allows UNIX system administrators to seem to always have the right tool for the job.
Cron traditionally has been considered another such a tool for job scheduling, but is it enough? This webinar considers that very question. The first part builds on a previous Geek Guide, Beyond Cron, and briefly describes how to know when it might be time to consider upgrading your job scheduling infrastructure. The second part presents an actual planning and implementation framework.
Join Linux Journal's Mike Diehl and Pat Cameron of Help Systems.
Free to Linux Journal readers.Register Now!
- Paranoid Penguin - Building a Secure Squid Web Proxy, Part IV
- SUSE LLC's SUSE Manager
- Google's SwiftShader Released
- Managing Linux Using Puppet
- My +1 Sword of Productivity
- Murat Yener and Onur Dundar's Expert Android Studio (Wrox)
- Non-Linux FOSS: Caffeine!
- SourceClear Open
- SuperTuxKart 0.9.2 Released
- Parsing an RSS News Feed with a Bash Script
With all the industry talk about the benefits of Linux on Power and all the performance advantages offered by its open architecture, you may be considering a move in that direction. If you are thinking about analytics, big data and cloud computing, you would be right to evaluate Power. The idea of using commodity x86 hardware and replacing it every three years is an outdated cost model. It doesn’t consider the total cost of ownership, and it doesn’t consider the advantage of real processing power, high-availability and multithreading like a demon.
This ebook takes a look at some of the practical applications of the Linux on Power platform and ways you might bring all the performance power of this open architecture to bear for your organization. There are no smoke and mirrors here—just hard, cold, empirical evidence provided by independent sources. I also consider some innovative ways Linux on Power will be used in the future.Get the Guide