redhat problems

redhat problems

[Nick Gawronski]

      Hi, We must do something about all of these problems with redhat.  
Think about it, rh8 had speakup and it was working just fine but look what 
has happend rh9 is here and we don't have speakup yet the 
readme-accessibility file is in 9 that says that redhat wants to make 
their products accessible.  Well, I don't think that they are beeing very 
nice about this at all.  If they removed speakup they should of removed 
readme-accessbility as well.  We must contact redhat and find out "why did 
you remove speakup yet leave readme-accessibility"  That is what we need 
to do about this.  Who says they have a right to put speakup in one 
version then take it away.  Think about this because we can make them put 
it back in to their product.  bye 

Re: redhat problems

[Luke Davis]

They have the *right* to do anything they wish in this regard.  Our only
option is to lobby them for what we want, and vote with our dollars.

Luke


On Wed, 16 Apr 2003, Nick Gawronski wrote:

>       Hi, We must do something about all of these problems with redhat.
> Think about it, rh8 had speakup and it was working just fine but look what
> has happend rh9 is here and we don't have speakup yet the
> readme-accessibility file is in 9 that says that redhat wants to make
> their products accessible.  Well, I don't think that they are beeing very
> nice about this at all.  If they removed speakup they should of removed
> readme-accessbility as well.  We must contact redhat and find out "why did
> you remove speakup yet leave readme-accessibility"  That is what we need
> to do about this.  Who says they have a right to put speakup in one
> version then take it away.  Think about this because we can make them put
> it back in to their product.  bye
>
>
> _______________________________________________
> Speakup mailing list
> Speakup@braille.uwo.ca
> http://speech.braille.uwo.ca/mailman/listinfo/speakup
>

Re: redhat problems

[ccrawford]

Not exactly.  If they want to sell to the feds, then they gotta play the 
game.

-- charlie Crawford.


On Wed, 16 Apr 2003, Luke Davis wrote:

> They have the *right* to do anything they wish in this regard.  Our only
> option is to lobby them for what we want, and vote with our dollars.
> 
> Luke
> 
> 
> On Wed, 16 Apr 2003, Nick Gawronski wrote:
> 
> >       Hi, We must do something about all of these problems with redhat.
> > Think about it, rh8 had speakup and it was working just fine but look what
> > has happend rh9 is here and we don't have speakup yet the
> > readme-accessibility file is in 9 that says that redhat wants to make
> > their products accessible.  Well, I don't think that they are beeing very
> > nice about this at all.  If they removed speakup they should of removed
> > readme-accessbility as well.  We must contact redhat and find out "why did
> > you remove speakup yet leave readme-accessibility"  That is what we need
> > to do about this.  Who says they have a right to put speakup in one
> > version then take it away.  Think about this because we can make them put
> > it back in to their product.  bye
> >
> >
> > _______________________________________________
> > Speakup mailing list
> > Speakup@braille.uwo.ca
> > http://speech.braille.uwo.ca/mailman/listinfo/speakup
> >
> 
> _______________________________________________
> Speakup mailing list
> Speakup@braille.uwo.ca
> http://speech.braille.uwo.ca/mailman/listinfo/speakup
> 

Re: redhat problems

[Janina Sajka]

I would encourage you to let them know how you feel. That's a good thing to do.

Just a minor point. When uou write that Speakup "was working fine" in 8.0, that's true for us. Unfortunately, it was causing problems for other people. Yes, it's also
true that Kirk fixed that problem, and it's also true that Red Hat took their sweet time picking up the fix that Kirk created. But, the way you said it isn't true.

Another point. Speakup isn't the only accessibility related package in the Red Hat distribution. So, pulling the README.Accessibility doesn't make sense unless Red Had
were to have pulled the other package, too. In fact, they didn't, it's still there. And, they did modify what the README.Accessibility says. So, they did the right
thing as far as that file goes.

As for the business about providing RCE related materials in accessible, alternate formats, I agree 100%.

Nick Gawronski writes:
> From: Nick Gawronski <nick@nickgawronski.com>
> 
>       Hi, We must do something about all of these problems with redhat.  
> Think about it, rh8 had speakup and it was working just fine but look what 
> has happend rh9 is here and we don't have speakup yet the 
> readme-accessibility file is in 9 that says that redhat wants to make 
> their products accessible.  Well, I don't think that they are beeing very 
> nice about this at all.  If they removed speakup they should of removed 
> readme-accessbility as well.  We must contact redhat and find out "why did 
> you remove speakup yet leave readme-accessibility"  That is what we need 
> to do about this.  Who says they have a right to put speakup in one 
> version then take it away.  Think about this because we can make them put 
> it back in to their product.  bye 
> 
> 
> _______________________________________________
> Speakup mailing list
> Speakup@braille.uwo.ca
> http://speech.braille.uwo.ca/mailman/listinfo/speakup

-- 
	
				Janina Sajka, Director
				Technology Research and Development
				Governmental Relations Group
				American Foundation for the Blind (AFB)

Email: janina@afb.net		Phone: (202) 408-8175

Re: redhat problems

[Christopher Moore]

Is this turning into the redhat blindies list?
Chris

Re: redhat problems

[Thomas D. Ward]

Hi, you must understand the removal of speakup was strictly technical by
nature. Allot of the people on list are out to get Red Hat for pulling
speakup when there are technical issues that need and should be resolved.
One technical issue I agree with Red Hat on is a moduler version of speakup
as rather than the current way speakup is compiled into the kernel direct.
If I had the time and patients to do so I would do so myself, but it really
is a big undertaking to modulerize speakup.

----- Original Message -----
From: Nick Gawronski <nick@nickgawronski.com>
To: <speakup@braille.uwo.ca>
Sent: Wednesday, April 16, 2003 5:25 PM
Subject: redhat problems


>       Hi, We must do something about all of these problems with redhat.
> Think about it, rh8 had speakup and it was working just fine but look what
> has happend rh9 is here and we don't have speakup yet the
> readme-accessibility file is in 9 that says that redhat wants to make
> their products accessible.  Well, I don't think that they are beeing very
> nice about this at all.  If they removed speakup they should of removed
> readme-accessbility as well.  We must contact redhat and find out "why did
> you remove speakup yet leave readme-accessibility"  That is what we need
> to do about this.  Who says they have a right to put speakup in one
> version then take it away.  Think about this because we can make them put
> it back in to their product.  bye
>
>
> _______________________________________________
> Speakup mailing list
> Speakup@braille.uwo.ca
> http://speech.braille.uwo.ca/mailman/listinfo/speakup

Re: redhat problems

[Luke Davis]

I agree with that.  However, there are several things in the stock kernel,
that do not have modularized versions.  This then, begs the question: are
they pulling those drivers?

Luke


On Wed, 16 Apr 2003, Thomas D. Ward wrote:

> Hi, you must understand the removal of speakup was strictly technical by
> nature. Allot of the people on list are out to get Red Hat for pulling
> speakup when there are technical issues that need and should be resolved.
> One technical issue I agree with Red Hat on is a moduler version of speakup
> as rather than the current way speakup is compiled into the kernel direct.
> If I had the time and patients to do so I would do so myself, but it really
> is a big undertaking to modulerize speakup.
>
> ----- Original Message -----
> From: Nick Gawronski <nick@nickgawronski.com>
> To: <speakup@braille.uwo.ca>
> Sent: Wednesday, April 16, 2003 5:25 PM
> Subject: redhat problems
>
>
> >       Hi, We must do something about all of these problems with redhat.
> > Think about it, rh8 had speakup and it was working just fine but look what
> > has happend rh9 is here and we don't have speakup yet the
> > readme-accessibility file is in 9 that says that redhat wants to make
> > their products accessible.  Well, I don't think that they are beeing very
> > nice about this at all.  If they removed speakup they should of removed
> > readme-accessbility as well.  We must contact redhat and find out "why did
> > you remove speakup yet leave readme-accessibility"  That is what we need
> > to do about this.  Who says they have a right to put speakup in one
> > version then take it away.  Think about this because we can make them put
> > it back in to their product.  bye
> >
> >
> > _______________________________________________
> > Speakup mailing list
> > Speakup@braille.uwo.ca
> > http://speech.braille.uwo.ca/mailman/listinfo/speakup
>
>
> _______________________________________________
> Speakup mailing list
> Speakup@braille.uwo.ca
> http://speech.braille.uwo.ca/mailman/listinfo/speakup
>

Re: redhat problems

[Thomas D. Ward]

No, they aren't pulling them, but they also were not breaking French
keymaps, and other things in the distro which speakup was doing.
It seams the opinion on this list, from the RH enemies, that Red Hat did
this to make some statement like, "screw all the blind people! We don't
care! We will do  this to screw them over!!!"
Such a opinion is false, and is character assassanation.  Red Hat had
specific technicaland realistic reasons for pulling speakup. If they were
out to screw us they would have yanked festival and emacspeak from the
distro as well. wouldn't they???

----- Original Message -----
From: Luke Davis <ldavis@shellworld.net>
To: <speakup@braille.uwo.ca>
Sent: Wednesday, April 16, 2003 7:53 PM
Subject: Re: redhat problems


> I agree with that.  However, there are several things in the stock kernel,
> that do not have modularized versions.  This then, begs the question: are
> they pulling those drivers?
>
> Luke
>
>
> On Wed, 16 Apr 2003, Thomas D. Ward wrote:
>
> > Hi, you must understand the removal of speakup was strictly technical by
> > nature. Allot of the people on list are out to get Red Hat for pulling
> > speakup when there are technical issues that need and should be
resolved.
> > One technical issue I agree with Red Hat on is a moduler version of
speakup
> > as rather than the current way speakup is compiled into the kernel
direct.
> > If I had the time and patients to do so I would do so myself, but it
really
> > is a big undertaking to modulerize speakup.
> >
> > ----- Original Message -----
> > From: Nick Gawronski <nick@nickgawronski.com>
> > To: <speakup@braille.uwo.ca>
> > Sent: Wednesday, April 16, 2003 5:25 PM
> > Subject: redhat problems
> >
> >
> > >       Hi, We must do something about all of these problems with
redhat.
> > > Think about it, rh8 had speakup and it was working just fine but look
what
> > > has happend rh9 is here and we don't have speakup yet the
> > > readme-accessibility file is in 9 that says that redhat wants to make
> > > their products accessible.  Well, I don't think that they are beeing
very
> > > nice about this at all.  If they removed speakup they should of
removed
> > > readme-accessbility as well.  We must contact redhat and find out "why
did
> > > you remove speakup yet leave readme-accessibility"  That is what we
need
> > > to do about this.  Who says they have a right to put speakup in one
> > > version then take it away.  Think about this because we can make them
put
> > > it back in to their product.  bye
> > >
> > >
> > > _______________________________________________
> > > Speakup mailing list
> > > Speakup@braille.uwo.ca
> > > http://speech.braille.uwo.ca/mailman/listinfo/speakup
> >
> >
> > _______________________________________________
> > Speakup mailing list
> > Speakup@braille.uwo.ca
> > http://speech.braille.uwo.ca/mailman/listinfo/speakup
> >
>
> _______________________________________________
> Speakup mailing list
> Speakup@braille.uwo.ca
> http://speech.braille.uwo.ca/mailman/listinfo/speakup

Re: redhat problems

[Janina Sajka]

Thomas D. Ward writes:
> From: "Thomas D. Ward" <tward1978@ea> specific technicaland realistic reasons for pulling speakup. If they were
> If they were out to screw us they would have yanked festival and emacspeak from the
> distro as well. wouldn't they???
> 
And at-spi which doesn't even do anything yet as the GNOME accessibility applications aren't ready yet.

Re: redhat problems

[Luke Davis]

I'll just say one thing here: this is only another reason, why there
should be a non-kernel version of speakup.


On Wed, 16 Apr 2003, Janina Sajka wrote:

> Thomas D. Ward writes:
> > From: "Thomas D. Ward" <tward1978@ea> specific technicaland realistic reasons for pulling speakup. If they were
> > If they were out to screw us they would have yanked festival and emacspeak from the
> > distro as well. wouldn't they???
> >
> And at-spi which doesn't even do anything yet as the GNOME accessibility applications aren't ready yet.
>
>
> _______________________________________________
> Speakup mailing list
> Speakup@braille.uwo.ca
> http://speech.braille.uwo.ca/mailman/listinfo/speakup
>

Re: redhat problems

[Janina Sajka]

Huh? What is that? I have no idea what a "nonkernel version of Speakup" is, but if you want fully user-space accessibility, it's out there. Go use emacspeak, yasr,
screader, etc. You have choices. That's a good thing. I want my choices, too. I expect that's a good thing as well.

If there's on screen display, there needs to be a generic accessible alternative. If there's user action capture of any sort, there needs to be the ability to
interface alternative input devices. By my logic, Speakup in the kernel is progress. We still need to fix grub and the bios.

I'll tell you what, Luke. Let's support choices. Just don't decide for me which ones I should do without unless you want everyone in the world to do without them, too.
Maybe then I'd consider your suggestion equitable. Putting it like this, if I understand you correctly, is just more acquiessance to inequity. 

PS: I really don't understand how you can make the kind of strong statements you've justifiably made about RH's RCE policy over the last few weeks, yet accept second
class citizenship at the system initialization level. Those two don't square with me.


Luke Davis writes:
> From: Luke Davis <ldavis@shellworld.net>
> 
> I'll just say one thing here: this is only another reason, why there
> should be a non-kernel version of speakup.
> 
> 
> On Wed, 16 Apr 2003, Janina Sajka wrote:
> 
> > Thomas D. Ward writes:
> > > From: "Thomas D. Ward" <tward1978@ea> specific technicaland realistic reasons for pulling speakup. If they were
> > > If they were out to screw us they would have yanked festival and emacspeak from the
> > > distro as well. wouldn't they???
> > >
> > And at-spi which doesn't even do anything yet as the GNOME accessibility applications aren't ready yet.
> >
> >
> > _______________________________________________
> > Speakup mailing list
> > Speakup@braille.uwo.ca
> > http://speech.braille.uwo.ca/mailman/listinfo/speakup
> >
> 
> _______________________________________________
> Speakup mailing list
> Speakup@braille.uwo.ca
> http://speech.braille.uwo.ca/mailman/listinfo/speakup

-- 
	
				Janina Sajka, Director
				Technology Research and Development
				Governmental Relations Group
				American Foundation for the Blind (AFB)

Email: janina@afb.net		Phone: (202) 408-8175

Re: redhat problems

[Luke Davis]

We already do agree to that.  Choices are the best solution to any
situation.

My point was this: if there was a user-space speakup, I tend to think this
current Redhat problem would be a bit less intense. I have used other
Linux screen reading packages, and prefer Speakup by far, bugs and all.
I agree, that if they are on an instability binge, Readhat had good reason
to pull it.  However, if it was user-space, they may very well have left
it in, as the kernel would be (almost)  untouched.

Luke


On Wed, 16 Apr 2003, Janina Sajka wrote:

> Huh? What is that? I have no idea what a "nonkernel version of Speakup" is, but if you want fully user-space accessibility, it's out there. Go use emacspeak, yasr,
> screader, etc. You have choices. That's a good thing. I want my choices, too. I expect that's a good thing as well.
>
> If there's on screen display, there needs to be a generic accessible alternative. If there's user action capture of any sort, there needs to be the ability to
> interface alternative input devices. By my logic, Speakup in the kernel is progress. We still need to fix grub and the bios.
>
> I'll tell you what, Luke. Let's support choices. Just don't decide for me which ones I should do without unless you want everyone in the world to do without them, too.
> Maybe then I'd consider your suggestion equitable. Putting it like this, if I understand you correctly, is just more acquiessance to inequity.
>
> PS: I really don't understand how you can make the kind of strong statements you've justifiably made about RH's RCE policy over the last few weeks, yet accept second
> class citizenship at the system initialization level. Those two don't square with me.
>
>
> Luke Davis writes:
> > From: Luke Davis <ldavis@shellworld.net>
> >
> > I'll just say one thing here: this is only another reason, why there
> > should be a non-kernel version of speakup.
> >
> >
> > On Wed, 16 Apr 2003, Janina Sajka wrote:
> >
> > > Thomas D. Ward writes:
> > > > From: "Thomas D. Ward" <tward1978@ea> specific technicaland realistic reasons for pulling speakup. If they were
> > > > If they were out to screw us they would have yanked festival and emacspeak from the
> > > > distro as well. wouldn't they???
> > > >
> > > And at-spi which doesn't even do anything yet as the GNOME accessibility applications aren't ready yet.
> > >
> > >
> > > _______________________________________________
> > > Speakup mailing list
> > > Speakup@braille.uwo.ca
> > > http://speech.braille.uwo.ca/mailman/listinfo/speakup
> > >
> >
> > _______________________________________________
> > Speakup mailing list
> > Speakup@braille.uwo.ca
> > http://speech.braille.uwo.ca/mailman/listinfo/speakup
>
>

Re: redhat problems

[Adam Myrow]

I don't ever want Speakup to be user space for one reason.  Having it in
the kernel is the only logical way to get speech from bootup to shutdown,
which makes it possible to install a Linux distribution from CD with
speech.  I hope the future support of software speech synthesizers will
not break this feature.

Re: redhat problems

[Thomas D. Ward]

I do agree that speakup is an awesome product, but it isn't the only way to
have a screen reader from startup to shutdown.
If you could create a screen reader as a system service in the way apache,
sendmail, etc work then as soon as your system services load so would the
screen reader. Maybe not as nice as speakup does, but would probably be
easier to setup and compile than speakup is.

----- Original Message -----
From: Adam Myrow <amyrow@midsouth.rr.com>
To: <speakup@braille.uwo.ca>
Sent: Wednesday, April 16, 2003 9:07 PM
Subject: Re: redhat problems


> I don't ever want Speakup to be user space for one reason.  Having it in
> the kernel is the only logical way to get speech from bootup to shutdown,
> which makes it possible to install a Linux distribution from CD with
> speech.  I hope the future support of software speech synthesizers will
> not break this feature.
>
>
>
> _______________________________________________
> Speakup mailing list
> Speakup@braille.uwo.ca
> http://speech.braille.uwo.ca/mailman/listinfo/speakup

Re: redhat problems

[William Loughborough]

At 10:15 PM 4/16/2003 -0400, Thomas D. Ward wrote:
>would probably be easier to setup and compile than speakup is.

"would be's" are always a lot easier than "is's".

--
Love.

It's Bad Luck to be Superstitious! 

Re: redhat problems

[Janina Sajka]

But then it wouldn't be Speakup. If you prefer it, you should consider deferring to the possibility that its presence in the kernel is the very reason you like it so
well.

Do you think you'd have access to any console if Speakup loaded further up the stack? I happen to think access to any console is a very big deal, and very much an
equalizer. After all, everyone else has that, even if they choose not to use it.


Luke Davis writes:
> From: Luke Davis <ldavis@shellworld.net>
> 
> We already do agree to that.  Choices are the best solution to any
> situation.
> 
> My point was this: if there was a user-space speakup, I tend to think this
> current Redhat problem would be a bit less intense. I have used other
> Linux screen reading packages, and prefer Speakup by far, bugs and all.
> I agree, that if they are on an instability binge, Readhat had good reason
> to pull it.  However, if it was user-space, they may very well have left
> it in, as the kernel would be (almost)  untouched.
> 
> Luke
> 
> 
> On Wed, 16 Apr 2003, Janina Sajka wrote:
> 
> > Huh? What is that? I have no idea what a "nonkernel version of Speakup" is, but if you want fully user-space accessibility, it's out there. Go use emacspeak, yasr,
> > screader, etc. You have choices. That's a good thing. I want my choices, too. I expect that's a good thing as well.
> >
> > If there's on screen display, there needs to be a generic accessible alternative. If there's user action capture of any sort, there needs to be the ability to
> > interface alternative input devices. By my logic, Speakup in the kernel is progress. We still need to fix grub and the bios.
> >
> > I'll tell you what, Luke. Let's support choices. Just don't decide for me which ones I should do without unless you want everyone in the world to do without them, too.
> > Maybe then I'd consider your suggestion equitable. Putting it like this, if I understand you correctly, is just more acquiessance to inequity.
> >
> > PS: I really don't understand how you can make the kind of strong statements you've justifiably made about RH's RCE policy over the last few weeks, yet accept second
> > class citizenship at the system initialization level. Those two don't square with me.
> >
> >
> > Luke Davis writes:
> > > From: Luke Davis <ldavis@shellworld.net>
> > >
> > > I'll just say one thing here: this is only another reason, why there
> > > should be a non-kernel version of speakup.
> > >
> > >
> > > On Wed, 16 Apr 2003, Janina Sajka wrote:
> > >
> > > > Thomas D. Ward writes:
> > > > > From: "Thomas D. Ward" <tward1978@ea> specific technicaland realistic reasons for pulling speakup. If they were
> > > > > If they were out to screw us they would have yanked festival and emacspeak from the
> > > > > distro as well. wouldn't they???
> > > > >
> > > > And at-spi which doesn't even do anything yet as the GNOME accessibility applications aren't ready yet.
> > > >
> > > >
> > > > _______________________________________________
> > > > Speakup mailing list
> > > > Speakup@braille.uwo.ca
> > > > http://speech.braille.uwo.ca/mailman/listinfo/speakup
> > > >
> > >
> > > _______________________________________________
> > > Speakup mailing list
> > > Speakup@braille.uwo.ca
> > > http://speech.braille.uwo.ca/mailman/listinfo/speakup
> >
> >
> 
> _______________________________________________
> Speakup mailing list
> Speakup@braille.uwo.ca
> http://speech.braille.uwo.ca/mailman/listinfo/speakup

-- 
	
				Janina Sajka, Director
				Technology Research and Development
				Governmental Relations Group
				American Foundation for the Blind (AFB)

Email: janina@afb.net		Phone: (202) 408-8175

Kernel/user space (Was: Re: redhat problems)

[Luke Davis]

Okay, since we're going to have this discussion, let's have it, under a
better subject...

Long before I started using Speakup, I was apposed to having it in the
kernel, for all manner of reasons.

However, after using it a bit, and learning more about how it worked, I
became less attached to that idea, and started looking at it as more of a
driver, of the display type, and thus as something that needed to be in
the kernel.  At least, my arguments against it, lost some major weight.

As it stands, I am happy with Speakup as it is--in the kernel.  I still
maintain, however, that there may be a better way.

What I am looking at (unless Kirc, et al already did), is whether a hybrid
solution is possible--part in the kernel, and part in user space.

The only part that (and this is said with an admited lack of knowledge on
certain things, and is as such subject to change without notice) needs to
be in the kernel, is what is, at minimum, required to access the consoles,
and *maybe* talk to the synths.
I am hoping that some parts can be moved out of the kernel, while still
retaining the full functionality of Speakup as it is.  At the very least,
buffering of data will be necessary.  What I mean is, that when output
starts to a console (such as when booting starts), data will be buffered
until the rest of the package, or at least what is needed to speak, is
loaded, either from initrd, or from the root fs.  This is necessary for
some hardware synths (DEC PC), and software synths, anyway, and as such
should not be as strange as it initially looks.

The questions, as I see them, are:
(1) is this a feasable idea; and
(2) can enough of Speakup be moved into user space to make this worth
doing?

I do not know the answers to those yet.

However, that is my active idea.  Pleese feel free to change my mind.

What I am thinking, is that if this can be made to happen, the kernel
parts can be made highly stable, while the rest (managing the data which
the kernel parts provide), can be as unstable as may be necessary.

 Luke


On Wed, 16 Apr 2003, Janina Sajka wrote:

> But then it wouldn't be Speakup. If you prefer it, you should consider deferring to the possibility that its presence in the kernel is the very reason you like it so
> well.
>
> Do you think you'd have access to any console if Speakup loaded further up the stack? I happen to think access to any console is a very big deal, and very much an
> equalizer. After all, everyone else has that, even if they choose not to use it.

RE: Kernel/user space (Was: Re: redhat problems)

[Saqib Shaikh]

Hi

I am working on something very similar.  I am making a device file,
/dev/acsint, which exposes various accessibility information to userspace -
like what is being written to the screen, and what keys are being pressed.
It's not ready yet because I have my final exams coming up, but it will be
finished during the summer holidays.  I am then going to work with the
author of BrlTTY to add speech support.

Then you will have a daemon is userspace which provides full speech support.
I don't want to compete with Speakup - this is my prefered way of doing
things and one day I hope to make it a reality - many others will prefer the
philosophy of Speakup.

Thanks, Saqib


-----Original Message-----
From: speakup-admin@braille.uwo.ca
[mailto:speakup-admin@braille.uwo.ca]On Behalf Of Luke Davis
Sent: 17 April 2003 03:25
To: speakup@braille.uwo.ca
Subject: Kernel/user space (Was: Re: redhat problems)


Okay, since we're going to have this discussion, let's have it, under a
better subject...

Long before I started using Speakup, I was apposed to having it in the
kernel, for all manner of reasons.

However, after using it a bit, and learning more about how it worked, I
became less attached to that idea, and started looking at it as more of a
driver, of the display type, and thus as something that needed to be in
the kernel.  At least, my arguments against it, lost some major weight.

As it stands, I am happy with Speakup as it is--in the kernel.  I still
maintain, however, that there may be a better way.

What I am looking at (unless Kirc, et al already did), is whether a hybrid
solution is possible--part in the kernel, and part in user space.

The only part that (and this is said with an admited lack of knowledge on
certain things, and is as such subject to change without notice) needs to
be in the kernel, is what is, at minimum, required to access the consoles,
and *maybe* talk to the synths.
I am hoping that some parts can be moved out of the kernel, while still
retaining the full functionality of Speakup as it is.  At the very least,
buffering of data will be necessary.  What I mean is, that when output
starts to a console (such as when booting starts), data will be buffered
until the rest of the package, or at least what is needed to speak, is
loaded, either from initrd, or from the root fs.  This is necessary for
some hardware synths (DEC PC), and software synths, anyway, and as such
should not be as strange as it initially looks.

The questions, as I see them, are:
(1) is this a feasable idea; and
(2) can enough of Speakup be moved into user space to make this worth
doing?

I do not know the answers to those yet.

However, that is my active idea.  Pleese feel free to change my mind.

What I am thinking, is that if this can be made to happen, the kernel
parts can be made highly stable, while the rest (managing the data which
the kernel parts provide), can be as unstable as may be necessary.

 Luke


On Wed, 16 Apr 2003, Janina Sajka wrote:

> But then it wouldn't be Speakup. If you prefer it, you should consider
deferring to the possibility that its presence in the kernel is the very
reason you like it so
> well.
>
> Do you think you'd have access to any console if Speakup loaded further up
the stack? I happen to think access to any console is a very big deal, and
very much an
> equalizer. After all, everyone else has that, even if they choose not to
use it.

_______________________________________________
Speakup mailing list
Speakup@braille.uwo.ca
http://speech.braille.uwo.ca/mailman/listinfo/speakup

RE: Kernel/user space (Was: Re: redhat problems)

[Doug]

Saqib,

This is very interesting. Please post more information
on this later. Also, I'd love to test your stuff out.
I am very much into multi-modal interfaces. I want to
work on alternatives to using the actual keyboard to
control the synthesiser.

Thanks,
Doug


Saqib wrote:
 > I am working on something very similar.  I am making a device file,
>/dev/acsint, which exposes various accessibility information to userspace -
>like what is being written to the screen, and what keys are being pressed.

RE: Kernel/user space (Was: Re: redhat problems)

[Lorenzo Prince]

It's all about CHOICE!  In fact, that is what Linux is all about.  We
could always go back to using just Winblows.  The $199 per PC operating
system that doesn't half work and costs another $1000 just to make it
talk.  LOL.  I'll stick with Linux, and thank God and open-source
technology and all the wonderful people that make it all possible for us
to have real choices.  And not only does it not cost any money, but it is
illegal fore anyone to stop us from making the choice to use Linux and
whichever screen reen reader we want, and even to give it away if we want
to.  WOW!  LONG LIVE LINUX!

Lorenzo

E Pluribus Unix

Saqib Shaikh staggered into view and mumbled:

> Hi
>
> I am working on something very similar.  I am making a device file,
> /dev/acsint, which exposes various accessibility information to userspace -
> like what is being written to the screen, and what keys are being pressed.
> It's not ready yet because I have my final exams coming up, but it will be
> finished during the summer holidays.  I am then going to work with the
> author of BrlTTY to add speech support.
>
> Then you will have a daemon is userspace which provides full speech support.
> I don't want to compete with Speakup - this is my prefered way of doing
> things and one day I hope to make it a reality - many others will prefer the
> philosophy of Speakup.
>
> Thanks, Saqib
>
>
> -----Original Message-----
> From: speakup-admin@braille.uwo.ca
> [mailto:speakup-admin@braille.uwo.ca]On Behalf Of Luke Davis
> Sent: 17 April 2003 03:25
> To: speakup@braille.uwo.ca
> Subject: Kernel/user space (Was: Re: redhat problems)
>
>
> Okay, since we're going to have this discussion, let's have it, under a
> better subject...
>
> Long before I started using Speakup, I was apposed to having it in the
> kernel, for all manner of reasons.
>
> However, after using it a bit, and learning more about how it worked, I
> became less attached to that idea, and started looking at it as more of a
> driver, of the display type, and thus as something that needed to be in
> the kernel.  At least, my arguments against it, lost some major weight.
>
> As it stands, I am happy with Speakup as it is--in the kernel.  I still
> maintain, however, that there may be a better way.
>
> What I am looking at (unless Kirc, et al already did), is whether a hybrid
> solution is possible--part in the kernel, and part in user space.
>
> The only part that (and this is said with an admited lack of knowledge on
> certain things, and is as such subject to change without notice) needs to
> be in the kernel, is what is, at minimum, required to access the consoles,
> and *maybe* talk to the synths.
> I am hoping that some parts can be moved out of the kernel, while still
> retaining the full functionality of Speakup as it is.  At the very least,
> buffering of data will be necessary.  What I mean is, that when output
> starts to a console (such as when booting starts), data will be buffered
> until the rest of the package, or at least what is needed to speak, is
> loaded, either from initrd, or from the root fs.  This is necessary for
> some hardware synths (DEC PC), and software synths, anyway, and as such
> should not be as strange as it initially looks.
>
> The questions, as I see them, are:
> (1) is this a feasable idea; and
> (2) can enough of Speakup be moved into user space to make this worth
> doing?
>
> I do not know the answers to those yet.
>
> However, that is my active idea.  Pleese feel free to change my mind.
>
> What I am thinking, is that if this can be made to happen, the kernel
> parts can be made highly stable, while the rest (managing the data which
> the kernel parts provide), can be as unstable as may be necessary.
>
>  Luke
>
>
> On Wed, 16 Apr 2003, Janina Sajka wrote:
>
> > But then it wouldn't be Speakup. If you prefer it, you should consider
> deferring to the possibility that its presence in the kernel is the very
> reason you like it so
> > well.
> >
> > Do you think you'd have access to any console if Speakup loaded further up
> the stack? I happen to think access to any console is a very big deal, and
> very much an
> > equalizer. After all, everyone else has that, even if they choose not to
> use it.
>
> _______________________________________________
> Speakup mailing list
> Speakup@braille.uwo.ca
> http://speech.braille.uwo.ca/mailman/listinfo/speakup
>
>
> _______________________________________________
> Speakup mailing list
> Speakup@braille.uwo.ca
> http://speech.braille.uwo.ca/mailman/listinfo/speakup
>

RE: Kernel/user space (Was: Re: redhat problems)

[Saqib Shaikh]

I forgot to mention that the BrlTTY folks now have BrlTTY being loaded very
early on.  I'm sure I read somewhere that it can be started before the
filesystem checks etc - but I'm not sure.

Saqib


-----Original Message-----
From: speakup-admin@braille.uwo.ca
[mailto:speakup-admin@braille.uwo.ca]On Behalf Of Luke Davis
Sent: 17 April 2003 03:25
To: speakup@braille.uwo.ca
Subject: Kernel/user space (Was: Re: redhat problems)


Okay, since we're going to have this discussion, let's have it, under a
better subject...

Long before I started using Speakup, I was apposed to having it in the
kernel, for all manner of reasons.

However, after using it a bit, and learning more about how it worked, I
became less attached to that idea, and started looking at it as more of a
driver, of the display type, and thus as something that needed to be in
the kernel.  At least, my arguments against it, lost some major weight.

As it stands, I am happy with Speakup as it is--in the kernel.  I still
maintain, however, that there may be a better way.

What I am looking at (unless Kirc, et al already did), is whether a hybrid
solution is possible--part in the kernel, and part in user space.

The only part that (and this is said with an admited lack of knowledge on
certain things, and is as such subject to change without notice) needs to
be in the kernel, is what is, at minimum, required to access the consoles,
and *maybe* talk to the synths.
I am hoping that some parts can be moved out of the kernel, while still
retaining the full functionality of Speakup as it is.  At the very least,
buffering of data will be necessary.  What I mean is, that when output
starts to a console (such as when booting starts), data will be buffered
until the rest of the package, or at least what is needed to speak, is
loaded, either from initrd, or from the root fs.  This is necessary for
some hardware synths (DEC PC), and software synths, anyway, and as such
should not be as strange as it initially looks.

The questions, as I see them, are:
(1) is this a feasable idea; and
(2) can enough of Speakup be moved into user space to make this worth
doing?

I do not know the answers to those yet.

However, that is my active idea.  Pleese feel free to change my mind.

What I am thinking, is that if this can be made to happen, the kernel
parts can be made highly stable, while the rest (managing the data which
the kernel parts provide), can be as unstable as may be necessary.

 Luke


On Wed, 16 Apr 2003, Janina Sajka wrote:

> But then it wouldn't be Speakup. If you prefer it, you should consider
deferring to the possibility that its presence in the kernel is the very
reason you like it so
> well.
>
> Do you think you'd have access to any console if Speakup loaded further up
the stack? I happen to think access to any console is a very big deal, and
very much an
> equalizer. After all, everyone else has that, even if they choose not to
use it.

_______________________________________________
Speakup mailing list
Speakup@braille.uwo.ca
http://speech.braille.uwo.ca/mailman/listinfo/speakup

Re: Kernel/user space (Was: Re: redhat problems)

[Gregory Nowak]

One problem I see with this idea is that if you get a kernel panic before the rest of the package loads, you're up a creek without a sightling (grin).

Greg


On Wed, Apr 16, 2003 at 09:24:30PM -0500, Luke Davis wrote:
> Okay, since we're going to have this discussion, let's have it, under a
> better subject...
> 
> Long before I started using Speakup, I was apposed to having it in the
> kernel, for all manner of reasons.
> 
> However, after using it a bit, and learning more about how it worked, I
> became less attached to that idea, and started looking at it as more of a
> driver, of the display type, and thus as something that needed to be in
> the kernel.  At least, my arguments against it, lost some major weight.
> 
> As it stands, I am happy with Speakup as it is--in the kernel.  I still
> maintain, however, that there may be a better way.
> 
> What I am looking at (unless Kirc, et al already did), is whether a hybrid
> solution is possible--part in the kernel, and part in user space.
> 
> The only part that (and this is said with an admited lack of knowledge on
> certain things, and is as such subject to change without notice) needs to
> be in the kernel, is what is, at minimum, required to access the consoles,
> and *maybe* talk to the synths.
> I am hoping that some parts can be moved out of the kernel, while still
> retaining the full functionality of Speakup as it is.  At the very least,
> buffering of data will be necessary.  What I mean is, that when output
> starts to a console (such as when booting starts), data will be buffered
> until the rest of the package, or at least what is needed to speak, is
> loaded, either from initrd, or from the root fs.  This is necessary for
> some hardware synths (DEC PC), and software synths, anyway, and as such
> should not be as strange as it initially looks.
> 
> The questions, as I see them, are:
> (1) is this a feasable idea; and
> (2) can enough of Speakup be moved into user space to make this worth
> doing?
> 
> I do not know the answers to those yet.
> 
> However, that is my active idea.  Pleese feel free to change my mind.
> 
> What I am thinking, is that if this can be made to happen, the kernel
> parts can be made highly stable, while the rest (managing the data which
> the kernel parts provide), can be as unstable as may be necessary.
> 
>  Luke
> 
> 

Re: Kernel/user space (Was: Re: redhat problems)

[Luke Davis]

Hmm, yes, a very big problem at that.  I'll need to consider this.

On Wed, 16 Apr 2003, Gregory Nowak wrote:

> One problem I see with this idea is that if you get a kernel panic
> before the rest of the package loads, you're up a creek without a
> sightling (grin).
>
> Greg
>
>
> On Wed, Apr 16, 2003 at 09:24:30PM -0500, Luke Davis wrote:
> > Okay, since we're going to have this discussion, let's have it, under a
> > better subject...
> >

Re: Kernel/user space (Was: Re: redhat problems)

[Thomas D. Ward]

That is true, but there are many simple users who don't like going through
and building kernels everytime an update comes along.
Most of us on the list have experience with patching kernels, building them,
and installing them.
However, for newbies to Linux are fighting with the os, and learning how to
compile all at once. That's pretty tuff.
Fortunately, this problem is getting less and less now that there are kernel
rpms with speakup, Slack w=comes with it, etc.

----- Original Message -----
From: Gregory Nowak <greg@romuald.net.eu.org>
To: <speakup@braille.uwo.ca>
Sent: Wednesday, April 16, 2003 11:01 PM
Subject: Re: Kernel/user space (Was: Re: redhat problems)


> One problem I see with this idea is that if you get a kernel panic before
the rest of the package loads, you're up a creek without a sightling (grin).
>
> Greg
>
>
> On Wed, Apr 16, 2003 at 09:24:30PM -0500, Luke Davis wrote:
> > Okay, since we're going to have this discussion, let's have it, under a
> > better subject...
> >
> > Long before I started using Speakup, I was apposed to having it in the
> > kernel, for all manner of reasons.
> >
> > However, after using it a bit, and learning more about how it worked, I
> > became less attached to that idea, and started looking at it as more of
a
> > driver, of the display type, and thus as something that needed to be in
> > the kernel.  At least, my arguments against it, lost some major weight.
> >
> > As it stands, I am happy with Speakup as it is--in the kernel.  I still
> > maintain, however, that there may be a better way.
> >
> > What I am looking at (unless Kirc, et al already did), is whether a
hybrid
> > solution is possible--part in the kernel, and part in user space.
> >
> > The only part that (and this is said with an admited lack of knowledge
on
> > certain things, and is as such subject to change without notice) needs
to
> > be in the kernel, is what is, at minimum, required to access the
consoles,
> > and *maybe* talk to the synths.
> > I am hoping that some parts can be moved out of the kernel, while still
> > retaining the full functionality of Speakup as it is.  At the very
least,
> > buffering of data will be necessary.  What I mean is, that when output
> > starts to a console (such as when booting starts), data will be buffered
> > until the rest of the package, or at least what is needed to speak, is
> > loaded, either from initrd, or from the root fs.  This is necessary for
> > some hardware synths (DEC PC), and software synths, anyway, and as such
> > should not be as strange as it initially looks.
> >
> > The questions, as I see them, are:
> > (1) is this a feasable idea; and
> > (2) can enough of Speakup be moved into user space to make this worth
> > doing?
> >
> > I do not know the answers to those yet.
> >
> > However, that is my active idea.  Pleese feel free to change my mind.
> >
> > What I am thinking, is that if this can be made to happen, the kernel
> > parts can be made highly stable, while the rest (managing the data which
> > the kernel parts provide), can be as unstable as may be necessary.
> >
> >  Luke
> >
> >
>
> _______________________________________________
> Speakup mailing list
> Speakup@braille.uwo.ca
> http://speech.braille.uwo.ca/mailman/listinfo/speakup

Re: Kernel/user space (Was: Re: redhat problems)

[Thomas D. Ward]

As I said in a previous post it may be possible to write a screen reader
which would run as a system service.As such it would start as soon as the
services such as sendmail, apache, postfix,
got loaded. It might not have all the abilities of speakup, but I could see
it being vary easy to install, expand, and wouldn't be kernel linked.
Also another advantage is it could probably be ported to FreeBSD, and other
operating systems.
The problem is time, and man power.

----- Original Message -----
From: Luke Davis <ldavis@shellworld.net>
To: <speakup@braille.uwo.ca>
Sent: Wednesday, April 16, 2003 10:24 PM
Subject: Kernel/user space (Was: Re: redhat problems)


> Okay, since we're going to have this discussion, let's have it, under a
> better subject...
>
> Long before I started using Speakup, I was apposed to having it in the
> kernel, for all manner of reasons.
>
> However, after using it a bit, and learning more about how it worked, I
> became less attached to that idea, and started looking at it as more of a
> driver, of the display type, and thus as something that needed to be in
> the kernel.  At least, my arguments against it, lost some major weight.
>
> As it stands, I am happy with Speakup as it is--in the kernel.  I still
> maintain, however, that there may be a better way.
>
> What I am looking at (unless Kirc, et al already did), is whether a hybrid
> solution is possible--part in the kernel, and part in user space.
>
> The only part that (and this is said with an admited lack of knowledge on
> certain things, and is as such subject to change without notice) needs to
> be in the kernel, is what is, at minimum, required to access the consoles,
> and *maybe* talk to the synths.
> I am hoping that some parts can be moved out of the kernel, while still
> retaining the full functionality of Speakup as it is.  At the very least,
> buffering of data will be necessary.  What I mean is, that when output
> starts to a console (such as when booting starts), data will be buffered
> until the rest of the package, or at least what is needed to speak, is
> loaded, either from initrd, or from the root fs.  This is necessary for
> some hardware synths (DEC PC), and software synths, anyway, and as such
> should not be as strange as it initially looks.
>
> The questions, as I see them, are:
> (1) is this a feasable idea; and
> (2) can enough of Speakup be moved into user space to make this worth
> doing?
>
> I do not know the answers to those yet.
>
> However, that is my active idea.  Pleese feel free to change my mind.
>
> What I am thinking, is that if this can be made to happen, the kernel
> parts can be made highly stable, while the rest (managing the data which
> the kernel parts provide), can be as unstable as may be necessary.
>
>  Luke
>
>
> On Wed, 16 Apr 2003, Janina Sajka wrote:
>
> > But then it wouldn't be Speakup. If you prefer it, you should consider
deferring to the possibility that its presence in the kernel is the very
reason you like it so
> > well.
> >
> > Do you think you'd have access to any console if Speakup loaded further
up the stack? I happen to think access to any console is a very big deal,
and very much an
> > equalizer. After all, everyone else has that, even if they choose not to
use it.
>
> _______________________________________________
> Speakup mailing list
> Speakup@braille.uwo.ca
> http://speech.braille.uwo.ca/mailman/listinfo/speakup

Re: Kernel/user space (Was: Re: redhat problems)

[Janina Sajka]

Hey, Thomas,

If that's what you want, why aren't you using it? It already exists. In fact, there are several such things, yasr being one. Have at it. Nothing is stopping you.

Just one simple request. Stop insisting that I join you.
I like mine the way Speakup is now, loaded with the kernel.

So, can we be happy now? You got yours, I got mine, all's peace and love and Captain Krunch, OK?

				Janina


Thomas D. Ward writes:
> From: "Thomas D. Ward" <tward1978@earthlink.net>
> 
> As I said in a previous post it may be possible to write a screen reader
> which would run as a system service.As such it would start as soon as the
> services such as sendmail, apache, postfix,
> got loaded. It might not have all the abilities of speakup, but I could see
> it being vary easy to install, expand, and wouldn't be kernel linked.
> Also another advantage is it could probably be ported to FreeBSD, and other
> operating systems.
> The problem is time, and man power.
> 
> ----- Original Message -----

Re: Kernel/user space (Was: Re: redhat problems)

[Thomas D. Ward]

Sheesh. Janina. I hadn't suggested that anyone join me in the endever. I
don't really like YASR, and that's one reason I use speakup as well.
I believe I was attempting to explain to Luke that it would be possible to
make a screen reader as a system service, and in the user space.
I didn't see your name in my previous post asking for you to join me. Ok?
Let's knock off the jumping on other members for every little comment they
make.

----- Original Message -----
From: Janina Sajka <janina@rednote.net>
To: <speakup@braille.uwo.ca>
Sent: Thursday, April 17, 2003 9:56 AM
Subject: Re: Kernel/user space (Was: Re: redhat problems)


> Hey, Thomas,
>
> If that's what you want, why aren't you using it? It already exists. In
fact, there are several such things, yasr being one. Have at it. Nothing is
stopping you.
>
> Just one simple request. Stop insisting that I join you.
> I like mine the way Speakup is now, loaded with the kernel.
>
> So, can we be happy now? You got yours, I got mine, all's peace and love
and Captain Krunch, OK?
>
> Janina
>
>
> Thomas D. Ward writes:
> > From: "Thomas D. Ward" <tward1978@earthlink.net>
> >
> > As I said in a previous post it may be possible to write a screen reader
> > which would run as a system service.As such it would start as soon as
the
> > services such as sendmail, apache, postfix,
> > got loaded. It might not have all the abilities of speakup, but I could
see
> > it being vary easy to install, expand, and wouldn't be kernel linked.
> > Also another advantage is it could probably be ported to FreeBSD, and
other
> > operating systems.
> > The problem is time, and man power.
> >
> > ----- Original Message -----
>
> _______________________________________________
> Speakup mailing list
> Speakup@braille.uwo.ca
> http://speech.braille.uwo.ca/mailman/listinfo/speakup

Re: Kernel/user space (Was: Re: redhat problems)

[Janina Sajka]

Why are you upset? I didn't break into anyone's private mailbox. No, I responded to a [public post on a public list.

And, most certainly I understood that you were saying "it would be possible ..." ya di ya di ya di. I got that. 

Obviously, though, there's some kind of mis-communication going on here. And, that part I don't understand. You like Speakup, but you wish it were something else, like
all in user space. That's the part I don't get. Because, then it wouldn't be Speakup. It would be something else, like yasr, or screader, or brasso, or whatever. So,
as I was pointing out, you could certainly use these.

So, if you're hanging with Speakup because you like it, what's the problem? Is it user space you want? Or Speakup?

Somehow, this issue, every time it comes up, just reminds me of that old saw about having one's cake and eating it too.

Thomas D. Ward writes:
> From: "Thomas D. Ward" <tward1978@earthlink.net>
> 
> Sheesh. Janina. I hadn't suggested that anyone join me in the endever. I
> don't really like YASR, and that's one reason I use speakup as well.
> I believe I was attempting to explain to Luke that it would be possible to
> make a screen reader as a system service, and in the user space.
> I didn't see your name in my previous post asking for you to join me. Ok?
> Let's knock off the jumping on other members for every little comment they
> make.
> 
> ----- Original Message -----
> From: Janina Sajka <janina@rednote.net>
> To: <speakup@braille.uwo.ca>
> Sent: Thursday, April 17, 2003 9:56 AM
> Subject: Re: Kernel/user space (Was: Re: redhat problems)
> 
> 
> > Hey, Thomas,
> >
> > If that's what you want, why aren't you using it? It already exists. In
> fact, there are several such things, yasr being one. Have at it. Nothing is
> stopping you.
> >
> > Just one simple request. Stop insisting that I join you.
> > I like mine the way Speakup is now, loaded with the kernel.
> >
> > So, can we be happy now? You got yours, I got mine, all's peace and love
> and Captain Krunch, OK?
> >
> > Janina
> >
> >
> > Thomas D. Ward writes:
> > > From: "Thomas D. Ward" <tward1978@earthlink.net>
> > >
> > > As I said in a previous post it may be possible to write a screen reader
> > > which would run as a system service.As such it would start as soon as
> the
> > > services such as sendmail, apache, postfix,
> > > got loaded. It might not have all the abilities of speakup, but I could
> see
> > > it being vary easy to install, expand, and wouldn't be kernel linked.
> > > Also another advantage is it could probably be ported to FreeBSD, and
> other
> > > operating systems.
> > > The problem is time, and man power.
> > >
> > > ----- Original Message -----
> >
> > _______________________________________________
> > Speakup mailing list
> > Speakup@braille.uwo.ca
> > http://speech.braille.uwo.ca/mailman/listinfo/speakup
> 
> 
> _______________________________________________
> Speakup mailing list
> Speakup@braille.uwo.ca
> http://speech.braille.uwo.ca/mailman/listinfo/speakup

-- 
	
				Janina Sajka, Director
				Technology Research and Development
				Governmental Relations Group
				American Foundation for the Blind (AFB)

Email: janina@afb.net		Phone: (202) 408-8175

Re: Kernel/user space (Was: Re: redhat problems)

[Luke Davis]

Yes, but Janina makes a good point, about the speaking from startup.
Afaik, the only way to do that, is to have *some* hooks in the kernel;
hence my hybrid idea.

Luke


On Thu, 17 Apr 2003, Thomas D. Ward wrote:

> As I said in a previous post it may be possible to write a screen reader
> which would run as a system service.As such it would start as soon as the
> services such as sendmail, apache, postfix,
> got loaded. It might not have all the abilities of speakup, but I could see
> it being vary easy to install, expand, and wouldn't be kernel linked.
> Also another advantage is it could probably be ported to FreeBSD, and other
> operating systems.
> The problem is time, and man power.
>
> ----- Original Message -----
> From: Luke Davis <ldavis@shellworld.net>
> To: <speakup@braille.uwo.ca>
> Sent: Wednesday, April 16, 2003 10:24 PM
> Subject: Kernel/user space (Was: Re: redhat problems)
>
>
> > Okay, since we're going to have this discussion, let's have it, under a
> > better subject...
> >
> > Long before I started using Speakup, I was apposed to having it in the
> > kernel, for all manner of reasons.
> >
> > However, after using it a bit, and learning more about how it worked, I
> > became less attached to that idea, and started looking at it as more of a
> > driver, of the display type, and thus as something that needed to be in
> > the kernel.  At least, my arguments against it, lost some major weight.
> >
> > As it stands, I am happy with Speakup as it is--in the kernel.  I still
> > maintain, however, that there may be a better way.
> >
> > What I am looking at (unless Kirc, et al already did), is whether a hybrid
> > solution is possible--part in the kernel, and part in user space.
> >
> > The only part that (and this is said with an admited lack of knowledge on
> > certain things, and is as such subject to change without notice) needs to
> > be in the kernel, is what is, at minimum, required to access the consoles,
> > and *maybe* talk to the synths.
> > I am hoping that some parts can be moved out of the kernel, while still
> > retaining the full functionality of Speakup as it is.  At the very least,
> > buffering of data will be necessary.  What I mean is, that when output
> > starts to a console (such as when booting starts), data will be buffered
> > until the rest of the package, or at least what is needed to speak, is
> > loaded, either from initrd, or from the root fs.  This is necessary for
> > some hardware synths (DEC PC), and software synths, anyway, and as such
> > should not be as strange as it initially looks.
> >
> > The questions, as I see them, are:
> > (1) is this a feasable idea; and
> > (2) can enough of Speakup be moved into user space to make this worth
> > doing?
> >
> > I do not know the answers to those yet.
> >
> > However, that is my active idea.  Pleese feel free to change my mind.
> >
> > What I am thinking, is that if this can be made to happen, the kernel
> > parts can be made highly stable, while the rest (managing the data which
> > the kernel parts provide), can be as unstable as may be necessary.
> >
> >  Luke
> >
> >
> > On Wed, 16 Apr 2003, Janina Sajka wrote:
> >
> > > But then it wouldn't be Speakup. If you prefer it, you should consider
> deferring to the possibility that its presence in the kernel is the very
> reason you like it so
> > > well.
> > >
> > > Do you think you'd have access to any console if Speakup loaded further
> up the stack? I happen to think access to any console is a very big deal,
> and very much an
> > > equalizer. After all, everyone else has that, even if they choose not to
> use it.
> >
> > _______________________________________________
> > Speakup mailing list
> > Speakup@braille.uwo.ca
> > http://speech.braille.uwo.ca/mailman/listinfo/speakup
>
>
> _______________________________________________
> Speakup mailing list
> Speakup@braille.uwo.ca
> http://speech.braille.uwo.ca/mailman/listinfo/speakup
>

Re: Kernel/user space (Was: Re: redhat problems)

[Janina Sajka]

Fine, Luke, but you're not the only one to think this way, and you may not even be the first.

This is what is known as modularity. It's why we have kernel loadable modules, which can be passed arguments at the boot> prompt, etc., etc.

If I read this list correctly, early and certainly broken versions will soon be popping out of CVS. Eventually, it'll be called Speakup 2.0. 

So, relax. It's all in the chute.

PS: How's that beginner doc coming along?

Luke Davis writes:
> From: Luke Davis <ldavis@shellworld.net>
> 
> Okay, since we're going to have this discussion, let's have it, under a
> better subject...
> 
> Long before I started using Speakup, I was apposed to having it in the
> kernel, for all manner of reasons.
> 
> However, after using it a bit, and learning more about how it worked, I
> became less attached to that idea, and started looking at it as more of a
> driver, of the display type, and thus as something that needed to be in
> the kernel.  At least, my arguments against it, lost some major weight.
> 
> As it stands, I am happy with Speakup as it is--in the kernel.  I still
> maintain, however, that there may be a better way.
> 
> What I am looking at (unless Kirc, et al already did), is whether a hybrid
> solution is possible--part in the kernel, and part in user space.
> 
> The only part that (and this is said with an admited lack of knowledge on
> certain things, and is as such subject to change without notice) needs to
> be in the kernel, is what is, at minimum, required to access the consoles,
> and *maybe* talk to the synths.
> I am hoping that some parts can be moved out of the kernel, while still
> retaining the full functionality of Speakup as it is.  At the very least,
> buffering of data will be necessary.  What I mean is, that when output
> starts to a console (such as when booting starts), data will be buffered
> until the rest of the package, or at least what is needed to speak, is
> loaded, either from initrd, or from the root fs.  This is necessary for
> some hardware synths (DEC PC), and software synths, anyway, and as such
> should not be as strange as it initially looks.
> 
> The questions, as I see them, are:
> (1) is this a feasable idea; and
> (2) can enough of Speakup be moved into user space to make this worth
> doing?
> 
> I do not know the answers to those yet.
> 
> However, that is my active idea.  Pleese feel free to change my mind.
> 
> What I am thinking, is that if this can be made to happen, the kernel
> parts can be made highly stable, while the rest (managing the data which
> the kernel parts provide), can be as unstable as may be necessary.
> 
>  Luke
> 
> 
> On Wed, 16 Apr 2003, Janina Sajka wrote:
> 
> > But then it wouldn't be Speakup. If you prefer it, you should consider deferring to the possibility that its presence in the kernel is the very reason you like it so
> > well.
> >
> > Do you think you'd have access to any console if Speakup loaded further up the stack? I happen to think access to any console is a very big deal, and very much an
> > equalizer. After all, everyone else has that, even if they choose not to use it.
> 
> _______________________________________________
> Speakup mailing list
> Speakup@braille.uwo.ca
> http://speech.braille.uwo.ca/mailman/listinfo/speakup

-- 
	
				Janina Sajka, Director
				Technology Research and Development
				Governmental Relations Group
				American Foundation for the Blind (AFB)

Email: janina@afb.net		Phone: (202) 408-8175

Re: Kernel/user space (Was: Re: redhat problems)

[Scott Howell]

Luke,

The only problem I can see right off is the fact that data is buffered. I
for one want all output immediately and not soem stuff queued and only
available once a service comes online. This is where Speakup truly shines
and I can't say I've ever had a problem with Speakup causing problems for
any kernels I compiled. Matter of fact and this is for Kirk, I no longer
have any problems stopping speech when booting my dual processor box. Kirk
you may recall some time back I was haivng problems with this, but that has
gone away. Now only if I could get my Linux box back from the dead, I'd be
sooo much happier. I hate using my wife's winblows box. Well hopefully this
weekend I can borrow some parts from a friend of mine and see what's wrong
with the old box.



----- Original Message -----
From: "Luke Davis" <ldavis@shellworld.net>
To: <speakup@braille.uwo.ca>
Sent: 16 April, 2003 22:24
Subject: Kernel/user space (Was: Re: redhat problems)


> Okay, since we're going to have this discussion, let's have it, under a
> better subject...
>
> Long before I started using Speakup, I was apposed to having it in the
> kernel, for all manner of reasons.
>
> However, after using it a bit, and learning more about how it worked, I
> became less attached to that idea, and started looking at it as more of a
> driver, of the display type, and thus as something that needed to be in
> the kernel.  At least, my arguments against it, lost some major weight.
>
> As it stands, I am happy with Speakup as it is--in the kernel.  I still
> maintain, however, that there may be a better way.
>
> What I am looking at (unless Kirc, et al already did), is whether a hybrid
> solution is possible--part in the kernel, and part in user

Re: redhat problems

[Patrick Turnage]

Hello
I think that RH has a really good reason for keeping speakup out of the
kernel at this time. They have some valid complaints about it and when
those are addressed it probably will end up in the distribution again.
I do think if you want to take the RHCE exams they should be a little more
occomidating.
They have the right to make  whatever policy they want with regard to their
exam documentation but a NDA is a binding contract between RH and the
person taking the exam. 
If you want to write to RH it should be to ask them to attempt to develop
policies that allow disabled persons to take part in their training
matterial and to have some equal or as close to equal access during the
RHCE exams..
Oh on another note.. I had a computer wqith windows XP. It for some reason
did not boot.. I took a standard slack root disk and a custom kernel and
loadlin put it on a cd  and connected my usb hard drive and backed up all
my data.. Linux is flexible it has saved me more times thatn I can even
count.. Once I used Linux on a zip drive for a month while my notebook's
hard drive was off being repaired. With a little customization only booting
was the issue.. Of course after a month of use that zip disk stopped
working but still.
I see all these MCSE's walking around my college campus and when I talk to
them about Linux for access to hard drives that have failed they just say
they don't use it.. I'm glad I learned it and to anybody who is just
begining to explore Linux your doing yourself a favor..
sincerely,
Patrick


-----
Patrick Turnage
E-mail: pturnage@tampabay.rr.com
AOL Instant Messenger: kg4dqk
Home Page:
http://www.access-connect.com
Connecting the world to access technology information.
For all mainstream and adaptive hardware and software.

Re: redhat problems

[William F. Acker WB2FLW +1-303-722-7209]

OK, Patrick, you now have, and Thomas has all along, implied that you had 
knowledge of all of RH's complaints with Speakup.  How 'bout sharing them 
with the group?  I know what the answer to this question was last week, 
Kirk, but for this week: has anyone at Red Hat Incorporated sent you any 
bug reports, or, better yet, patches?

-- 
          Bill in Denver


On Wed, 16 Apr 2003, Patrick Turnage wrote:

> Hello
> I think that RH has a really good reason for keeping speakup out of the
> kernel at this time. They have some valid complaints about it and when
> those are addressed it probably will end up in the distribution again.
> I do think if you want to take the RHCE exams they should be a little more
> occomidating.
> They have the right to make  whatever policy they want with regard to their
> exam documentation but a NDA is a binding contract between RH and the
> person taking the exam. 
> If you want to write to RH it should be to ask them to attempt to develop
> policies that allow disabled persons to take part in their training
> matterial and to have some equal or as close to equal access during the
> RHCE exams..
> Oh on another note.. I had a computer wqith windows XP. It for some reason
> did not boot.. I took a standard slack root disk and a custom kernel and
> loadlin put it on a cd  and connected my usb hard drive and backed up all
> my data.. Linux is flexible it has saved me more times thatn I can even
> count.. Once I used Linux on a zip drive for a month while my notebook's
> hard drive was off being repaired. With a little customization only booting
> was the issue.. Of course after a month of use that zip disk stopped
> working but still.
> I see all these MCSE's walking around my college campus and when I talk to
> them about Linux for access to hard drives that have failed they just say
> they don't use it.. I'm glad I learned it and to anybody who is just
> begining to explore Linux your doing yourself a favor..
> sincerely,
> Patrick
> 
> 
> -----
> Patrick Turnage
> E-mail: pturnage@tampabay.rr.com
> AOL Instant Messenger: kg4dqk
> Home Page:
> http://www.access-connect.com
> Connecting the world to access technology information.
> For all mainstream and adaptive hardware and software.
> 
> 
> 
> _______________________________________________
> Speakup mailing list
> Speakup@braille.uwo.ca
> http://speech.braille.uwo.ca/mailman/listinfo/speakup
> 

Re: redhat problems

[Kirk Reiser]

"William F. Acker WB2FLW +1-303-722-7209" <wacker@octothorp.org> writes:

> Kirk, but for this week: has anyone at Red Hat Incorporated sent you any 
> bug reports, or, better yet, patches?

Nehr a word.

  Kirk

-- 

Kirk Reiser				The Computer Braille Facility
e-mail: kirk@braille.uwo.ca		University of Western Ontario
phone: (519) 661-3061

Re: redhat problems

[Lorenzo Prince]

Cool!  Never even thought of that use for the Real OS.  The best OS!  The
world's most flexible OS!  I guess we Linux-lovers can tell the rest of
the world that even if they hate Linux, there is still an extremely good
use for it when nothing else works.  Personally, I avoid the problem
altogether and use Linux as much as possible.

Lorenzo

E Pluribus Unix

Patrick Turnage staggered into view and mumbled:

> Hello
> I think that RH has a really good reason for keeping speakup out of the
> kernel at this time. They have some valid complaints about it and when
> those are addressed it probably will end up in the distribution again.
> I do think if you want to take the RHCE exams they should be a little more
> occomidating.
> They have the right to make  whatever policy they want with regard to their
> exam documentation but a NDA is a binding contract between RH and the
> person taking the exam.
> If you want to write to RH it should be to ask them to attempt to develop
> policies that allow disabled persons to take part in their training
> matterial and to have some equal or as close to equal access during the
> RHCE exams..
> Oh on another note.. I had a computer wqith windows XP. It for some reason
> did not boot.. I took a standard slack root disk and a custom kernel and
> loadlin put it on a cd  and connected my usb hard drive and backed up all
> my data.. Linux is flexible it has saved me more times thatn I can even
> count.. Once I used Linux on a zip drive for a month while my notebook's
> hard drive was off being repaired. With a little customization only booting
> was the issue.. Of course after a month of use that zip disk stopped
> working but still.
> I see all these MCSE's walking around my college campus and when I talk to
> them about Linux for access to hard drives that have failed they just say
> they don't use it.. I'm glad I learned it and to anybody who is just
> begining to explore Linux your doing yourself a favor..
> sincerely,
> Patrick
>
>
> -----
> Patrick Turnage
> E-mail: pturnage@tampabay.rr.com
> AOL Instant Messenger: kg4dqk
> Home Page:
> http://www.access-connect.com
> Connecting the world to access technology information.
> For all mainstream and adaptive hardware and software.
>
>
>
> _______________________________________________
> Speakup mailing list
> Speakup@braille.uwo.ca
> http://speech.braille.uwo.ca/mailman/listinfo/speakup
>

Re: redhat problems

[Thomas D. Ward]

I've been thinking of that, and a console screen reader that could be
loadeed as a linux service rather than a kernel module.

----- Original Message -----
From: Luke Davis <ldavis@shellworld.net>
To: <speakup@braille.uwo.ca>
Sent: Wednesday, April 16, 2003 8:13 PM
Subject: Re: redhat problems


> I'll just say one thing here: this is only another reason, why there
> should be a non-kernel version of speakup.
>
>
> On Wed, 16 Apr 2003, Janina Sajka wrote:
>
> > Thomas D. Ward writes:
> > > From: "Thomas D. Ward" <tward1978@ea> specific technicaland realistic
reasons for pulling speakup. If they were
> > > If they were out to screw us they would have yanked festival and
emacspeak from the
> > > distro as well. wouldn't they???
> > >
> > And at-spi which doesn't even do anything yet as the GNOME accessibility
applications aren't ready yet.
> >
> >
> > _______________________________________________
> > Speakup mailing list
> > Speakup@braille.uwo.ca
> > http://speech.braille.uwo.ca/mailman/listinfo/speakup
> >
>
> _______________________________________________
> Speakup mailing list
> Speakup@braille.uwo.ca
> http://speech.braille.uwo.ca/mailman/listinfo/speakup

Re: redhat problems

[Lorenzo Prince]

Actually, it would be cool if it could be a choice to either compile it in
the kernel or as a module.  A modularized speakup may be more widely
adopted by companies like Redhat, but would lack some of the things we
have come to love about Speakup, such as being able to hear all the boot
messages or to scroll back the console through them.  However, at the same
time, patching it directly into the kernel gives us all the things we
love, but can sometimes cause instabilities and could even distabilize the
kernel, which looks rather unattractive to major companies like Redhat,
who's sighted customers need to be able to trust the reliability of their
kernel as much as we do.  This problem has been solved in a way by
Slackware, who gives us a precompiled Speakup kernel, but the kernel
source is the official kernel.org source without speakup, but is available
for our patching.  Other companies may not want to include 20+ kernels on
their CD's.  Those who use only one kernel need a choice to either include
Speakup in the kernel or as a module, whichever one they feel would
benefit all their customers the most.

Lorenzo

E Pluribus Unix

Luke Davis staggered into view and mumbled:

> I agree with that.  However, there are several things in the stock kernel,
> that do not have modularized versions.  This then, begs the question: are
> they pulling those drivers?
>
> Luke
>
>
> On Wed, 16 Apr 2003, Thomas D. Ward wrote:
>
> > Hi, you must understand the removal of speakup was strictly technical by
> > nature. Allot of the people on list are out to get Red Hat for pulling
> > speakup when there are technical issues that need and should be resolved.
> > One technical issue I agree with Red Hat on is a moduler version of speakup
> > as rather than the current way speakup is compiled into the kernel direct.
> > If I had the time and patients to do so I would do so myself, but it really
> > is a big undertaking to modulerize speakup.
> >
> > ----- Original Message -----
> > From: Nick Gawronski <nick@nickgawronski.com>
> > To: <speakup@braille.uwo.ca>
> > Sent: Wednesday, April 16, 2003 5:25 PM
> > Subject: redhat problems
> >
> >
> > >       Hi, We must do something about all of these problems with redhat.
> > > Think about it, rh8 had speakup and it was working just fine but look what
> > > has happend rh9 is here and we don't have speakup yet the
> > > readme-accessibility file is in 9 that says that redhat wants to make
> > > their products accessible.  Well, I don't think that they are beeing very
> > > nice about this at all.  If they removed speakup they should of removed
> > > readme-accessbility as well.  We must contact redhat and find out "why did
> > > you remove speakup yet leave readme-accessibility"  That is what we need
> > > to do about this.  Who says they have a right to put speakup in one
> > > version then take it away.  Think about this because we can make them put
> > > it back in to their product.  bye
> > >
> > >
> > > _______________________________________________
> > > Speakup mailing list
> > > Speakup@braille.uwo.ca
> > > http://speech.braille.uwo.ca/mailman/listinfo/speakup
> >
> >
> > _______________________________________________
> > Speakup mailing list
> > Speakup@braille.uwo.ca
> > http://speech.braille.uwo.ca/mailman/listinfo/speakup
> >
>
> _______________________________________________
> Speakup mailing list
> Speakup@braille.uwo.ca
> http://speech.braille.uwo.ca/mailman/listinfo/speakup
>

Re: redhat problems

[Janina Sajka]

Lorenzo Prince writes:
> 
> ... A modularized speakup [...] would lack some of the things we
> have come to love about Speakup, such as being able to hear all the boot
> messages or to scroll back the console through them.


So says you. Do you know this for a fact, or are you supposing this? Care to explain?


You did state it as fact.

				Janina

Re: redhat problems

[Lorenzo Prince]

Kernel modules are loaded later than the kernel itself.  Unless there is a
buffer in the kernel to keep track of the console text before the module
is loaded, it won't catch all the text from the beginning.

Lorenzo

E Pluribus Unix

Janina Sajka staggered into view and mumbled:

> Lorenzo Prince writes:
> >
> > ... A modularized speakup [...] would lack some of the things we
> > have come to love about Speakup, such as being able to hear all the boot
> > messages or to scroll back the console through them.
>
>
> So says you. Do you know this for a fact, or are you supposing this? Care to explain?
>
>
> You did state it as fact.
>
> 				Janina
>
>
> _______________________________________________
> Speakup mailing list
> Speakup@braille.uwo.ca
> http://speech.braille.uwo.ca/mailman/listinfo/speakup
>

Re: redhat problems

[Janina Sajka]

Not so fast. Maybe you're correct, and maybe not. Are you familiar with the ide-scsi module? When does that one get loaded--if it's to be loaded?

I cite ide-scsi as an example to you. Sayhing "later than the kernel" covers a lot of time, and pretty much the entire stack.

Lorenzo Prince writes:
> From: Lorenzo Prince <lorenzo@princenet.sytes.net>
> 
> Kernel modules are loaded later than the kernel itself.  Unless there is a
> buffer in the kernel to keep track of the console text before the module
> is loaded, it won't catch all the text from the beginning.
> 
> Lorenzo
> 
> E Pluribus Unix
> 
> Janina Sajka staggered into view and mumbled:
> 
> > Lorenzo Prince writes:
> > >
> > > ... A modularized speakup [...] would lack some of the things we
> > > have come to love about Speakup, such as being able to hear all the boot
> > > messages or to scroll back the console through them.
> >
> >
> > So says you. Do you know this for a fact, or are you supposing this? Care to explain?
> >
> >
> > You did state it as fact.
> >
> > 				Janina
> >
> >
> > _______________________________________________
> > Speakup mailing list
> > Speakup@braille.uwo.ca
> > http://speech.braille.uwo.ca/mailman/listinfo/speakup
> >
> 
> _______________________________________________
> Speakup mailing list
> Speakup@braille.uwo.ca
> http://speech.braille.uwo.ca/mailman/listinfo/speakup

-- 
	
				Janina Sajka, Director
				Technology Research and Development
				Governmental Relations Group
				American Foundation for the Blind (AFB)

Email: janina@afb.net		Phone: (202) 408-8175

Re: redhat problems

[Lorenzo Prince]

Not sure.  In my Slackware 9 kernel, ide-scsi is compiled into the kernel
by default according to the .config file in the source tree.

Lorenzo


E Pluribus Unix

Janina Sajka staggered into view and mumbled:

> Not so fast. Maybe you're correct, and maybe not. Are you familiar with the ide-scsi module? When does that one get loaded--if it's to be loaded?
>
> I cite ide-scsi as an example to you. Sayhing "later than the kernel" covers a lot of time, and pretty much the entire stack.
>
> Lorenzo Prince writes:
> > From: Lorenzo Prince <lorenzo@princenet.sytes.net>
> >
> > Kernel modules are loaded later than the kernel itself.  Unless there is a
> > buffer in the kernel to keep track of the console text before the module
> > is loaded, it won't catch all the text from the beginning.
> >
> > Lorenzo
> >
> > E Pluribus Unix
> >
> > Janina Sajka staggered into view and mumbled:
> >
> > > Lorenzo Prince writes:
> > > >
> > > > ... A modularized speakup [...] would lack some of the things we
> > > > have come to love about Speakup, such as being able to hear all the boot
> > > > messages or to scroll back the console through them.
> > >
> > >
> > > So says you. Do you know this for a fact, or are you supposing this? Care to explain?
> > >
> > >
> > > You did state it as fact.
> > >
> > > 				Janina
> > >
> > >
> > > _______________________________________________
> > > Speakup mailing list
> > > Speakup@braille.uwo.ca
> > > http://speech.braille.uwo.ca/mailman/listinfo/speakup
> > >
> >
> > _______________________________________________
> > Speakup mailing list
> > Speakup@braille.uwo.ca
> > http://speech.braille.uwo.ca/mailman/listinfo/speakup
>
> --
>
> 				Janina Sajka, Director
> 				Technology Research and Development
> 				Governmental Relations Group
> 				American Foundation for the Blind (AFB)
>
> Email: janina@afb.net		Phone: (202) 408-8175
>
> _______________________________________________
> Speakup mailing list
> Speakup@braille.uwo.ca
> http://speech.braille.uwo.ca/mailman/listinfo/speakup
>

Re: redhat problems

[Janina Sajka]

Lorenzo Prince writes:
> 
> Not sure.  In my Slackware 9 kernel, ide-scsi is compiled into the kernel
> by default according to the .config file in the source tree.

And, according to the Configure.help file in /usr/src/linux/Documentation it can be compiled as a module.

Do you know when it's loaded?

> 
> Lorenzo
> 
> 
> E Pluribus Unix
> 
> Janina Sajka staggered into view and mumbled:
> 
> > Not so fast. Maybe you're correct, and maybe not. Are you familiar with the ide-scsi module? When does that one get loaded--if it's to be loaded?
> >
> > I cite ide-scsi as an example to you. Sayhing "later than the kernel" covers a lot of time, and pretty much the entire stack.
> >
> > Lorenzo Prince writes:
> > > From: Lorenzo Prince <lorenzo@princenet.sytes.net>
> > >
> > > Kernel modules are loaded later than the kernel itself.  Unless there is a
> > > buffer in the kernel to keep track of the console text before the module
> > > is loaded, it won't catch all the text from the beginning.
> > >
> > > Lorenzo
> > >
> > > E Pluribus Unix
> > >
> > > Janina Sajka staggered into view and mumbled:
> > >
> > > > Lorenzo Prince writes:
> > > > >
> > > > > ... A modularized speakup [...] would lack some of the things we
> > > > > have come to love about Speakup, such as being able to hear all the boot
> > > > > messages or to scroll back the console through them.
> > > >
> > > >
> > > > So says you. Do you know this for a fact, or are you supposing this? Care to explain?
> > > >
> > > >
> > > > You did state it as fact.
> > > >
> > > > 				Janina
> > > >
> > > >
> > > > _______________________________________________
> > > > Speakup mailing list
> > > > Speakup@braille.uwo.ca
> > > > http://speech.braille.uwo.ca/mailman/listinfo/speakup
> > > >
> > >
> > > _______________________________________________
> > > Speakup mailing list
> > > Speakup@braille.uwo.ca
> > > http://speech.braille.uwo.ca/mailman/listinfo/speakup
> >
> > --
> >
> > 				Janina Sajka, Director
> > 				Technology Research and Development
> > 				Governmental Relations Group
> > 				American Foundation for the Blind (AFB)
> >
> > Email: janina@afb.net		Phone: (202) 408-8175
> >
> > _______________________________________________
> > Speakup mailing list
> > Speakup@braille.uwo.ca
> > http://speech.braille.uwo.ca/mailman/listinfo/speakup
> >
> 
> _______________________________________________
> Speakup mailing list
> Speakup@braille.uwo.ca
> http://speech.braille.uwo.ca/mailman/listinfo/speakup

-- 
	
				Janina Sajka, Director
				Technology Research and Development
				Governmental Relations Group
				American Foundation for the Blind (AFB)

Email: janina@afb.net		Phone: (202) 408-8175

Re: redhat problems

[Lorenzo Prince]

I believe it is loaded after all the drives are detected and it knows
where the ide ports are and which one has the CDRW drive.  This can be
compiled as a module, but it isn't necessary to have it start immediately.
It can start at any time before the CDRW drive is used for writing.
Basically, my point was that a module has to be loaded either from a
script, from the command line, or in /etc/modules.conf using the module
loader.  Even if run from the /etc/rc.d/rc.S script, a module won't be
loaded before any text is printed to the screen.  This is why I thought,
in the case of a modularized speakup, that it would probably still be
necessary to patch the kernel itself to cause it to buffer console output
until the Speakup module is actually loaded, as someone mentioned in an
earlier post on this thread.

Lorenzo

A man said to the Universe: "Sir, I exist!"

"However," replied the Universe, "the fact has not created in me a
sense of obligation."
		-- Stephen Crane

Janina Sajka staggered into view and mumbled:

> Lorenzo Prince writes:
> >
> > Not sure.  In my Slackware 9 kernel, ide-scsi is compiled into the kernel
> > by default according to the .config file in the source tree.
>
> And, according to the Configure.help file in /usr/src/linux/Documentation it can be compiled as a module.
>
> Do you know when it's loaded?
>
> >
> > Lorenzo
> >
> >
> > E Pluribus Unix
> >
> > Janina Sajka staggered into view and mumbled:
> >
> > > Not so fast. Maybe you're correct, and maybe not. Are you familiar with the ide-scsi module? When does that one get loaded--if it's to be loaded?
> > >
> > > I cite ide-scsi as an example to you. Sayhing "later than the kernel" covers a lot of time, and pretty much the entire stack.
> > >
> > > Lorenzo Prince writes:
> > > > From: Lorenzo Prince <lorenzo@princenet.sytes.net>
> > > >
> > > > Kernel modules are loaded later than the kernel itself.  Unless there is a
> > > > buffer in the kernel to keep track of the console text before the module
> > > > is loaded, it won't catch all the text from the beginning.
> > > >
> > > > Lorenzo
> > > >
> > > > E Pluribus Unix
> > > >
> > > > Janina Sajka staggered into view and mumbled:
> > > >
> > > > > Lorenzo Prince writes:
> > > > > >
> > > > > > ... A modularized speakup [...] would lack some of the things we
> > > > > > have come to love about Speakup, such as being able to hear all the boot
> > > > > > messages or to scroll back the console through them.
> > > > >
> > > > >
> > > > > So says you. Do you know this for a fact, or are you supposing this? Care to explain?
> > > > >
> > > > >
> > > > > You did state it as fact.
> > > > >
> > > > > 				Janina
> > > > >
> > > > >
> > > > > _______________________________________________
> > > > > Speakup mailing list
> > > > > Speakup@braille.uwo.ca
> > > > > http://speech.braille.uwo.ca/mailman/listinfo/speakup
> > > > >
> > > >
> > > > _______________________________________________
> > > > Speakup mailing list
> > > > Speakup@braille.uwo.ca
> > > > http://speech.braille.uwo.ca/mailman/listinfo/speakup
> > >
> > > --
> > >
> > > 				Janina Sajka, Director
> > > 				Technology Research and Development
> > > 				Governmental Relations Group
> > > 				American Foundation for the Blind (AFB)
> > >
> > > Email: janina@afb.net		Phone: (202) 408-8175
> > >
> > > _______________________________________________
> > > Speakup mailing list
> > > Speakup@braille.uwo.ca
> > > http://speech.braille.uwo.ca/mailman/listinfo/speakup
> > >
> >
> > _______________________________________________
> > Speakup mailing list
> > Speakup@braille.uwo.ca
> > http://speech.braille.uwo.ca/mailman/listinfo/speakup
>
> --
>
> 				Janina Sajka, Director
> 				Technology Research and Development
> 				Governmental Relations Group
> 				American Foundation for the Blind (AFB)
>
> Email: janina@afb.net		Phone: (202) 408-8175
>
> _______________________________________________
> Speakup mailing list
> Speakup@braille.uwo.ca
> http://speech.braille.uwo.ca/mailman/listinfo/speakup
>

Re: redhat problems

[Nick Gawronski]

Hi, do you think that speakup will be in the next version of redhat?  
bye On Wed, 16 Apr 2003, Thomas D. Ward wrote:

> Hi, you must understand the removal of speakup was strictly technical by
> nature. Allot of the people on list are out to get Red Hat for pulling
> speakup when there are technical issues that need and should be resolved.
> One technical issue I agree with Red Hat on is a moduler version of speakup
> as rather than the current way speakup is compiled into the kernel direct.
> If I had the time and patients to do so I would do so myself, but it really
> is a big undertaking to modulerize speakup.
> 
> ----- Original Message -----
> From: Nick Gawronski <nick@nickgawronski.com>
> To: <speakup@braille.uwo.ca>
> Sent: Wednesday, April 16, 2003 5:25 PM
> Subject: redhat problems
> 
> 
> >       Hi, We must do something about all of these problems with redhat.
> > Think about it, rh8 had speakup and it was working just fine but look what
> > has happend rh9 is here and we don't have speakup yet the
> > readme-accessibility file is in 9 that says that redhat wants to make
> > their products accessible.  Well, I don't think that they are beeing very
> > nice about this at all.  If they removed speakup they should of removed
> > readme-accessbility as well.  We must contact redhat and find out "why did
> > you remove speakup yet leave readme-accessibility"  That is what we need
> > to do about this.  Who says they have a right to put speakup in one
> > version then take it away.  Think about this because we can make them put
> > it back in to their product.  bye
> >
> >
> > _______________________________________________
> > Speakup mailing list
> > Speakup@braille.uwo.ca
> > http://speech.braille.uwo.ca/mailman/listinfo/speakup
> 
> 
> _______________________________________________
> Speakup mailing list
> Speakup@braille.uwo.ca
> http://speech.braille.uwo.ca/mailman/listinfo/speakup
> 

Re: redhat problems

[Janina Sajka]

I expect Speakup in the next version, which should be out in about six months. The early beta versions should be out in about two to three months. I expect other,
accessibility-related applications will be added as well.

However, I have no special knowledge that this will be the case. This is just my opinion.

Nick Gawronski writes:
> From: Nick Gawronski <nick@nickgawronski.com>
> 
> Hi, do you think that speakup will be in the next version of redhat?  
> bye On Wed, 16 Apr 2003, Thomas D. Ward wrote:
> 
> > Hi, you must understand the removal of speakup was strictly technical by
> > nature. Allot of the people on list are out to get Red Hat for pulling
> > speakup when there are technical issues that need and should be resolved.
> > One technical issue I agree with Red Hat on is a moduler version of speakup
> > as rather than the current way speakup is compiled into the kernel direct.
> > If I had the time and patients to do so I would do so myself, but it really
> > is a big undertaking to modulerize speakup.
> > 
> > ----- Original Message -----
> > From: Nick Gawronski <nick@nickgawronski.com>
> > To: <speakup@braille.uwo.ca>
> > Sent: Wednesday, April 16, 2003 5:25 PM
> > Subject: redhat problems
> > 
> > 
> > >       Hi, We must do something about all of these problems with redhat.
> > > Think about it, rh8 had speakup and it was working just fine but look what
> > > has happend rh9 is here and we don't have speakup yet the
> > > readme-accessibility file is in 9 that says that redhat wants to make
> > > their products accessible.  Well, I don't think that they are beeing very
> > > nice about this at all.  If they removed speakup they should of removed
> > > readme-accessbility as well.  We must contact redhat and find out "why did
> > > you remove speakup yet leave readme-accessibility"  That is what we need
> > > to do about this.  Who says they have a right to put speakup in one
> > > version then take it away.  Think about this because we can make them put
> > > it back in to their product.  bye
> > >
> > >
> > > _______________________________________________
> > > Speakup mailing list
> > > Speakup@braille.uwo.ca
> > > http://speech.braille.uwo.ca/mailman/listinfo/speakup
> > 
> > 
> > _______________________________________________
> > Speakup mailing list
> > Speakup@braille.uwo.ca
> > http://speech.braille.uwo.ca/mailman/listinfo/speakup
> > 
> 
> 
> _______________________________________________
> Speakup mailing list
> Speakup@braille.uwo.ca
> http://speech.braille.uwo.ca/mailman/listinfo/speakup

-- 
	
				Janina Sajka, Director
				Technology Research and Development
				Governmental Relations Group
				American Foundation for the Blind (AFB)

Email: janina@afb.net		Phone: (202) 408-8175

Re: redhat problems

[Nick Gawronski]

Hi, Should I contact redhat with issues relating to putting speakup in 
the next version or who should I contact?  Also, Is there an email 
address for redhat or will I need to use the forms?  bye On Wed, 16 Apr 
2003, Janina Sajka wrote:

> I expect Speakup in the next version, which should be out in about six months. The early beta versions should be out in about two to three months. I expect other,
> accessibility-related applications will be added as well.
> 
> However, I have no special knowledge that this will be the case. This is just my opinion.
> 
> Nick Gawronski writes:
> > From: Nick Gawronski <nick@nickgawronski.com>
> > 
> > Hi, do you think that speakup will be in the next version of redhat?  
> > bye On Wed, 16 Apr 2003, Thomas D. Ward wrote:
> > 
> > > Hi, you must understand the removal of speakup was strictly technical by
> > > nature. Allot of the people on list are out to get Red Hat for pulling
> > > speakup when there are technical issues that need and should be resolved.
> > > One technical issue I agree with Red Hat on is a moduler version of speakup
> > > as rather than the current way speakup is compiled into the kernel direct.
> > > If I had the time and patients to do so I would do so myself, but it really
> > > is a big undertaking to modulerize speakup.
> > > 
> > > ----- Original Message -----
> > > From: Nick Gawronski <nick@nickgawronski.com>
> > > To: <speakup@braille.uwo.ca>
> > > Sent: Wednesday, April 16, 2003 5:25 PM
> > > Subject: redhat problems
> > > 
> > > 
> > > >       Hi, We must do something about all of these problems with redhat.
> > > > Think about it, rh8 had speakup and it was working just fine but look what
> > > > has happend rh9 is here and we don't have speakup yet the
> > > > readme-accessibility file is in 9 that says that redhat wants to make
> > > > their products accessible.  Well, I don't think that they are beeing very
> > > > nice about this at all.  If they removed speakup they should of removed
> > > > readme-accessbility as well.  We must contact redhat and find out "why did
> > > > you remove speakup yet leave readme-accessibility"  That is what we need
> > > > to do about this.  Who says they have a right to put speakup in one
> > > > version then take it away.  Think about this because we can make them put
> > > > it back in to their product.  bye
> > > >
> > > >
> > > > _______________________________________________
> > > > Speakup mailing list
> > > > Speakup@braille.uwo.ca
> > > > http://speech.braille.uwo.ca/mailman/listinfo/speakup
> > > 
> > > 
> > > _______________________________________________
> > > Speakup mailing list
> > > Speakup@braille.uwo.ca
> > > http://speech.braille.uwo.ca/mailman/listinfo/speakup
> > > 
> > 
> > 
> > _______________________________________________
> > Speakup mailing list
> > Speakup@braille.uwo.ca
> > http://speech.braille.uwo.ca/mailman/listinfo/speakup
> 
> 

Re: redhat problems

[Janina Sajka]

There's a link called "Contact Red Hat" near the bottom of the Red Hat Home Page at http://www.redhat.com. I'd just start there.

If I may offer a word of advice, ...

I'd keep my statements and questions personal. I think it's very powerful to talk about what Speakup, and having Speakup included in the Red Hat distribution means to
you, personally. It's OK to talk about what you dream about and what you intend to achieve, and how having Speakup inside the Red Hat distribution would help. It's OK
to talk about how not having it there makes things that much more dificult.

Ditto regarding the RCE. 

The reason that the personal approach is so powerful is that it's next to impossible for anyone to disagree with you. On the other hand, if you make assertions about
facts or laws, for example, you make it easier for them to just have a different viewpoint of the facts and the law. Their viewpoint, in other words, is as good as
yours. But, if you say, "this is what it means to me," they can't do that quite so easily.

Nick Gawronski writes:
> From: Nick Gawronski <nick@nickgawronski.com>
> 
> Hi, Should I contact redhat with issues relating to putting speakup in 
> the next version or who should I contact?  Also, Is there an email 
> address for redhat or will I need to use the forms?  bye On Wed, 16 Apr 
> 2003, Janina Sajka wrote:
> 
> > I expect Speakup in the next version, which should be out in about six months. The early beta versions should be out in about two to three months. I expect other,
> > accessibility-related applications will be added as well.
> > 
> > However, I have no special knowledge that this will be the case. This is just my opinion.
> > 
> > Nick Gawronski writes:
> > > From: Nick Gawronski <nick@nickgawronski.com>
> > > 
> > > Hi, do you think that speakup will be in the next version of redhat?  
> > > bye On Wed, 16 Apr 2003, Thomas D. Ward wrote:
> > > 
> > > > Hi, you must understand the removal of speakup was strictly technical by
> > > > nature. Allot of the people on list are out to get Red Hat for pulling
> > > > speakup when there are technical issues that need and should be resolved.
> > > > One technical issue I agree with Red Hat on is a moduler version of speakup
> > > > as rather than the current way speakup is compiled into the kernel direct.
> > > > If I had the time and patients to do so I would do so myself, but it really
> > > > is a big undertaking to modulerize speakup.
> > > > 
> > > > ----- Original Message -----
> > > > From: Nick Gawronski <nick@nickgawronski.com>
> > > > To: <speakup@braille.uwo.ca>
> > > > Sent: Wednesday, April 16, 2003 5:25 PM
> > > > Subject: redhat problems
> > > > 
> > > > 
> > > > >       Hi, We must do something about all of these problems with redhat.
> > > > > Think about it, rh8 had speakup and it was working just fine but look what
> > > > > has happend rh9 is here and we don't have speakup yet the
> > > > > readme-accessibility file is in 9 that says that redhat wants to make
> > > > > their products accessible.  Well, I don't think that they are beeing very
> > > > > nice about this at all.  If they removed speakup they should of removed
> > > > > readme-accessbility as well.  We must contact redhat and find out "why did
> > > > > you remove speakup yet leave readme-accessibility"  That is what we need
> > > > > to do about this.  Who says they have a right to put speakup in one
> > > > > version then take it away.  Think about this because we can make them put
> > > > > it back in to their product.  bye
> > > > >
> > > > >
> > > > > _______________________________________________
> > > > > Speakup mailing list
> > > > > Speakup@braille.uwo.ca
> > > > > http://speech.braille.uwo.ca/mailman/listinfo/speakup
> > > > 
> > > > 
> > > > _______________________________________________
> > > > Speakup mailing list
> > > > Speakup@braille.uwo.ca
> > > > http://speech.braille.uwo.ca/mailman/listinfo/speakup
> > > > 
> > > 
> > > 
> > > _______________________________________________
> > > Speakup mailing list
> > > Speakup@braille.uwo.ca
> > > http://speech.braille.uwo.ca/mailman/listinfo/speakup
> > 
> > 
> 
> 
> _______________________________________________
> Speakup mailing list
> Speakup@braille.uwo.ca
> http://speech.braille.uwo.ca/mailman/listinfo/speakup

-- 
	
				Janina Sajka, Director
				Technology Research and Development
				Governmental Relations Group
				American Foundation for the Blind (AFB)

Email: janina@afb.net		Phone: (202) 408-8175

Re: redhat problems

[Keith Watson]

God, not to piss off the pope or anything, but I think you two 
(or 3) should find a ring, gloves and audience elsewhere, cause I 
sure am tired of hearing the whining and bitching. Oh no now I 
bet I have pissed off the pope and I will sure to be flamed for 
it.

-- 
Keith Watson
kwatson@smed.yi.org

Among the major impediments to discovery are not the ignorant
but those with illusions of knowledge.    - B. Alan Wallace

Re: redhat problems

[William Loughborough]

At 09:25 PM 4/16/2003 -0400, Keith Watson wrote:
>I have pissed off the pope

Nope, you haven't pissed me off at all. I was declared a pope in paragraph 
12 of
http://rdfweb.org/people/danbri/2002/02/blindless/#ethical
and am not at all angry with you.

--
Love.

It's Bad Luck to be Superstitious! 

RE: redhat problems

[Whitley GS11 Cecil H]

>Is this turning into the redhat blindies list?
>Chris

Hmmmm, if this was a list discussing routers you wouldn't ask if it were a
cisco's blindy's list now would ya?  Ditto DVD's and Sony/phillips, ditto
processors and Intel....  I assume my point is made.  Whether anyone likes
it or not, RedHat is the top dog in Linux dists.  They ship more product
than the next three combined.  I'm not saying they are the best, I am also
not saying they are not the best, I am saying they have the most paying
customers for whatever that's worth.  They have spent the time and money and
they are a certified operating environment for DOD, point at "any" other
Linux dist that can claim that.

So why the discussion??  I seem to recall a quote from Jesse James
(attribution may be faulty)...  When asked why he robbed banks his reply was
because that's where the money is.  RedHat fits that bill, it's where the
money is.  

Cecil