Tuesday morning, I took the Paris Métro over to the offices of Communications Week International. The one editor I knew let me in, showed me his boss’s office, then promptly left for the U.S. The rest of the morning, I furiously banged away at a PC, trying to get enough columns written to stave off my editors in New York (and pay for some dinners in Paris).
After finishing enough pithy columns to pay the Maitre d’, I went to the nearby bistro for a lunch of chicken Riesling, ratatouille, and a bit of wine. Sauntering back to the office, I had only to figure out how to submit the columns to the head office.
Of course, the menu option on the PC labeled “MCI Mail” did absolutely nothing. I knocked on a few random editor’s doors, but was met by frantic stares and hurried brushoffs. My problem, of course, was that I was wearing a suit and was thus mistaken for one of the all-too-frequent employees from the U.S. that came in to use the office for a day in order to write off their trip to Paris on their income taxes.
Needless to say, the editor with a deadline to meet has no time to work with these corporate junketeers who come in to do some “work.” The only work these visits involved would be for the locals. Finally, I convinced an editor that I was only masquerading as a respectable person and actually did write for a living. I couldn’t quite bring myself to take on the identity of “trade press” or “journalist” but it was finally established that I was a “guest columnist/consultant.”
The editor became quite helpful and took my disk and disappeared into her office to perform some magic submission ritual into the Atex system in New York. I asked her why any PC couldn’t perform the same operation.
She explained that a team of consultants had been working assiduously on the problem, but some mysterious incompatibility problem had prevented fully operational capabilities from being attained. Since I had a couple of hours to kill while waiting for a call from London, I decided to take a look at this mysterious modem malady.
I went back to the PC I had been working on and started up Procomm. It seemed to be installed correctly, although, frankly, it is just about impossible to install it incorrectly. I then pulled up the dialing menu and picked MCI from the directory.
Nothing. Next step was to pull up a simple terminal emulation screen and type “AT.”
“OK,” the modem responded.
Hmm. Obviously there was either a fully functioning modem or a pretty good modem emulator on this system.
Walking around to the back of the desk, my highly trained eye spotted the problem. The modem wasn’t plugged into the wall. Sure enough, a few minutes later, I was reading my MCI mail.
Why would an Internet explorer keep an MCI Mail account? There are two reasons. First, the telex gateway on MCI Mail is wonderful. It allows me to communicate with people in countries like China, which have very limited e-mail capabilities. The telex gateway actually allows me to send and receive telexes.
There is a more important reason, however. There are a few people with whom I correspond, mostly members of the trade press who haven’t figured out how to reach my Internet mailbox from their MCI Mail accounts. If I don’t keep an MCI Mail account, I’m reduced to sending faxes back and forth to these people.
It has often puzzled me how people who spend their life covering computers can know so little about how they work. There are some exceptions of course. The editor of Communications Week International, for example, has both Internet and MCI mailboxes, and knows the difference between them.
People like him are, unfortunately, very much the exception in the trade press. The features editor of one prominent networking newspaper, for example, was unable to figure out how to use MCI Mail, yet persisted in editing “in-depth” articles about Broadband ISDN, NFS, and a host of other technically sophisticated issues.
So how does the trade press write in-depth pieces? All too often, the articles are simply a rehash of brochures and briefings. I remember a time I did a feature piece on DECnet Phase V for one of the monthly publications.
I met the senior editor assigned to “work with me” in Boston. Wearing a yellow power tie and driving a Detroit muscle car, he told me that the piece lacked “punch.” So he rewrote it. Close to deadline, somebody decided I ought to have a look at it. The new and improved lead explained how DECnet Phase V would be available on systems ranging from VMS and Ultrix to the Macintosh and PDP.
Macintosh and PDP?
Running DECnet Phase V on a PDP is kind of like trying to simulate the weather on a PC/AT. Running on a Macintosh, though highly unlikely, was theoretically possible, but in my stacks and stacks of reading on the subject, I had not heard of any such project.
In a not so gentle manner, I explained to my senior editor that having read a stack of functional specifications five feet high, it was my considered technical opinion that running on a PDP was unlikely if not impossible. Did my esteemed editor have a source for his information.
“I was briefed by marketing,” he replied.
I called up the Senior Executive Technology Editor and told him he was free to run the DECnet piece, but I would prefer, indeed insist, that my name not be on it.
So he fired me and killed the piece.
Technical knowledge is considered to be of minimal importance, indeed often a liability by the computer and communications trade press. Again, there are exceptions. For example, Kelly Jackson, formerly with Communications Week, is known for insightful coverage of data communications issues. There are others, but they are too rare.
People with degrees in journalism are often hired straight out of school, and are given no time to acquire any technical knowledge. Frequent contact with senior executives gives junior journalists a feeling that they are “part of the scene.” All too often, though, they are simply manipulated and fed a carefully composted salmagundi of marketing manure.
The cycle feeds itself. The executives get used to getting good press based on marketing hype instead of real information. The journalists keep feeling like they are getting the real story and feel increasingly confident and powerful.
There are two solutions to this quandary. First, technically astute people need to write more. People like Marshall T. Rose, who devotes part of his time to writing books, are all too rare. The technology does no good if people don’t know how it works and it is the responsibility of the developers to document their work.
The second answer is for the trade press to acquire a bit more knowledge. Being able to use electronic mail, for example, should be a prerequisite to getting a piece published and certainly won’t cause a writer to transform into a technogeek.
Wednesday morning, I sat outside my hotel and waited to be picked up by Pascal Renaud, head of the computer group at ORSTOM, a national research institution in France.
ORSTOM’s mission is to work with researchers in developing countries. It is an unusual institution in that half of its permanent staff are outside France, scattered over 41 sites around the world.
Twenty minutes late, early for Paris, a tiny car zipped up on the sidewalk outside of my hotel. Pascal jumped out and we introduced ourselves. As we darted through the streets of Paris, I handed him a copy of Stacks. He was pleased.
He was so pleased, in fact, he commenced to leaf through the book as he drove. I had visions of my own book causing my death. While this sort of untimely morbid vision had certainly occurred to me before, I had always assumed I would meet my end at the hands of an OSF hit squad, not in a ten horsepower Renault. Of course, the OSF would use different tactics, probably boring me to death.
As we passed the Louvre, Pascal finished my book and we started talking about ORSTOM. ORSTOM was founded right after World War II as a think tank devoted to the French colonies. While much of the research concerns questions such as agriculture and health, it is nonetheless not a development agency. It focuses instead on basic research issues, such as how to stop the spread of diseases like malaria and sleeping sickness.
Many of the ORSTOM research centers are located in former French colonies. For example, most of the 17 African centers are located in French West Africa, in countries like Niger and the Ivory Coast. A typical research center, such as the ones in Niamey, Niger, and Lomé, Benin, employs 50 people. Others, such as the center in Dakar, Senegal, employs 100 French and 200 African researchers. All told, the institute has a budget of FF 900 million (U.S. $150 million), employs 880 researchers and 720 support staff, and has offices in Africa, South America, Asia, and Oceania.
So how do you provide computing support to such a group? In 1985, Pascal Renaud was brought in to head the computer support group. At the time, resources consisted of a motley assortment of systems like an HP1000 and a Honeywell mini.
“I tossed out everything,” Pascal said with a smile. “It was a bit of a fight, but I got rid of it all.”
The basic applications needed for ORSTOM were typical of many scientific institutions, including statistical analysis, a bibliographic database, and analysis of satellite images. There were, however, two quite unusual requirements. First, with 41 locations all over the world, communication was vital.
To make the communication issue even more important was the issue of support. Many ORSTOM sites were located in places with some of the world’s worst telecommunications. In addition, most sites didn’t have trained personnel. Setting up and maintaining equipment in such locations was a real challenge.
After a bit of digging around, ORSTOM settled on Sun workstations. Within France, the systems were hooked together using TCP/IP over X.25 and were part of the French Internet.
Keeping links up 24 hours a day to Africa would not be practical. Some countries turned off electricity at night. In addition, tariffs were high enough that a call to Paris 24 hours per day would be prohibitive. TCP/IP also had some problems in such an environment. Running TCP/IP over a 2,400 bps link, the wizardry of Van Jacobson notwithstanding, just doesn’t work.
The solution was UUCP. In some countries, such as Togo, X.25 networks were available and were often much newer than the voice network. A SunLink board connected the workstation to Togopac at 1,200 bps. An X.75 link hooked Togopac to the French Transpac. The UUCP F protocol ran on top of X.25 and calls were placed once or twice a day to transfer mail.
The normal UUCP G protocol, designed for very bad lines, is highly resilient but also inefficient. The F protocol has one check-sum per file and is thus more appropriate for the relatively high-cost, high-quality X.25 links.
Other places didn’t have X.25. In Ouagadougou, for example, ORSTOM simply placed a daily call to the Montpellier hub in France. The UUCP G protocol was used to transfer mail over the dialup link.
This network was called RIO, which stood alternatively for Réseau Informatique de l’ORSTOM or Réseau Intertropical d’Ordinateurs. Connectivity to the rest of the Internet was provided through a TCP/IP link into France’s FNET and UUCP links to EUnet.
The service on the network (at least the UUCP portions) was simply e-mail. A pre- and post-processor for mail allowed accents to be included in 7-bit ASCII. UUENCODE allowed transfer of PC and Macintosh binary files.
When a new site was added to the network, Pascal Renaud and local researchers would host a conference. Conferences were typically well attended and typically included government officials, PTT staff, any local non-governmental organizations (e.g., the UN), and university researchers.
ORSTOM had a policy of allowing any of these people to use RIO. This open policy helped make ORSTOM part of the local community and helped spread mail access to many new parts of the world.
Invariably, Pascal relates, somebody at one of these conferences would want to know if they could access RIO from the PC in their office instead of walking over to the ORSTOM offices. As far as Renaud was concerned. he had no problem with remote access.
Unfortunately, placing a telephone call in many of these countries can be a torturous experience. After Pascal would explain that remote access was possible, but would involve a modem and a call, most researchers would shrug their shoulders and say “thanks anyway, I’ll walk in.”
Supporting scientific computing in such a far-flung network is quite a challenge. Only a few sites had real computer support people. Dakar, for example, had one staffer to support the 15 Suns at that site. For other facilities, ORSTOM had an interesting support structure.
In France, military service is compulsory. An alternative, however is a system somewhat like the U.S. Peace Corps. ORSTOM, as a national laboratory, receives an annual quota of young engineers and puts them to work maintaining computers in far-away places.
With several hundred users and an open-door policy, RIO is evidence that some of the most important work in the Internet community is done far on the periphery, removed even from the TCP/IP protocols that many use to define the core.
At the core of the Internet, the issue is one of adding new classes of users, such as recent K-12 initiatives. RIO serves an equally vital, if not more important role of adding new countries to the global village.
Leaving Pascal, I went to a café near my hotel and had a fine cassoulet of snails for lunch. There, over a half bottle of Beaujolais Villages, I pondered the immense difficulty of spreading the Internet into some of the places Renaud had to work.
A few years ago, I traveled to a some of these sites: Niamey in Niger, Lome in Benin, and Abidjan in the Ivory Coast. In the cities, such as Niamey, there is a passable infrastructure. Phones work much of the time and with a UPS, power regulators, and security guards you can keep a computer system going much of the day. In regional cities in Niger, however, things were much tougher. Yet, these regional cities have universities, international aid groups, hospitals, and research centers.
Some would argue that high technology, such as computer networks, are inappropriate in countries where per capita income is measured in the hundreds of dollars and the basic infrastructure, like roads, is crumbling.
In such an environment, technology should be appropriately used, not avoided. Agricultural aid workers, for example, need to consult their colleagues overseas. Likewise, doctors should be able to work as part of a global community instead of being left alone in an isolated outpost.
Voice communication over a telephone system is not an effective technology in these circumstances. International telephone calls take a very long time to place and are often terminated abruptly. Calls are expensive, and you never know if your part will be there. Voice calls are a point-to-point communications technique and do not allow appeals to large groups.
It is precisely in these outlying areas that the Internet is most needed. Messages can be prepared at any time and then batched for transmission. In many countries, the X.25 networks are far superior (i.e., far newer) than their voice counterparts.
Technologies like electronic mail are important in the developed countries by helping us do better research or provide better education to children. In countries like Niger, electronic mail can support education and research, but it can also do something much more important. It can help save lives.