Sonar GNU/Linux merges with Vinux

[Linux for blind general discussion]

The boot messages I receive from my computer before the kernel starts 
are piped out through a serial port automatically, and need no special 
configuration to display them. I just hooked up a uart cable to the 
header on one computer and the USB port on another and ran tinyserial's 
com utility on the USB connected machine before booting the other, only 
specifying /dev/ttyUSB0 as the serial device to listen to and 115200 as 
the baud rate. But those things at least appear to be fairly standard, 
and I can see no reason why having to run a single utility from a shell 
would preclude its use by anyone who needs it. I guess the difference 
may be that I run ARM computers here, although I was under the possibly 
incorrect impression that most newer machines, if they have serial ports 
at all, were supposed to make it that easy to pipe boot messages through 
them. So although serial console support is indeed in the kernel, it's 
in every kernel, and should be, as the serial console is an i/o device, 
whereas a screen reader should only be using that device if needed, and 
should not be locked into the kernel. The screen reader is an 
intermediary between the user and the traditional i/o devices; it is 
not, nor should it be, an i/o device. If someone does still need to be 
able to hear boot messages from the kernel while the initial ram disk is 
in use, said ram disk is perfect for running userspace applications 
early in most cases. And since many minimal distros run their live 
environments from RAM, adding sound drivers to the initial ram disk 
shouldn't cause too much pain, except on extreme low-memory systems, 
which in many cases won't have any sort of screen reader at all, as 
usually they only have a programmer interface these days, which is 
accessible via uart or some other means of connected communication.

Incidentally, of all the ARM computers I've used, only the Raspberry Pi 
supports Speakup at all, and I have a strong preference for nearly any 
other, as the Pi just feels sluggish, possibly due to the i/o 
bottlenecks inherent in the design, and nearly all other computers even 
remotely in the same price range have noticeably better specs. 
Additionally, although I am able to install Arch in my sleep, and have 
even quite easily gotten Fedora 25 working on one of my computers by 
removing the installed Fedora kernel and copying over /boot from a 
working Arch system, the thought of compiling a kernel, especially since 
I would have to do it every time there is an update, is not at all 
appealing. Will I give up on the inexpensive and quite capable computers 
that I enjoy using or the distros I enjoy running on them? Absolutely 
not. Will I whine and complain because the vendors and their kernel 
developers "don't care about accessibility?" Most assuredly not, as I 
have other more viable options for getting speech when and where I need 
it. Or maybe I should whine and complain that Uthe uefi folks don't care 
about accessibility if it isn't as easy to get serial boot loader 
output. Again, no. Could I run a BSD on one of my ARM computers in the 
future? I can hope, as I do want to play with it some. Therefore, what I 
need most is a flexible and fully portable userspace screen reader that 
has access to kernel device interfaces when needed, but can be installed 
and will run on any machine, no matter the running kernel. Brltty almost 
fits that bill, but its screen reading functionality is nowhere near the 
quality of its braille feature set. Fenrir does have the dependency on 
Python, which is a rather large runtime for an initial ram disk or 
similar. So it may be that this SBL will be the best option, with a 
fallback serial console if I must debug using boot messages that come 
from the kernel, or from the boot loader, since I also see those quite 
easily with Uboot.
~Kyle