[SOLVED] So, there is PulseAudio... How about to begin investigating adding LinuxPAM to Slackware too?
SlackwareThis Forum is for the discussion of Slackware Linux.
Notices
Welcome to LinuxQuestions.org, a friendly and active Linux Community.
You are currently viewing LQ as a guest. By joining our community you will have the ability to post topics, receive our newsletter, use the advanced search, subscribe to threads and access many other special features. Registration is quick, simple and absolutely free. Join our community today!
Note that registered members see fewer ads, and ContentLink is completely disabled once you log in.
If you have any problems with the registration process or your account login, please contact us. If you need to reset your password, click here.
Having a problem logging in? Please visit this page to clear all LQ-related cookies.
Get a virtual cloud desktop with the Linux distro that you want in less than five minutes with Shells! With over 10 pre-installed distros to choose from, the worry-free installation life is here! Whether you are a digital nomad or just looking for flexibility, Shells can put your Linux machine on the device that you want to use.
Exclusive for LQ members, get up to 45% off per month. Click here for more info.
The bluez-5.x stuff came from Dugan (primarily) and me, and I've been working on new blueman-2.x for over a year (even contributing to it upstream a bit), and the combination of bluez-5.x and blueman-2.x is a huge improvement for me. I'm sure it's nice for many other Slackware users too, but understand that *I* put forth the effort on it because *I* needed it. For the first time in literally years, bluetooth devices work reliably - every time I need them. My experience there along with Pat and other Slackware team members' testing is why bluez-5.x went into -current. If we had known then that pulseaudio would be needed, then I can't say for sure what the decision would have been, but given the positive reception and results from bluez-5, it seemed reasonable to see how pulseaudio would play with Slackware before reverting bluez-5.x.
After experimenting with pulseaudio, primarily from mario's suggestions and testing of what was mostly ppr:kut's work originally, we were pleasantly surprised to find that PA worked well with very few hiccups. As he said in an earlier post somewhere, Pat did a lot of reading and researching on what bothered people most about PA and made sure those issues were solved before it ever hit the -current tree. Even better, it was added in such a way that *not* using it doesn't even require recompiling things - there's absolutely no reason to get all bent out of shape about it being there. If you don't want to use it, then do a bit of research to figure out how to turn it off; otherwise, use it and enjoy it - it just works.
Ultimately, this "most people have no need for it" banter is a bit disheartening. *I* need it. pprkut needs it. Probably other devel team members need it, or at the very least, they recognize that it makes some parts of what they do easier, which certainly approaches "need" as far as I can tell. This sounds a lot like what pprkut already said, but basically, the people doing the actual work on making Slackware decided that pulseaudio was the best way forward for the distribution as a whole. We've *never* made seat-of-the-pants judgments about things of this nature before, and we didn't this time, and we don't intend to start, so this closeted implication of that is pretty damned insulting. Give it a rest or go find another distribution that's more suitable.
Last edited by rworkman; 01-18-2016 at 11:46 PM.
Reason: typos
I like PA in that it now lets me seamlessly throw audio from one device to another in near-real time, as opposed to manually maintaining an ~/.asoundrc . It also now makes some tweaking much easier to do (e.g. parametric equalizer with PA and LADSPA) than previously (I'm aware of alsaequal, but I prefer parametric over fixed-band graphic eqs.)
Kudos to @rworkman and team for making sure PA "just works"(TM)
The bluez-5.x stuff came from Dugan (primarily) and me, and I've been working on new blueman-2.x for over a year (even contributing to it upstream a bit), and the combination of bluez-5.x and blueman-2.x is a huge improvement for me. I'm sure it's nice for many other Slackware users too, but understand that *I* put forth the effort on it because *I* needed it. For the first time in literally years, bluetooth devices work reliably - every time I need them. My experience there along with Pat and other Slackware team members' testing is why bluez-5.x went into -current. If we had known then that pulseaudio would be needed, then I can't say for sure what the decision would have been, but given the positive reception and results from bluez-5, it seemed reasonable to see how pulseaudio would play with Slackware before reverting bluez-5.x.
After experimenting with pulseaudio, primarily from mario's suggestions and testing of what was mostly ppr:kut's work originally, we were pleasantly surprised to find that PA worked well with very few hiccups. As he said in an earlier post somewhere, Pat did a lot of reading and researching on what bothered people most about PA and made sure those issues were solved before it ever hit the -current tree. Even better, it was added in such a way that *not* using it doesn't even require recompiling things - there's absolutely no reason to get all bent out of shape about it being there. If you don't want to use it, then do a bit of research to figure out how to turn it off; otherwise, use it and enjoy it - it just works.
Ultimately, this "most people have no need for it" banter is a bit disheartening. *I* need it. pprkut needs it. Probably other devel team members need it, or at the very least, they recognize that it makes some parts of what they do easier, which certainly approaches "need" as far as I can tell. This sounds a lot like what pprkut already said, but basically, the people doing the actual work on making Slackware decided that pulseaudio was the best way forward for the distribution as a whole. We've *never* made seat-of-the-pants judgments about things of this nature before, and we didn't this time, and we don't intend to start, so this closeted implication of that is pretty damned insulting. Give it a rest or go find another distribution that's more suitable.
I certainly needed bluez-5.x to support my heart rate monitor via dbus. I'm glad that it was added.
Kudos to @rworkman and team for making sure PA "just works"(TM)
+1 on that.
Reading through the various PulseAudio-related threads, it looks like there are two types of "conservative" users.
Those who trust Slackware as a conservative distribution, e. g. maintained by a team who won't include any half-baked "technology preview" in an otherwise reliable distribution.
Those who seem to be opposed to any change, whatever it is, and whose epidermic reaction to the sensible introduction of a new feature is a mere "How can I get rid of $NEWFEATURE"?
Distribution: Debian, Red Hat, Slackware, Fedora, Ubuntu
Posts: 13,597
Rep:
Richard Cranium, that kind of language isn't acceptable at LQ. If you'd like to continue participating here, please refrain from using it in the future. Thanks.
Distribution: slack 7.1 till latest and -current, LFS
Posts: 368
Rep:
Kudos rworkman,
I am happy to see pulseaudio added to slackware.
It makes indeed my life easier as developer as I was shipping it with the gnome-3.18 + systemd + wayland build
as pulseaudio is activated by dbus, I did not had to recompile it for systemd.
................
Ultimately, this "most people have no need for it" banter is a bit disheartening. *I* need it. pprkut needs it. Probably other devel team members need it,
................
Give it a rest or go find another distribution that's more suitable.
Well, that's exactly what makes Slackware a toy distro.
I have nothing against PulseAudio. What bothers me is the decision making process.
Well, that's exactly what makes Slackware a toy distro.
I have nothing against PulseAudio. What bothers me is the decision making process.
Cheers
Slackware's reputation as a stable, reliable distro didn't happen by accident; it was the result of many years of making decisions that have panned out as workable over the long run. Your definition of "toy", as I understand it, is due to some people in the decision-making process including something that you don't consider "professional" for their own benefit. Well, it doesn't impact the overall reliability of the distro. And do you really think that "professional" distros like Red Hat, CentOS, OpenSUSE, and the like just add things for only professional reasons? Do you not think that these people add things to them for their own needs and/or wants?
I have yet to encounter a distro that is as professional as Slackware. In my decade of using it, I have seen nothing about it that makes it a "toy" distro. If, on the other hand, a "toy" is something you define as playing with for fun, then yes, maybe they do, but that's what part of what makes Slackware a fulfilling computing experience, IMHO. And it still doesn't impact the stability. At all.
LinuxQuestions.org is looking for people interested in writing
Editorials, Articles, Reviews, and more. If you'd like to contribute
content, let us know.