On 2/27/07, David Zeuthen <davidz@xxxxxxxxxx> wrote:
So it's like this. For *modern* Linux desktop we've been moving functionality from system-wide daemons into per-session daemons *simply* because system-wide daemons have a number of problems.
Justification by cargo cult. Here's a few reasons per-session Pulse is [relatively] a worse idea: You lose state on switch. Transitions are abrupt and 'poppy'; think of the X mode changes upon switch. Per session is harder, yields inferior results in the long run, and gives us no path to move to immediately. Impossibility of emulation. Emulation is not optional. We do not make forward progress by throwing all the current users under the bus. This is *the* reason esd was a resounding failure.
One of those is that you want to read user settings and enforce policy depending on users session [1].
Of course. And that's no different if it's done in the session or in the system.
Another problem is that if you have system-wide daemons you need to coordinate clients with different identities; e.g. you suddenly need to label your objects and make sure that an object created by uid 500 cannot be manipulated by uid 501. Things like that. Does PA handle that already?
No, it does not. It will also not currently handle f-u-s as a session daemon either.
For starters, how are all the exiting PA tools going to work with PA running system-wide?
PA has always worked as a system daemon.
How is it going to work with multiple sessions? I don't think there's anything "easy" about this. If it was easy, wouldn't you have RPM's for us already? ;-)
The code is easy. The politics make me want to walk away and never look back.
I think what you want is some system-wide private PA mixer service that only per-session PA instances can connect to over a private protocol.
That is actually one possibility up for consideration, but I think needlessly complicated. The problem is not making Pulse work well with f-u-s-- the problem is keeping ALSA, ESD and OSS access working with f-u-s. Remember-- that's everybody right now. Monty -- Fedora-desktop-list mailing list Fedora-desktop-list@xxxxxxxxxx https://www.redhat.com/mailman/listinfo/fedora-desktop-list
