the direction of speakup

Wed May 8 12:13:46 EDT 2013

John and list,

I don't think it is safe to assume everybody is using, or even can use a 
GUI.

One of the great strengths of Linux has always been that it will run on 
older and less powerful machines. Although that gap is closing with the 
greater sophistication of today's distros. I can still do everything I 
want to do via the command line, thanks to SpeakUp, and on machines too 
old and slow to run even Windows XP satisfactorily.

There are still people using low-end hardware. What of the Raspberry Pi 
for example, or other embedded Linux systems?

The command-line is one thing which still makes it possible for blind 
and visually impaired people to find employment in places where they can 
do all their work from the command-line. As sys admins or server-side 
programmers.

John, can I ask what you mean when you say removing SpeakUp from the 
kernel will benefit us all? That's not a facetious question or a 
challenge. I'm just curious why you say so.

Mike

On 08/05/2013 16:03, John G. Heim wrote:
> I totally disagree. Speakup has little purpose except for the fact 
> that it runs in kernel space. First of all, there are other screen 
> readers for user space. And you really need a GUI these days. I 
> suppose there are people using speakup all day every day. Mutt for 
> email, lynx or edbrowse for the web. But I'm sure the vast majority of 
> linux users use orca for every day tasks.
>
> The most important feature for speakup is to bail you out when you are 
> really in trouble because your server is down. I don't know what you 
> do for a living but I do systems admin and I cannot live without 
> speakup in kernel space. About the only thing that I can think of that 
> is equivalent to simply plugging in a hardware synth and getting boot 
> messages would be setting up something like a Raspberry Pie to boot 
> into kermit and display serial console messages. But it wouldn't be 
> the same because you'd need a keyboard for the RPI. I don't know -- 
> when a server is down, the last thing I want to do is mess with all 
> that stuff. I just want to plug in the hardware speech synth and press 
> the print screen key.
>
> On 05/08/13 08:37, Robert Spangler wrote:
>> I throw my vote in for putting Speakup in userspace. As others have
>> said, if we use software speech, we aren't hearing the earliest boot
>> messages anyways. While there are still many folks using hardware
>> speech, it seems as though the software speech trend is expanding. In
>> addition, there are other ways of checking boot messages. It is a
>> little disheartening, however, because being able to hear messages from
>> the start of boot time has been a major advantage to Linux users but I
>> think that getting Speakup out of the kernel will benefit us all in the
>> long run.
>>
>> Thanks,
>> Robert Spangler, B.A. in Urban Studies and Spanish
>> spangler.robert at gmail.com
>>
>> On 5/2/2013 3:22 AM, covici at ccs.covici.com wrote:
>>> If we gave up the kernel, which I would really prefer not to do, 
>>> then we
>>> could use speech dispatcher and write drivers for the serial synths or
>>> usb ones. But this is to be decided.
>>>
>>> acollins at icsmail.net wrote:
>>>
>>>> Hello all. If Speakup were a user space app, you could start it from
>>>> inittab, like you can brltty. It would also be able to access the 
>>>> video
>>>> scrollback buffer.
>>>>
>>>> I don't think the support for isa synths needs to go away just yet.
>>>> Believe it or not, there are still a few folks running older machines
>>>> with
>>>> isa slots with isa synths in them. Besides this, for those who really
>>>> want them, it is still possible to buy machines with isa slots, so if
>>>> you have an isa synth, you can use it in a new machine. So I don't
>>>> think it's time to drop isa support yet.
>>>>
>>>> Having said that, adding usable usb serial, and support for usb synths
>>>> should be a priority. At this point, I find myself ambivalent about
>>>> whether speakup stays in the kernel or not. You don't get any better
>>>> access to boot messages with software speech than you could from user
>>>> space. If the user space Speakup could be started from inittab, then
>>>> you could still get info about file system checks and such. The only
>>>> thing you couldn't get, which you can't get with software speech 
>>>> either,
>>>> is kernle panic errors. With Speakup in the kernel, and using a
>>>> hardware synth, you can sometimes still get that info, depending on 
>>>> how
>>>> the kernel panics. There have been a couple of times when this has 
>>>> been
>>>> a life saver for me, but it happens so rarely, that I could probably
>>>> live with the inconvenience. Thus I'm finding myself ambivalent about
>>>> Speakup staying in the kernel. But then I'm getting older, and
>>>> ambivalent about a lot of things. (grin)
>>>>
>>>> Gene Collins
>>>>
>>>>> hmmm, I wonder if we could just add a kernel driver as though we were
>>>>> writing one for a new serial card that way we would conform to 
>>>>> what the
>>>>> kernel devs want? From within that, maybe you could specify the 
>>>>> way to
>>>>> get the device to use, or maybe have some simple user space 
>>>>> program to
>>>>> tell it the device -- this is way off the top of my head, but is
>>>>> interesting to me. You could write drivers for speech dispatcher for
>>>>> serial synths, but getting that into an initramfs would be difficult,
>>>>> you would have to change the generation scripts for each 
>>>>> distribution,
>>>>> etc.
>>>>>
>>>>> my $.02 (or .2 trillion with hyperinflation).
>>>>>
>>>>> William Hubbs <w.d.hubbs at gmail.com> wrote:
>>>>>
>>>>>> All,
>>>>>>
>>>>>> let's start a new thread here to figure out what needs to be done 
>>>>>> with
>>>>>> speakup.
>>>>>>
>>>>>> Here are my ideas and the issues I see with them:
>>>>>>
>>>>>> 1. What should we do with support for the internal ISA synthesizers?
>>>>>>
>>>>>> My thought is that these can be dropped.
>>>>>>
>>>>>> 2. We basically have two choices for the serial synthesizer issues.
>>>>>>
>>>>>> a. If we keep this code inside the kernel, the bottom line is it 
>>>>>> needs
>>>>>> to be completely rewritten and there need to be changes made on the
>>>>>> kernel side to make it work correctly.
>>>>>> This will take time, and someone here will need to
>>>>>> work closely with the kernel developers, and we'll need to find
>>>>>> someone
>>>>>> in the kernel community to guide us -- maybe not by writing the
>>>>>> code for
>>>>>> us, but at least consulting with us.
>>>>>>
>>>>>> b. If we move this code into user space, we can code it however we
>>>>>> want,
>>>>>> and that frees us from involving the kernel team.
>>>>>>
>>>>>> question:
>>>>>>
>>>>>> If we move the serial code to user space, I realize there is a 
>>>>>> concern
>>>>>> about missing early boot messages. Would putting the user space 
>>>>>> daemon
>>>>>> into an initramfs solve this? would you be able to start it early
>>>>>> enough to get all of the boot messages if it was in an initramfs?
>>>>>>
>>>>>> William
>>>>>>
>>>>>> _______________________________________________
>>>>>> Speakup mailing list
>>>>>> Speakup at linux-speakup.org
>>>>>> http://linux-speakup.org/cgi-bin/mailman/listinfo/speakup
>>>>>
>>>>> -- 
>>>>> Your life is like a penny. You're going to lose it. The question is:
>>>>> How do
>>>>> you spend it?
>>>>>
>>>>> John Covici
>>>>> covici at ccs.covici.com
>>>>> _______________________________________________
>>>>> Speakup mailing list
>>>>> Speakup at linux-speakup.org
>>>>> http://linux-speakup.org/cgi-bin/mailman/listinfo/speakup
>>>> _______________________________________________
>>>> Speakup mailing list
>>>> Speakup at linux-speakup.org
>>>> http://linux-speakup.org/cgi-bin/mailman/listinfo/speakup
>>>
>> _______________________________________________
>> Speakup mailing list
>> Speakup at linux-speakup.org
>> http://linux-speakup.org/cgi-bin/mailman/listinfo/speakup
>>
>

-- 
Michael A. Ray
Analyst/Programmer
Witley, Surrey, South-east UK

Interested in accessibility on the Raspberry Pi?
Visit: http://www.raspberryvi.org/

 From where you can join our mailing list for visually-impaired Pi hackers