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 -- fedora-devel-list mailing list fedora-devel-list@xxxxxxxxxx https://www.redhat.com/mailman/listinfo/fedora-devel-list
