2 non native speaker :-)

what I mean is, there are several attempts of building PAM packages.
This is a waste of resources, there should be only one, this one from Slackware.
Resources could be better used for ConsoleKit problematic and similar, this would help Slackware more then not putting PAM in

does anyone know how many software would build different when PAM is available?
add features when configure/cmake/.. detects PAM.
multilib effects I think 0. so does meld, and ktown.


to me it seems tat the argument that we are not that longer so special when we do add PAM is exactly the main reason why we do not have PAM.

Make that 3.

Amen to that. On the latest count, we have four different experimental third-party projects.

We already have ponce's view on that. It would be interesting to hear some Slackware core team member's take on this, or even better, what does the BDFL himself think about this subject?

I don't know the reason, I think only vbatts can understand this question, I can only suppose that maybe it's because they probably needs more testing.

but as the target of the eventual push upstream is -current, they probably need and should be tested there: don't really want to force anybody but, IMHO, there shouldn't be any blocking problems for seasoned Slackware users to run -current on some testing servers and clients; then, as obvious, everybody must go the way he think it's the best for him.

I have no idea why people started parallel projects after vbatts started his own, maybe because they had different needs? surely they can answer better...

an awful lot, and it will be not practical at all to add as an option: things changes (and a lot) if it's there or there isn't and work to test this stuff would be huge. To whoever thinks this is a feasable way to follow I suggest to try it: just install one of the PAM implementations, fork SBo's repository, test this and report back, if you have managed to keep sane enough in the meantime.

basing on the report we got on SBo, there are some effects (that doesn't mean that personally I would not like to see it in too).

I don't think so: IMHO the reason is that what we have has been so well tested that anything else in comparison is a shot in the dark.

4 members found this post helpful.

Ah, we (me & the Oxford Dictionary) got it wrong.
Sort of, anyway. Clique might have been better.

and therefore it is not acceptable to work with 3rd party packages and why it has to be part of the system.
and it is easy to turn the game, those who not want PAM can replace packages.. at least than you get instance feedback when something is not working instead of something with limited functionality that you possible recognise to late.
(beside the fact that in reality we can do nothing and it is on PV to do something or not, but possible a statment would help some people improve their future planing)

At the time of writing, 93 poll responses after 2743 views, a response rate of 3.4%.
Votes in favour of including PAM, 40 from 2743 views, a pro vote of 1.5%.

I interpret that to mean that people needing PAM are having their needs met elsewhere.

Bayesian statistics would suggest the probability of PAM appearing in Slackware is very low.
My feeling is that the appearance of PAM in Slackware is more likely to be to be related to whether software can be compiled and run successfully, rather than with meeting some perceived need. I consider that calling out to our BDFL to pontificate on the grounds of "future planning" when the absence of PAM in Slackware is a long established fact is very disrespectful.

The lack of PAM is often touted as evidence of the pejorative "Slackware is a hobbyist distro", but I say "vive la difference".

I will not be voting in this poll as I consider it a "push poll".

2 members found this post helpful.

-PAM is for enterprise things
-enterprise needs only a specific set of packages

i don't like telling people what to do, but five(idk) of you can make and maintain that 50-some slackbuilds
didn't check but it's probably just one line in ./configure (no?),
so updating them comes down just mass applying `patch on slackbuilds (more or less)

<satire_mode_on>

At the time of responding, 2783 views and 44 votes against the inclusion of PAM. 1,18 % of Slackware users are opposed to PAM, which means that 98,82 % of Slackware users are not explicitly opposed to the inclusion of PAM

I interpret this as fuck yeah let's include PAM.

<satire_mode_off>

4 members found this post helpful.

based on what i saw:
42 (43.75%) -> yes
33 (34.38%) -> no
21 (21.88%) -> the rest

i believe there are other who don't vote as well

2 members found this post helpful.

I remember a few years ago blogger Caitlyn Martin started a real flamefest in this forum by daring to call Slackware a "hobbyist" distro. That was the exact word she used, and which provoked the wrath of many a Slackware user. Of course her temperament didn't help things, but that's a different problem.

Upon reflection, maybe I should have started a poll from a completely different angle. The question being: should Slackware include Enterprise stuff? I mean things like this for example.

What I see here is a sad waste of potential. There are so many arguments for using Slackware in business environments: the reliability, the extended support period (compared to openSUSE, Fedora and even Debian), the relative low-risk character of updates for stable releases, etc.

I understand very well that you don't need all that stuff if all you do with your Slackware box is block the door of your wooden cabin during snowstorms. For mysterious reasons, some users seem to lodge the mere word "enterprise" in brain regions next to "waiting line" or "wisdom tooth extraction". Go figure.

1 members found this post helpful.

18-04-13, 01:41:06-12-10, 20:50: 21-02-13, 03:43:I won't draw any conclusion and can bring neither personal opinion (by lack of), nor forecast: it's too hard to interpret expressions like "eventually" or "immediate future" when typed by Slackware's BDFL

2 members found this post helpful.

don't forget the vanilla-ness

as i learn more and more about linux, computers and about the "enterprise" "solutions" i grow only more and more sure about one thing
it's all... i'l be polite and shut up now

anyway i heard of this project to make enterprise ready slackware
it's called MLED or something, idk


also how did you know i'm planing when i grow old to make a wooden cabin and heat it with bitcoins ?
have you been reading my mind ?
where's that foiled hat of tin

2 members found this post helpful.

MLED is merely a collection of add-on packages for a complete out-of-the-box Slackware+Xfce desktop. It's still vanilla Slackware under the hood, and it has nothing to do with the topic at hand.

Niki, you have experience with MLES right?
What if you start a MLES-like project with a purpose of providing enterprise service on top of Slackware?
This way, you can do many experiments with PAM.
If many people gets interested with your project, more and more feedback will be gathered to make it more reliable.

This is what GSB has done in the past. They even made changes to the core packages in order to have a full GSB installation on top of Slackware, but that's fine as long as it's stated in the documentation.

Your project can be a valuable input to Pat if it's deemed to be stable and enough testing has been done by real users who do need those services.

2 members found this post helpful.

I gave that much thought, of course. Currently, my own MLES is really only a placeholder name for "all the server stuff that's not shipping with Slackware", e. g. Postfix, Dovecot, Postgrey, Squid, SquidGuard, SquidAnalyzer, Icecast, ... I'm not sufficiently competent with all the low-level stuff like PAM to make it work in a usable way. And since I'm running a one-man-company, I would probably need weeks if not months of free time with nothing else to do to produce something usable.

I suggested to both vbatts and ivandi to work together on this, but got no response. So I decided to launch this poll.