Sonar GNU/Linux merges with Vinux

[Linux for blind general discussion]

Tony Baechler here. Kyle, Kyle, Kyle. You're still missing the point. You 
seem to think I'm in love with a kernel-based screen reader and my mind is 
closed to alternatives. OK, let me try again.

On 4/26/2017 2:52 PM, Linux for blind general discussion wrote:
> I myself am completely opposed to a screen reader being locked into a
> kernel, and have been for many years, for very good, technical,
> non-political reasons.Text mode is exactly this: text mode. The layout of
> the entire screen is available as plain text and some other character codes
> that affect colors and other things, all of which are easy to interpret by a
> userspace screen reader. This is the nature of the beast on all operating
> systems, no matter the kernel. The screen reader *must* be fully in
> userspace, and must be modular enough to handle slightly different
> input/output interfaces, because that makes it portable to things like BSD,
> GNU/Herd or any other new OS that may come alon, and all with at most the
> help of a small module that knows how to read the text that is to be output
> to the screen, which can then be sent out to a speech synthesizer, whether
> hardware or software, in an equally modular way.

OK, fine. I would much rather see one screen reader to rule them all as long 
as it's open source. It would be great to not need to develop a standard for 
what keys announce the time because the same screen reader runs on any OS. 
Obviously, that isn't going to happen. As you just said, there still needs 
to be a module. That could be a kernel module or whatever, but it isn't 
going to ever fully run in user space. You failed to address how, say, 
Fenrir runs at the login screen. Do you enable it for all users? What if 
sighted people use the machine and don't want speech? OK, do you enable it 
only on the first console? That's fine until someone switches consoles. Does 
it run as root? If not, how does it read the login screen? OK, let's put 
that aside for the moment and say it starts in your startup shell scripts. 
How does someone enter their login and password without speech? None of this 
deals with a graphical login prompt, like if you're running X. When I was 
running X, all I had to do is switch to a text console and there was good 
old Speakup, ready to go. You tell me how to do that with any other screen 
reader and I'll gladly shut up and try it.

Additionally, having a
> screen reader in userspace and not bound to the kernel means that no one has
> to patch the kernel to accept the screen reader, and screen reader
> developers don't have to answer to kernel developers, kernel coding
> conventions or kernel release cycles in order to continue development of the
> screen reader.

Kyle, this is just plain nonsense. What if it's anything else other than a 
screen reader? Let's take XFS which is a filesystem driver. Yep, it's a 
kernel module with userspace utilities, actively developed by SGI. Somehow 
they all get along and new releases of the module make it into new releases 
of the kernel. OK, let's take any number of USB devices. There are lots of 
modules for all kinds of odd hardware. All of these are in the main kernel 
source, not in staging. The only difference is that we're talking about a 
screen reader.

Best of all, though a single bug that goes uncaught in a
> kernel-bound screen reader has the potential to crash the entire kernel, a
> userspace screen reader's bugs only affect that application, and in the
> worst cases, the screen reader may need to be restarted. No bug in a
> userspace screen reader will cause the report you've put valuable hours into
> to get lost in cyberspace because a previously hidden bug in the screen
> reader crashed the kernel before the report could be saved.

I agree with your point on this, but again, let's replace "screen reader" 
with "filesystem driver." It really doesn't matter what the kernel module 
does. That's why there is lots of aggressive testing and why there is a 
staging tree. This again comes back to not enough blind users to really test 
new code and get the bugs out. They don't even have to be blind. The sighted 
can load the speakup_dummy module. Anyone running Linux can do that.
>
> I did also mention the serial console as an alternative to a kernel-bound
> screen reader. The whole reason I mentioned this at all is not just because
> I can make a Raspberry Pi or even a less expensive computer act as a screen
> reader, but because I not only receive kernel boot and shutdown messages,
> but I receive boot loader messages as well, which the kernel is unable to
> provide. This allows me to debug things that happen when the kernel fails to
> boot. This can be caused by any number of kernel related problems, but can
> also be caused by filesystem corruption and other things that the boot
> loader can detect and report more easily than the kernel that is failing to
> boot. The only time I would have a problem using the serial console method
> is if the boot loader itself is either corrupt or has no serial i/o, and
> thankfully, most do.

OK, let's take a real example. I'm running Debian testing on ext3. I 
upgraded e2fsprogs and somehow it upgraded my system to ext4dev. It was 
probably my fault. I didn't know it did that. All I knew was it ran fsck at 
the next boot and acted strangely. I guess fsck upgraded to ext4dev without 
telling me which I would consider a bug in e2fsprogs, but no matter. I 
rebooted and fsck ran again. It bombed because it couldn't read my 
filesystem and landed me at the initramfs prompt. Tell me how a userspace 
screen reader could handle this and how you would fix it. Of course I booted 
my talking rescue CD and fixed it, but I had to reboot a number of times and 
landed at the initramfs prompt until I figured it out and solved the 
problem. I would think using your serial console method would be very 
inconvenient, especially on a daily basis. I don't need a null modem cable 
etc. Your solution wouldn't work on machines with no serial port, but either 
would Speakup unless you have an internal synth.

Honestly, I don't like software speech, especially ESpeak. Mbrola is not 
bad, but non-free. I have a slight hearing loss. My DECtalk Express is much 
easier for me to hear and understand. The main thing holding me back from 
switching fully to Orca is the lack of decent speech. If I understand you 
rightly, your solution still uses software speech, so wouldn't be convenient 
for me. Yes, you can still buy new hardware synths.

>
> Finally, I will reiterate the fact that just because Speakup is not included
> in a vendor or distro kernel does not indicate in any way that the vendor or
> distro developers don't care about accessibility, any more than failing to
> include the alsa front-end utilities would mean that a distro's developers
> don't care about sound.

To use a Trump line from the debates, wrong! It's very simple to package 
Speakup modules separately or to only include them in the main kernel 
without the rest of staging. Since Pulse still goes through ALSA, if a 
vendor doesn't include the ALSA utilities, I think it's fair to say they 
don't care about sound.

Speakup is just one possible option, and because it
> for a long time required a patched kernel, and now still requires staging to
> be enabled in order for it to work, has technical limitations that force
> distro developers and vendors to make hard choices about whether or not to
> include such an unknown variable into the functionality of the kernel, which
> by definition is to be a direct interface to the hardware rather than a way
> to run userspace programs in kernel memory.

Wrong again. Staging is only a different set of modules. Staging is compiled 
the same way as the rest of the kernel. No one is forced to load anything 
from staging. If a vendor packages staging separately, that would be 
understandable. If we're talking about RHEL which is fully supported by the 
vendor, you might have a point. We're talking about Fedora which has only 
community support. There is no reason, technical or otherwise, why they 
can't include staging with a disclaimer that it gets no security support. 
Even if they don't include all of staging or they choose to package it 
separately, they can still include the Speakup modules. No one is forced to 
load any kernel module except to make their hardware work. I can choose to 
not load the sound modules if I don't want sound, just as I can omit Speakup 
if I don't want speech or choose to use something else. Finally, why do the 
two most popular distros, Debian and Ubuntu, include staging? Arch is 
constantly updated. Does it not include staging? Are there any other 
community-supported distros which don't ship staging? Even with its faults, 
by finally getting it into staging, the vast majority of distros have Speakup.

Furthermore, there is a huge
> difference between not caring at all about accessibility and not knowing how
> best to handle it within the framework of an operating system, especially
> with such technical limitations as a kernel-bound screen reader presents.

I don't buy this argument either. As you well know, it's all open source. 
Anyone can see how other distros do things. Debian borrows from Fedora all 
the time. Fedora could borrow either the Debian or Ubuntu installers, or at 
least see how they're made accessible. They could reach out to us and ask 
for input and testing. They could form an accessibility team who actually 
tries to use their distro with blindfolds on and see how far they get. If 
they can't figure out how to get speech to start and they're sighted, how do 
they figure we'll manage? Show me the wiki page giving accessibility info 
after the installation. Don't just tell me Super-Alt-S. Give me a community 
list to ask questions.

I
> have said this many times, and will continue to do so. Instead of
> complaining about how little you think a developer or a group of developers
> cares about accessibility, work toward fixing the inherent problems with the
> accessibility tools and the technical limitations they present. At least
> give distro developers enough information to try to help fix the problems
> rather than just pissing and moaning on lists like this one when something
> you like presents challenges to developers that they otherwise may not know
> the best way to take on.


How? If I can't install their distro, I can't use it with speech, I can't 
get Speakup to work because it isn't included, I can't find docs etc, where 
do I start? Even more, what if they don't even try to make their installer 
accessible, as was the case for many years? You can't just push off your 
responsibility to speakupmodified.org and get off the hook. What if I don't 
want to run X? In fairness, the Ubuntu Server install doesn't have speech 
either, but only because the software stack is missing. The Speakup modules 
should be there. How the heck can you say that having to telnet or ssh into 
the Fedora installer is making it accessible? I can ssh into Debian or most 
live CDs. To put it simply, why should I bother? Why should I care when they 
apparently don't, or can't even have a starting point? Even from the 
Sonar/Vinux point of view, why not build off of Arch instead?