Path: 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: <1991Jun8.194822.2332@newshost.anu.edu.au> Sender: news@newshost.anu.edu.au Organization: Computer Services Centre, Australian National University, Canberra, Australia. Lines: 129 In article 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