[Date Prev][Date Next]   [Thread Prev][Thread Next]   [Thread Index] [Date Index] [Author Index]

Re: Installation of Redhat without a sighted assistance



Option 2 looks more practical than the others and easier to do.
May I assume that this might mean some sort of interactive scripted
front end to making a kickstart configuration file?  The commentary
and the manuals could rewritten on a less technical level as help
screens for the script.  But while linux has great scripting
languages, what should be used in the MS-DOS environment?  Or
should a temporary zipslack environment be installed for this
purpose?  Another possibility would be a boot floppy that would
mount or symlink to a live filesystem on a CD.  This could be a
special CD, or a generic slackware one (I run redhat, but buy the
$2 slackware CD's at the same time, since the live slackware
environment helps with setting up a rescue and recovery
environment).  There are some good ksh style shells for dos, too,
that might be used.  Copies could be posted with such a script.
Maybe the script could help with automating the downloading and
installation of emacspeak and other speech related packages, adding
"%post" script directives to the kickstart script, so that these
get installed with the rest.  Some rudimentary configuration could
be added, saving lots of questions and confusion for new users.
This post installation is only possible with kickstart -- a big
plus in such a situation.

Is it reasonable to assume the kind of access through MS-DOS that
would make this practical?  Maybe Jason's comments about the
"easiest and most practical solutions" are the best way to go,
perhaps rewriting the commentary in a kickstart sample file to be
as non technical as possible, to facilitate editing in the most
generic possible environment.  I really don't know -- it's just
been too long since I had to worry about such issues, and deal with
those environments.  Input from the newest listers is especially
needed here, since they still have more of that perspective.

We'd need new users to volunteer to critique the procedure, too, to
weed out excessively technical language or procedures, and test to
make sure it would work in commonly available hardware and software
environments.  One of the most tricky issues involves providing
free disk space for the new linux installation.  Someone would be
needed who could explain in non-technical language how to shrink
existing partitions "safely", or how to delete partitions to make
room, etc., probably from win9x.  Does any existing linux
documentation address this on the right level?  I know that
one of the existing HOWTO's relating to partitioning was much too
technical and detailed -- aimed at a different audience.

On Mon, 5 Jul 1999, Jason White wrote:

> This issue has often arisen for discussion on this mailing list.
> I think there are many other access concerns which are of much
> greater significance, and I would not place this problem high on
> a list of priorities. With this qualification in mind there are
> several practical solutions which could be put into effect:
> 
> 1. A CD-ROM could be prepared, containing a Linux distribution,
> together with a copy of BrlTTY and a fairly primitive speech
> output system; the latter could rely on either a hardware-based
> or software-only synthesizer and could be loaded prior to the
> installation process. The facilities for controlling the output
> could be included in the installation software or as a primitive
> kind of screen reader, whichever was easiest to implement given
> available resources.
> 
> 2. Alternatively, or in addition to the above, a "serial
> terminal" option could be provided, enabling the installation
> process to be operated from another computer, connected to the
> serial port.
> 
> 3. Alternatively, a small application could be written, capable
> of running in DOS with an existing braille or speech output
> package, which sets up an automated configuration script and
> launches the installation procedure.
> 
> However, the easiest and most practical solutions are:
> 
> 1. Arrange for someone else to read the screen during the
> installation process (which should in any case take less than
> half an hour).
> 
> 2. Follow the instructions for creating an automated installation
> script and ask a friend to read the screen if it doesn't proceed
> as expected.
> 
> I am not denying that operating system installation procedures
> tend to be inaccessible, but it should be remembered that
> installation need only be carried out once, whereas the
> accessibility of applications which one may wish to use on a
> routine basis is of much greater practical importance.
> 
> Also, computers are now available for purchase on which Linux has
> already installed; in appropriate cases this eliminates the
> problem from the standpoint of the end user.
> 
> As I remember, Hans once suggested developing a CD-ROM of the
> kind which I have described. However, there apeared to be
> insufficient interest on the part of list subscribers to justify
> the effort. One reason, perhaps, is that once the operating
> system is in place and working, most people set aside whatever
> problems they may have encountered during the installation
> procedure and start using the computer productively.
> 
> I would not seek to discourage anyone from taking steps to
> improve installation processes by making them more accessible, as
> I think this would increase the attractiveness of the software to
> new users.

-- 
L. C. Robinson
reply to lcr cyberhighway net

People buy MicroShaft for compatibility, but get incompatibility and
instability instead.  This is award winning "innovation".  Find
out how MS holds your data hostage with "The *Lens*"; see
"CyberSnare" at http://www.netaction.org/msoft/cybersnare.html



[Date Prev][Date Next]   [Thread Prev][Thread Next]   [Thread Index] [Date Index] [Author Index]