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
