Huh, you're the second person in this thread to say that about orca. But I just decided to switch to linux full time a few months ago and it was pretty much a breeze. I had been using that other operating system too but almost all the end users I support use linux (all good mathematicians do). So I felt I was cheating by not using linux. But I have had little to no trouble switching to linux with orca. I use thunderbird & firefox constantly. It's not quite as good as Windows/jaws but honestly, I made the transition fairly easily. I am really shocked to hear all these complaints about orca. Not to doubt you. It's just that it doesn't jibe with my experience at all. On 05/08/13 11:14, covici at ccs.covici.com wrote: > here here -- I use speakup all day long -- have never been able to gett > gnome reliably and I use that other operating system for web brousing > and stuff Linux will not do. > > John G. Heim <jheim at math.wisc.edu> 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 >>> >> >> -- >> --- >> John G. Heim, 608-263-4189, jheim at math.wisc.edu >> _______________________________________________ >> Speakup mailing list >> Speakup at linux-speakup.org >> http://linux-speakup.org/cgi-bin/mailman/listinfo/speakup > -- --- John G. Heim, 608-263-4189, jheim at math.wisc.edu
