| |||||||||||||
Choosing between portability and innovationChoosing between portability and innovationPosted Mar 8, 2011 1:10 UTC (Tue) by lacos (subscriber, #70616)In reply to: Choosing between portability and innovation by AndreE Parent article: Choosing between portability and innovation boilerplate trolling? At least try to be original Okay, I'll try to be "original" for him. All this desktop integration goo is getting increasingly difficult to get rid of. There are users who don't need their features, and certainly don't want their bugs, possible inter-app privacy holes, and very probable security vulnerabilities. So while these components are helpful for most people, there's a small group of "power users" who consciously want to remove them, and it is more and more difficult. The only thing I run on my "interactive systems" (both home desktop and work laptop, different distributions), out of "ConsoleKit, PolicyKit, systemd, HAL, PulseAudio or dbus" is D-Bus; and even that only because I can't remove it. I like to know why my UID runs a process; for PulseAudio, I was unable to find any reason. I have four unencrypted pendrives, one encrypted pendrive, one flash card reader, one dumb digital camera; obviously an optical drive, and an encrypted hard disk in a USB disk enclosure. Two non-root users can mount different sets of these, with reasonable file permissions and good IO performance afterwards (for a change). I don't buy gadgets each second day, so it's not hard to update my static config. The inability to mount unseen pieces of hardware is a feature.
(Log in to post comments)
Choosing between portability and innovation Posted Mar 9, 2011 13:49 UTC (Wed) by nix (subscriber, #2304) [Link]
There are good reasons why PA runs as you and not as a systemwide user (though it can). PA can be asked to load modules providing new features at runtime: this is obviously forbidden for systemwide daemons. PA can operate in a zero-copy mode, transferring audio data directly over shared memory: for obvious security reasons this must be avoided if the daemon may serve more than one user, forcing everything to be serialized and deserialized again.
PA itself is plainly necessary: most modern sound hardware can't mix, so the first open()er blocks all the rest. This is more than slightly aggravating to users (the difference between a very long block and a crash is not very large from a user perspective).
PA is really not that bad. Yes, it was buggy once upon a time (mostly because it used features that had never been used by anyone else), but these days it largely Just Works.
Choosing between portability and innovation Posted Mar 11, 2011 3:46 UTC (Fri) by phoenix (guest, #73532) [Link]
As has been shown by the BSDs, you do not need PulseAudio, or any other sound daemon, sound server, etc, in order to have non-blocking, multi-source/single-output sound setup.
Just because Linux can't do it, doesn't mean it's not possible, nor that it should be avoided.
Choosing between portability and innovation Posted Mar 11, 2011 12:40 UTC (Fri) by nix (subscriber, #2304) [Link]
Yeah, great, you can do all the flaming horror of sound mixing in kernel space. Thanks but no thanks.
|
|||||||||||||