[Computerbank] Re: Our service philosophy and linux

David Hatton davidth at melbpc.org.au
Thu Mar 21 11:39:05 UTC 2002


Hello All,

Its a bit late (email probs) but here is my 2c worth here (well, maybe
4c - its a bit longer than I originally intended :-) )


1) Our systems are supplied with linux for a number of good reasons,
   including :

   - It does the job, particularly on the type of hardware we get
     donated, which is usually 3 to 5 years old.

   - Absence of the need for license tracking and authentication, which
     would divert significant time and effort from core activities.

   - It is readily available and we can customise as required.
   
   - It can be used by recipients to learn a number of common computing
     tasks, for example the traditional web browsing and
     sending/receiving email, HTML authouring and publishing, building
     spreadsheets, word processing etc.
     
   - There are people who are prepared to become involved, and have the
     technical expertise, to set up linux based computers and generally
     offer technical help.

2) It seems to me that we need to make our recipients fully aware that
     the computers they are getting *are* secondhand, and may be
     somewhat more prone to component failure than new systems.

     I think the best approach here is to operate on a 'use best
     efforts' basis.  For example, if a recipient machine has a hard
     drive crash or the monitor quietly expires, we will use our best
     efforts to remedy the problem, but there are no guarantees. 
     
     These best efforts could extend, at our discretion, to replacement
     of unserviceable parts and adjustments to the linux software to
     accommodate the new bits (if required).

     See also below - "Coping with Microsoft"

3) Living with other operating systems.

   The software we supply is linux based.  This does not automatically
   preclude file transfer or some level of interoperability with other
   computers equipped with other operating systems and their respective
   applications. The downside is that sometimes -

        * data transfer can be incomplete.
        * people using other systems aren't prepared to use file
          standards common with linux/unix
          
   Thus it sometimes takes a little effort to make the transfer happen,
   although it seems to be getting easier as linux apps improve.

   It is perhaps beneficial to separate interoperability requirements
   into two parts, namely the need to create files which are for the
   sole use of the recipient, and the need to exchange files with other
   non-linux systems. (I believe this breakdown was first put forward
   by one of our vic members, Rodney Brown - apologies if I've got it
   wrong, Rodney).

   The point here is that if our recipient doesn't need to exchange
   files with others or preserve *all* the information in those files,
   then using linux shouldn't be a deterrent.  For example, if our
   recipient gets on the net and downloads a .pdf file and can use,
   say, xpdf to successfully view it, then the (linux) system has
   performed its function.  Another situation is with the creation of
   files with an "open standard specification", eg/. HTML.  Linux and
   other OSs use different programs to create a standard product - the
   test here is can a browser (ideally any browser) display the HTML in
   a consistent and acceptable way ?

   If, OTOH, our recipient needs to collaborate with another person or
   group in the creation of, say, a set of documents, then there may be
   a problem in agreeing on a common file format which is supported by
   all the groups' software.  This then becomes something to be dealt
   with by negotiation, taking into consideration the software
   available to each member of the group.  It appears that this
   situation can be the real difficulty, with far too many people not
   prepared to even consider minor adaptions to their computing
practices to
   accommodate someone creating information from a somewhat different
   platform.  This, regrettably, sometimes includes people who like to
   call themselves IT professionals!

   The question then becomes, what can we, as suppliers of linux
   software, do to ease our recipients problems in this area ?
   
   The first thing we need to do is to ensure, as far as possible, that
   our recipients know how to save files in different formats from linux
   applications.
   
   The second thing we can do is to get some of our volunteers to try
   out how well linux apps cope with reading and writing files
   originally created by applications running under other OSs, and
   *document* their findings.  This could well be a project for a
   geographically scattered group of computerbank volunteers/supporters.
   
   The third thing we could do, perhaps not immediately but I think it
   would be worthwhile working towards in the medium term, is a problem
   solving service aimed at providing solutions to interoperability
   problems, with particular attention to schools and (perhaps) small
   business.  This would use the results of our efforts with linux apps
   (see prev para).
   
4) Coping with Microsoft.

    As I have outlined above, we have good reasons to supply our
    computers with the linux operating system and associated
    applications.  Using this software, our recipients can do most, if
    not all, of the things they want to do with a computer.
    
    And we have a reasonably good chance of helping them if things go
    wrong, because our expertise is with linux and the hardware on which
    it can run.
    
    It would therefore, it seems to me, be a backward step to dabble
    with microsoft systems.  We would be taking time from our core
    activities, and using up our volunteers for "special cases".
    
    In addition, we would most likely be involving ourselves in extra
    work sorting out issues to do with licensing and support.  I don't
    think this is a good idea.
    
    If a potential recipient insists that they *must* have microsoft
    software installed on their system, we should then gently but firmly
    point them in the direction of other organisations which may be able
    to help them.  We have enough applications to keep us busy building
and
    supplying linux systems without going outside our core competencies,
    which, at the moment, are based on linux.  Should we decide, in the
    future, to adopt other software then at that time we will obviously
    need to review our software/hardware supply policies.
    
    We do have a "grey area" in that we need a simple and clear cut
    policy regarding those recipients who decide to install Microsoft
    Windows on their systems after they have obtained them from us.
    
    I would suggest the following -
    
    (1) We will use our best endeavours to ensure that any hardware,
    supplied by us to a recipient, which malfunctions due to a physical
    component failure is restored to operation.  This will be, at our
    discretion, by repair or replacement on a "return to base" basis,
    and will be limited to failures which occur within a period of
    thirty days from the supply of the computer to the recipient.

    (2) Any repairs or replacement carried out in accordance with
    paragraph (1) above will include any required adjustments to the
software
    installed, *provided* such software has been originally supplied by
    us.
    
    (3) In the event that software on the malfunctioning system has not
    been supplied by us, our best endeavours will be restricted to those
    specified in paragraph (1) above.




Hope this helps,

David H.


-- 
--------------------------
David T. Hatton
(davidth at melbpc.org.au)
--------------------------




More information about the computerbank mailing list