On Sun, Sep 02, 2018 at 05:35:17PM +0200, David Runge wrote:
Well, I guess you should've started complaining about that many years ago then ;-)
Maybe I should have... But if the standard answer is 'you can always roll you own', then expressing any opinion or preference becomes sort of pointless.
a set of users with common needs. So *all* features or permissions that members of a group need should be made dependent on being a member of that group and nothing else. This is entirely the opposite of defining groups for one particular feature such as real time and then requiring users to be a member of all of them. I don't exactly understand your logic here: Members of the realtime group *share* the same common needs. They ought to be able to acquire realtime scheduling for their processes.
The logic is: for audio you need access to audio devices, be able to run real-time processes, and be able to lock memory. So create a group that has all these privileges. For any other type of activities do the same. It's just a different way of organising groups. Instead of having groups for each single particular privilege, and require users to be a member of a mix of them, define a single group which combines whatever is required for some type of activity. BTW, following what I assume is your logic, the 'realtime' group should be split in two, one for real time and one for memory locking.
So, I'm unsure, what you're actually complaining about here.
I'm not complaining. Just preferred the way it was done before (give the audio group whatever is needed for audio).
For what it's worth, I noticed that after upgrading to kernel 4.18 I had to increase the memlock limit to avoid error messages almost all audio applications. With what exact setup is that? Which components are involved? How do you configure your users and limits? Are you using the realtime-privileges group? Is your user in the realtime group?
Ask a specific question and we'll try to give a specific answer.
I didn't ask any questions, only reported that I noticed something related to memory locking had changed. Which seemed to be on-topic. But to answer your questions: * Archliux updated last two days ago. * Jack, all audio apps using Jack (most of them my own). * Using the 'audio' group, which has realtime and memlock entries in limits.conf. * No * No Greetings from sunny Crete, -- FA