Originally Posted by montagdude

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.)

Originally Posted by kjhambrick

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

Originally Posted by Gerard Lally

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.

Originally Posted by 55020

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

Originally Posted by ChuangTzu

I believe its in Russian

Originally Posted by bassmadrigal

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.

Originally Posted by Slax-Dude

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.

Originally Posted by slalik

Sounds like Bulgarian

Originally Posted by ChuangTzu

Yet many desktops in US gov. (know from personal experience) run Slackware for workstations and especially for development.

If we use your criteria above, then lets apply it also to CentOS official repos, not EPEL, nux etc....

Originally Posted by upnort

Interesting. Would you please provide some validation?

Originally Posted by bassmadrigal

Just as there's no update guidelines for SBo. That doesn't mean that some maintainers won't try to push security updates as soon as they are aware of them... just that there's no mandate by the SBo admins to do so.

Originally Posted by a4z

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.