From mboxrd@z Thu Jan 1 00:00:00 1970 Return-Path: Received: by befuddled.reisers.ca (Postfix, from userid 65534) id 5131D1EF7BC; Thu, 9 Oct 2014 18:10:24 -0400 (EDT) Received: from mta1.math.wisc.edu (mta1.math.wisc.edu [144.92.166.23]) by befuddled.reisers.ca (Postfix) with ESMTP id EFC3C1EF7AF for ; Thu, 9 Oct 2014 18:10:22 -0400 (EDT) Received: from localhost (localhost [127.0.0.1]) by mta1.math.wisc.edu (Postfix) with ESMTP id 89DEF49CAB5 for ; Thu, 9 Oct 2014 17:10:22 -0500 (CDT) Received: from mta1.math.wisc.edu ([127.0.0.1]) by localhost (mta1.math.wisc.edu [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id bqJuAwMXCwrH for ; Thu, 9 Oct 2014 17:10:22 -0500 (CDT) Received: from mta1.math.wisc.edu (localhost [127.0.0.1]) by mta1.math.wisc.edu (Postfix) with ESMTP id 19C0C49CA37 for ; Thu, 9 Oct 2014 17:10:22 -0500 (CDT) X-Spam-Checker-Version: SpamAssassin 3.3.2 (2011-06-06) on mta1.math.wisc.edu X-Spam-Level: X-Spam-Status: No, score=-101.0 required=6.5 tests=ALL_TRUSTED, USER_IN_WHITELIST autolearn=disabled version=3.3.2 Received: from mailhost.math.wisc.edu (erdos.math.wisc.edu [144.92.166.25]) by mta1.math.wisc.edu (Postfix) with ESMTP for ; Thu, 9 Oct 2014 17:10:22 -0500 (CDT) Received: from [144.92.166.19] (vv507j.math.wisc.edu [144.92.166.19]) (using TLSv1 with cipher ECDHE-RSA-AES128-SHA (128/128 bits)) (No client certificate requested) by mailhost.math.wisc.edu (Postfix) with ESMTPS id 0476D42001B for ; Thu, 9 Oct 2014 17:10:22 -0500 (CDT) Message-ID: <543707CD.6030606@math.wisc.edu> Date: Thu, 09 Oct 2014 17:10:21 -0500 From: "John G. Heim" User-Agent: Mozilla/5.0 (X11; Linux x86_64; rv:24.0) Gecko/20100101 Icedove/24.8.1 MIME-Version: 1.0 To: "Speakup is a screen review system for Linux." Subject: Re: the push to get rid of CONFIG_VT in the kernel and the future of Speakup References: <87zjd64c16.fsf@mushroom.PK5001Z> <543593E4.5040400@gmail.com> <5435B055.1080804@math.wisc.edu> <20141009123742.GG1044@opera.rednote.net> <5436FCE9.7040101@gmail.com> In-Reply-To: <5436FCE9.7040101@gmail.com> Content-Type: text/plain; charset=UTF-8; format=flowed Content-Transfer-Encoding: 7bit X-Bogosity: Ham, tests=bogofilter, spamicity=0.000000, version=1.2.4 X-BeenThere: speakup@linux-speakup.org X-Mailman-Version: 2.1.18 Precedence: list List-Id: "Speakup is a screen review system for Linux." List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 09 Oct 2014 22:10:24 -0000 But again, the whole thing means nothing unless you can address the point of how a blind systems admin is going to do his job without a screen reader in the kernel. Your logic about getting everything out of the kernel that isn't necessary could apply to anything. Yet, there are thousands of linux kernel modules. Why? Because people need them. If blind people need speakup in the kernel, then it should be fixed or replaced with something that doesn't have any bugs. Not done away with. On 10/09/14 16:23, Kyle wrote: > According to Janina Sajka: > # PS: You can also expect serial headers on commodity network devices like > # home routers. That's how OpenWRT fuels itself. > > On the other hand, Speakup never has, and never will, run on a home > router, and the fact remains that although it may still be possible to > purchase a newer hardware speech synthesizer, they just don't put serial > cables on them now. The newest ones I've heard anything at all about > connect to USB ports, but have been entirely neglected by Speakup for > years, either due to extreme rigidity of the developers when depending > on dedicated ports, or more likely due to the impossibility of coding > for a changing USB enumeration from within the kernel. Please note that > although on most computers, especially laptops, a dedicated serial port > is past obsolete, no one here is indicating that support for such ports > be dropped from Speakup. WE JUST WANT OPTIONS! > > Additionally, on the subject of servers, it is one thing to have a > serial console that one can use if ssh or other remote connectivity > stops working, but Speakup is an entirely different type of software, > and comes with its own share of bugs, which are far easier to deal with > in userspace than in the kernel. Some may respond to the sysadmin story > of not being allowed to work on a server because of Speakup, calling it > a lack of consideration for people with disabilities. I, on the other > hand, recognize that the kernel should be as clean as possible, > especially in a server environment, and the potential for one module to > crash the entire kernel, potentially ruining the whole server, is > something to be avoided at all costs. It's one thing for a screen reader > to have a bug that crashes something in userspace, which is usually the > screen reader, but it's another thing entirely for it to crash the > kernel, which takes all of userspace down with it. This is a very good > reason to keep as much out of the kernel as possible, and why at least > some distributions aimed specifically at servers will not enable the > staging drivers, where the Speakup modules are built. It's not a matter > of keeping the blinks from being sysadmins, it's just a matter of the > rock solid stability that is needed on servers more than on any other > type of machine. > > So while you may find serial ports on servers, Speakup adoption on such > machines will be seriously inhibited until or unless it makes its way > out of the kernel and into userspace, where screen readers should be. > And though you may find serial port headers on home routers, Speakup > will never be used on those, as they have no use for it. So apples to > apples, the machines that can get the most benefit from Speakup don't > have the port needed to take advantage of hardware speech, and no module > has been written that will allow it to communicate using the ports on > such machines. Instead of focusing on which machines still have serial > ports, just move Speakup out of the kernel, and improve support for > software speech, USB devices and USB to serial converters from within > userspace. Then from within userspace, the serial communication via a > dedicated port can be repaired and improved also. > ~Kyle > http://kyle.tk/ >