Re: [PD] /etc/security/limits.conf WAS Re: Pd-0.39.2-extended-rc4 released on ubuntu
Sounds like a big buffer by default is the best option for the package. Maybe something like 50ms, that should be big enough to cover all but the really heinous hardware. Then docs about setting up for tight timing, limits.conf, -rt, etc. .hc On Jul 18, 2007, at 2:03 PM, Miller Puckette wrote: I think it's best to put this on the wiki as a possible tweak. There are too many 'reasonable' variations. For instance, on personal machines I use my own login name instead of a group 'audio' (for simplicity); also, I don't touch the 'nice' settings. I've never had stability problems with -rt and use it in all my routine work. My idea is to make my development environment exactly the same as the performance environment to reduce the chance of surprises. However, if you're in the habit of having Pd spawn sub-processes, -rt is dangerous. I'm not sure if renicing is safe or not; I never do it myself, preferring to count on the RTPRIO setting to take care of things. cheers Miller On Wed, Jul 18, 2007 at 06:52:11PM +0200, Frank Barknecht wrote: Hallo, hard off hat gesagt: // hard off wrote: The rlimits approach will soon be common knowledge among all Linux audio users anyway. Not everyone wants to learn about this stuff. Some people just want to install Ubuntu Studio and make music. hans, i am so much on your side here. ..although i'd say: 'some of us just want to install ubuntu studio, make massively complicated pd patches, and then make music.' Others want to make massive 36-channel recordings with Ardour, run 128-voice synthesiziers with SuperCollider, rock the party with Mixxx, play Csound5 in realtime, edit midi arrangements with MusE, run a live webradio stream with icecast2 while OTOH others want to harden their webserver with port-knock logins or set fierce limits for all users. Should all these packages fight for who should edit limits.conf and whose edits will finally survive? This is not about if users should learn how to edit limits.conf or not, this is about playing fair with other pieces of software installed in a distribution. If it was only about making editing limits.conf easier, here's a way: Just run this script as root/under sudo: #!/bin/sh if test -w /etc/security/limits.conf then read -p Update /etc/security/limits.conf? [yN]: DOIT if test $DOIT = y then echo @audio - nice -10 /etc/security/limits.conf echo @audio - rtprio 99 /etc/security/limits.conf echo @audio - memlock unlimited /etc/security/ limits.conf echo /etc/security/limits.conf updated successfully! echo You need to logout completely and login again to echo activate changes. echo Also make sure you're in group \audio\. else echo Okay, doing nothing fi else echo /etc/security/limits.conf not writable, giving up fi # EOF Ciao -- Frank Barknecht _ __footils.org_ __goto10.org__ ___ PD-list@iem.at mailing list UNSUBSCRIBE and account-management - http://lists.puredata.info/ listinfo/pd-list ___ PD-list@iem.at mailing list UNSUBSCRIBE and account-management - http://lists.puredata.info/ listinfo/pd-list You can't steal a gift. Bird gave the world his music, and if you can hear it, you can have it. - Dizzy Gillespie ___ PD-list@iem.at mailing list UNSUBSCRIBE and account-management - http://lists.puredata.info/listinfo/pd-list
Re: [PD] /etc/security/limits.conf WAS Re: Pd-0.39.2-extended-rc4 released on ubuntu
On Jul 14, 2007, at 2:16 PM, Frank Barknecht wrote: Hallo, Hans-Christoph Steiner hat gesagt: // Hans-Christoph Steiner wrote: Can anyone make a wiki page about this on http://puredata.org/docs ? It would be quite handy to have. Also, I'd love to hear suggestions how to make this part of the Pd- extended package. I think it makes a lot of sense to have this a debconf question. I suppose setuid could be a debconf question as well. I *really* don't think, that every audio software on the planet should try to setup a user's system for a certain way of realtime operation. If at all, this should be done only by the package libpam-modules or maybe by some meta-package (e.g. realtime-desktop) that the puredata package could recommend. I am interested in the result rather than how it is implemented. If that was a bad idea, are there any others? I think it is important that the Pd packages work well after installing without having to tweak it, including having glitch-free audio after installing. It works like this with many programs on Mac OS X, I think it should work the same on GNU/Linux. The rlimits approach will soon be common knowledge among all Linux audio users anyway. Not everyone wants to learn about this stuff. Some people just want to install Ubuntu Studio and make music. It would like to support that impulse. I think that is possible without restricting people from getting deeper. .hc Adding a note to /usr/share/doc/puredata/README.Debian would be something to consider, of course. Ciao -- Frank Barknecht _ __footils.org_ __goto10.org__ ___ PD-list@iem.at mailing list UNSUBSCRIBE and account-management - http://lists.puredata.info/ listinfo/pd-list Mistrust authority - promote decentralization. - the hacker ethic ___ PD-list@iem.at mailing list UNSUBSCRIBE and account-management - http://lists.puredata.info/listinfo/pd-list
Re: [PD] /etc/security/limits.conf WAS Re: Pd-0.39.2-extended-rc4 released on ubuntu
Hallo, Hans-Christoph Steiner hat gesagt: // Hans-Christoph Steiner wrote: I am interested in the result rather than how it is implemented. If that was a bad idea, are there any others? I think it is important that the Pd packages work well after installing without having to tweak it, including having glitch-free audio after installing. The issue is: Tweaking Pd is fine, but editing limits.conf is tweaking a very different part of the system. If I may exaggerate a teeny-tiny bit: I guess we would never consider to download, configure, compile and install a realtime-patched kernel while installing Pd, even though Pd would benefit from that. Regarding getting glitch-free operation in Pd for newbies: Just make a big buffer size the default, then nobody should get (too many) glitches even without realtime mode. As I wrote elsewhere, enabling -rt for Pd as default in my opinion is a bad idea, and without that startup setting, it doesn't matter at all what's in limits.conf. As I wrote there as well: Personally I never run -rt except in performances or rehearsals for performances. It works like this with many programs on Mac OS X, I think it should work the same on GNU/Linux. Things may have changed, but when I still had Windows, no audio application I installed has ever asked me if I would like to change the security settings of my system. Not everyone wants to learn about this stuff. Some people just want to install Ubuntu Studio and make music. It would like to support that impulse. I think that is possible without restricting people from getting deeper. By all I know, Ubuntustudio, Jacklab, Pure:Dyne and 64Studio already have limits.conf set up accordingly. Ciao -- Frank Barknecht _ __footils.org_ __goto10.org__ ___ PD-list@iem.at mailing list UNSUBSCRIBE and account-management - http://lists.puredata.info/listinfo/pd-list
Re: [PD] /etc/security/limits.conf WAS Re: Pd-0.39.2-extended-rc4 released on ubuntu
The rlimits approach will soon be common knowledge among all Linux audio users anyway. Not everyone wants to learn about this stuff. Some people just want to install Ubuntu Studio and make music. hans, i am so much on your side here. ..although i'd say: 'some of us just want to install ubuntu studio, make massively complicated pd patches, and then make music.' ___ PD-list@iem.at mailing list UNSUBSCRIBE and account-management - http://lists.puredata.info/listinfo/pd-list
Re: [PD] /etc/security/limits.conf WAS Re: Pd-0.39.2-extended-rc4 released on ubuntu
Hallo, Frank Barknecht hat gesagt: // Frank Barknecht wrote: By all I know, Ubuntustudio, Jacklab, Pure:Dyne and 64Studio already have limits.conf set up accordingly. Or actually: I didn't check, so maybe they haven't (except pure:dyne, which has), but it may be worth to take a look at how they do it, if they do it, and if they don't, maybe indeed suggest a meta-package that sets limits.conf. A puredata package as well as jackd, ardour etc. could then recommend this package. Just doing this for limits.conf would be trivial, but such a tweak-realtime package could also include some other stuff, like setting interrupts, checking for preempt in the kernel etc. But to reiterate: IMO this is not something a Pd package should even try to do itself, especially out of respect for the various distribution policies. Ciao -- Frank Barknecht _ __footils.org_ __goto10.org__ ___ PD-list@iem.at mailing list UNSUBSCRIBE and account-management - http://lists.puredata.info/listinfo/pd-list
Re: [PD] /etc/security/limits.conf WAS Re: Pd-0.39.2-extended-rc4 released on ubuntu
Hallo, hard off hat gesagt: // hard off wrote: The rlimits approach will soon be common knowledge among all Linux audio users anyway. Not everyone wants to learn about this stuff. Some people just want to install Ubuntu Studio and make music. hans, i am so much on your side here. ..although i'd say: 'some of us just want to install ubuntu studio, make massively complicated pd patches, and then make music.' Others want to make massive 36-channel recordings with Ardour, run 128-voice synthesiziers with SuperCollider, rock the party with Mixxx, play Csound5 in realtime, edit midi arrangements with MusE, run a live webradio stream with icecast2 while OTOH others want to harden their webserver with port-knock logins or set fierce limits for all users. Should all these packages fight for who should edit limits.conf and whose edits will finally survive? This is not about if users should learn how to edit limits.conf or not, this is about playing fair with other pieces of software installed in a distribution. If it was only about making editing limits.conf easier, here's a way: Just run this script as root/under sudo: #!/bin/sh if test -w /etc/security/limits.conf then read -p Update /etc/security/limits.conf? [yN]: DOIT if test $DOIT = y then echo @audio - nice -10 /etc/security/limits.conf echo @audio - rtprio 99 /etc/security/limits.conf echo @audio - memlock unlimited /etc/security/limits.conf echo /etc/security/limits.conf updated successfully! echo You need to logout completely and login again to echo activate changes. echo Also make sure you're in group \audio\. else echo Okay, doing nothing fi else echo /etc/security/limits.conf not writable, giving up fi # EOF Ciao -- Frank Barknecht _ __footils.org_ __goto10.org__ ___ PD-list@iem.at mailing list UNSUBSCRIBE and account-management - http://lists.puredata.info/listinfo/pd-list
Re: [PD] /etc/security/limits.conf WAS Re: Pd-0.39.2-extended-rc4 released on ubuntu
Hallo, Miller Puckette hat gesagt: // Miller Puckette wrote: I've never had stability problems with -rt and use it in all my routine work. My idea is to make my development environment exactly the same as the performance environment to reduce the chance of surprises. However, if you're in the habit of having Pd spawn sub-processes, -rt is dangerous. I'm not sure if renicing is safe or not; I never do it myself, preferring to count on the RTPRIO setting to take care of things. My main reason to not run -rt normally is to avoid the risk of getting into a lockup when I do something wrong in my patch. ;) A reason not to have it in .pdrc/.pdsettings is, that I often to run two Pds, one for Gem, one for audio. I prefer starting the audio Pd with -rt manually then, while the Gem-Pd won't run with -rt. (I also run two Pds, because Gem with Mesa-DRI drivers crashes Pd when closing the gemwin, and often even without closing. By running two Pds I only loose half of my work.) But anyway, I believe all this should be a choice of the user and not be predefined by the package. Ciao -- Frank Barknecht _ __footils.org_ __goto10.org__ ___ PD-list@iem.at mailing list UNSUBSCRIBE and account-management - http://lists.puredata.info/listinfo/pd-list
[PD] /etc/security/limits.conf WAS Re: Pd-0.39.2-extended-rc4 released on ubuntu
Can anyone make a wiki page about this on http://puredata.org/docs ? It would be quite handy to have. Also, I'd love to hear suggestions how to make this part of the Pd- extended package. I think it makes a lot of sense to have this a debconf question. I suppose setuid could be a debconf question as well. .hc On Jul 13, 2007, at 12:32 PM, Miller Puckette wrote: Aha, on the next boot it worked. Thanks! Miller On Fri, Jul 13, 2007 at 07:43:10AM +0200, Frank Barknecht wrote: Hallo, Miller Puckette hat gesagt: // Miller Puckette wrote: Pd does a seteuid(setuid()) to un-get root priveliges if run as setuid, after its priority gets promoted, so that it runs as the user who started it. But there are apparently loopholes, as Mathieu has found. I'm trying to repeat Frank's trick with /etc/security/ limits.conf, so far without success, but if that works it would be much preferable to making Pd setuid root. Here it works for several months at least: (~)-$ ls -l /usr/bin/pd -rwxr-xr-x 1 root root 809768 May 31 19:05 /usr/bin/pd (~)-$ /usr/bin/pd -rt priority 8 scheduling enabled. priority 6 scheduling enabled. Debian with libpam-modules 0.79-4. Ciao -- Frank Barknecht _ __footils.org_ __goto10.org__ ___ PD-list@iem.at mailing list UNSUBSCRIBE and account-management - http://lists.puredata.info/ listinfo/pd-list ___ PD-list@iem.at mailing list UNSUBSCRIBE and account-management - http://lists.puredata.info/ listinfo/pd-list [W]e have invented the technology to eliminate scarcity, but we are deliberately throwing it away to benefit those who profit from scarcity.-John Gilmore ___ PD-list@iem.at mailing list UNSUBSCRIBE and account-management - http://lists.puredata.info/listinfo/pd-list
Re: [PD] /etc/security/limits.conf WAS Re: Pd-0.39.2-extended-rc4 released on ubuntu
Hallo, Hans-Christoph Steiner hat gesagt: // Hans-Christoph Steiner wrote: Can anyone make a wiki page about this on http://puredata.org/docs ? It would be quite handy to have. Also, I'd love to hear suggestions how to make this part of the Pd- extended package. I think it makes a lot of sense to have this a debconf question. I suppose setuid could be a debconf question as well. I *really* don't think, that every audio software on the planet should try to setup a user's system for a certain way of realtime operation. If at all, this should be done only by the package libpam-modules or maybe by some meta-package (e.g. realtime-desktop) that the puredata package could recommend. The rlimits approach will soon be common knowledge among all Linux audio users anyway. Adding a note to /usr/share/doc/puredata/README.Debian would be something to consider, of course. Ciao -- Frank Barknecht _ __footils.org_ __goto10.org__ ___ PD-list@iem.at mailing list UNSUBSCRIBE and account-management - http://lists.puredata.info/listinfo/pd-list
Re: [PD] /etc/security/limits.conf WAS Re: Pd-0.39.2-extended-rc4 released on ubuntu
Frank Barknecht wrote: [...] its astonishing, how often we agree... mfga.sdr IOhannes ___ PD-list@iem.at mailing list UNSUBSCRIBE and account-management - http://lists.puredata.info/listinfo/pd-list
Re: [PD] /etc/security/limits.conf WAS Re: Pd-0.39.2-extended-rc4 released on ubuntu
On Jul 14, 2007, at 2:16 PM, Frank Barknecht wrote: Hallo, Hans-Christoph Steiner hat gesagt: // Hans-Christoph Steiner wrote: Can anyone make a wiki page about this on http://puredata.org/docs ? It would be quite handy to have. Also, I'd love to hear suggestions how to make this part of the Pd- extended package. I think it makes a lot of sense to have this a debconf question. I suppose setuid could be a debconf question as well. I *really* don't think, that every audio software on the planet should try to setup a user's system for a certain way of realtime operation. If at all, this should be done only by the package libpam-modules or maybe by some meta-package (e.g. realtime-desktop) that the puredata package could recommend. The rlimits approach will soon be common knowledge among all Linux audio users anyway. Adding a note to /usr/share/doc/puredata/README.Debian would be something to consider, of course. If someone writes that README, I'll happily add it to the package. I think that docs or packages/linux_make could work as a place in CVS for it. Ciao -- Frank Barknecht _ __footils.org_ __goto10.org__ ___ PD-list@iem.at mailing list UNSUBSCRIBE and account-management - http://lists.puredata.info/ listinfo/pd-list [W]e have invented the technology to eliminate scarcity, but we are deliberately throwing it away to benefit those who profit from scarcity.-John Gilmore ___ PD-list@iem.at mailing list UNSUBSCRIBE and account-management - http://lists.puredata.info/listinfo/pd-list
