[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