Sonar GNU/Linux merges with Vinux

Thu Apr 27 00:30:20 UTC 2017

But, again, Kyle, the serial console is also kernel dependent. You're 
simply depending on a different set of developers. You could switch to a 
user space screen reader once the host is done booting just as you 
switch to a getty once the boot is done.

-- John Heim
On 04/26/2017 04:52 PM, Linux for blind general discussion wrote:
> Tony and all,
> 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. 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. 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 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.
>
> You're absolutely right: YASR is not a viable userspace screen reader. 
> In fact, it's not a screen reader. Rather, it's a shell reader. There 
> was in fact a try at adding a separate program that could read the 
> login screen, but the overall nature of YASR makes it less than ideal, 
> as you still have to run a separate instance of YASR along with the 
> shell in every terminal you want to read.
>
> 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. 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. 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 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.
> ~Kyle
>
> _______________________________________________
> Blinux-list mailing list
> Blinux-list at redhat.com
> https://www.redhat.com/mailman/listinfo/blinux-list