you obviously do not understand that PAM is not that optional like java or flash because it has an impact of a lot of packages that can make use of PAM and this is mostly not a runtime desiccation.
I would like to say that with this lack of understanding of technical details you are not alone an well placed in the group of no voters even if you missed the therm additional complexity layer in the system, but if I do so several people will feel emotional bad and therefore I don't.

1 members found this post helpful.

I have no dog in this particular fight and didnt vote, but that seems the sensible attitude to me. Make it available as slackbuilds or in /extra, or optional in some way, not included by default.

I voted yes, because technically PAM has to be part of the system to be useful. In the long run, packages from separate project would replace far too much of Slackware, which would defeat the purpose (who would like to maintain that many custom packages in the enterprise environment to which PAM would bring it?). Good example is gnome3, it might be fun to play, but running on production? No way!

That said, I like Willy's input. It seems to me this is Slackware way for innovation. Someone starts, someone helps, more people find it useful, therefor start using it. Then it becomes official, like slackware64. If we are about to bring PAM into Slack, we must hold hands and work out implementation which works(tm). At the start it could be provided to public in much the same way as we now have multilib (e.g. available through slackpkg+ on current/next stable).

And I would also like to second Slax-Dude so his thoughts would not sink unnoticed:

3 members found this post helpful.

Incorrect. For PAM to be useful it has to have purpose. Just including it doesn't give it purpose, as packages in great amounts must be rebuilt as needed to include PAM support at build-time, plus many configuration files must be created to configure PAM module usage properly for what could be a general context inclusion, but a general context configuration is useless for security purposes. In fact, it's not any better than choosing to exclude PAM. PAM requires a great deal of configuration and testing per instance of usage. This is what Kiki hasn't been telling you.

Per package that uses PAM, is an instance that requires that package be tested against a configuration, and in return so too must that configuration. Calculate the fact some packages must interoperate, these instances must be tested as well. However, therein lies the problem of PAM. Because different levels of security and configurations can exist, these create numerous instances that have to be checked, documented, and tested repeatedly against other security levels, configurations, and instances. And then these packages must be tested with every other package that interoperates with them even if they don't use PAM.

The easy path would say turn everything to pam_unix.so by default. While on paper that's fine, in practice it's foolish and no better than building without PAM. This is why including PAM with a default configuration is pointless. Yes it's in the system, but is it being used or bypassed? It's bypassed because pam_unix.so is nothing but a bypass/disabled module that only passes things along, and doesn't limit anything. In truth if this is your grand plan, you'd get more mileage out of implementing a UnionFS with effective permission handling per logical partition.

For PAM to work, and work as intended, it has to be optional to rebuild around only the most needed parts of the system it has to work with, otherwise, adding PAM creates a problem of a great deal of packages that must be tested, retested, etc.

The best design is to keep it optional, rebuild as needed, and reinstall package to gain the most effective implementation. Because no two PAM using instances are the same, these will have different configurations as well. You keep it minimal in impact and you don't create a monster in the system.

I highly doubt Patrick needs such a headache to deal with in terms if the complexity added to the system, by that's my point of view on that.

2 members found this post helpful.

I see what you mean, but it seems to me, that purposes can be many. For example some of us think, that having PAM out of box would widen Slackware usage scenarios a bit. So the fact that PAM is there could place Slackware amongst Cent, Debian, Suse as an option to do big things on big machines in big networks.

Also purpose can be concrete: to authenticate user x from machine y to do z. For this, one man project could be sufficient.

I also notice attitude „this needs x work, y testing, and n of that“ is counter productive. If alienbob and others thought like that we would still be using slackware32 and installing programs with ./configure make install. I mean it is usually better to think what could be created. That way things grow. Plus, there were quotes of Patrick himself mentioning possible inclusion of PAM in not defined future. In my humble opinion best future for anything is now.

5 members found this post helpful.

this is why it has to be part of the distribution. and this is what people that think its a good idea to make it optional do not understand.
when it is in the system and you do think the default configuration you mentioned does not fit your needs you have at least a chance to change
this without rebuilding the half distro,
and even with pam_unix and pam_cracklib you have already some interesting options.
the rest of the post is therefore the usual mix of facts an fiction plus some FUD mixed into something that fits to you opinion and to to reality.

2 members found this post helpful.

Testing interoperability between packages isn't FUD when a new dependency enters the system.

How do you propose to test, check, and reconfigure, patch, and maintain dozens of packages that would have to either be rebuilt against PAM as well as test a generalized, if that term can accurately be used, default configuration as well as test hundreds of possible configurations against other PAM modules with every PAM dependent package in every conceivable configuration? Just how many people and man hours do you expect will be needed to do such a feat? Slackware isn't maintained on the same size and scale as Debian, Red Hat, Ubuntu, etc. Did you all not even consider this? Even in the least?

The only FUD here is the outcry that not having PAM will doom Slackware, or somehow cripple it.

no. this is FUD.
facts are:
Slackware has not to test all constellations in all combinations. Other distributions do it also not, maybe they have more users and get more feedback at debian or fedora, but this is stuff for the applications.
if there are bugs in software they have to be reported to the software maintainer, as usual and as now.
for Slackware there is current, so there will be some testing time anyway, as usual and as now.
and I think that the PAM using software parts are better tested than the no PAM using software parts because more developer will have machines with PAM than without.


possible not doom but definitely cripple, this is a fact and not FUD.

and how do you use Slackware in your day job ReaperX7 ?

2 members found this post helpful.

With all respect, permit me to laugh with tears!

You realize that you talk about things when probably you do not known nothing on subject? You are amazing, man! You are epic!

For your knowledge, there exists a complete Slackware based Linux distribution, well PAMified, and it works like a charm. Trust me! I earn my money maintaining it.

And please be gentile with the showing of ghosts and succubus of PAM later configurations... There are not such things.

While spreading your ultra-orthodox speech, please be aware that there are persons that already made the complete pathway, and while you talk from your imagination (because looks like your experience into subject is glorious zero), another people known very punctual how to skin the cat...

P.S. Looking at the glorious feedback into subject, I begin to understand WHY the company where I work prefer to NOT publish the distribution which they develop in-house. :P

6 members found this post helpful.

Is there any way to persuade your company to consider publishing their product? I'd more than happily give it a spin. If you fear being invaded by obnoxious users, you can always opt for a restricted mailing list as primary communication support. Last but not least, don't forget the famous adagio: given enough eyeballs, all bugs are shallow.

Cheers,

Niki

Not having PAM will not doom Slackware, nor cripple it! There are plenty of users who like it as is, and it is great for it's simplicity. But having PAM could expand it's usefulness and enable it to do cool things. Bring it up a level.

Only thing that would bring doom is negative attitude, because it's easy to neglect "new" things, just because they do something differently or there is learning/work involved. Nicer would be to accept the challenge and use those things to be awesome in Slackware way. So the question is to be awesome or to be grumpy old men. Which usually are irritated by anything that threatens their little comfy word, just because they think they lost ability to grasp on fresh ideas.

Anyway, happy slacking

2 members found this post helpful.

I use Slackware for many things.

Development of custom SlackBuilds for my Slackworks repository.
Development of my LinuxFromScratch system when I get time, which does not have PAM either.
Supplying an emergency "get it useable" operating system to client computers who may have EOL operating systems or lack recovery media.
Filling out forms, letters, and other data processing for my business.
Printing invoices for my customers and clients.
Scanning storage drives for malware and file system errors when needed.
Playing older arcade style games using MAME and classic games using MESS in my free time.
Doing my taxes... Yay...
Researching recipes with my loving wife who loves baking and cooking.
Maintaining a personal in home backup and file server that also acts as a print server.
Learning GNU/Linux shell scripting using Bash and standard shell language.
Web surfing and research.
Image processing when me and my wife go on outings and vacations.
Corresponding with family members across the US and Canada who I rarely get to see.

I doubt I've had a need for PAM in any of those instances. Slackware has been my workhorse for various things.

I want all of you to remove your fingers from the keyboards, sit back in a lounge chair, count to 30, take a deep breath, and consider this:

No poll will have the persuasive power to change anything in Slackware. This is a discussion forum, not a bug tracker or a RFC entry point.
It's all nice to discuss possible paths Slackware could take, but that's all it is. Pat may or may not read it. Today was the first time I read this thread and I was appalled. I will post this item and then never re-visit it.

PAM may or may not be added to Slackware. Darth Vader and some others in this forum know that Slackware can run as well WITH PAM as it runs WITHOUT PAM.
Systemd may or may not be added to Slackware. Some people in this forum know that Slackware can run as well WITH systemd as it runs WITHOUT systemd.

The decision is Pat's and if he decides to add anything to Slackware, it will be done in a way that he considers the best for Slackware. That may or may not be the best for individual people in here, but that is entirely beside the point.
This distribution is free to download and use, take that into consideration. You can donate or buy swag at the Store if you care about Slackware and its future, but no one forces you to spend money on it. And Patrick himself has NEVER asked for money in this forum. There is only the sentence in the ANNOUNCE file in every release "You'll feel good, be helping the project, and have a great decorative item perfect for any computer room shelf. :-)"

Now, if all of you care to add more discussion material to this thread, fine, but please refrain from bringing the topics to table that have been beaten to death in this and other threads. And treat each other with respect. You do not get respected unless you also show respect.

If you can not wait for PAM or systemd to get added to Slackware, there is no one holding you back if you want to create your own package repository and maintain that. If it is stable and it fulfills a need, other people will start using it. My own ktown repository, Bart's systemd add-on and Nikki's MLED are good examples of how you can add stuff on top of Slackware without having to create a new distribution. All these package repositories replace several Slackware packages. That is fine, and with slackpkg/slackpkg+ it is even easy to maintain if the repository is setup correctly.

19 members found this post helpful.

it seems you use Slackware at home on a stand alone machine, or even machines
mabye ssh , nfs or smb to some other machine, yes?
of course you never missed PAM
but this is no reason to tell here totally wrong things

4 members found this post helpful.

http://www.linuxquestions.org/questi...ml#post5257973


I am sure that if you have the same "solid" background in car engine mechanics trying to tinker your car engine to make it more flexible will bring a disaster. I only hope you wont ask car manufacturers to stop putting that complex buggy and inflexible thing in their products and make it optional for the customers who need it.


Cheers

3 members found this post helpful.