Creating a jackuser group

[Anthony Green]

On Thu, 2007-02-08 at 01:48 -0600, Callum Lerwick wrote:
> 
> So handing out RT privs has to be done very carefully.

I don't want to lose momentum on this issue...

IIRC...

a) There was an objection to using groups to manage RT privs.
b) There was an objection to forcing users to answer a question about RT
privs the first time they run qjackctl.
c) There was an objection about requiring RT privs to run jackd via
qjackctl.

So, one at a  time...

a) There was an objection to using groups to manage RT privs.

As Callum mentions above, I think we need to be careful about handing
out RT privs.  Not every user should have them.  Using groups to handle
this is standard practice in the Linux audio community, and I believe
it's the kind of thing that groups are intended to manage.
There was also one suggestion to name the group after the permissions
granted.  I don't think this is a workable solution.  Perhaps there's a
chance that pulseaudio and jackd permissions will be similar, but
real-time java users will want something very different.  I think we
should stick to workload-defined groups.  Whether or not some of these
groups end up in the base system or are managed in add-on packages is an
open question.

b) There was an objection to forcing users to answer a question about RT
privs the first time they run qjackctl.

I don't really see this as any different from forcing users to answer
questions when they first run evolution or the gimp.  We just need to
phrase the question is a user-friendly way.
 
c) There was an objection about requiring RT privs to run jackd via
qjackctl.

Fair enough.  This is a bug and I'll file it when I get online later
today (I'm on a plane right now).


Given all this, I would still like to move ahead with creating a
jackuser group in the base system and implement the qjackctl
question-asking code.  Are there still objections?


AG