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.