Same thing here... I understand there are resources limitations and it's better to have a more robust and reliable "less" than a clumsy, control-less unstable and buggy "all-inclusive".

I'll be happy if it comes, it'll remove an argument for the "anti-slackers", but until then I appreciate Slackware as it is, as I appreciated it and was fascinated in my teenage years in the 90s... Not meaning it hasn't evolved, but I still can have the same "magic feeling" I had in those years, whereas all other OSes removed "the fun out from computing" in me (to steal distrowatch tagline).

PS/ "An-inclusive" often means EVERYTHING is included, even bugs .

I think if someone has an intelligent comment ( a statement based on some newish information everyone may not already know) to make on any subject it ought to be welcomed.

I would also point out that despite a lot of crying and nonsense that we had a productive thread recently. We did answer a number of important questions. We pretty well established what can and can't be done around centralized authentication beyond NIS without PAM. We defined the complexities of adding PAM as an end user. We pointed out even adding PAM without kerberos packages would be helpful. We got a lot of good input form people who have integrated Slackware into larger environments and people who have built packages and done some real testing. Which not everyone can do because not everybody has an ADS domain they are free to join member servers into. Pat commented; its message sent and received. In summary the answer was not now, but maybe not never either. This all took place in the current development cycle before things started settling into pre-beta. This was a much more reasonable time to be lobbying for something to be done.

This thread on the other hand was basically a troll. It began with some snark about puleaudio which is essentially unrelated and added exactly nothing new to the PAM discussion. In a small way wasting Pat and Eric's time with this type of stuff is perhaps one of the reasons those of us that want PAM can't get it.

Seriously if you have something to add start a thread. It would be helpful I think if it was specific like:
PAM would enable us to...
Built some PAM packages discovered...
... can't be built without PAM support.

What we don't need at least not leading up to a new relase where things are already mostly settled is another "Slackware should have PAM thread".

13 members found this post helpful.

inconsistency is wonderful, take this,
http://www.linuxquestions.org/questi...ml#post5479724
and replace bluetooth/sound with central authentication.

so what intelligent discussion should there be, there are some project that show which packages would need to be changed/maintaned, but there is no trustable solution for Slackware, not now and very possible not within years.
so it's clear that the userbase of Slackware does not need PAM because everyone that needs PAM has moved to different distribution. and those who will need it in future will have to do the same because the statements and release cycles do no make it look like there will be a solution before several years!

1 members found this post helpful.

Slackware's upgrade to BlueZ 5 broke bluetooth sound. Slackware had to add PulseAudio in order to fix something which worked before and was suddenly broken.
Regarding PAM - Slackware never had PAM, so adding it won't fix something that worked before and suddenly got broken. Slackware documentation does not mention anywhere that central authentication should work. If some functionality in Slackware suddenly breaks as a result of a future package update and adding PAM would fix this, then who knows - you could see PAM getting added to Slackware.

I fail to see the inconsistency.

10 members found this post helpful.

Well, I guess I'll dig up a post by PV that everybody loves to through at PAM proponents:
http://www.linuxquestions.org/questi...2/#post4182564
I know that patching BlueZ in order for it to work without PulseAudio may not be a trivial task... but it suggests that for some things the "hammer it till it fits" approach is used while for others the "change it because it doesn't fit anymore" approach is preferred.

Try harder?

PS: I know that PAM is a big deal and adds to the already huge PV's workload and I'm happy to keep solving my problems by myself.
I'm a pragmatic guy and I believe in the "use the right tool for the job" philosophy (I even use windows(tm) for some jobs)

2 members found this post helpful.

You can't wait and want Slackware with PAM right now? Easy:

1. Fork Slackware
2. Add PAM
3. Change the name. I suggest PAMSlack or SlackPAM
4. Release

3 members found this post helpful.

to create on more non trust able solution?
lame attemt to be original Didier.
Look, I am not one of the persons that can not boot into a different runlevel just because I have to deal with a different distribution.
So the consequences for me are clear, Slackware will be on a notebook at home, sometimes on weekends as hobbies, main work continues as in the last >18 months on a different distribution.
I do not have the time nor the will to fix the technical debts Slackware has created for itself in the last decade. The only active thing I can do is donating, and this happens to the project I actual use for the reason that I am permanently reminded of them through the usage.
See, I follow the kiss principle.

3 members found this post helpful.

We can't always get what would like. That's life.

To me, Slackware is a tool.
My preferred tool.
It is like a swiss army knife that doesn't have a corkscrew.
When I want to open a bottle of wine I'll chose another tool: screwdriver with a corkscrew, hammer with a corkscrew, or just a one use tool like a corkscrew.

Sure, I wished Slackware had a corkscrew... but it is easier for me to simply use another tool than to redesign my preferred one.

Trying to fit a squared peg into a round hole is very time consuming

Slackware is the least annoying distro (for me) and it actually tries to get out of my way when I'm doing stuff.
It allows me to do things the way I want to, instead of the way someone else thinks things should be done.
It doesn't try to hide things from me like being able to login as root and bork my system.
It is MY system after-all
That being said, if it doesn't do what I need I'll use something else for that task.

1 members found this post helpful.

You cut out an important part of that quote. Software that has non-PAM code is running into problems because it is not well tested. They've had to fix a few bugs with patches because of it not working as it should.

These are two very different things: 1. adding PAM because software completely removed support for non-PAM setups. 2. support exists for non-PAM setups, but it's buggy.

As far as I know, they haven't run into any software dealing with #1 that doesn't have a decent alternative (in fact, I don't know if they've even run into a program that removed support for non-PAM setups... the changelog for 14.1 and -current don't seem to imply it).

The difference is in how many people put their word to their mouth and actually stepped up doing something about it. We had users (not core team members, mind you) develop everything from small patches to huge features in order to keep shadow support going (iirc). *Nobody* cared about pulseaudio. There was plenty of time. Lot's of people must've seen it coming and if they had cared enough, they would have submitted patches upstream to keep alsa support going. Not only to bluez, but also to xfce, plasma 5 and whatever the next thing is that will drop plain alsa support. That didn't happen, that's why pulseaudio is in the tree.

When someone says "sooner or later we will not be able to avoid $this", it's *your* cue to step up your game and do something about it. If you don't, you forfeit your right to complain when the inevitable happens.

11 members found this post helpful.

I will preface this with saying that I don't really care about PAM, if it comes to Slackware, I will trust that it was the right decision. I trust Pat's decisions on what a distro needs.

For once though, I would like to see a PAM thread that started with, "I tested so-and-so's PAM build" and I have this working. It added these awesome features, here's what broke, here's what didn't break ... et cetera. I don't see enough people requesting PAM putting *any* effort toward testing it. It seems pretty obvious that it is a significant undertaking.

Go forth and test:

http://www.slackware.com/~vbatts/pam/
https://github.com/Dlackware/systemd...er/systemd/pam
http://www.bisdesign.ca/ivandi/slackware/SlackMATE/pam/

If you want PAM, test and help these projects or start your own, don't just ask for handouts. VirtualBox is only a download away, you don't even need to bork your current install. ;^)

9 members found this post helpful.

As someone who does not use bluez, kde or xfce I have not noticed any programs remove alsa support and if they did I would instantly bring it up with their upstream developers assuming I could not fix it myself. Nevertheless I did what I could for myself and blacklisted pulseaudio before it was installed. I am willing to recompile/remove any packages that causes problems with that and anyone else with similar complaints should do similar. Though now that my system is pulse free and working reliably as always I will not hold back in sharing my honesty that this is a really poor decision and I can not emphasize my disappointment in the slackware maintainers strongly enough. The only result from this is to fix some obscure feature most people here have no need for and a forum full of pulseaudio bugs, complaints and arguments.

Also, even though I do not have any bluetooth hardware, devices or interest in getting either I will and am bringing this up with the bluez upstream, others should join in.

They have #bluez @ freenode and this mailing list.
http://www.bluez.org/development/lists/

Just because you don't use bluetooth and have no interest in getting it anytime soon, doesn't mean that those who do use bluetooth should be left out in the cold just because you don't happen to like pulseaudio. And do you actually know for a fact that "most people here have no need for" bluetooth audio? Really, that statement borders on arrogance. Nowhere have I seen you poll people here to see if they use bluetooth. Just because you see a few posts of people complaining about problems with bluetooth/pulseaudio configuration problems doesn't mean that they constitute the majority of Slackware users.

I don't have bluetooth hardware, but I respect Pat V.'s decision to include pulseaudio because he has to consider the broader aspect of Slackware usage, not just a few, like you and I. I don't know what problems you have had with pulseaudio, but I have no such issues. Sound continues to work like it always has.

Finally, if you want to complain upstream, feel free to do so, but don't assume everyone should be as aggrieved as you are, and take similar action. Complaining isn't likely to change the situation, although it might make you feel a little better.

Just my

Regards,

Matt

2 members found this post helpful.

The dark orange part is easily dealt with (every "how do I disable Pulseaudio" thread got an instant answer), and the red part isn't Pat's fault.