On Wed, Dec 23, 2009 at 1:49 PM, Lennart Poettering <lennart at poettering.net> wrote: > On Wed, 23.12.09 13:16, Markus Rechberger (mrechberger at gmail.com) wrote: > >> > Right. It is innovative to carry on with the brokeness we always had >> > just because we always had it and not because we would ever think >> > about the brokeness and fix it? Is that what you think? >> >> Right, we had /etc/group for setting up the permissions pulseaudio breaks this >> behaviour even with the Alsa compat library. > > Group-based access control is too limited for controlling access to > seats in a multi-session environment. ?That's why we have extended > this with mechanisms like ConsoleKit and PolicyKit. > >> Sorry this behaviour is just broken, Pulseaudio should not be part >> of any distribution until a certain level of compatibility is >> reached. ?compiz is optional it's easily possible to enable or >> disable it. > > I guess we have to agree to disagree here. > > ConsoleKit (which is at the core of the multi-session support on our > desktops now, including in PA) has been designed 3 years ago and > pushed ino all distributions. It's the wrong time to whine about that > now, and to me. If you think the whole CK design is an abomination > then you are welcome to, but I'd prfer if you'd take that complains > somewhere else. > >> The recommendation to use system mode is also a failure, why should >> someone reconfigure the entire audio system on a distribution? > > If you run things headless/in a server you have to configure > things. Surprise surprise... > > Also, let me point out that dmix does not support simultaneous output > of streams from multiple users simultaneously either by default, for > security reasons. You can enable that, but you have to configure that > manually and it comes with a big yellow warning sign. This means that > PA and ALSA dmix are really not that different in this respect. PA > will make use of audio devices it has access to. ALSA dmix can do the > same. As long as one user accesses a PA device it is blocked for all > other users, which is very much like with ALSA dmix. The only > difference is that on ALSA dmix after the user stopped using the > device it is immediately accessible to othre users again, while in PA > there is a 1s timeout. Not that big a difference. > > I'd prefer if you'd get your facts right before you start whining. > >> We have deployed alot devices which depend on audio nowadays at >> certain b2b customers, guess how many are using pulseaudio? -- >> exactly noone. After talking to engineers everyone feels like PA is >> just a pain, and by forcing your ideas which break the default >> behaviour this situation will not improve. > > I dont force anything. It's Free Software. Take it or leave it. If you > don't like it then you are entitled to that, but I find it kinda > annoying if you then whine on our mailing lists, and start demanding > things. That's not how it works. I am interested in constructive > feedback but not at all being accused of "forcing". And if we disagree > on something then please accept that. I have explained why we do > things the way we do. And unless you have a better approach and some > code to show I am pretty good at simply going on with what I do. > >> I'd rather like to see a clear statement why it is currently not >> working, so someone can get onto that topic and fix it. If you want >> to block it for other users add a configuration option for it but >> again don't break the default behaviour > > Did you read any of the emails I wrote in this thread? > > if not, try it! > You're certainly good at ignoring bugreports your way, instead of finding solutions to fix it up. Markus
