On Fri, 19.06.09 20:32, Ralf Mardorf (ralf.mardorf(a)alice-dsl.net) wrote: This should have no such impact. The flag is only checked for on fork(), i.e. almost never. Lennart -- Lennart Poettering Red Hat, Inc. lennart [at] poettering [dot] net http://0pointer.net/lennart/ GnuPG 0x1A015CC4

On Fri, Jun 19, 2009 at 9:03 PM, Lennart Poettering<mzynq(a)0pointer.de> wrote: That's a fair point. Given history, I expect the last thing we want is to create an impression that providing good audio services in a distribution must be seriously detrimental to anyone's server workload. For my part, I have applications that use JACK if available, falling back first to PulseAudio's callback API and then to ALSA via PortAudio, using effectively the same callback code in each case. I'd be happy to add another couple of lines to improve the scheduling of my callback thread when using Pulse in a "desktop" context. A bit more code is no problem; there's already quite a lot of logic there: arguably too much, but I don't want to lose PortAudio because it provides portability, I don't want to lose the direct Pulse layer since it works best of the three for me in most desktop situations, and I don't want to lose JACK because, well, it's JACK. But I probably would mind having to explicitly include and link against DBUS libraries. I appreciate that my code is already using DBUS somewhere under the covers, but another explicit build dependency for two lines of code doesn't seem ideal. So a way to do this through the PulseAudio API would be very welcome to me. Chris

On Sat, 20.06.09 03:42, Lee Revell (rlrevell(a)joe-job.com) wrote: PA runs as user process. That's why this is needed. If a process is a user process the user can do with it whatever he wants, in the PA case this is even especially easy since all he needs to do is load some module he wrote into the daemon. We leave the RR interval at the default. I have some doubts that fiddling with the RR interval is a good idea. First of all the API to do that is messy and changed across kernel versions a few times. Secondly, rtkit is not really useful beyond desktop media stuff, and a desktop media application that wants to take a substantial CPU share while being RT (where the interval would matter) is uh, suspicious to say the least. The CPU time is limited by RLIMIT_RTTIME and also simply by the fact that on system overload (the definition of which can be configured in rtkit) the RT threads are demoted. I mean, if fiddling with the rr interval turns out to be necessary, we can still add an interfaces this. Dunno. I kinda have the idea that this is mostly a theoretical question anyway, since at least in the audio case in the usual case only one process is runnable anyway, ... If someone wants this, and has a good use case we can certainly add this, but I'd not think too much about stuff we don't need right now. To my knowledge while the process is waiting for IO to complete for the page fault other processes will be scheduled. The time spent in page faults is not counted as process time. Lennart -- Lennart Poettering Red Hat, Inc. lennart [at] poettering [dot] net http://0pointer.net/lennart/ GnuPG 0x1A015CC4

On Sun, 21.06.09 11:09, Paul Davis (paul(a)linuxaudiosystems.com) wrote: Simpler solutions? I am listening! What would a "simpler solution" be, that doesn't suffer by all the issues I pointed out in the README? Also, what's baroque with this? I mean, really, this offers an API of two tiny functions. Not sure why you'd call that baroque? Dunno. SCHED_ISO would certainly be nice, but having that wouldn't solve the problem really either. Also in the end you need to supervise RT processes anyway, which is heavily bound to admin policy and will hence probably always require some userspace part. And rtkit is just a tiny piece of software that only requires minimal additions to client code to be useful. So if one day it turns out it won't be necessary anymore then we can simply remove without much hassle. This doesn't have to be a solution for the eternity. Ah yeah? How so? What's complex? Adding a single #ifdef'ed fucntion call to your code? I mean, really, there's not much left that could be simpler than that. Uh? I see one function call for mach's setThreadToPriority vs. .... one function for pthread_setschedparam(). Uh? Where's the practical difference? So what? How does that matter? New features you only get with new code. And it's not that adding support for rtkit to some software would break anything that worked previously. RLIMIT_RTPRIO will still work just fine, if people set it. All rtkit is about is that we can enable RT scheduling for media applications out-of-the-box on newer Linux distributions. If 'out-of-the-box' doesn't matter to you then fine, I am pretty sure that distributors who ship your software do care about it. I am pretty sure that in Fedora we would simply patch jack_acquire_real_time_scheduling() to query rtkit if pthread_setschedparam() fails with EPERM. It's a tiny patch. However, I really don't see why you wouldn't want to merge a jack patch like that to jack's official sources as long as it is a compile-time option. I am pretty sure the distributors would be thankful for that. If people can make a good case for SCHED_FIFO, then fine, we can add that to rtkit. Personally, I believe that RR vs. FIFO is not so much a decision that the programmer should make. I think this is more a decision for the admin, because this influences fairness between consumers of RT. Uh. First of all, it's hard to find a POSIX system these days that doesn't have D-Bus installed. All big distributions ship it. All big desktop environments require it. Even non-Linux systems that are from the last 5 years ship it. To find a system that lacks D-Bus you need to go to niche distributions which are specifically designed to avoid sytems such as D-Bus. But I seriously doubt they really matter. D-Bus is simply an API for IPC, one that happens to have an adoption of 100% on relevant POSIX implementations. If you try to avoid D-Bus for IPC when coding for those systems then all you do is reinventing the wheel over and over, duplicating a substantial amount of code, and potentially buggy code. At this point in time it's not D-Bus that is bloat but it is the applications that still implement their own non-trivial IPC system that include unnecessary bloat. Finally, I believe your insisting on POSIX is a lost cause anyway, because it is a fictitious OS interface. It's a good guideline, but limiting yourself to it will limit the usefulness of your application drastically because you don't make use of a real operating system's feature set anymore, but to one that does only exist as an idea, as the least common denominator of a few OSes that are already quite aged these days. Also, at an ironic side note, your own jack_acquire_real_time_scheduling() implementation as one example is not even POSIX compliant. You print pthread_t as a %d. POSIX is pretty explicit that pthread_t does not have to be an int, not even an arithemtic type, but could be a struct. In summary: I am not asking you to adopt this replacing some of your current code. All I kindly ask for is to ease the distributors life by adding a tiny bit of fallback code that does a tiny call into rtkit in case sched_setschedparam() fails with EPERM and is #ifdef as __linux__ && HAVE_DBUS and is also contorollable as a compile-time configure option. Lennart -- Lennart Poettering Red Hat, Inc. lennart [at] poettering [dot] net http://0pointer.net/lennart/ GnuPG 0x1A015CC4

On Sun, 21.06.09 19:02, Paul Davis (paul(a)linuxaudiosystems.com) wrote: It's me who wrote the kernel patch actually. And after discussing my plans and the pros and cos with a few kernel/rt folks the patch went into Ingo's tree. The patch didn't come out of the blue sky and then Lennart came around and wrote rtkit using it. No. Instead I have been discussing the issue we fix with rtkit with a couple of people off and on for quite some time now. And a couple of weeks ago I decided to actually to do something about it and wrote this little patch accompanied by this little userspace support for it which is going by the name of rtkit. This is the patch btw: http://git.kernel.org/?p=linux/kernel/git/x86/linux-2.6-tip.git;a=commitdif… Have you actually read rtkit's README file? This goes a bit into details about the reasons to solve the issues this way. http://git.0pointer.de/?p=rtkit.git;a=blob;f=README No. I am not talking about *replacing*. I have asked for adding support for rtkit to it. The thing is that we cannot safely hand out RT privileges to user processes without doing acess/rate limiting, watchdog support, calls into policy systems and so on and so on. You are really misunderstanding the situation here. Firstly, *I* wrote the patch, and *I* was the one pushing this through. Secondly, this is not coming out of the blue sky, but this is the result of discussions with the RT folks, both inside RH and outside of RH. (which is partially documented in the acked-by/signed-off-by of the patch, just have a look!) Now, if you think you have a better insight into how things should be done than all of us, then hey, be my guest, why don't you make some *proper* suggestions how an alternative should be looking like? Asking for "creative use" and giving the fault to the distributors just doesn't cut it. The big problem with RLIMIT_RTPRIO is that it is vulnerable to a combined fork bomb/busy loop attack. Which I btw documented in the README (which I figure you didn't read?). Because that is the way it is, we, the distributors, never enabled RLIMIT_RTPRIO by default. What did happen is that some distros added an ugly unsecure kludge by adding "jackuser" group or suchlike that you can add a user to that had RLIMIT_RTPRIO set. But that's hardly a clean solution, and also leaves the "out-of-the-box" issue unresolved. The low-level sched_setschedparam() syscall is a basic primitive that can be used as building block for implementing RT in userspace. It does only minimal policy leaving all the rest for userspace, as it should be. Nothing in POSIX however says that this is the API that applications should rely on to use, behind which all security policy decisions are hidden. You seem to suggest that I wasn't talking to the kernel folks before I do something like this. That is wrong. This announcement of mine was just the last step in doing all this, not the first step. Yes, and there are good reasons for it (see above). Gah. This discussion is so pointless. If you don't want to use in Jack then fine. The distributions will ship the API and if you don't make use of it, so be it. It's certainly disappointing, but ultimately it's not my problem. No hard feelings, Lennart -- Lennart Poettering Red Hat, Inc. lennart [at] poettering [dot] net http://0pointer.net/lennart/ GnuPG 0x1A015CC4

On Sun, 21.06.09 21:16, Paul Davis (paul(a)linuxaudiosystems.com) wrote: What I am saying is that the current system is too "binary": Either you have RT sched and then for *everything*. Or you haven't, and then you haven't got it for *anything*. For the desktop case you need something in between: RT that cannot be misused, basically. Doing that securely is particularly hard, which is the reason why we still haven't got it. Only if this solution "in between" is found, we can enable RT by default for normal users. Now, a lot of suggestions have been made to fix this over the years. RLIMIT_RTPRIO, isochronous scheduling, using cgroups and so on. All of those solutions turned out to be suboptimal and never got adopted by the distros in a wide scale, or haven't even made into the kernel. Now, rtkit is another approach, a lot simpler, and something that was in the end implementable in just a few days of work, with only minor changes necessary on the kernel side. Something "good enough", to for being adopted for the next few years. Since it enforces all kinds of policy on its clients this little tool lives in userspace, so that the policy parameters don't have to be encoded in the kernel. Now, as mentioned rtkit might not be a solution for eternity. However it is a solution that should be good enough for quite some time. Maybe one day we get isochronous scheduling in the kernel with all the "adding up" issues fixed in a clean way. That day we can kill rtkit again from the distros. Should be easy enough given how minimal the interfacing between apps and rtkit actually is. I wasn't around at those discussions back then, and neither was I in the position I am in now. My views on that story is that back then RT for audio was only relevant for audio _production_, and the folks involved didn't see a problem with asking the user to become a member of some group. Nowadays, RT for audio is relevant for the normal desktop use case, too. And asking for group membership or some other way to bump RLIMIT_RTPRIO is very bad UI. Almost no user can make a properly informed decision before agreeing to that. So, the situation changed since then. What was a bit of a niche feature in those days is now something that should be exposed by default. And this asks for reinvestigating the whole story, and making RT less "binary", as mentioned above, and supervising its use. Back then desktop folks were not involved. polkit was not around and it was a bit of a nichey special-purpose feature. All that changed now. The kernel patch was discussed publicly on lkml. I discussed this on IRC with a couple of folks involved, whose OK I was looking for. Also, the kind of anti-desktop fud war that errupted as a result to this little announcement on lad is not really a convincing argument for always keeping all of LAD in the loop. Lennart -- Lennart Poettering Red Hat, Inc. lennart [at] poettering [dot] net http://0pointer.net/lennart/ GnuPG 0x1A015CC4

On Sun, 21.06.09 16:42, Fernando Lopez-Lezcano (nando(a)ccrma.Stanford.EDU) wrote: By default the watchdog will only become active after 10s of complete lockup. This should be enough. We can raise it if this turns out to be necessary, but let's wait for a request based on real-world data before we do something like that. Also note that in a case like yours admin and user are usually identically, so if you don't trust rtkit just bypass it and use RLIMIT_RTPRIO as it was done before rtkit came into the game. rtkit only comes into play as last resort when rt is cannot otherwise be required (at least if developers follow my recommendations from the README). If the supervised realtime sched that rtkit gives you isn't good enough, then simply give your application unsupervised RT by means of RLIMIT_RTPRIO or CAP_SYS_NICE or something suchlike. Lennart -- Lennart Poettering Red Hat, Inc. lennart [at] poettering [dot] net http://0pointer.net/lennart/ GnuPG 0x1A015CC4

On Mon, 22.06.09 23:19, Jörn Nettingsmeier (nettings(a)folkwang-hochschule.de) wrote: What is so difficult to understand that rtkit is not intended to be a solution for hardcore rt users? rtkit is not for you! Let me repeat this: RTKIT IS NOT FOR YOU! rtkit is a just missing piece of the puzzle that allows distros to enable RT by default for their desktop users. And rtkit doesn't break RLIMIT_PRIO, it isn't even activated when that is set. Let me repeat this, too: RTKIT DOESN'T BREAK RLIMIT_RTPRIO! It was clearly a bad idea to post about rtkit on lad. It is a big waste of time fighting this through against all those desktop-haters, fdo-haters, dbus-haters, who apparently believe I am out to take away their freedom to run their systems the way want. I really don't need this shit. The amount of constructive criticism in this thread is next to zero, nobody even bothers to read the README before just fudding around. Lennart -- Lennart Poettering Red Hat, Inc. lennart [at] poettering [dot] net http://0pointer.net/lennart/ GnuPG 0x1A015CC4

On Mon, 22.06.09 23:46, Jörn Nettingsmeier (nettings(a)folkwang-hochschule.de) wrote: That is simply bogus. With the reset-on-fork kernel patch in place you can perfectly supervise an RT process and it cannot evade you. If the system becomes unresponsive (which is all that we try to detect), then we can demote/kill everyone who's misbehaving. The worst thing that can happen is that we demote more processes than necessary. But so what? As long as the evildoer's process is demoted/killed you have a usable system again. Also, stuff such as RLIMIT_RTTIME (which we specifically check to be set in clients in rtkit) should make sure that the process cannot even misuse RT in the first place. Really, all this has been answered before. You can run around in circles if you like to, but this is where I get off. Lennart -- Lennart Poettering Red Hat, Inc. lennart [at] poettering [dot] net http://0pointer.net/lennart/ GnuPG 0x1A015CC4

On Tue, 2009-06-23 at 10:44 +0200, Jörn Nettingsmeier wrote: As far as I can tell any executable can get rt rights. It does not depend on having a list of trusted applications. I __think__ it goes like this - if this is wrong any gurus out there please correct me (and I'm also writing this to help myself understand the issues - it does not mean that I agree with everything :-): <in the kernel present> You need SCHED_FIFO/SCHED_RR to get your audio processing thread to be scheduled in time, but any program can wedge the machine by going into a tight loop without yielding the processor (deliberately or through a bug). So RLIMIT_RTTIME is introduced to limit the time a process/user/whatever (I don't know the details of how this works) can hog the cpu. So that the machine now does not wedge permanently, and at least other processes have a chance to run so that you/the system can kill the buggy program. <in the kernel future> A buggy or malicious program that is given rt scheduling can still fork processes very fast and DOS the computer anyway. So another kernel feature is added to prevent _that_ by making a process drop rt scheduling when it forks if the right option is selected (this is the new feature that will be part of 2.6.31). <but> Existing userland mechanisms that authorize non-root use of SCHED_FIFO| SCHED_RR don't/can't force use of RLIMIT_RTTIME or the new SCHED_OTHER on fork flag. So __something__ is needed on userland... (AFAIK nobody has written something addressing this before rtkit, I may be wrong about this...) <in userland> An additional way of granting rt access is needed that will at least give programs access to rt and at the same time force them to use the flags that make it less likely a user process can hang the machine. I think that is part of the goal of rtkit. It does that by honoring requests from any program that wants to go rt only if the request has an appropriate value for RLIMIT_RTTIME. And then rtkit grants the right but it additionally forces the SCHED_OTHER on fork flag on the process requesting rt. Still not enough of course [[not enough for a general purpose desktop that is _reasonably safe_ from hanging from either bugs in programs or malicious attacks]] But a process could fork processes that actually request rt and then DOS the computer in the same way as before... But then, as you have a single point of entry that intercepts requests to have rt scheduling you can deliberately throttle down buggy or malicious programs that would still hang the machine. This is necessarily heuristics driven (how many times per second, how many requests total, etc, etc). As it is heuristics then a sufficiently clever program might be able to get around that, I don't know. As a last resort a watchdog system is there to help. I think that's about it (at least what I can understand). As this is userland there is no silver bullet that will kill the problem for good. At least not one I can think of. And I can't think of anything in kernel land either that will get rid of the basic problem (but I have not thought very hard about either, I try and very soon it starts to hurt :-) I guess there would be many other ways of doing this in userland, but that would need somebody to go ahead and write them! In a desktop world, as a plain user, I would like to have a system where I can play sound without excessive latency and without clicks and be reasonably safe from buggy or malicious programs being able to crash my computer, and without having to configure things by hand to get that. That would seem to require both kernel and userland support. I would also like to be able to use whatever system is in place to be able to get Jack to work as designed, without whatever software is in place interfering with it. In the end both regular desktop apps and jack would work out of the box... -- Fernando

On Tue, 2009-06-23 at 13:12 -0400, Paul Davis wrote: yes, sorry, I was briefly swallowed into the rtkit-world :-) ... I don't know either, hopefully yes. This is what Lennart wrote in his original announcement: Do you have any idea what containers are? No clue here... It would seem to me that sched-rt-groups (with cgroup support) does address the problem, but differently. SCHED_RESET_ON_FORK would prevent the creation of a rt fork bomb, sched-rt-groups + cgroups would just contain it within the boundaries of the maximum rt time alloted to that group. All other issues remain the same (ie: what to do in userland when a process _is_ eating cpu like crazy). Right? Yes another issue that has not been raised or explained in the thread is: What is verified? User account? Other stuff? -- Fernando

On Tue, 2009-06-23 at 15:27 -0400, Paul Davis wrote: Not my reading of it. The default 100%/95% split will be allocated to root only (the only entity - this is not a group or a cgroup - that is there by default). My understanding is that non-root users will not be able to run realtime unless that is changed from the default (even if other mechanism allows them to run rt). I don't know how you enable the whole thing in the first place. The document provides two ways of reallocating realtime real state (configurable at build time), one by uid and the other by using cgroup's. So, yes, you apparently depend on cgroups to get the functionality. Merged != Beautiful :-) I did not want to comment on that part initially. He does not say "the API is not usable for the purpose at hand" but rather "it is horrible", which is a subjective thing. It may be horrible (and that is what it looks like from a brief look at Documentation/cgroups.txt - try it), but usable. Or may be horrible and not usable, we don't know. I don't know enough to comment on this. It could be a "not invented here" thing, or there could be sound technical reasons (the "non-obvious consequences" he does not dwell on or explain). Hmmm, did Lennart specifically answer the issue of the clone bomb? I can't remember and the thread is looong (I had a couple of points that I made that seemed to be valid and never got a confirmation reply)... If the clone bomb is still an issue then the whole SCHED_RESET_ON_FORK concept seems less than useful. Ingo was also involved so I imagine they thought about this thoroughly? On the other hand it would not be the first time Ingo just replaces a whole kernel subsystem from scratch (usually with a nice outcome :-) Argh. I should try to find the SCHED_RESET_ON_FORK thread(s) on lkml to see what was argued. Yes, it is debatable. I would put mechanisms for policy in the kernel and the policy itself in userspace. I don't know either. In either case the watchdog would probably be running with the highest rt priority so it should be scheduled in as fast in one as in the other. Probably faster when what needs to be killed is SCHED_OTHER. Looks to me like there are too many questions that only Lennart can answer. -- Fernando

[something appears to be wrong on the list, I'm not seeing your posts there, I'm just getting the emails directly addressed to me] On Tue, 2009-06-23 at 16:27 -0400, Paul Davis wrote: I think that means that if you create a new group (whatever that is - I'm not sure at this point) and do nothing, the member (whatever they are) will not be able to run rt. You have to first set the root group to something smaller and then allocate that to the new group. But is does not seem to be usable without them. But but.. but.... For example, in the kernel I'm running (2.6.29.5 + rt21): $ cat /proc/sys/kernel/sched_rt_period_us 1000000 $ cat /proc/sys/kernel/sched_rt_runtime_us 950000 So that part is there and configured. And: CONFIG_CGROUP_SCHED=y And furthermore: CONFIG_RT_GROUP_SCHED=y see here for an interesting entry: https://bugzilla.redhat.com/show_bug.cgi?id=442959 and http://bugzilla.kernel.org/show_bug.cgi?id=10361 (referenced inside the previous ticket) this is when it was apparently added to the Fedora kernels: -------- * Fri Apr 18 2008 Kyle McMartin &lt;kmcmartin(a)redhat.com&gt; - Enable CONFIG_RT_GROUP_SCHED (#442959) -------- There's something else I'm missing because I'm still able to run rt as a non-root user even though I have all this stuff. Is Fedora configuring this somewhere else? Is this overriden by something else? I think the idea is no control panel :-) If that is the case then I don't know what is the use of SCHED_RESET_ON_FORK. I am missing something. Is a clone something harder to do than a fork? It appears to be the same amount of programming effort. So, if SCHED_RESET_ON_FORK works on fork and not clone, and it is possible to make a clone bomb then SCHED_RESET_ON_FORK is worthless (IMHO), as a clone bomb's effect would be the same as the fork bomb's effect AFAICT and then why not deal with both using the same mechanism rather that _adding_ something to the kernel. I definitely _have_ to be missing something. Lock up a machine? As in hang it? I don't imagine it is _that_ easy. I guess you could use up all memory and eventually get the machine completely catatonic. And then the oom killer kicks in and something random that uses memory dies... Ah, yes. -- Fernando

On Tue, 2009-06-23 at 18:44 -0400, Paul Davis wrote: I have no idea yet. Or maybe there is some other configuration that needs to be done before it is activated. Or. Maybe it is not working at all and we are not getting rt, we have no error message and have not noticed it :-) ;-P I imagine configuring this so that all rt usage is in one bag if possible (both root and nonroot processes are counted in the same bin). There is no need in our usage case to differentiate, and in fact it is impossible. -- Fernando

On 06/26/2009 12:32 PM, Fernando Lopez-Lezcano wrote: Probably everyone's scared of making someone upset ;-) Actually I think the opposite is working this list has been very quiet for months now. This recent flare up was unusual... Patrick Shirkey Boost Hardware Ltd

On 06/24/2009 10:24 AM, Fernando Lopez-Lezcano wrote: It's not something that can be directly pinned on Lennart though. It's not exactly empowering to have to fight for every inch before the work is started. Maybe he wanted to conserve his mental energy for the actual code and save the fight for a time when he could handle the load... It's becoming a recurring theme round here, maybe it has always been this way? It seems to me that it's become more so in the past few years. Lest we recall the eruption over getting lv2 into reactor or whatever that app was. Maybe it's because we are all that much busier these days that it's harder to find the time to edit our responses? Patrick Shirkey Boost Hardware Ltd

On Wed, Jun 24, 2009 at 12:26 AM, Fernando Lopez-Lezcano&lt;nando(a)ccrma.stanford.edu&gt; wrote: For what it's worth, as someone who is not incredibly well-versed in kernel issues but is very interested in the topic at hand (configuring RT process priority), I was learning a hell of a lot from the discussion until he threw up his hands and said, to paraphrase, 'gah, you guys just don't understand me', and walked away. I really wish he hadn't. Even if some of what was said was verging on harsh, it was all valid criticism and I would have loved to have seen more of the concrete points go answered. From a user's point of view, or even a programmer's point of view, learning to use Linux's RT provisions properly is really not that obvious, for all the reasons mentioned in this thread. We were just getting to the point where people started summarizing and explaining things, when he disappeared from the conversation. (By the way, from where I am looking, this disappearance only emphasizes his attempt to drop a "solution" on the community and walk away---not very encouraging.) Honestly though considering that he seems to be a very well-experience free software programmer working for Red Hat, it's quite surprising to me how little he seemed to expect criticism and comments from the community that would be most interested in what he was announcing, and whom he knew had done lots of work on the exact topic previously. Did none of the issues brought up in this LAD thread ever appear in his discussions on LKML? Steve

On Tue, 2009-06-23 at 15:19 -0700, Fernando Lopez-Lezcano wrote: This is what I think is the relevant part of his answer: Hmmm, so fork bombs are more difficult (impossible?) to eradicate without the SCHED_RESET_ON_FORK patch), thread bombs are done with one kill one way or the other, would that be correct? And the watchdog deals with both. -- Fernando

On Tue, 2009-06-23 at 13:15 -0700, Fernando Lopez-Lezcano wrote: It looks like this is all I can find... not a lot of arguing: 2nd try: http://lkml.org/lkml/2009/5/29/57 3rd version: http://lkml.org/lkml/2009/6/15/318 4th try: http://lkml.org/lkml/2009/6/15/330 -- Fernando

On Mon, 22.06.09 18:00, drew Roberts (zotz(a)100jamz.com) wrote: Has been answered before. I want to make PA RT by default. PA is installed default on all big distros. Lennart -- Lennart Poettering Red Hat, Inc. lennart [at] poettering [dot] net http://0pointer.net/lennart/ GnuPG 0x1A015CC4

Hi, On Mon, 2009-06-22 at 15:08 -0700, Fernando Lopez-Lezcano wrote: Then the assumption is that an audio-playing process belongs to the top-priority processes which deserve the most computation time (on a typical desktop system). I wouldn't agree to that assumption. Sure I do have a media player running in the background and I don't want the playback to click or skip. The same goes for video watching and so on. But I might accept drop outs if the machine is under heavy load (like when compiling a large program, rendering a video, ...) and don't want the media player to consume all the computation power. But then latency is no issue either as a media player most often plays static files which can be read in advance to keep the buffers full. The same goes for web streams which need to be buffered anyway in order to compensate jitter and limited bandwidth. Typically between 1/3 and 1/5 second is responsive enough for most desktop applications and still makes for plenty audio buffers even under non-rt situations. So after reading all those messages I'm somewhat left up wondering if the addressed problem (real-time audio for desktop applications) really is an existing problem. The same goes for the theoretical threat of a rt-fork bomb. Just because in theory someone could write such a program and make it run on a someone else's machine doesn't seem like enough reasoning for implementing a protection mechanism on a large user base. In theory there are much more real threats for the average user which nobody cared to address. And it has been shown that in theory the suggested protection mechanism can be circumvented, too. BTW: I read the README file and don't see why it should be required reading for this thread. Lennart explained it much better through his mails than the README file (which contains two typos :-). Yours sincerely, Dennis Schulmeister PS: Sorry Fernando for first sending this directly to you. -- Dennis Schulmeister - Schifferstr. 1 - 76189 Karlsruhe - Germany Tel: +49 721/5978883 - Mob: +49 152/01994400 - eMail: dennis(a)windows3.de Now moved to the corridor: Hermes! (http://ncc-1701a.homelinux.net) Besides that: http://www.denchris.de - http://www.motagator.net/bands/65 <GnuPG KeyIDs: B8382C97, 01AD62DE>

On Tue, 2009-06-23 at 01:59 +0200, Lennart Poettering wrote: I'd be curious which difference it makes. Okay, that was inaccurate by me. But still audio performance has always been fine for typical desktop usage without rt privileges me thinks. Because the issue of latency is relative in that case. But maybe I'm missing an important point. Yours sincerely, Dennis Schulmeister -- Dennis Schulmeister - Schifferstr. 1 - 76189 Karlsruhe - Germany Tel: +49 721/5978883 - Mob: +49 152/01994400 - eMail: dennis(a)windows3.de Now moved to the corridor: Hermes! (http://ncc-1701a.homelinux.net) Besides that: http://www.denchris.de - http://www.motagator.net/bands/65 <GnuPG KeyIDs: B8382C97, 01AD62DE>

On Tue, 2009-06-23 at 03:54 +0200, Esben Stien wrote: & games... -- Fernando

Dennis Schulmeister &lt;linux-audio-dev(a)windows3.de&gt; writes: Well, 1 second is totally unacceptable on VoIP;). I don't use a headset and neither does the persons I talk to. The audio goes out my speakers and the remote persons speakers and if there were a 1 second delay, that would be pretty annoying trying to talk. ? Right, and like gaming with VoIP, coordinating the first strike team. -- Esben Stien is b0ef@e s a http://www. s t n m irc://irc. b - i . e/%23contact sip:b0ef@ e e jid:b0ef@ n n

On Mon, Jun 22, 2009 at 11:37:20PM +0200, Lennart Poettering wrote: Reading it does not imply agreeing with everything said there. If it makes your life easier: I *did* read it. Since you claim that all the *Kit stuff is optional, and you will still allow us to run our systems as we see fit, and since you wear a Red Hat, please tell me how to remove root 1830 1 0 Jun22 ? 00:00:00 /usr/sbin/console-kit-daemon permanently in FC10. It used to be a service but apparently isn't anymore. And while you're at it, and since I don't run gdm or gnome, same for: fons 2243 1 0 Jun22 ? 00:00:00 /usr/bin/gnome-keyring-daemon -d --login fons 2309 1 0 Jun22 ? 00:00:00 /usr/libexec/gvfsd fons 2346 1 0 Jun22 ? 00:00:00 /usr/libexec//gvfs-fuse-daemon /home/fons/.gvfs fons 2434 1 0 Jun22 ? 00:00:00 /usr/libexec/gconf-im-settings-daemon fons 2436 1 0 Jun22 ? 00:00:00 /usr/libexec/gconfd-2 fons 2516 1 0 Jun22 ? 00:00:00 /usr/libexec/gvfs-hal-volume-monitor fons 2518 1 0 Jun22 ? 00:00:00 /usr/libexec/gvfs-gphoto2-volume-monitor Once that is taken care of, I may start to believe what you say. Ciao, -- FA Io lo dico sempre: l'Italia è troppo stretta e lunga.

On Tue, Jun 23, 2009 at 12:49:40AM +0200, Lennart Poettering wrote: Actually F8 would be enough. ConsoleKit was a service there and I just disabled it without any ill effect. In F10 that choice has been removed, and I predict that whatever you wirte today, the same will happen with your RealtimeKit. Today you claim it's optional, 'if it's not for you then don't use it', etc. etc. Maybe it will be optional in F12. But based on previous experience I'm pretty sure things won't stay like that. By the time we are at F13 or 14, if someone asks you how to disable RealtimeKit, your answer will be similar to the one you gave above: 'downgrade to F10 or use a distro that better suits your needs, nobody is forcing you use Fedora, etc.' Indeed, nobody is forcing me to use Fedora. But it is the base of one of the best specialised audio distros, CCRMA. Maybe you don't care about that, then just say so. Ciao, -- FA Io lo dico sempre: l'Italia è troppo stretta e lunga.

Well, I think this is fundamentally a good idea. I just thought someone ought to say that. I quite understand the frustration Paul expresses about the existing methods of doing this never having being fully exploited, but I can see why this has happened. It's still simple enough to put your user or group name into limits.conf and get "proper" scheduling if you care enough; meanwhile, I think there's something reassuring about the provision of a fallback way of getting "good enough for the rest of us" scheduling without too much danger of rogue applications melting the naive user's computer. Since I like to think of much of my software as being of use by random persons who have a passing interest in music and audio, I think this could be a very good thing. I had a few questions and still have some concerns about the implementation, but actually I'm even coming around to the idea of dumping in a couple of DBUS calls into my application code rather than using a library -- it has the advantage that I can do it right now (or whenever I get around to it) without having to worry about distro or library support, since nothing is lost if the service isn't available. And since I probably only want it for the Pulse driver, that makes it slightly less onerous to demand the extra dependency on DBUS, since I know that any system with PulseAudio will have the DBUS libraries. Altogether, though it doesn't feel like the most elegant solution to the problem (shunting the whole problem off to the audio layer would be preferable), it could work out quite nicely. Chris

On Tue, Jun 23, 2009 at 1:03 PM, Fons Adriaensen&lt;fons(a)kokkinizita.net&gt; wrote: There certainly do seem to be a lot of new Kits on the block. ps -ef? Well, there's your problem right there. Shoulda been using BSD... Chris

On Tuesday 23 June 2009, Bob Ham wrote: +10,000 PA is one of the biggest screwups ever, but red hat can't see it. -- Cheers, Gene "There are four boxes to be used in defense of liberty: soap, ballot, jury, and ammo. Please use in that order." -Ed Howdershelt (Author) The NRA is offering FREE Associate memberships to anyone who wants them. <https://www.nrahq.org/nrabonus/accept-membership.asp> "In short, _N is Richardian if, and only if, _N is not Richardian."

On Tuesday 23 June 2009, Ivica Ico Bukvic wrote: Oh it works fine on my lappy, IF you don't mind the audio being 3 words behind the lips making the noise when watching a news clip from cnn/fgox/abc/nbc/whoever. I had to get rid of it to even get ANY sound on my main machine, which has at least 3 audio systems in it, I simply could not convince it that the default card to output to was the audigy2 (SBO400) card. The ASUS mobo audio just doesn't cut it, and AFAICT, the 'hda' audio on my HD-2400 Pro video card is not even bonded out. PA probably works reasonably well for those who want to tinker with it for each audio generating app they run. But put it into a multichannel/multicard environment and it craps its pants. Me, I just wanna see & hear the news from the tv peoples web sites like cnn etc. Or play some music I ripped from my own CD's. For that, PA fails. -- Cheers, Gene "There are four boxes to be used in defense of liberty: soap, ballot, jury, and ammo. Please use in that order." -Ed Howdershelt (Author) The NRA is offering FREE Associate memberships to anyone who wants them. <https://www.nrahq.org/nrabonus/accept-membership.asp> The longer the title, the less important the job.

On 06/24/2009 12:50 AM, Chris Cannam wrote: I have been experimenting with PA for the past two years since Fedora 7 and have found that the latest release with fedora 11 is definitely the most stable and user friendly so far. I encourage anyone who has had bad experiences to upgrade to 0.15 to see the improvements. I am very happy with the experience from a desktop applications and normal user pov. I think that Lennart has heard the call for a more user friendly way to disable it. For most users it wouldn't require more than adding a simple button to the control panel to disable it at boot. However for users who don't want to be tied to dbus there is a bigger problem. I agree that it goes against the unix paradigm to insist on desktop deps for non desktop systems. Perhaps this will be solved in the future if enough people resist the current wave of enforced dbus integration? -- Patrick Shirkey Boost Hardware Ltd

Le 23 juin 09 à 17:04, Paul Davis a écrit : I would certainly help if we can keep the discussion on "technical issues" a bit more, since I don't think the subject is completely closed yet... (like the issue with sched-rt-group thing for instance... http://ww2.cs.fsu.edu/~rosentha/linux/2.6.26.5/docs/scheduler/sched-rt-grou…) Stephane

On Mon, Jun 22, 2009 at 09:24:24AM +0100, Bob Ham wrote: There is a lot wrong here. * Question: is the 'demoting' of RT-threads applied only to RT threads granted by this daeomon, or does it apply to all, including those created by processes running as root ? In the latter case this system is not only broken, but should be classified as malware. * Why should an app running on an headless system at RL3 be forced to go through a collection of desktop-oriented daemons in order to do something that amounts to a simple POSIX system call ? * Claiming that 'group based security is broken' is not only a show of ignorance, but also of arrogance. All UNIX sysadmins of the last 30 years must have been idiots. * I don't run a 'desktop' on any machine, nor do I want one. The thing I'm looking at is a computer screen, and that's it. I want to remain the master of my system, whatever I do is by definition to be trusted. This includes running RT threads that may block the machine. I'm not married into the Kit family, and the last thing I want is this collection of mothers-in-law interfering with my system. If the the desktop kids want this sort of thing that's fine. Let them build it into their desktops, but keep it out of the operating system. * All this talk from the freedesktop crowd about 'security' is as misleading as it can be, *All* security violations I've seeen lately on any of my systems were generated by these desktop madness. This includes: - Gdm making unauthorised network connections (disable DNS and see it hang for two minutes). - Login manangers changing device permissions. - Gnome automounting removable disks that don't have the 'user' flags set in /etc/fstab. - Digital camera software making unauthorised copies of pictures to the local hard disk. And more. This is 'big brother' security - basically it means: 'trust us, we want the best for you, and are trying to make your life easy'. * If this trend continues then within a year or two there will some 'FilesystemKit' that requires the OK from freedesktop.org each time you open a file. And no doubt also a 'DecencyKit' checking the color of your underwear. * It is IHMO high time to start the development of a kernel patch that removes all of this, and provides a clean POSIX system to those who want it. Ciao, -- FA Io lo dico sempre: l'Italia è troppo stretta e lunga.

On Mon, 22.06.09 15:05, Fons Adriaensen (fons(a)kokkinizita.net) wrote: Is that so? It can do both. resetting all is the default. It shouldn't. Quoting myself from the announcement: "If you don't do RT development or doing RT development only for embedded cases, ... then it doesn't mean anything for you." rtkit is only relevant for the desktop. end of story. A "collection of desktop-oriented daemons"? Do I smell D-Bus fud again? This is getting so old. And stays so wrong. D-Bus is deeply rooted in system now, even the init system speaks it now. Get over it already. Oh my. Just because someone mentions that UNIX has issues you don't have to call him "ignorant" and "arrogant". Also, it's not me who declared that UNIX groups are broken. That's a fight others have sucessfully fought through the distros already. PolicyKit entered all major distributions. If you think that UNIX is the only true verity and think that pk is an abomination then bring that up with the pk guys, not with me. Then don't do it. You are clearly not the intended audience of rtkit then. Have you actually read my announcement mail? This stuff is only useful for out-of-the-box RT support on major distributions. If you roll everything your own, because that makes you happy, then ignore rtkit. Also, rtkit is just an offer. No need to adopt it if you think it is an abomination. But if you do care that your software performs well out-of-the-box on newer distros then think about it. The API is there, you just make use of it. Yes, we hate security. And it is our declared objective to make your life miserable. Surprised? Didn't you know, it's world domination we are going for! We want to control your computer and then you, muhahaha. And we take away your freedoms. And creating a working desktop is just our cover for this. Muahahahaah! Muahahahahaahahaaaa! Yes, do it! Not sure what exactly you want to patch out. But please do it! Lennart -- Lennart Poettering Red Hat, Inc. lennart [at] poettering [dot] net http://0pointer.net/lennart/ GnuPG 0x1A015CC4

On Mon, 22.06.09 10:08, Paul Davis (paul(a)linuxaudiosystems.com) wrote: What exactly are you asking for as "user-space infrastructure"? Some easy to reach UI that will allow you to make yourself a member of some group? This is unlikely to happen. At least not from the desktop camp. I mean, rtkit is user-space infrastructure, so what are you asking for that isn't covered by rtkit? Yes. I guess you can say that. Although I wouldn't call it a "mistake". RLIMIT_RTPRIO was added with audio production in mind. While I think even then it sucks UI-wise, it certainly was good enough and better than anything there was before. However, as soon as we want to make RT available out-of-the-box RLIMIT_RTPRIO just doesn't cut it. Lennart -- Lennart Poettering Red Hat, Inc. lennart [at] poettering [dot] net http://0pointer.net/lennart/ GnuPG 0x1A015CC4

On Mon, 22.06.09 11:53, Paul Davis (paul(a)linuxaudiosystems.com) wrote: This is really the wrong approach. And no other OS does it. Really, how would you find it if you install Fedora and one of the questions during installation is whether you want to bump RLIMIT_RTPRIO for your user, or not? Which user understands what "realtime" means anyway? My mom certainly doesn't. Sometimes, there is a bit of disconnect between what kernel folks think is a good idea and what userspace folks think is one. [Which (hint hint!) is precisely the reason why plumbers conf is so important as an attempt to bridge that gap!] Back then audio and embedded realtime folks had a stake in the outcome. Desktop folks did not, but apparently were expected to add the "simple" UI for that? I mean, complaining that I now mostly kept lad out of the loop is not entirely fair if back then you kept desktop folks out of the loop... (As a side note: capabilities are still there and doing better than ever.) I am arguing that if you have that flag you can set it when handing out rt sched to other processes in a supervised fashion and be sure that the process cannot escape your supervision. As mentioned rtkit implements a watchdog, too. A watchdog however is an a-posteriori solution to the problem. I.e. when things already wrong it can be used to fix things up again. rtkit otoh tries to focus on a-priori solutions, making sure that users cannot misuse RT in the first place. Please, please with cream on top, read rtkit's README: http://git.0pointer.de/?p=rtkit.git;a=blob;f=README Starting at line 39 is the part about watchdogs. It also roughly explains the problems with the various other approaches that were tried before. Because it fixes the problem that is "escaping supervision". Without the patch a process can easily escape supervision or at least play race games with the supervisor. rtkit is the supervisor. I have now changed rtkit to make the policy configurable system wide. I believe the sched policy should be a choice for the admin, not the developer, as it controls fairness of different RT software to each other. And again, as I already offered: if someone offers a good real-world case then we can make the sched policy controllable from the client side, too, and even the RR qantum, if that's really needed. However, unless anyone makes a good case how this matters for desktop applicatios I'd like to start small. Lennart -- Lennart Poettering Red Hat, Inc. lennart [at] poettering [dot] net http://0pointer.net/lennart/ GnuPG 0x1A015CC4

On Mon, 22.06.09 16:34, Fons Adriaensen (fons(a)kokkinizita.net) wrote: rtkit is just one little bus-activated service. Not sure where you see a "collection of daemons". But group-bases access *is* broken. I mean, I am sorry if that hurts your feelings, but uh, it's just the way it is. FUD, FUD. FUD. FUD. FUD. FUD. FUD. And FUD. KDE adopted it too. And quite a few system daemons too. Lennart -- Lennart Poettering Red Hat, Inc. lennart [at] poettering [dot] net http://0pointer.net/lennart/ GnuPG 0x1A015CC4

Fons Adriaensen wrote: You're not ignoring it, you're practically waging the war against it, effectively trying to make life more miserable for the desktop users (yes, like me for example). Why? The existence of rtkit doesn't make it harder for you to assign RT privileges to every process on the machine. However, it makes it possible to prevent rogue processes from obtaining/abusing the RT scheduling while letting user-approved processes to still use it. In some contexts, asking the users to give up every single application a dangerous permission just to let them run your application, is a bad idea (it makes any other application in the system capable of locking up the PC without the chance of preventing it). Okay, it uses a commonly available message passing infrastructure (D-Bus) instead of reinventing the wheel. So what? Is one way of sending messages to other processes somehow bad because it's an Evil Baby-Eating D-Bus? POSIX is Good, FreeDesktop is Evil, since when? What's the reasoning behind THAT? Krzysztof

Fons Adriaensen wrote: Your point being? "When was the last time you've seen a Microsoft Word virus? Why did you open it?" was probably some Microsoft manager's thinking more than decade ago. With the increasing number of Linux-based systems sold to novice users, you're sure nobody will ever use RT API to do something nasty? Basically, Lennart pointed out a potential security hole and shown a way to fix it. The fact that it's not abused yet (mostly due to lack of popularity of RT kernels) doesn't mean it won't be abused ever. Especially if things like pulseaudio and games will making use of RT privileges. Krzysztof

On Mon, Jun 22, 2009 at 05:58:41PM +0100, Krzysztof Foltman wrote: My point being that if you use that word you'd better know what it means. It fixes nothing at all. It just makes a system fail in a different way which IMHO is not better but rather worse than the original one. Ciao, -- FA Io lo dico sempre: l'Italia è troppo stretta e lunga.

On Mon, 22.06.09 11:15, Fernando Lopez-Lezcano (nando(a)ccrma.Stanford.EDU) wrote: rtkit doesn't need to be the exclusive consumer of the kernel RT interfaces. RLIMIT_RTPRIO is another supported mechanism that continues to work. Even if some folks seem to believe it, I am not replacing anything existing, shoving down their throats something they didn't need before. All I do is adding something new, that helps a few desktopish cases and can be integrated into various applications very easily and with only minimal impact on dependencies, and is only used as fallback if nothing else is configured. Really, I am doing my best to ease adoptions for those interested. By default it only ever looks at non-root processes. Lennart -- Lennart Poettering Red Hat, Inc. lennart [at] poettering [dot] net http://0pointer.net/lennart/ GnuPG 0x1A015CC4

On Mon, 22.06.09 12:51, Fernando Lopez-Lezcano (nando(a)ccrma.Stanford.EDU) wrote: rtkit is bus activated. It's only active when it is used. The distinction between demoting all and demoting only the 'known' processes is hence mostly theoretical. I picked "demoting all" as the default since it 'felt' more secure. Dunno. If someone can offer me real-world case where this distinction really matters, I am all ears. Otherwise I'd got for the safe default for now. For RLIMIT_RTPRIO nothing changes. It wasn't enabled by default in the big distros and it wont be enabled in the future either. Lennart -- Lennart Poettering Red Hat, Inc. lennart [at] poettering [dot] net http://0pointer.net/lennart/ GnuPG 0x1A015CC4

On Mon, 2009-06-22 at 14:18 -0700, Fernando Lopez-Lezcano wrote: I think I may be misunderstanding something. Or I'm just SSSLLLLOOOOWWWW... You wrote yesterday: If rtkit would demote all processes when triggered, regardless of whether rtkit granted the privileges or not then I can't really bypass it, it is always there defining policy. -- Fernando

On Tue, 2009-06-23 at 01:53 +0200, Lennart Poettering wrote: Sorry to be a pest, if only _one_ app requests through rtkit then all bets are off until a logout/login sequence, right? I happen to think it is the wrong thing to do in general: you are essentially forcing policy for something you don't have complete control over, so that it may overlap or override with what other methods want. It is probably going to create problems in the long run, but that is a very non-scientific thing to say. (BTW, I still have to try to figure out if jack support is possible - don't know when I'm going to have time - jack bestows rt on threads that the client programs use, but not through a fork) -- Fernando

On Sun, Jun 21, 2009 at 4:09 PM, Paul Davis&lt;paul(a)linuxaudiosystems.com&gt; wrote: Well, my comment (from the point of view of applications rather than library development) was not so much about portability as simple convenience. Regardless of which method is ultimately used to establish proper audio scheduling, it would be nice to be able to handle it through the same audio API as I am already using. PortAudio and JACK APIs both contain some support for this, PulseAudio is the odd one out for me. Chris

On Tue, Jun 23, 2009 at 2:33 PM, Patrick Shirkey&lt;pshirkey(a)boosthardware.com&gt; wrote: Patrick, the point is well made. The decision's already been taken, excluding the wider linuxaudio community, and no amount of enthusiastic input here will make any difference to Lennert's intent, or anyone else involved in this project. Seems we got the short straw. Again. A real shame. Alex -- www.openoctave.org midi-subscribe(a)openoctave.org development-subscribe(a)openoctave.org

Patrick Shirkey wrote: I hope so. As I read this thread I'm further convinced that the requirements for normal desktop audio and pro-audio are dissimilar enough to demand very close inspection of any system sound component added to a distribution or even to the kernel itself, especially any component with the capability of wrecking the low-latency soft realtime performance we've become accustomed to for serious recording on Linux. I do not say that PulseAudio is a culprit here, I'm only emphasizing the need for healthy vigilance regarding additions that have implication for the existing working systems for serious recordists (i.e. JACK and ALSA). Ah, cat-herding. I agree with you, Patrick, I'm just not sure how easily it'll get done, if at all. Do they need integrated at all ? I'm currently writing an article that asks that question (among others re: the default Linux sound server). Frankly, I stand on the side of those users who want *nothing* between JACK and ALSA, so whatever solution finally presents itself, for me it must include the provision for completely eliminating it, with no ill effects upon the rest of the non-audio parts of the system. However, I also recognize the need for a solution a la PulseAudio for the normal user. I'm becoming further convinced that serious Linux audio production is simply not going to be an out-of-the-box experience for users, that it will always require intervention on the user's part, and that that intervention will discourage some (many?) users from trying a Linux system for creative audio work. We represent a very thin slice of the Linux user pie, and our concerns don't appear to be priority concerns for mainstream distro maintainers. And maybe that's not a bad thing. Ah, but what does PulseAudio have to contend with ? Where is its opposition ? Is there any other serious contender for the crown of the default Linux sound server ? Lennart seems happiest about PulseAudio's wide acceptance, which is fine, and I am glad to see him here trying to make the system work to everyone's satisfaction. It remains to see whether that's possible, but as long as PulseAudio can be easily and fully removed, uninstalled, or toggled off, without damage or hindrance to the rest of the system then I'm not sure if a real problem exists. *How* PulseAudio can be removed etc is perhaps a problem best resolved by the distro maintainers. Perhaps we should require that the kernel developers and mainstream distribution maintainers all run Ardour for three weeks and attempt at least two multitrack/multichannel recordings. At least by then they'd maybe have a better notion of what defines a system for serious recording. ;) For my purposes the entire discussion boils down to this: Will PulseAudio negatively impact the excellent performance offered by 64 Studio, Planet CCRMA, JAD, or any other audio-optimized distribution ? It appears that Lennart wants to make PulseAudio as transparent as possible to the end user, but when I need to see it, I want to see it all and I want to be able to control it completely, right down to eliminating any trace of it, if that's what I desire. Again I say, I have nothing against PulseAudio. I simply want a guarantee that its existence does not threaten the continued excellent performance I've come to expect from the kernels prepared for the audio-optimized distributions. If that scenario can be warrantied then I'm a happy camper. Okay, I've rambled enough. Better minds are making better points, but I wanted to add my POV. Btw, I won't pretend to have followed this discussion in all its technicalities, but as a user the topic is a priority interest. Best, dp

Fernando Lopez-Lezcano wrote: I understand this part. But this part: is what I'm trying to get a handle on. At this point I'm all in favor of PA as an attempt to resolve the problems of normal desktop audio. However, I haven't had such a great experience with it in recent versions of Ubuntu (I know, I know...) but I'm hoping to get "unsoured" about those experiences. The possibility of out-of-the-box low-latency realtime JACK-enabled performance would be nice to have in mainstream Linux distributions. Best, dp

Patrick Shirkey wrote: Yes, also, Palm Pre doesn't ship with pre-installed Ardour, Aeolus, Hydrogen or Csound. I really don't see why! /s Krzysztof

On Tue, 2009-06-23 at 12:19 +0100, Krzysztof Foltman wrote: Really? No Ardour on the Palm Pre? Now, thank you! I can just cancel my order and stick with the Treo which still is a single-tasking system. I mean: Hey, Ardour doesn't run on either device. Yours sincerely, Dennis Schulmeister -- Dennis Schulmeister - Schifferstr. 1 - 76189 Karlsruhe - Germany Tel: +49 721/5978883 - Mob: +49 152/01994400 - eMail: dennis(a)windows3.de Now moved to the corridor: Hermes! (http://ncc-1701a.homelinux.net) Besides that: http://www.denchris.de - http://www.motagator.net/bands/65 <GnuPG KeyIDs: B8382C97, 01AD62DE>

Patrick Shirkey wrote: It won't be viable for a handy or a toaster, but ... http://www.indamixx.com/ -- Secret of Tux: http://images.wallaceandgromit.com/user_uploads/forum_thumbnails/5/75/355.j… "Gromit bit me" says HMV dog: http://img.dailymail.co.uk/i/pix/2007/03_03/GomitHMVPA_468x319.jpg

Patrick Shirkey wrote: Ah, okay, I translated from English into German without thinking :D, on German a 'mobile device' means the same as on English, but the English word 'mobile' on German is 'Handy'. A rhetorical questions is including the answer. I'm a user and I'm only interested in JACK and ALSA, maybe because I haven't the knowledge to realize the advantages of Pulse Audio or maybe because it's applicable what I'm thinking, because of my experiences. If all sides that are involved in rtkit, dbus, pulse audio (or completely other issues) discussions would explain there standpoints to users, answers might come spontaneous. If there are different standpoints. Why not asking the users? A user most times can't say something about explicit technical issues, but a user can give answers about the usage. I'm 100% sure that there are users with different needs, having different opinions and they will argue because of their needs. Developers are users too, but they are just a handfull off people and they are deeply involved in their projects. Imagine a policeman who's family was killed. Would it be wise to allow him to do the investigations? If I have guests and I like beer, I anyway will ask my guest if they want wine or beer. You should go and ask people in open forums, instead of asking developers or even users in closed mailing lists. Maybe forums for audio and multimedia users (and users are consumers and producers), not especially for Linux users and don't ask them if they want JACK and/ or ALSA, ask them what they want to do and what they need to do that. Just my 2 cents. Cheers, Ralf

On 24/6/2009, "Patrick Shirkey" &lt;pshirkey(a)boosthardware.com&gt; wrote: I don't think this adds much to what has been stated by Fons and others, but perhaps it explains a little? I'm not a hardcore audio developer like most of the guys here, but I've been making audio/music/noise, and coding, since the days of 486sx25s and windows 3.1. Back then, and for many years after, it was a real concern to be able to disable as many irrelevant (to audio) processes in the system as possible (as I'm sure you're aware). Now I have a pretty capable system, but when I want to run RT audio apps I still want to disable as many irrelevant processes on the system as I can. For this reason I really dislike the big monolithic desktop environments. There are several applications tied into them (some serious, plain useful, or just fun) which I'd love to have working but which force me to install all sorts of software I really don't want or need - along with all sorts of processes running in the background. So it feels a bit freedom eroding. The choice seems to be between a system which 'just works' but which wastes system resources on things I don't want, or a system which I have to spend hours setting up, constantly have to deal with the idiosyncrasies of, but which is as fast and powerful as it could be. The notions of old, to raise the potential for system resources to be only used for the job at hand (ie audio) are still strongly rooted and people don't like it when they feel their freedom to use systems in this way is threatened by forcing them to install software and have running processes they don't want. James.

On Sun, 2009-06-21 at 19:14 -0400, Paul Davis wrote: Without reading code it sounds from the description of RealtimeKit that it is designed to avoid exactly the kind of thing Jack does routinely, that is to grant rt scheduling to threads that belong to other processes (the Jack clients). -- Fernando

On Sun, Jun 21, 2009 at 8:05 PM, Lennart Poettering&lt;mzynq(a)0pointer.de&gt; wrote: that was sort of my precisely my point. i only read your patch, i didn't look at it in the context of the whole kernel. if indeed it only applies to fork() and not to clone() calls that create threads and not tasks, then its not really protecting against anything, is it? however, from what i could see of the patch the no-inherit-RT property belongs to the process, not a thread, and thus could not be reset by a thread create call without wierd semantics. so it appears to me that your patch still leaves the kernel open to a thread-bomb ... am i wrong?

On Sun, 21.06.09 16:06, Fernando Lopez-Lezcano (nando(a)ccrma.Stanford.EDU) wrote: This is a dep of PA now. Since all major distros adopted PA I'd be surprised if they wouldn't adopt rtkit too. If things run like they usually run then this will enter the other distros one cycle past F12. Nothing. Then the call into rtkit will simply fail. Since the rtkit call is intended to be used as fallback only things will work as well or badly as they did before rtkit was introduced. Dunno. I disagree. The primary objective for rtkit is to be able to run media applications as RT by default, out-of-the-box. I doubt that this feature matters for legacy distros/kernels. Dunno. All processes that want to have rt need to ask rtkit themselves. (which is the only safe thing to do, only then we get the credentials properly defined) Right now you can edit the service startup file and pass them as command line parameters. Just read the README I linked. Lennart -- Lennart Poettering Red Hat, Inc. lennart [at] poettering [dot] net http://0pointer.net/lennart/ GnuPG 0x1A015CC4

On Sun, 21.06.09 20:58, Fernando Lopez-Lezcano (nando(a)ccrma.Stanford.EDU) wrote: Again, the worst thing that happens is that you need to bump RLIMIT_RTPRIO for your user, as you always did. rtkit doesn't take that away. Summary: Kernel that lacks SCHED_RESET_ON_FORK: RLIMIT_RTPRIO is what matters. Kernel that has SCHED_RESET_ON_FORK: RLIMIT_RTPRIO still matters when it is set, rtkit is used as fallback. Also note that supporting rtkit often enough doesn't add a build-time dep to you application and the runtime dependency is very soft too: if it isn't found it's not used, that's all. In JACK's sources the only place where I see fiddling with the scheduler is in jack_acquire_real_time_scheduling(), which takes a pthread_t. pthread_t is process local, so I am pretty sure JACK doesn't try to change scheduling of out-of-process threads. This should hence be perfectly compatible with the rtkit model. Lennart -- Lennart Poettering Red Hat, Inc. lennart [at] poettering [dot] net http://0pointer.net/lennart/ GnuPG 0x1A015CC4

On Tue, 2009-06-23 at 20:25 -0700, Fernando Lopez-Lezcano wrote: Another point re: rt kernels... With this in mind: http://git.0pointer.de/?p=rtkit.git;a=patch;h=db2d157f0d8922e88689631b9de26… I know, I know, all I keep asking about configurability... I do have a problem with the current default priorities of Fedora's jack (one of the reasons I override that package in Planet CCRMA). In rt kernels the best possible performance for something like jack implies reordering the priorities of rt processes so that highest priority is the interrupt that services the soundcard, then comes jack, then comes everything else (not that simple but that's the gist of it). I use rtirq (at the bottom of http://www.rncbc.org/jack/). A max priority of 29 does not leave much room for reordering the whole spectrum of rt processes that are part of an rt kernel... Is there a reason for that low priority? Can it be overriden? (the max) -- Fernando

On Sun, 21.06.09 16:40, Fernando Lopez-Lezcano (nando(a)ccrma.Stanford.EDU) wrote: Yes. Doing that is broken, and ugly. Doing authorization via groups is broken, since practically you can never take group membership away. Which is precisely one of the reasons why PolicyKit got created. Lennart -- Lennart Poettering Red Hat, Inc. lennart [at] poettering [dot] net http://0pointer.net/lennart/ GnuPG 0x1A015CC4

On Mon, 22.06.09 09:33, Arnold Krille (arnold(a)arnoldarts.de) wrote: Please read up on PoliyKit. What it does, and why it has been introduced. You practically cannot take group membership away from a user after you gave it to him, and also adding a seperate group for every tiny bit you need to authorize access to doesn't scale. Except that this doesn't work. http://hal.freedesktop.org/docs/PolicyKit/intro-define-problem.html Lennart -- Lennart Poettering Red Hat, Inc. lennart [at] poettering [dot] net http://0pointer.net/lennart/ GnuPG 0x1A015CC4

On Mon, 22.06.09 19:59, Jens M Andreasen (jens.andreasen(a)comhem.se) wrote: But uh, that app could then not access the starting user's file in any way. There is no such thing a trusted user applications. And I don't think we want to go down the road to sandboxing for this. Lennart -- Lennart Poettering Red Hat, Inc. lennart [at] poettering [dot] net http://0pointer.net/lennart/ GnuPG 0x1A015CC4

Lennart Poettering wrote: security is a matter of good design, not of "oh, look, he has become evil, let's revoke his privileges" ad-hockery. it should never be necessary to automatically revoke rights from users. if i have to get rid of a misbehaving creature fast, "passwd -l villain" in combination with "mv ~villain/.ssh /tmp" and a quick pkill fixes things for me. and the very good part is that this decision is made by a human, not by some imperial shitload of policy that caters to the needs of some mythical desktop user. your rtkit cannot protect against anything, you can just play policy catch-up with evildoers forever. that's about the same level of security that outgoing firewalls in windows provide - you depend on process names and whatnot, and if i rename "Internet Explorer.exe" to "Windows Update.exe", i'm free to do as i please (not quite, but you get the idea). this is *not security*. this is theater. proper security sometimes includes the wisdom that certain threats cannot be met without throwing out the child with the bathwater. some daemon fiddling with rt privs at runtime in my book qualifies as drowning the child first, then throwing it out. maybe eating it afterwards, but i'm not sure.

On Monday 22 June 2009 23:35:57 Jörn Nettingsmeier wrote: Yippie! We are back at the "child eating" stage! /me gets out the popcorn...

On Mon Jun 22 2009 - 10:33:37 EEST, Arnold Krille wrote: I for one consider this "kit" naming pretty awkward, and if it's just the slow adoption of microsoftsounding techniques into Linux. Heck it (kit) may be the next buzzword of the century. And then, once `rpm -qa` has a "Kit" in every line, maybe then people start thinking what it buys. Where's the unix in everyone of us? ConsoleKit for example, rpm -q summarizes it as "System daemon for tracking users, sessions and seats" and should, subsequently, had better been called consolesessiond or something, for "ConsoleKit" does not tell me much. RealtimeKit even gives me the wrong impression that it alone would magically make RT work (which is not the case).

On Mon, Jun 29, 2009 at 3:13 PM, Fons Adriaensen&lt;fons(a)kokkinizita.net&gt; wrote: i believe that in this context, the term actually comes from academic computing environments, in which, indeed, computer users did not have any personal space at all, but simply sat down wherever there was "a seat", often in a library or campus computing center. as a sysadmin, you were tracking "seats" more than individuals that you knew and interacted with. in fact, this terminology might never have come about were it not for the way that unix allowed computing costs to come down and universities and colleges to provide more open access to the systems. i very much doubt if any MBA was involved at all.

On Mon, 22.06.09 01:55, Adam Sampson (ats(a)offog.org) wrote: I am Linux developer. My priority is Linux. rtkit is Linux-specific, internally it makes use of quite a few Linux-only features. Which makes it very small and lean. I like it that way. I guess one can't have one's cake and eat it too. I don't think it is worth creating a tiny mini library that I'd need to maintain and everyone depend on for just one (or two) little function call. Especially since this would be an extra dep to a lot of software. D-Bus otoh is nowadays so deeply integrated into th system (heck, we now have it in the init system itself, too, and there has been work to add kernel code for socket(AF_DBUS)), that it's available everywhere and on many projects a dep anyway. Also, the reference client should compile fine on non-Linux, however it will become a NOP and return ENOSUPP when you call it. I added this precisely to allow compilation of the code on other OSes and minimizing the ifdef orgies. Uh? To me it looks as if dbus was AFL/GPL2+ which a verified with a quick grep over dbus' git repo. How did you come to the conclusion that dbus was AFL/GPL2-only? Can you point me to where this is claimed? dbus is GPL2+. When linked against the rkit daemon that gets practically upgraded to GPL3. Problem solved. Hehe, it's all davidz's fault. Lennart -- Lennart Poettering Red Hat, Inc. lennart [at] poettering [dot] net http://0pointer.net/lennart/ GnuPG 0x1A015CC4

On Mon, 22.06.09 08:52, Adam Sampson (ats(a)offog.org) wrote: Really, I see not much value in supporting more than one kernel. That just means reinventing the wheel over and over. If others care, fine for them. This is bogus. There is no dependency on rtkit here. if during runtime the rtkit service is found it is used. If it is not found it isn't used. end of story. There is not compile time dependency on rtkit and no runtime dependency either. If I had introduced my own little library everyone would have to link to it. However this way they just have to depend on dbus, which is something many applications link to any way. So this way there is many cae no dependency added at all. And the build is certainly easier. Also, the client reference implementation is tiny. it just wraps two method calls. Trivial stuff. Then file a bug. The .c/.h files are pretty explicit. Ever single file one has the GPLv2+ blurb in it. Lennart -- Lennart Poettering Red Hat, Inc. lennart [at] poettering [dot] net http://0pointer.net/lennart/ GnuPG 0x1A015CC4

Lennart Poettering &lt;mzynq(a)0pointer.de&gt; writes: I find this statement surprising, having found that testing on multiple operating systems is an excellent way of finding subtle bugs in code. (I assume you're just talking about RealtimeKit here and not PulseAudio as a whole, since there are clear advantages to making that available to as large a userbase as possible if you want it to be widely adopted...) Yes, there is a runtime dependency on RealtimeKit -- else there would be no point in having it in the first place! If I'm building an operating system package for an application that wants realtime priority, then my package has to have an explicit dependency on RealtimeKit as well as D-Bus. It's neither trivial nor tiny -- rtkit.c is a bit over a hundred non-comment/blank lines of code. The entirety of thread.c in libjack (which handles getting realtime priority on a variety of operating systems, among other things) is less than two hundred. This should be in a library, *not* copied-and-pasted into multiple places; that's a maintenance nightmare waiting to happen. I should be clearer here that I think the RealtimeKit approach is actually pretty sensible on Linux, and I don't have any objections to using D-Bus. I just think it's important to recognise that this approach is not appropriate for all platforms, and providing a more conventional library interface would be more convenient for programmers, more portable, and generally better software engineering practice. I have done. I wasn't aware that it *was* a bug until you commented on it; I'm used to trusting packages' explicit statements in their documentation about their licenses. (Looking at license statements in headers is not sufficient; as in RealtimeKit, it's very common to have different licenses applying to different files, or dependencies on libraries which end up restricting the license of the overall package.) Thanks, -- Adam Sampson &lt;ats(a)offog.org&gt; <http://offog.org/>

On Mon, 2009-06-22 at 01:55 +0100, Adam Sampson wrote: Count me in as being surprised. I would imagine it would be natural to include the LAD community in such a discussion. If not _all_ of LAD, then I would imagine I would at least invite the Jack developers to participate. If not _all_ of them, then at least a small subset (the main developers). After all Jack users, developers, packagers, system administrators, etc, have been dealing with this very same issue publicly for many many years[*] and were part of previous discussions about this... Oh well... -- Fernando [*] in my case since 2001 or so (when Planet CCRMA went public - but if I remember correctly I was using realtime scheduling access methods for non-root users at CCRMA even before that). My memory is fuzzy, but I may have the dubious distinction of being the first to add a way to access SCHED_FIFO to jackd as a non-root user using capabilities, as I needed that for CCRMA (based on code in, I think, muse - or was it some other program?). A very ugly hack that hopefully has been purged from the jack source code a long time ago :-)

On Mon, 22.06.09 21:28, Emanuel Rumpf (xbran(a)web.de) wrote: Dude. Seriously. As pointed out gazillions of times handing our RLIMIT_RTPRIO to everyone is an invitation to freeze the machine. While that might not be a problem on an audio workstation, it is a problem for the big distributions. Lennart -- Lennart Poettering Red Hat, Inc. lennart [at] poettering [dot] net http://0pointer.net/lennart/ GnuPG 0x1A015CC4