So, please tell me what features differentiate RHEL from Slackware?

What does it do that Slackware cannot?

What, in your mind, makes it more reliable?

What are these so called Enterprise features?

Why do you believe the marketing?

One thing that Slackware didn't have until now is PAM. I understand that without PAM, you can't have LDAP and that's a bad thing for enterprise servers, which need to be able to accommodate hot-desking.

3 members found this post helpful.

The point is that Linux is Linux. Having the word "Enterprise" in the name doesn't give it some magical attributes...

6 members found this post helpful.

IMHO taking a number of small steps rather than one or a few huge jumps brings less "surprises". In my working life as a support engineer and now as a pensioner I always recommended to keep at least one box up to date and handle the problems if any. So I closely follow Current.

1 members found this post helpful.

yes, but it sounds more sophisticated

And Kerberos authentication.

1 members found this post helpful.

I've got a desktop manufactured in 2012 (ThinkCentre M92P) and a laptop manufactured in 2007 (ThinkPad T60) that are both still going strong with Slackware x86_64 14.2. As long as these machines don't burn out and 14.2 keeps getting patches, I'll be fine until Patrick Volkerding & co. are ready to release 15.

IMO, Slackware still lives up to its reputation regardless of OP's opinion.

2 members found this post helpful.

Would it be as stable as 14.2 out of the box? Because if not it would be very bad for many use cases.

1 members found this post helpful.

To be fair, RHEL is a lot more Enterprise-ready than Slackware. Slackware can be made to work with some extra effort, but RHEL enjoys some advantages:

* There are a lot more sysadmins who know how to make RHEL fill various Enterprise roles,

* Red Hat puts several engineers' full-time effort into making sure RHEL supports the hardware commonly used in Enterprise scale operations,

* While Slackware's official packages are top-notch, third-party Slackbuild quality is a bit hit-and-miss. Most don't get updated regularly, and some Enterprise-relevant packages are only available as third-party Slackbuilds.

* Slackware's documentation is not oriented towards getting Enterprise-type tasks done the way RHEL's is.

* The closest thing Slackware has to kickstart/spacewalk is FAI, which requires more effort to get working.

* RHEL is able to install optional binary packages out-of-the-box, while Slackware requires more configuration.

* Slackware is not as VM-friendly as RHEL.

* Slackware cannot live-patch its kernel (kexec is available, but requires a kernel compiled with CONFIG_KEXEC set, which the last I checked Slackware's weren't).

* RHEL offers turnkey solutions for things like GlusterFS data clusters or high availability database clusters, while with Slackware you have to set up equivalent solutions from scratch.

* Misc little things which are mostly a matter of writing Slackbuilds for the appropriate packages .. I track some of these in http://ciar.org/ttk/public/enterprise-slackware.html

The common thread throughout all of this is that you can totally do Enterprise-stuff with Slackware, but it takes extra effort and you have to figure out how to do it as you go in lieu of official documentation.

On top of that, a company large enough to be interested in Enterprise kind of things will need to hire several system administrators. RHEL-savvy sysadmins are a dime a dozen, and if you want to go all fancy RHEL-certified sysadmins are a dollar a dozen. They're everywhere. Purse your lips to whistle and they'll already be lined up to submit their resumes.

How easy do you think it is to find Slackware-savvy sysadmins? It pains me to say, because I love Slackware dearly, but there just aren't that many floating around.

That having been said, I would use Slackware in an Enterprise environment in a heartbeat. It has its own advantages over RHEL, and all of these disadvantages can be overcome. If management let me donate our solutions back to the community, making Slackware more Enterprise-ready to a wider audience, so much the better.

6 members found this post helpful.

Slackware doesn't offer DKMS (Dynamic Kernel Module Support) out of the box - which is a system to handle rebuilding of external kernel modules (Nvidia, VirtualBox, ...) automagically, whenever your kernel is updated/replaced.

2 members found this post helpful.

These two points seem to be quite vague. Could you please clarify their meaning a little?

I'm a big VM user, and am puzzled by the second point in particular. Slackware in a VM (on VMware ESXi) serves a fundamental role in my office.

Slackware is great, but it is not perfect. We all have desires and expectations about the future of Slackware and I think is good to share the community view of it, so the Slackware team can see what can or want to do about it. I think this might be among the reasons why ktown, csb, slackbuilds and a lot of other great contributions exists.

Personally I would like to:
- have the installer modified so it select an appropriate font size depending on the DPI or something
- have the installer to provide a set of pre-made package templates tags to generate cloud, server, desktop or developer packages, etc.
- improve the web page, update the news section with important changes (like the introduction of PAM, help for testing, etc.), and make the changelog feed visible from the main page
- engage the community to improve the documentation. At least publish the README files as articles in the web
- supporting old hardware is great, but I don't think it should compromise the ability to use modern one
- have a predictable release cycle will be a huge benefit for me, so I can plan when to update, and when I would be able to deploy a feature that requires some library or kernel version
- try to get rid of unsupported software, even if it still works

I do most of these things for myself (to some degree), and some of them are solved by current, which is what I use. Slackware is fantastic for a lot of reasons, and in every decision there are trade-offs which is up to the team, and ultimately to Patrick to make.

Lastly, I don't try to convince anybody, I'm just sharing some concerns I have. They might have no value for most.

3 members found this post helpful.

You may try slackpkg templates. It means, installing a basic system first and then using slackpkg to install remaining packages from a template.
Creating the actual templates for stuff like server/desktop/developer workstation is something the community can pick up and provide through a repository.
For instance, I provide a template to install a digital audio workstation (DAW) package set straight from my own repository (using slackpkg+): http://www.slackware.com/~alien/tools/templates/

I would like to see that too, but Pat always puts other priorities higher on the TODO. Slackware offers RSS feeds for the ChangeLog information though: https://mirrors.slackware.com/feeds/
That is what the Slackware Documentation Project is meant to address. See https://docs.slackware.com/slackware:readmes for instance.

2 members found this post helpful.

Done in a Slint version 14.1.

1 members found this post helpful.

Thanks for posting that. I am retired, this stuff is a hobby now. Back when I was doing enterprise stuff ages ago with HP-UX. I dabbled in RHEL a little bit. That was interesting reading. What are some of those advantages?