On 2018-09-02 21:52:33 (+0200), Fons Adriaensen wrote: > 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. I'm not sure that would be the standard answer. However, with free software you at least have that possibility! > > > 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. That's a valid point and could potentially be done in the future. The idea behind the realtime-privileges package is, that it can be reused (depended upon by other packages) or just used for non-single purposes (apart from audio). Additionally a decoupling from the audio group was sought after, because otherwise one instantly has a larger group of users with access to those permissions, only because they are in the audio group. Indeed a more granular approach to grouping! Thanks for explaining your reasoning. I now get what you meant! However, from a packaging standpoint, it makes more sense to have one package that offers functionality, than to redundantly package the same files in many packages (also makes it much faster to adapt them!). > > 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). I see. Sorry, if I misinterpreted that then. > > > 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. I see. The kernel 4.18 most likely doesn't have much to do with it though, but changes to the (now) gcr dependants [1], that you had installed before. As gcr is required by many packages it is entirely possible, that the limits file in question got installed when updating something, that now requires gcr. > 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 Hm, in this case you can only remove whatever requires gcr and gcr or edit its limits configuration (to keep using /etc/security/limits.conf directly) or start using dropin files below /etc/security/limits.d (which is recommended). Best, David [1] https://www.archlinux.org/packages/extra/x86_64/gcr/ -- https://sleepmap.de
Attachment:
signature.asc
Description: PGP signature
