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?
_______________________________________________
Blinux-list mailing list
Blinux-list@redhat.com
https://www.redhat.com/mailman/listinfo/blinux-list
