🚀 go-pugleaf

RetroBBS NetNews Server

Inspired by RockSolid Light RIP Retro Guy

Article View: comp.society.development
Article #103

Re: Computers and Telephones

#103
From: Albert Langer
Date: Wed, 12 Jun 1991 15:11
129 lines
7401 bytes
In article <ccfj.676580159@hippo> ccfj@hippo.ru.ac.za 
(F. Jacot Guillarmod) writes:

>In <1991Jun8.194822.2332@newshost.anu.edu.au> cmf851@anu.oz.au (Albert Langer) writes:

>OK, so let's try and reach some sort of consensus.  Here are my modified
>views:
>
>1 - good, or adequate communications infrastructure is desirable - but
>there are mechanisms available for use in situations where comms is
>abysmal.  But in the case of abysmal comms, you need a very strong
>desire to communicate to overcome your disadvantages.

Agreed. Except I would add that simple software improvements could make
an abysmal comms link simply look like a normal comms link that is
twice as slow and twice as costly (but no harder to use). That merely
requires a desire strong enough to pay twice the comms costs (which
may not be the dominant costs).

Current software makes bad phone lines hard to use - with skills
needed to setup the modems at each end for the best connection and
to overcome problems caused by repeated lost connections. Improved
software should be able to make optimum use of whatever phone line
is available and also adapt to changes without operator intervention.
If it can be used for voice then it can be used for data - noise and
other problems merely affect the data rate.


>2 - a major problem is the configuration and maintenance of an
>'email/news engine' (hardware+o/s+enduser software) - but with a bit of
>thought and care it may be possible to put together some sort of turnkey
>system that could just about be dropped by parachute with a note on the
>power cord saying "plug me in here".  That's not intended to sound
>facetious - I reckon most of us reading this group could get quite far
>down the road to putting together and configuring just such a system.

Agreed. So let's get down to it! Actually it is quite a big job, and
involves designing the network that each "engine" connects into even
more than designing the individual engines. But the key thing is the
design criteria for a "turnkey" system. That has NOT been a design
criteria for current systems but once the need is acknowledged there
is no reason it can't be achieved.


>3 - user education is the crux, in two senses - firstly as to "How do I
>send a message" and secondly to address the problem of "Why the hell
>should I bother about sending messages".  These two educational tasks
>are vastly different in scope, but both need to be addressed - in
>different contexts.  The first is a technical problem, and the second is
>'political'.

I partly agree concerning the first and disagree on the second. The second
is a "marketing" problem. Given that only a small westernized elite that
has access to telephones and computers are likely to be directly involved
initially in developing countries and given the additional communications
costs, I think it will only be used where there is a real benefit. Some
demand clearly exists already and the normal process would be to spread
out from there without any great need for "education" (who "educates"
people or "markets" email in developed countries - that is only becoming
significant now AFTER substantial numbers have started using it). The
only special thing I can see about developing countries is that they
have no hope whatever of achieving an early "critical mass" of users
within each country (or even regionally) and therefore international
links are crucial. Email use will spread from people using it for
international connections to local use rather than the other way round,
so we should concentrate on the international connections more than
might otherwise appear necessary.

I agree that technical improvements to make it easier to see how to
send (and receive) messages are highly desirable (and especially
necessary to substitute for other forms of "user education" that
are harder to provide in developing countries).

However I'm not convinced they are "the crux". Provided that
"system administration" tasks are taken care of, there are existing
user interfaces available, at least commercially, that should not
be a major barrier. Even senior business executives use email
nowadays and if they can be taught, anybody can. (Or at least I see
no reason why the simplified user interfaces made available to
business executives should not be more widely available).


>4 - you can't do it alone - you need a support group of some sort.  By
>this I mean a site in a developed country that is well connected to
>existing networks and that is prepared to allow you to connect up to
>them (and possibly bear the costs of dialup as a gesture of goodwill
>towards the developing country) and is prepared to do a lot of initial
>baby sitting.

I think that is part of the problem. It just transfers some of the
system administration problem to a developed country site instead
of handling it in a developing country. That may well be the only
way to go for some immediate urgent links but it severely restricts
growth by depending on continuing goodwill and resource input from
host sites in developed countries. Far better to design the network
(not just the individual site "engine") to require minimal support.

There would need to be a site in a developed country well connected
to existing networks and with sufficient technical expertise both
to maintain those connections and to maintain the rest of the
network. But the rest should just "plug in" without needing to
negotiate special arrangements anywhere. This includes plugging
in to links with neighbours and regional hubs etc - not direct
to one central site nor from each developing country to a separate
developed country site.

The network should configure itself semi-automatically to minimize the
cost of feeds (while maintaining reliability etc) and will need
adequate accounting systems to allow sites that can provide a 
cheaper feed to do so without having to pay the full cost themselves
on behalf of others.

>None of that sounds impossible, does it?  I can think, offhand, of
>several countries around here that could benefit instantly if such a
>'package' could be put together.  However, few sites are altruistic
>enough to spend the time and money required.  Perhaps they should be.

It requires a "project" involving a number of people from a number
of areas. My points above are intended to suggest that we should
concentrate on item 2 rather than giving equal attention to all 4.
That will also be of great benefit within develeped countries and
should make it possible to attract involvement from people not
particularly concerned about developing countries.

Let's do it!

--
Opinions disclaimed (Authoritative answer from opinion server)
Header reply address wrong. Use cmf851@csc2.anu.edu.au
Technical Details
Message-ID: <1991Jun12.151153.9569@newshost.anu.edu.au>
Path: arc1-ca.pugleaf.net!utzoo!utgpu!news-server.csri.toronto.edu!cs.utexas.edu!uunet!munnari.oz.au!manuel!cmf851
References: <ccfj.676148819@hippo> <1991Jun8.194822.2332@newshost.anu.edu.au> <ccfj.676580159@hippo>

Show Full Headers
Complete Article Headers
Path: arc1-ca.pugleaf.net!utzoo!utgpu!news-server.csri.toronto.edu!cs.utexas.edu!uunet!munnari.oz.au!manuel!cmf851
From: cmf851@anu.oz.au (Albert Langer)
Newsgroups: comp.society.development
Subject: Re: Computers and Telephones
Message-ID: <1991Jun12.151153.9569@newshost.anu.edu.au>
Date: 12 Jun 91 15:11:53 GMT
References: <ccfj.676148819@hippo> <1991Jun8.194822.2332@newshost.anu.edu.au> <ccfj.676580159@hippo>
Sender: news@newshost.anu.edu.au
Organization: Computer Services Centre, Australian National University, Canberra, Australia.
Lines: 129