Server with ability to load modules in userspace shouldn't be a forced requirement for anything.
How long before PA modules start to write into /sys and how long before apache needs to be running to start KDE?
Shady software like Skype seem to depend on PA like it's a part of the kernel, but there's a good reason why it isn't a part of the kernel.
Wish the bluez/gstreamer/mozilla devs would use kernel interface instead of bloating the client software with these remotely exploitable functions for no good reason.

This reminds me of samba flaw the other day, and how someone was telling me that I must upgrade the system ASAP because everyone else did.
It's become so widespread that everyone assumes it's installed, and I get probed for open smb all the same, even though I've never had it running.
Same thing with sudo, I've never got used to it. Now there's a flaw in it and everyone must patch except me (I've never had it in the first place)

In conclusion, I see also how minimal Slackware systems are looked down upon around here, and are considered crippled or something.
With this I disagree, I'd rather have just /a/ and build with /d/ everything else I want, than userspace that depends on security holes.
Not a popular opinion I guess, but it is what it is.

3 members found this post helpful.

I'm going to continue to derail this thread. Feel free to tell me to stop, enorbet.

I know for me, I don't look down on minimal installs. But people should have a rough knowledge of why they want a minimal install, the workings of Slackware, and how to fix problems if they're going to go that route. Someone who pops in and asks for a package set for a minimal install obviously doesn't understand the concept behind it. What one person considers minimal, someone else is likely to consider bloated and another would consider crippled. People who do their research and have a basic understand on how Linux dependencies work (so when they have an issue, they can diagnose it) and they have an idea of what type of minimal system they'd need, then more power to them.

In the end, many users want a minimal install for inaccurate reasons (faster system, less memory used, etc). In those cases, I will try and provide them information to explain why those things aren't affected by what you install, rather by what you run. I will probably always tell them it's easier to just do a full install, but if they insist, I have no problems providing resources to help them out (although, I will strongly suggest that if they post about a problem to mention they don't have a full install -- it can save some time in the troubleshooting process). And you're absolutely right, doing a full install does leave more possible attack vectors. Every unused program is an unneeded security risk, but the process to go through your packages and find out what is and isn't needed is on the more complex side, and not everyone is capable of making that determination... or fixing it if they removed/never installed the wrong package.

I don't see how we're derailing anything. The thread was marked "Solved" and now we're having a discussion. I'd like to think that I've learned something along the way.

That's precisely why I think if you're going to uninstall pulseaudio you should have to do it yourself. I've broken my system a million times and I learned something every single time. Working your way through each package is a great way to familiarize yourself with the system. I used to joke that some other distributions save you time by breaking things in advance; Slackware makes you break it yourself.

Fot those who could not disable Pulse Audio, you might want to try this. There is a file /etc/pulse/client.conf

Try. if you would, setting "autospawn = no" and "daemon-binary = /bin/false"

Actually, bass, I don't view this tangent as derailing at all but at least a propos to the title of the thread. It is just as valid to use and/or Love, PA as it is to not use it, and/or Leave it, especially based on how either condition affects one's or even everyone's system. I suppose it is somehow even valid if you disable it just because it's the closest thing to physically slapping the smugness off Lennart's face but is far less purposeful and defensible. It is my opinion that works should be judged on their merit not the character nor personality of the creator. Witness the case of Mr. Reiser.

1 members found this post helpful.

The exception to the rule is when the two things are connected. If I'm feeling down, I go to the systemd mailing list to watch Lennart close bug reports. It's hilarious until you step back and think about how important this could be.

I have to duck out of this thread, but I'm sorry I couldn't help you. The only reason I posted in the first place was that I thought I had the answer for you.

You do realize, that before 14.2, Slackware already used software written by Poettering? The question on the merits of a work of his already qualified a program to be put in a Linux distribution. Pulseaudio was included to meet a dependency. That also makes sense for a Linux distribution to if the goal is to make it easy to access something. While Pulseaudio went through some hard scrutiny (you gotta remember, there have been alot of poor sound server implementations already), that is nothing compared to the scope of his design choices of his later far reaching project. If he had kept his /emotional/ mouth shut on arguments about pulseaudio or his later project, he likely would never have been a headline to achieve his notoriety that he now has. Another words, there was no problem judging him on his merits, it's just doing so now always gets you labeled on some side of the fictional, emotional debate, one that he himself started. If he never personally interjected himself to create "news", I probably wouldn't have known him by name.

For Mr. Reiser, yes, his software got adopted. He achieve notoriety later by creating "news" on what he did. Yes, almost no connection between the two other than the name. Had he not done that, I wouldn't have really known him either. Yes he was somewhat of a figure in the kernel space, but it was in the narrative written later after the event, we see him as that way now.

1 members found this post helpful.

You must be really joking! This even KDE3 sound system was able to do (and more like real time sound). But it was 9 years ago! Mhm, maybe this time was needed for pulseaudio developers to grow up.

1 members found this post helpful.

I use pulseaudio, but I can get by without it. And on minimally spec'd systems I do go without pulseaudio, the cost of having it is too high. But low spec'd machines are getting rare now. Even a cheap ARM sbc has 1GB+ ram and measures cpu speed in GHz, not MHz. Mostly I learn to live with pulseaudio now. Although because I'm cheap. I only have one good soundcard and one good set of speakers and several computers. So one of the computers does the complex pulseaudio bit, and the rest just have "default-server = 192.168.2.1" in $HOME/.config/pulse/client.conf. In fact I just learned how to use jack locally and send that to pulse with snd-aloop and alsaloop today.

$ sudo modprobe -r snd-aloop
$ sudo modprobe snd-aloop pcm_substreams=2 enable=1
$ jackd -r -d alsa -d hw:Loopback -P -o 2 -r 48000 -s -m
$ alsaloop -C hw:Loopback,1,0 -P pulse

If I want the local soundcard to enjoy jackd from the loopback device:

$ alsa_out -j hw:Loopback -d hw:SB
$ alsa_in -j hw:Loopback -d hw:SB
$ qjackctl

Connect the monitor to jacks playback and jacks capture to the system output. You can't have more than one loopback it seems so let the id= default.

$ aplay -l
Where SB is hw:1 and is an actual output device with speakers attached. This setup allows me to have local fluidsynth and stuff and use the pulseaudio server machine over the network. Various complex .asoundrc routes and jackdbus routes for the same setup, but I prefer the raw CLI way before going full wizard with magic configs.

$ fluidsynth -a jack -g 1.5 -j -l -m alsa_seq /usr/share/sounds/sf2/FluidR3_GM.sf2
$ vkeybd --octave 8 --channel 0 --device alsa
$ qjackctl

To have a clickey piano gui and a synthesizer to have it make sound. Basically you don't have to go without pulseaudio to have all the toys. But performance is performance and pulseaudio is a pig. Although a lot less of a pig on the client end of a networked audio setup. As I drool over an asus tinker board or Fitlet-H to take over the server side of pulse with a side of NAS duties.

1 members found this post helpful.

After some research, I'm answering my own question. I found that this issue, along with a Firefox right-click/menu delay issue right after Firefox is started, were both due to Pulseaudio shutting itself down after a specified time (default appears to be 20 seconds). When Pulseaudio is running I don't see these delays. I made the following two changes to my system (bare Openbox as the window manager) and that seems to have fixed the issues.

1) Added "/usr/bin/start-pulseaudio-x11" to my Openbox autostart script. This starts Pulseaudio as soon as Openbox starts.
2) To make sure Pulseaudio doesn't shut itself down, I changed "exit-idle-time = 20" to "exit-idle-time = -1" in the /etc/pulse/daemon.conf config file.

I did find some similar posts about this on the net which pointed me in the right direction, I never would have guessed the Firefox issue was related to Pulseaudio. Hopefully I won't see any negative effects from these changes.

You certainly have the right attitude! Well done, keep going.

I went back and re-read your OP because I'm interested in finding the source of your troubles, and noticed this:
Can I ask why you went multi-lib and not straight 64 bit? As someone who prefers simplicity, you've certainly chosen to complicate things for yourself by choosing that route.

There are very few reasons for doing so these days. If you have some specific software, can it be run in a 32 bit VM?

Thank you and of course you can ask and I'm glad to answer.

Other than the most obvious and common uses for PCs of email, online banking, about a dozen forums, and websurfing, all of which are most often browser related, my main needs are high quality audio recording/editing and gaming. Gaming has become rather serious business for me for exercising eye/hand coordination since I went through a minor stroke roughly two years ago impairing feeling, strength and coordination on my left side. The problem-solving aspect of games is good for keeping mentally sharp. The best games for a wide range of activities are online games and many of them require Wine and they often also require comm apps for team play. Lately the comm application "Discord" has enjoyed extreme popularity, partly because it runs on so many platforms, but recently they dropped the 32 bit version for Linux and now only support 64bit.

As you may know VMs are less than ideal for audio apps and even moreso for gaming since hardware acceleration is not supported. My main audio recording/editing app cost over $1200.00 USD fifteen years ago when 64 bit was mainly just a twinkle (and a wrinkled forehead) in a few Intel Engineers' minds and the MIPS and DEC boys had yet to make the breakthroughs that would bring 64 bit to the Desktop. There isn't a sufficient cost/benefit ratio to spend another thousand bucks now for 64 bit.

So while Wine is considerably easier to configure and run in 32 bit and none of my audio apps require 64 bit I'd have just stuck with 32 bit had Discord not removed 32 bit support. Other than Discord there is so far no compelling reason for me to go 64 bit (main box is only 8GB RAM which PAE handles well) but the writing is on the wall that before long (maybe 3-5 years) 32 bit will have become quite rare so I felt the need to learn 64 bit Multilib now to accommodate where I am now as well as where I expect to be in 3-5 years.

I hope this isn't too long-winded but it is a valid question that IMHO deserves a complete answer.

4 members found this post helpful.

But is this really that different from something like multilib? That certainly has the potential to break your system, and we've seen examples of it occurring on the forum when people don't keep multilib up to date when they update Slackware. I do agree that trying to fix a broken system can lead to a large gain of knowledge. But I imagine most people who would want pulse removed would be technical enough to follow the steps needed to do it once they're laid out. Just like FreeSlack, it has the potential to break a system, but the people who likely care about that, would have the knowledge to fix a broken system if it occurs.

But if this were to ever become a thing, I wouldn't be recommending it to people. It would just be available for those who already decided to remove it.

I find it ironic that they only offer 64bit to Linux and only offer 32bit to Windows.

What you're saying certainly is a valid point. And no, your multilib analogy is not that different. The difference that impacts my opinion is that multilib adds on to the existing system, while uninstalling pulseaudio removes a core component.

Obviously, my personal opinions are my own and they only determine how I spend my own time. Anyone else can do whatever they want and I would never question their right to do so. (As long as that doesn't take away any of my rights.)

I do agree completely about removing a core component. That is why I would never recommend doing it. I think it would be easier to troubleshoot it and try to find some resolution that doesn't require removing pulseaudio.

Overall though, it seems that removing pulseaudio isn't as high on the list anymore. There doesn't seem to be as many posts on the forum about it like when it was first added to -current. Maybe people have solved their problems with pulse or maybe they're starting to accept that it won't be removed from Slackware so they're just learning to live with it. Finally, there's others that have removed/disabled it and moved on with their lives. I don't imagine that someone will take up my offer and create packages that have pulseaudio removed, but my offer to host it is there if someone does.