Personally, i would pick the second option: avoid PAM
less burden, more secure, less headache...

I think a lot of this recent talk (in this thread) isn't about PAM itself, but adding PAM into SBo. It would increase the work of the package maintainers substantially needing to verify that their scripts work with and without PAM. I know for me, I wouldn't want to take the extra time to verify that my script works "with PAM" and "without PAM". I already need to check it for 32bit and 64bit, and then I'd have to check for 32bit w/PAM, 32bit w/o PAM, 64bit w/PAM, and 64bit w/o PAM. (Granted, my two lowly scripts on SBo likely won't see any difference with or without PAM, but for some who manage 10 or 50 scripts, this could end up creating a HUGE burden on those maintainers.)

If it were integrated directly into Slackware, I have no problem with supporting it with my SlackBuilds (I'd have to, or let someone else take them up). And I'd imagine a good chunk of the SBo project maintainers would be the same, and they'd have to, or step down, since SBo needs to support a full Slackware installation. Granted, orbea's reasoning may be different from my own.

NOTE: Do not take this as me advocating for PAM in Slackware... I honestly don't care. But, as many others, (yourself included), it obviously doesn't belong in SBo. I think the best way for 3rd-party support of PAM is what ivandi, vbatts, and bartgymnast have each provided. People who need PAM in packages that are available on SBo can do the work themselves to make sure it is enabled properly in the SlackBuild (if they find changes that can be made that won't affect non-PAM builds, it's likely the maintainer would even incorporate it into the official SlackBuild). If it is eventually added to Slackware, then it is, and I'll make sure my scripts are supported (it certainly wouldn't be grounds for me to leave Slackware or reside on an older version).

5 members found this post helpful.

That wasn't a good example my friend.

1 members found this post helpful.

Thanks for note, Travis; maybe not luckiest comparation ever...

But, if I know right, from my colleague and good friend Arash, he do not eat pork meat, from religious reasons. Also, from the discussions with him, looks like the pig meat is a big no-no also for (Ultra-)Orthodox Jews. Like in India, there are regions where is not considered the best idea to eat Cow meat, also from religious reasons.

Sorry if I touched your beliefs.

Idea was about acting in some way, from religious reasons. Ie. someone not eat Cow meat, or he refuse to support a PAM build, because of his beliefs.

I don't have problem with your understandings about Islam and honestly I respect your information about other nations. However, your examples means that Muslims think Christians eat dirty animals which is not true. There are some words in Islam without good synonym in English, in this case "Najes" doesn't mean dirty.

Anyway, god bless CTM. Now I understand what he/she wrote in the first page of this thread:

1 members found this post helpful.

Hm, I maintain about 200 packages to have a functional Slackware based system. 46 of them are PAM related. Even if Slackware ships PAM I will still have to maintain about 150 packages. So personally I don't care if PAM goes in or not. But I believe that being able out of the box to operate in multi-user environment with central authentication will be beneficial for Slackware. The distribution will eventually regain some user base. And there will be some more interesting posts in this forum. Not only "OMG, my mouse moves randomly, have I been hacked!!!"



Cheers

What the hell are you talking about? Certainly not the same thing I was...

So I open this thread and I see... Darth Vader presuming to explain Islam to someone in Iran.

Oohhh kay....

A PAMified Slackware will require probably less burden[1], because will not require to patch the things to work only with shadow authentication, the Slackware affiliated programmers will have also less headaches[3], trying to make the develop patches and even bigger things, to support, again, the shadow authentication, while, as even Our Dear Leader agree, we will run code much more tested, then more secure[2] and stable.

So, picking avoiding the PAM, you will obtain instead: more burden, less secure and more headache.

Long story short, you said that you refuse to maintain PAMfied packages. Why? Religious beliefs or another reasons? Please explain.

Please be kind and look again and you'll see that our Iranian friend, Travis, was gentle enough to explain me the Islam POV about the pig meat, and to give the necessary details.


So, someone from Iran explained (a very small part of) Islam to me.

"Refuse" is a stronger word than I meant, "hesitant" would be closer. My reasons are practical, I do not need pam and I certainly do not need the additional headache of supporting it any slackbuilds I may write. This is only made worse in how kereberos and pam like to dig their claws into your system making them hard to remove, I would like to have as few programs that do that on my system as feasible. I am willing to maintain clean chroots to test slackbuilds so others can use them, but there is a line where my system and the chroots will diverge so much that I might as well stop submitting or even maintaining slackbuilds at SBo...

Exactly that's also my POV. Making a life from implementing the combination of Slackware and PAM, I was able to see both advantages and disadvantages and to understand well the consequences of this step into.

Thanks for details, but let's note that Kereberos and PAM are different animals. And PAM can work fine without Kerberos.

In other hand, working everyday with PAM and Slackware, from my experience, I doubt that you have something to change into build or to the default/base PAM configuration, for almost all packages...

For a more precise opinion, please say what are your packages and I will tell you the PAM impact to them.