Thanks montagdude

That's a dang good summary of why PAM has not been included in Slackware ( PAM is useless for AD Integration without Kerberos and compiling against Kerberos is a complicated mess ).

-- kjh

3 members found this post helpful.

So Kerberos makes a mess. There is enough interest for PAM and Kerberos for there to be support for a project that maintains it. Here is a project that includes PAM: https://github.com/Dlackware/pam If I needed PAM and Kerberos that is what I'd use.

1 members found this post helpful.

That's true, but in a business environment I don't think it's a good idea to rely on a small third-party project like that with no promise of continued maintenance or security updates. At least I wouldn't. (Nothing against the Dlackware guys; they do great work, but that's just the reality. Plus, their goal is to provide the GNOME desktop on Slackware, not an enterprise version of Slackware.)

1 members found this post helpful.

I work as a sole professional practitioner, as a lawyer and translator. I use Slackware for everything, except when I need to do some specialized modification to some PDF files. In such cases I boot my Windows partition.

LibreOffice and Plasma 5 are a must for me.

1 members found this post helpful.

those saying that SBo is not professional or is not suitable for a professional environment because it is maintained by volunteers is quite comical. The vast majority of the GNU/open-source community and just opensource in general consists of people volunteering their time to make the software we all utilize and that includes the corporate world.

Ponder that for a moment. Also, last time I checked the International Space Station runs Debian (non-systemd of course), and funny that, Debian, is well... maintained by a bunch of volunteers from around the world many of which have never met in person.

Kind of squashes that whole concept of whats professional and what is not now doesnt it. Do you really think that RedHat and SuSe only utilize proprietary or corporate controlled software? This isn't Redmond people.

PS: also last time I checked its the sys admin.'s job to maintain his/her box or even 100's of boxes, or are we starting to offshore that responsibility as well. and no this is not taking the thread off course because SBo and SlackBuilds in general are essential to anyone running Slackware or Salix etc...

9 members found this post helpful.

I think a lot of people in this thread have come down rather harshly on a4z. Reading over his comments, I don't see anything he said as denigrating the efforts of anyone at Slackware or working on Slackbuilds.org. Nor did he suggest in any way either were 'not good'. He simply stated why he believes they are not suitable his, and I expect the use cases of many others.

The car I have tuned configured for autocross is street legal. I usually drive it to events. Its exhausting... not the way I'd set it up to use to go buy groceries or commute to work in at all. That does not mean its not a great car, it means its unsuitable for those tasks.

SBo is nothing short of amazing! Everyone who has contributed should be super proud of what they have accomplished. Its been a very useful project for me and I thank everyone involved. This thread was about what is keeping Slackware out of many business environments though and the answers really are the size maintenance expectations of the software library, and authentication/authorization integration.

The ways to address those are:
1) Kerberos + PAM
2) Debian like policies around LTS releases and commitments to patches security updates.

Both of those things have consequences (though i feel 1 is pretty innocuous, even if some disagree) which might make Slackware and its extended ecosystem less useful, or less agile in other ways and for other people. That is fine, that is just a choice its not good or bad and its up to the project leaders to make that choice. Nobody is complaining.

5 members found this post helpful.

ever notice its usually by people not running Slack or they do but want to turn it into something else.

You do realize that Slackware has had LTS releases longer then Debian and supports releases much older as well, right? Also, most of those enterprise distros are issuing updates for holes they created with all of their custom patches.

2 members found this post helpful.

This is a point I made earlier. It's all very well saying RH support their server until 2024, but how many bugs did they introduce to their server OS with the insane rush to integrate barely tested, barely-out-of-beta software?

Another point I made that has not been answered: RH support their server OS until 2024. Do they support nux? Do they support epel? I think the answer to both questions is no. So the same as slackbuilds, then?

And, finally, when RHEL 7 was released 3 years ago, the major components were already old. OpenSSL, for example, upon which so many other components depend. I am curious to know how far RH will be able to go in 2021, 2022 and 2023, to backport fixes to OpenSSL (and others). I am not saying it can't be done; I am just curious to know if it can, and if it's practicable without opening yet another can of worms.

2 members found this post helpful.

Slackware was there first. No kidding. http://www.linuxjournal.com/article/3024?page=0,1 Mar 01, 1999

5 members found this post helpful.

yes, but unpredictable, you can not count on a time. It may, or may not, be updated for maybe so and so long ...
Also, not sure how selective Slackware is, I think is is so that as long as something builds, it is updated, if not, than the update of this component stops. This is usually not an argument you can use in any business.
So that some components of older Slackware releases received some updates does not mean that Slackware supports reliable older releases longer than others[you name it], since this could be a misleading argumentation an shows some technical deficits in understanding LTS support.

1 members found this post helpful.

He is talking about policy, not the years.

I don't think the point a4z brought up was directed at the volunteers, but rather at the lack of any guidance by SBo admins on when updates should be published. Some package maintainers will push out updates as soon as they're available upstream, whether it be a security update or new features. Others will only push out updates when a package breaks. Others will push out updates whenever they think about checking if there's new releases upstream.

I don't say any of this to belittle the SBo project; I am impressed with it and how things are handled. And I'm not using this post to suggest that the guidance be put in place. Overall, I think it works great for most users. But this lack of guidance on package updates do make it difficult for enterprises to know what they're getting into.

With Slackware, once a stable release is put out, updates generally only come to it in the form of security updates or bug fixes. The same can't be said of SBo. You may upgrade a program and it has suddenly switched from a gtk interface to qt and had everything change. Or a new program could've deprecated something that was needed on the older version.

This information shouldn't be taken as a slight towards SBo. SBo was not designed for the enterprise and I don't think they should change to better conform to the enterprise. It shouldn't be taken as an insult that this incredible project, admined by some amazing volunteers, and supported by a massive group of amazing package maintainers isn't "enterprise ready". It's an "everything and the kitchen sink" approach, just like Slackware

Unfortunately, there is no official support schedule for any Slackware versions. 12.0 and 12.1 were EOLd at around their 5 year mark, but 13.0 still has support almost 8 years later. But then Pat could EOL everything 14.1 and below tomorrow. Slackware doesn't list any release to be LTS or not. And we don't know when a release will eventually become EOLd.

As with the above, I don't think this is necessarily bad. Enterprise companies generally tend to be the ones who worry about support life and EOLs, but Slackware doesn't advertise itself to be "enterprise ready". Yes, it would be nice to know how much longer Pat intends to support older versions for those who tend to install a version for a LONG period of time, but until that happens, users will need to be prepared for older versions to be EOLd.

5 members found this post helpful.

in some senes they do, since there are RedHat people contributing to epel and companies rely often on some epel components.
The plan for epel is to be supported as long as RHEL releases.
This is everything somehow soft formulated, and if epel goes away, RedHat can say we never promised you anything.
I think this is more a kind of strategic decision to outsource some parts and have bug reports about these parts on a other location. In reality, if epel would start to become obsolete, or cause to many problems, RedHat would lose customers, that's guaranteed. So there is not too much to worry about, and reality shows already that companies/customers accept this situation.
So I think your answer of no, at least referring to epel, is not totally correct.

Nux is something different since there is/might be also a licensing question for companies. At home on CentOs this might not be an issue, but usin nux packaes at work might, no idea about that.
But these are so few packages, maintaining them self is not an issue if this would ever be required because nux would go away.

You are missing the point.
Nobody said opensource is unfit for enterprise.
We are only saying that not all opensource projects are "enterprise ready".

Debian has very different guidelines for package maintainers than SBO.
They are different things: SBO is a script repository and Debian is a linux distro.
Maintainers in SBO have no obligation to update their scripts, unless it fails to produce a working package. That's it.
Maintainers in Debian are obliged to update their packages in case there is a version bump that squashes a serious security related bug.
A company can rely on Debian. Not so much on SBO... <-- again: this is not to say SBO is not great! Don't kill me!

Again, you are missing the point.
Opensource in general is "enterprise" agnostic (as is all software).
I would not trust my company's fate to closed source software if it was not maintained correctly.
This is not a "opensource is unfit for enterprise" discussion and nobody here said as much.

For some of us, Slackware fits perfectly in our professional lives and for some it doesn't.
We slackers that think it doesn't are just explaining why and what we wish it did differently.

Again *sigh* nobody stated otherwise.
We are just saying that administering 100 Slackware boxes is significantly harder and more time consuming than other "enterprise ready" distros out there.
Maintaining 1500+ packages (just security patches alone, never mind new features) like kikinovak did is no walk in the park, and eventually became unmanageable for him.

Fact is: every company (and their sysadmin) has different requirements and Slackware is a good fit for a minority only.
The stated goals of Slackware are not "be enterprise ready".
It is a very nice learning tool and an excellent base system that can be expanded to do anything from server to desktop.
Unfortunately, it is a lot of work to expand the "base" system to what is needed in a company (my view. others may differ).
SBO helps expanding it and is fine for personal use, but is not predictable enough for professional use (again, my opinion).
Third party repositories are the way to go, but that requires skilled and driven package maintainers (not easy to maintain a big repo). I'd trust most of them for personal use, but only a few for a company.

5 members found this post helpful.