speechd-discuss
[Top][All Lists]
Advanced

[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]

address@hidden: Re: Maintaining speechd-up]


From: Trevor Saunders
Subject: address@hidden: Re: Maintaining speechd-up]
Date: Mon, 19 Jul 2010 18:36:40 -0400

----- Forwarded message from Trevor Saunders <trev.saunders at gmail.com> -----

Date: Mon, 19 Jul 2010 17:17:26 -0400
From: Trevor Saunders <address@hidden>
To: address@hidden
To: Klaus Knopper <speechd at knopper.net>
Subject: Re: Maintaining speechd-up
User-Agent: Mutt/1.5.20 (2009-06-14)

HI,

On Tue, Jul 20, 2010 at 01:00:24AM +0200, Klaus Knopper wrote:
> On Mon, Jul 19, 2010 at 04:31:43PM -0400, Trevor Saunders wrote:
> > Hi,
> > 
> > Hopefully this is clearer.  I think you are confusing
> > 1. a console screen reader needs to run as root so it can read some
> > file
> > 2. a console screen reader needs to be root however it works.
> > 
> > you said that a console screen reader needs to run as root, which I
> > showed you by example is false.
> 
> True, it is possible to run a screenreader in userspace. But I would
> agree with Halim that it may be less comfortable and maybe even less
> secure in some ways.

are you talking about running as root or running in kernel mode like speakup 
does?

> Consider the mess of
> inter-screenreader-communication if you would like to chance the
> userspace screenreaders settings without restart on ALL consoles

 I feel like the *right* way to handle this would be to reload
configuration on some signal probably HUP.  WHich is perfectly secure.

> (volume, speed, profiles), cut&pase between screens,

Why should the screen reader be dealing with cut and paste? its a
screen reader not a general purpose utility.  Also note linux consoles
don't support this nativaly so why do you think its such a great idea?
If you really want it why not submit a kernel patch that adds this to
the kernel.  Personally I use screen and its copy and paste as well as
its other features.

 >and maybe also
> interface with different devices (braille, keyboard-navigation etc.). A
> common screenreader that handles all the locally used hardware is
> probably much less complex than a userspace program that needs to handle
> locking and task switching issues all on its own.

what? I'm confused by the task switching and locking what do you mean?

> Both methode have advantages and disadvantages. I can only say for SBL
> that it works well running as rooted system-wide service, and I did not
> find a security problem yet if it is correctly configured and its config
> files (and devices) have correct permissions. The system console and
> ttys do not need to be user-readable, yet they can be used with
> non-privileged user accounts (opened by init as root, then privileges
> dropped to the user application).

sure, I believe this is getty and login's job what does it have to do
with a screen reader?

Trev

> 
> Regards
> -Klaus

----- End forwarded message -----



reply via email to

[Prev in Thread] Current Thread [Next in Thread]