speechd-discuss
[Top][All Lists]
Advanced

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

Considering ConsoleKit and GSettings/DConf


From: Bill Cox
Subject: Considering ConsoleKit and GSettings/DConf
Date: Thu, 12 Aug 2010 16:28:06 -0400

I'll just point out that in Vinux today, users have to edit three
entirely separate sets of speech-dispatcher configuration files:
/etc/speech-dispatcher controls the instance of speech-dispatcher used
with speakup.  /var/lib/gdm/.speech-dispatcher controls GDM's copy of
speech-dispatcher at the login window.  And users control their own
Gnome instance with ~/.speech-dispatcher.

On the Vinux lists, we often get three posts from each new user as
they try and get voxin to work with each of these systems, and it
confuses the heck out of them!  We're strongly considering writing a
simple python GUI app that lives on the desktop simply for the purpose
of installing and configuring voxin in all three locations.

So, I empathise with users who prefer the simplicity of global
pulseaudio and global speech-dipsatcher.  It's easy to configure, and
more reliable.  I feel like we haven't come up with the right solution
to the security issues of concern.

For example, rather than running speech-dispatcher and pulseaudio as
user, why not have both check permissions of the client now and then?
Both systems are perfectly capable of handling multiple users in
parallel, and running in user mode seems like a hack.  When things go
wrong, typically the user has every right to the sound card, but some
idle process has locked it up.  As a system-wide process, PA can mix
sound from both legal users, and the idle process has no negative
impact, and in fact sometimes positive, such as when users on the
console want to hear notifications in Gnome.  If the screen has been
locked, the rights manager should let PA and SD know that applications
in the Gnome session have lost rights to the sound card, and cork
them.  In the meantime, users on the consoles should be free to
continue without worrying about the gnome session.  I suspect the
reason for PulseAudio is that it required less work on their part to
simply run as a user process, and let the system deal with
permissions.  So, is all this pain about laziness?

Bill



reply via email to

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