Well, there is a significant difference between your problem and that
which is solved with the header block on the motherboard. I am
responsible for several servers that weren't bought at my request. I had
nothing to do with the purchase of the hardware yet I have to keep them
operating. I am going to say that is a fairly common phenomena in the
sys admin world. Every time you switch jobs or even get a promotion, you
are going to be responsible for computers you didn't spec out. I've
already installed 2 of those converters so I could use my hardware synth
with these machines.
So I think it would depend on why you want to use a hardware synth with
your laptop. Is that a choice or something you absolutely have to do?
The linux kernel developers aren't ethically obligated to be all things
to all people. They couldn't do that even if they tried. But I am
suggesting that they do have an ethical obligation to try very hard not
to do something that would cost a blind sys admin his job. I understand
that it may be impossible for them to avoid it in this case. But that
decision should not be made lightly.
PS: I am not really talking about myself personally. I am about as
secure in my job as I can be. I'm just assuming other blind sys admins
have jobs similar to mine. Here at the University of Wisconsin, there
are a lot of linux systems admin jobs. And for the majority of them, it
would be a big problem if you couldn't access the boot messages.
On 10/08/14 21:18, Gregory Nowak wrote:
When the serial port question comes up, someone always points out that
the headers for a serial port are still there, even though the actual
outside db-9/db-25 port isn't there. Unfortunately, this assumption
seems to be geared to desktop users. What about those of us using
laptops, and said laptop doesn't have pc-express/pcmcia? From this
point of view, moving speakup into user space at least partly has
advantages. This is especially true since the way things are now, I
can't connect a hardware synthesizer to my laptop anyway. On the other
hand, having speakup in user space would mean that I could use a usb
to serial converter.
I'm sure there are more of us in a similar situation, not just yours
truly. Ideally, speakup should support as many hardware configurations
as possible. Standard serial ports should be supported, as well as
non-standard ports. Some of you may recall I still have a machine here
with a doubletalk PC installed in a ISA slot. Ideally, I would like to
be able to keep using my doubletalk if possible.
One more thing to consider. Back when speakup first came out, kernels
weren't as modularized as they are now (more modules were built-in),
and initial ramdisks weren't as big as they are now (assuming they
were used in something other than install media. I first started with
GNU/linux using slackware 7.1. From what I recall (and I could be
wrong), when the system was installed, there was no initrd, all the
modules needed to mount the root FS were in the kernel. In such a
situation, having speakup be part of the kernel was a must. Nowadays,
I don't know of any distribution which doesn't create a initial
ramdisk as part of the install process. So, the only situation where
having speakup be a part of the kernel is if someone is building a
custom kernel, and including everything needed for booting into the
kernel without an initial ramdisk. How many of us here still do that?
My guess is very few of us if any.
I am not saying speakup should be moved out of the kernel. I'm merely
gently suggesting that the case for keeping speakup fully in kernel
space isn't as strong as it once was. It does seem to me though like
there just might be more advantages to putting at least part of
speakup into user space today. Ok, that's my $0.01 worth.
Greg
On Wed, Oct 08, 2014 at 04:26:09PM -0400, covici@xxxxxxxxxxxxxx wrote:
That is what I think as well -- and most motherboards do have serial
ports, just the headers are not brought out to the back.
_______________________________________________
Speakup mailing list
Speakup@xxxxxxxxxxxxxxxxx
http://linux-speakup.org/cgi-bin/mailman/listinfo/speakup
