Re: Updating mbrola (again)

[Brian Buhrow <buhrow%nfbcal.org@localhost>]

	hello.  To answer your questions and to give a little more background, as I wrote, I
started with NetBSD in the 386BSD days.  I was already an experienced Unix programmer, having
worked with SunOS, Mt. Xinu on Vax 11750 and 11780 machines, as well as Ultrix and somewhat
with SCO's operating system, later, Open Server.
At some point, I wrote a kernel driver for the DECTalk PC for NetBSD and got it working with
Emacspeak.  However, I never really learned the intricacies of Emacs or Emacspeak, preferring
vi instead.  For the first 18 years or so I worked with Unix/NetBSD, I accessed it using a
serial console or via the network, using telnet, later ssh.

	My current technique for bootstrapping NetBSD machines into usable states is to boot them
using a serial console, either a real port via the motherboard, as in the case of the RPI or
via a virtual console, in  the case of Xen, various motherboards with IPMI base boards  or various 
cloud providers.  Then, once I get the
machine loaded enough to boot into multi user, I fire up an sshd listener and I'm off to the
races.  This lets me capture kernel boot messages, panic messages and work with the in-kernel
debugger, or kgdb if necessary.
If I'm bootstrapping a machine without a serial port, a laptop, for example, I'll build a boot
image on a flash disk that writes its dmesg output to a file which isn't destroyed when the
operating system shuts down.  This lets me figure out the names of all the devices NetBSD sees
when it boots, permitting me to alter the boot image to either bring up the network so I can
get to it via the network or to figure out why the system isn't booting.  You might note that
this doesn't work in all cases, i.e. if the system doesn't boot to a place where the OS can
write to the flash drive.  However, in such cases, it's often the case that the video console
isn't working then either, so I'm not at much of a disadvantage relative to my sighted
developers, as they, like me, will try to take to a serial console at that point, one way or
another.

	Since Yasr works entirely in user space, using pseudo terminals, I don't need to alter the
operating system at all to get a working machine that talks on the keyboard and video consoles.
I'm familiar with Speakup on Linux and while I feel it is a very useful system, I don't think
it is a good idea for the screen reader to exist in the kernel, for a variety of reasons,
ranging from security concerns to the ability to maintain said screen reader inside of a pretty
dynamically changing environment.  That is, by putting the screen reader inside the kernel,
when ever the kernel changes, the screen reader needs to change as well, meaning it's very easy
to break the screen reader without intending to do so or even realizing that it has been
broken.

	No, I've not written a pkgsrc distribution for YASR or Eflite, but you can download
versions with my changes for NetBSD and robustness at:
https://web.nfbcal.org/~buhrow/yasr.tar.gz
This gets you a working version of Yasr, along with the eflite speech synthesizer, including my
fixes for Yasr, flite and eflite.
Note that I've build and used this on i386 and amd64
systems.  I have it mostly working on the RPI, but there are some issues with eflite that I've
not yet worked out.

	I've used it in xterm windows with great success, but, as I note in the README  file, I've been
having some X keyboard issues which are related to my lack of knowledge of how X works, rather
than a technical inability for Yasr to work inside X itself.

	As to edbrowse, my preference is lynx.  Since Yasr works wel with full-screen terminals, I
like the more full-screen experience lynx provides.  In fact, if lynx implemented Javascript
and the DOM, it would be a fully featured text based browser.

	Finally, since this e-mail is far too long already, I'll note that most of the techniques
I describe above for getting a machine up and accessible nonvisually, work for all the BSD's,
i.e. FreeBSD, OpenBSD, etc.  They also work for Linux in many cases.  
Hope this is interesting.
-Brian